I am unable to receive calls from any number to my VoIP number. I am using GoIP 4 (GSM over IP). Device details are following:
Firmware Version: GS-4.01-96
Module Version: M35FAR02A01_RSIM
Software Name: EasyPhone
Call In settings:
User No Input Timeout(s): 60
CID Forward Mode: Use CID as SIP caller ID
CID Prefix: Null
Channel: CH1
Call IN via GSM: Enable
Forwarding to VoIP Number: 3333
Dial Plan: Null
GSM Call Waiting: Disable
Hunt Group Mode: Disable
Auto Incoming Call Block: Enable
In a simple way, my question is how to configure GoIP 4 to receive calls and forward to VoIP number?
Kindly help me to configure it with the right way.
Thanks.
Firstly, Check your GOIP status if the VOIP is showing "Y", If it is, then go to the Call in setting.
Your dial plan should be ";" instead of none, disable your Auto Incoming Call Block, and in your Inbound Route in elastix, let your DID be your extension no.
Call in setting:
User No Input Timeout(s): 60
CID Forward Mode: Use CID as SIP caller ID
CID Prefix: Null
Channel: CH1
Call IN via GSM: Enable
Forwarding to VoIP Number:Ur extension No
Dial Plan: ;
GSM Call Waiting: Disable
Hunt Group Mode: Disable
Auto Incoming Call Block: disable
Related
Using Siemens Logo!Soft Comfort, I want to connect a Siemens Logo! (8) with pymodbus
Settings on a network input on siemens soft comfort (I also tried Unit ID 255 and Modbus Type "DI" (Digital input))
Pc Settings, (I have tried both Interfaces)
Pymodbus code:
import time
client = ModbusTcpClient('192.168.0.3')
print(client.connect())
while True:
time.sleep(1)
print(client.write_coil(1, True))
time.sleep(1)
print(client.write_coil(1, False))
The output:
True
Modbus Error: [Input/Output] [WinError 10054] An existing connection was forcibly closed by the remote host
Modbus Error: [Input/Output] [WinError 10054] An existing connection was forcibly closed by the remote host
There are two ways to connect to the Logo via PC, either with the Logo acting as a Modbus server or a Modbus client.
LOGO! as a Modbus server:
Add a server connection:
Leave the options completely empty:
You should then see a little yellow socket at the bottom of the logo:
No further configuration is needed (the Diagram Editor can be left empty)
Push this configuration to the Logo:
Send modbus-tcp-messages to the Logo, as described in the original post. The coils to target are described in the Logo!-Settings (they start at 1, while pymodbus starts at 0, so you need to subtract 1:
So if we want to turn on the Q1:
from pymodbus.client.sync import ModbusTcpClient
client = ModbusTcpClient('192.168.0.3') # Default port is 502
client.write_coil(address=8192, value=True) # Default unit_id is 1
LOGO! as Client
Add a Client connection:
Enter the values you want to read:
Run a modbus server, see Documentation
I'm using Plugin.BLE to iterate a bluetooth device's services / characteristics / descriptors. When I find the descriptor I'm looking for, I try enabling notifications by writing 02-00 into the descriptor. This works for Android devices but on iOS, I get a an error:
Objective-C exception thrown. Name: NSInternalInconsistencyException Reason: Client Characteristic Configuration descriptors must be configured using setNotifyValue:forCharacteristic
The offending C# code looks like:
await descriptor.WriteAsync(new byte[2] { 02, 00 });
Is there a different way on iOS devices to enable notifications?
It is apparent that this is one of those platform specific issues that will have to be refactored out into an interface / platform-implementation pattern. So for the iOS version of the application, in order to do the above, I had to write against CoreBluetooth. Once you have your device / service / characteristic / client configuration descriptor, you call the following:
peripheral.SetNotifyValue(true, characteristic);
After setting that value, a callback is issued to the peripheral delegate:
public override void UpdatedCharacterteristicValue(CBPeripheral peripheral, CBCharacteristic characteristic, NSError error) { }
From there I was able to continue what I was doing before.
I'm using nObex on Windows to create a Obex connection to an android phone over bluetooth. As library I'm using nObex https://github.com/nccgroup/nOBEX
AF_BLUETOOTH is under windows not available, whereas I'm using pybluez to create the connection.
Authentication works fine, on the phone I have to accept that I get access to the file system. When I'm trying to create the OBEX connection:
b'\x80\x00\x0e\x10\x00\xff\xffF\x00\x071106'
|opcode for connect = 0x80| length = 0x000e|obex version = 0x10 = 16| flags = 0x00| max obex message length = 0xffff| length header = 0x0007| profile = 1106
I'm getting the following response:
b'\xc6\x00\x0c\x10\x00\xff\xfe\xcb\x00\x00\x00\x01'
\xc6 = 198 is the flag for "HTTP Not Acceptable"
Does anybody understands, why I'm not able to get a connection?
For MAP and FTP Profiles the target ID must be added. I used for this the UUID which is wrong.
The target ID for the Message Access service (MAS) can be found in the MAP document (https://www.academia.edu/32372957/MESSAGE_ACCESS_PROFILE) on page 64
I am trying to setup an iot-edge device as an edge gateway. We wouldn't want our leaf/sensor/downstream devices directly connecting to the internet/cloud, and thus I would expect the iot-edge-gateway(as it name suggests) to bridge the connection between downstream devices and the cloud/iot-hub. However, I realize that the connection string for iot-hub/edge at any device level is simply
connection-string-for-iothub-with-gatewayhostwayAppended
This makes me assume that downstream devices transmit messages to an endpoint (prolly messages/* )to cloud/iot-hub and it is from there that gateway gets it(works with that data maybe then) and forwards it back to the $upstream, which shuns the whole point of a gateway.
Here in the message routing section of IOT-EDGE-GATEWAY
https://learn.microsoft.com/en-us/azure/iot-edge/how-to-create-transparent-gateway, in the ROUTE MESSAGES FROM DOWNSTREAM DEVICES section
{
"routes":{
"sensorToAIInsightsInput1":"FROM /messages/* WHERE NOT IS_DEFINED($connectionModuleId) INTO BrokeredEndpoint(\"/modules/ai_insights/inputs/input1\")",
"AIInsightsToIoTHub":"FROM /messages/modules/ai_insights/outputs/output1 INTO $upstream"
}
}
makes it sound like the gateway is routing messages falling on the built-in-endpoint(Default) to $upstream. I can't find any other clearer documentations over the web on this subject. I would really appreciate if someone clears this up. I was expecting the connection string for edge-gateway(that i'd mention in the device end to be something along the lines of localhost:port and not cloudaddress+gatewayhostname)
If your connection string contains a gateway hostname - and the SDK you are using on the device properly handles this, the device only connects to the gateway, not to the IoT Hub.
You can see the example from the .NET SDK here:
this.HostName = builder.GatewayHostName == null || builder.GatewayHostName == "" ? builder.HostName : builder.GatewayHostName;
https://github.com/Azure/azure-iot-sdk-csharp/blob/f86cb76470326f5af8426f3c2695279f51f6e0c8/iothub/device/src/IotHubConnectionString.cs#L30
If the gateway hostname is set, it actually overwrites the IoT Hub hostname for the connection.
I want to test the QoS of the MQTT protocol. I use aedes as my broker.
For testing QoS 2, one of the test cases I'd have to evaluate, is to run a scenario where once a message is published by the client, the broker forwards it to the subscriber who receives the message but the acknowledgement(tcp) and/or the pubrec(mqtt) are not received by the broker. By running such a case, I check that the message is not received twice by the subscriber.
So my plan is, once a message is published by the client to run aedes.authorizePublish broker-side and set a sleep for a couple of seconds and in the meantime to block the IP of the subscriber on the used port(1883).
Have tried:
netsh advfirewall firewall add rule name="IP Block" dir=in
protocol=TCP interface=any action=block remoteip=172.30.10.120
localport=1883
So I expect that the broker will publish the message to 172.30.10.120(subscriber) and that no packets from subscriber should be received by the broker until I invert the netsh command with
netsh advfirewall firewall delete rule name="IP Block" remoteip=172.30.10.120.
This is the code that runs the aedes broker:
mqttBroker.authorizePublish = function (client, packet) {
if (packet.topic === 'hello' && client.id === '01B4C') {
let PACK = packet;
setTimeout(function (packet) {
mqttBroker.publish(PACK)
}, 10000)
}
}
So I expected to get packets like that:
Packets when I remove eth cable from subscribed client
But the packets from the image above are the ones I get when I simply remove the eth cable from my subscribed client and put it back in.
The packets I get from the procedure with the netsh commands are:
Packets when I block the ip from subscribed client, only the direction to the broker
My questions are:
Is this a good way to test MQTT QoS like that?
How can I simulate this scenario in an automated way where no cables are removed, of course, and I block one way of the connection?
Thanks in advance
P.S. Beginner programmer..