I notice with the new firmware I now have a user defined digit map labeled ipd. I also note that the default ITSP digit maps include this |(Mipd)|.
What is this all about and why do I need it? I have an old dialplan from my PAP2 that I have been using on the OBi110. It works fine. Do I need to include the |(Mipd)| in it?
User Defined DigitMaps are a nice way to keep from having to maintain multiple copies of the same DigitMap. For example, I use the following Digitit Map on ITSPA, ITSPB, Trunk Group 1, and several Voice Gateways:
(1xxxxxxxxxxS4|<1>[2-9]xxxxxxxxxS4|<1870>xxxxxxxS4|011xx.|xx.|(Mipd)|[^*]@@.)
Rather than duplicate it numerous times in all those places, and worse, have all those places to edit if I want to make a change to it, I put it in a User Defined DigitMap named 'ste' (Seven/Ten/Eleven). Then I can simply reference it using (Mste) from all the places I want to use it.
'ipd' is a DigitMap for doing IP Dialing. It supports dialing a SIP URI using an IP address:
1234567890@127.0.0.1:5060
can be dialed from a phone using
1234567890*127*0*0*1*5060
Thanks for the reply Ron.
----
I think I have discovered a bug in the web portal expert config. When I enter a user defined digit map and press the save button, the web page jumps back to the dashboard and does not save anything. The other pages work right. It just happens when I try to save a user defined digit map.
This bug has been fixed already. You may try save it again.
Thank you for pointing it out.
OBi Support Team.
It works. THANKS!
RonR.
Is there any echo test in term of IPs such that we can use them for testing using IP direct dialling method?
Thanks
YH
Quote from: yhfung on March 29, 2011, 04:02:40 PMIs there any echo test in term of IPs such that we can use them for testing using IP direct dialling method?
I thought this would be an easy question to answer, but in verifying what I was about to say, I think I've discovered some problems with IP dialing in the OBi.
There's an echo test at iNum : 883510000000091@inum.net
Calling this URI from a Voice Gateway (as described here : http://www.obitalk.com/forum/index.php?topic=526.0) works reliably EXCEPT the first time after a reboot. [The first time, the OBi reports there was no respose from the service provider.]
Calling this URI from a Speed Dial : SP2(883510000000091@inum.net) : works reliably EXCEPT the first time after a reboot as described above.
Calling this URI from a Speed Dial : SP2(883510000000091@91.121.72.17) : fails reliably with the OBi reporting there was no respose from the service provider.
Dialing this URI from the telephone keypad : 883510000000091*91*121*72*17 : fails reliably with the OBi reporting there was no response from the service provider.
Mixed in with the failures are sporadic reboots.
This is with a SIP provider on SP2/ITSPB and PrimaryLine = SP2.
With PrimaryLine = SP1 (Google Voice), IP dialing from the phone keypad is sent to Google Voice.
I also tried changing SIP providers on SIP2/ITSPB, but the results were unchanged.
yhfung,
Can you reproduce the failures I described in the previous post?
Quote from: RonR on March 29, 2011, 07:05:34 PMCalling this URI from a Speed Dial : SP2(883510000000091@inum.net) : works reliably EXCEPT the first time after a reboot as described above.
Calling this URI from a Speed Dial : SP2(883510000000091@91.121.72.17) : fails reliably with the OBi reporting there was no respose from the service provider.
Dialing this URI from the telephone keypad : 883510000000091*91*121*72*17 : fails reliably with the OBi reporting there was no response from the service provider.
This is with a SIP provider on SP2/ITSPB and PrimaryLine = SP2.
Obihai Support Team,
Any chance you can see if you can reproduce these failures?
Thanks
obi-support2,
Care to comment?
Thanks,
Ron
RonR,
I can reproduce all the cases, including the reboot issue.
For the inum.net case, I cannot explain why the 1st call does not work, but subsequent ones work yet. Still looking at it. Could be a bug on the OBi.
For the IP dialing case, I suspect this is not acceptable by inum. That is, they expect to see a domain in the INVITE Request-URI, perhaps. Unless you can test this case successfully with another device or softphone (make sure the INVITE request-uri is showing the IP address for a fair comparison w/ OBi).
I can trigger unit to reboot when trying a few failed calls (no response from server) back to back. The OBi may have an issue handling multiple outstanding un-replied SIP INVITE requests. I have filed a bug for it.
Thank you for reporting the problems.
Quote from: obi-support2 on March 31, 2011, 04:46:11 PMFor the IP dialing case, I suspect this is not acceptable by inum. That is, they expect to see a domain in the INVITE Request-URI, perhaps.
At first glance, that would appear to be the case. I have a request into iNum to investigate this.
I studied this some more and may be able to explain your observation:
In fact, using IP address in Request-URI is not a problem for inum.
However, the domain inum.net resolves to the IP address 91.121.72.17 (using DNS A Record), which I believe is NOT running any SIP service (not at port 5060 anyway). That server replies ICMP error to the INVITE sent by the OBi. Hence all your IP calls to that address failed.
On the other hand, the domain sip.inum.net resolves to 81.201.82.25 (using DNS A Record), which is running proper SIP service. This server accepts the INVITE from OBi and everything works. So if you dial this IP address, it will work every time. If you replace inum.net with sip.inum.net in your speed dial, it will work every time also; including the first time after reboot.
--------------
Now the interesting part, why using inum.net will fail the first time, but works for subsequent calls? It turns out that if you do DNS request with the name _sip._udp.inum.net as a DNS SRV record, DNS Server actually returns the correct hostname sip.inum.net which has the proper sip service running. Then a subsequent DNS lookup of sip.inum.net will produce the correct server IP address, etc.
When OBi looks up a SIP server domain (inum.net in this case), it will try DNS A, DNS SRV on the same domain, and DNS SRV on the same domain with _sip._udp. prepended, in parallel. In this case, the DNS A record comes back with a successful result (although it is not the correct server) first, so the device takes that address and fires the INVITE right away. Hence the first call fails.
A little later the DNS SRV record also comes back with a successful result. And this time it has a correct server address. This new result overwrites the last record and the OBi remembers it internally. Hence subsequent calls are successful.
We should be able to do something to improve this.
obi-support2,
Great detective work! I did a Google search on sip.inum.net and didn't find a single hit in the first 5 pages. Every reference everywhere is to @inum.net. It appears iNum is assuming everyone is using DNS SRV records. I retested everything here and it works as you predicted.
Thank you very much,
Ron