User defined digit map ipd. Why do I need it?
obi-support2:
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.
RonR:
Quote from: obi-support2 on March 31, 2011, 04:46:11 pm
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.
At first glance, that would appear to be the case. I have a request into iNum to investigate this.
obi-support2:
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.
RonR:
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
Navigation
[0] Message Index
[*] Previous page