Using OBi Voice Gateways with SIP Providers
obi-support2:
It is correct that release 1.2.2101 removes the NAT support for SIP Gateway calls and URL calls. This includes using local IP address/port for Contact and RTP in the outbound INVITE, as well as not using STUN and ICE, regardless settings of SP1/SP2 service.
The logic for this decision is to make SIP Gateway Calls and URL calls less dependent on the behavior of the main service on SP1 and SP2. We expect most uses of SIP Gateway and URL Calls are in cases where:
1. Called URL is on the same subnet
2. Called URL, if it is an ITSP, would have infrastructure (like an outbound proxy) to
handle NAT traversal.
We recognize that there are still valid cases where NAT support may be required. I have put in a request to see if an option can be added in a future release.
Meanwhile, port forwarding on your router would be a good work around if have access to it.
You will need to port forward the SIP Port on SP1/SP2, and also the entire RTP Port Range in the underlying ITSP Profile.
RonR:
Quote from: obi-support2 on March 31, 2011, 05:12:34 pm
We recognize that there are still valid cases where NAT support may be required. I have put in a request to see if an option can be added in a future release.
obi-support2,
Might I suggest you carve out your low-level SIP support routines such that they are generally callable from not only SP1/SP2 but also directly from the Voice Gateways, SIP URI's and IP Dialing, so they don't rely on having a SIP provider already configured on SP1/SP2. It's a real shame you can't have Google Voice on both SP1 and SP2 and still use Voice Gateways, SIP URI's and IP Dialing for SIP calling, when the code is just sitting there.
I would also suggest you use a notation of SIP(URI) instead of SP1/SP2 for Voice Gateways, Speed Dials, etc. and that IP Dialing assume the same. None of these should be tied to SP1/SP2 or PrimaryLine.
oleg:
Hi obi-support2,
Thank you for the response. Unfortunately port forwarding on the router does not help. I have dd-wrt Linux Kernel 2.4 based router which probably does the best for SIP, in particular it always assigns the same internet port number for outgoing packets as local port number (and of course I have SIP and RTP ports on router mapped to OBi device). Said that, two problems remain and I can confirm them (either running tcpdump or syslog on both sides):
- "Contact" header in "200 OK" was sent with local network IP (local port was equal to internet port), which caused ATA on other side to send undeliverable ACK (sent to my local IP). As result OBi was not able to establish connection.
- INVITE contains local IP for RTP data and ATA on other side may direct RTP stream to unreachable local IP. That resulted in one way audio. Many providers can recognize local IP and direct RTP stream "symmetrically" (than it works), but this is not the case for many ATA devices.
Please (please!!!!) consider employing STUN for outgoing calls. If you have doubts - add it conditionally, based on settings, that's fine. It will greatly improve connectivity and therefore usability of OBi device.
P.S. I second RonR's suggestion to separate SIP URI calling from SP1/SP2. Fully functional SIP URI calling independent from SP1/SP2 would be just great. The device would support up to 3 simultaneous registrations on SP1/SP2/OBiTALK and quite a big set of SIP URI destinations without registration. That's the dream device!
Regards,
---oleg
MichiganTelephone:
I realize this thread is a bit dated but I just wanted to add three points:
First, I also experienced one-way audio on inum calls, but not on Sipbroker calls. I have no idea why it should be different between the two, but it is. I didn't make any effort to resolve that because I never use inum anyway. My firmware is 1.2.1 (Build: 2103).
Second, on Sipbroker calls, it was sending "unknown" for the Caller ID. I found that if you put a regular phone number (I do suggest including the country code, but I think it will take any number) in the AuthUserID field of the Voice Gateway6 settings, it will send that as the Caller ID number, or at least that worked on a couple of test calls that I tried.
Third, when using Sipbroker I could not use the # key to indicate the end of the number because it appears the device considered the # part of the number dialed. But if I add timeout values (such as S4) to the DigitMap then the # key works as it should:
(<*>[x*][x*].S4|*[x*][x*].S4)
N7AS:
RonR,
In your origional post, you can use Voice Gateways with SIP providers...
Can this be done if I have 2 GV accounts sp1 and sp2? sp1 is primary. I have quite a few GV accounts that I would like to add to the OBi110 if it's possible.
Navigation
[0] Message Index
[#] Next page
[*] Previous page