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]

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.

[RonR]

NOTE:  You must have at least one SIP provider already configured on the OBi using SPx/ITSPx.

It's a real shame, seeing as how all the code to handle SIP providers is sitting there, but you can only use SIP providers on Voice Gateways (and with considerable limitations) through an existing SP1/SP2 Service that's configured with a VoIP provider.

Google Voice accounts cannot be added though Voice Gateways.

[GizmoChicken]

You missed a major restriction the OBi developers placed on using Voice Gateways with SIP:
NOTE:  You must have at least one SIP provider already configured on the OBi using SPx/ITSPx.

Any thoughts on WHY the OBi developers placed this restriction on using Voice Gateways? 

As I've posted elsewhere:

I don't understand the need for the "SP1" and "SP2" preceding the target service.  As posted by another, this seems to imply that either "SP1" or "SP2" must be a SIP service.  That is, gateways won't work if BOTH "SP1" or "SP2" are attached to Google Voice accounts.  I can't understand why this limitation has been imposed. 

I suppose I could sort of understand why a voice gateway may require setting a "SIP signalling protocol" and why it might be easier to do that by referring to "ITSP Profile A" or "ITSP Profile B" rather that specifying the protocol (and/or other parameters) for each voice gateway.  But IF that's the case, why not adjust your code so that something like the following configurations could be used: ITSP-A(sip.xyz.com:5081) or ITSP-B(192.168.15.118).

Am I way off base?

[RonR]

You missed a major restriction the OBi developers placed on using Voice Gateways with SIP:
NOTE:  You must have at least one SIP provider already configured on the OBi using SPx/ITSPx.

Any thoughts on WHY the OBi developers placed this restriction on using Voice Gateways?

Using the OBi Voice Gateways with SIP providers was an after-thought.  The SIP support code in the OBi was apparently not written in a manner for general use, and rather than reorganizing it such that it could be, SIP support through Voice Gateways was quickly shoe-horned in as a piggy-back operation on SP1/SP2, with a lot of limitations as a result.

[JamesC]

Hi All,

Quick question here. If a voice gateway uses the sp1/sp2 interfaces to call out, would the sp1/sp2 affect the quality?

I have the below settings on my Obi110
sp1 : Google Voice (for free in/out US calls)
sp2 : sipgate (For free backup incoming calls)
vg4 : sp2(callcentric.com)

I've always heard about great quality of Callcentric, but would the fact that it is run through sipgate be a quality factor? Not saying sipgate does not have great quality, just wondering about the relation.

Thanks

[RonR]

Hi All,

Quick question here. If a voice gateway uses the sp1/sp2 interfaces to call out, would the sp1/sp2 affect the quality?

I have the below settings on my Obi110
sp1 : Google Voice (for free in/out US calls)
sp2 : sipgate (For free backup incoming calls)
vg4 : sp2(callcentric.com)

I've always heard about great quality of Callcentric, but would the fact that it is run through sipgate be a quality factor? Not saying sipgate does not have great quality, just wondering about the relation.

Thanks

It's not actually being run through Sipgate.  It's being piggy-backed on the support for SIP that's configured on SP2, but the actual communications is with CallCentric and not Sipgate.

There are some considerations that might affect CallCentric operation:

Note that when using a SP trunk to access a (SIP) gateway, the device will:
- Not use the outbound proxy, ICE, or STUN regardless the settings on the SP trunk.
- Use only the device's local address as the SIP Contact, and ignore any natted address discovered by the device.
- Use the gateway's SIP URL to form the FROM header of the outbound INVITE.
- Use the gateway's AuthUserID and AuthPassword for authentication.
- Apply the symmetric RTP concept.

If I were you, I'd temporarily configure SP2 for CallCentric instead of Sipgate and find out what, if any, trade-offs there are in using the Voice Gateway instead.

[GizmoChicken]

Using the OBi Voice Gateways with SIP providers was an after-thought.  The SIP support code in the OBi was apparently not written in a manner for general use, and rather than reorganizing it such that it could be, SIP support through Voice Gateways was quickly shoe-horned in as a piggy-back operation on SP1/SP2, with a lot of limitations as a result.

Thanks RonR.  I hope OBi will eventually reorganize the code to remove these limitations.  Or better still, I hope OBi will just allow for more SP accounts.

[JamesC]

Thank you RonR!

Using Callcentric through vg4 has provided superb quality these pass few days. I can't tell the difference in quality configuring it as SP1 or VG4. Now I could start filling up the other voice gateway slots!
The weird thing is that while localphone and callcentric works well as a VG, I never got voxalot or iNum to work. The Rx stream is always 0. Would it be something to do with disabling G711 codecs?

Thanks

James

[RonR]

I never got voxalot or iNum to work. The Rx stream is always 0. Would it be something to do with disabling G711 codecs?

I don't have any problem with either Voxalot or iNum and G711U.  Voxalot uses a blend of Asterisk and OpenSER (I think that's the other half) and has always been a bit prone to RTP issues for many.  I'm glad to hear LocalPhone and CallCentric do well on Voice Gateways.

[GizmoChicken]

Using the OBi Voice Gateways with SIP providers was an after-thought.  The SIP support code in the OBi was apparently not written in a manner for general use, and rather than reorganizing it such that it could be, SIP support through Voice Gateways was quickly shoe-horned in as a piggy-back operation on SP1/SP2, with a lot of limitations as a result.

Thanks RonR.  I hope OBi will eventually reorganize the code to remove these limitations.  Or better still, I hope OBi will just allow for more SP accounts.

Just to reiterate the situation, when SP1 and SP2 are BOTH configured to work with Google Voice (GV) accounts, we are NOT able to use the outgoing SIP "Voice Gateways" feature.

In the "Feature Requests" section, I requested OBi to eliminate this limitation so as to allow using the outgoing SIP "Voice Gateways" feature even when SP1 and SP2 are BOTH configured to work with Google Voice (GV) accounts.  If you support (or oppose) this request, please comment here:

http://www.obitalk.com/forum/index.php?topic=751.0

[daibaan]

Anybody tried to configure onesuite VoIP service on voice gateway?

I was able to configure onesuite on SP1 (GV on SP2) and use it to make outgoing call.  I have also successfully configure sipgate, callentric, callwithus, whistlephone on VG and callout via SP1.  However, when I configure onesuite on a VG, outgoing call simply fails, Obi complains that server does not respond.

Anyone got an idea?

[RonR]

Does OneSuite support calling without SIP registration?  If OneSuite requires SIP registration, you won't be able to use it on a Voice Gateway.  You will also need a SIP provider provisioned on either SP1 or SP2 in order to be able to use a SIP provider on a Voice Gateway.

[daibaan]

I am not sure if onesuite requires registration or not, but I have always enable registration on onesute connection, and that is how X_RegisterEnable in ITSP Profile A (used by SP1) is set.

However, you just reminded me that since I AM using onesuite as SP1 - with registration enable, that may have interfere  with the onesuite VG call using the same SP1 config? maybe I should change SP1 to sipgate  (which is actually the ultimate goal, because I want to use sipgate to provide a backup dial-in number) first and try the onesuite VG again. will get to it tonight

Thanks RonR

[daibaan]

Problem solved with 1.2.1 (Build: 2283)

First, I have verified onesuite.com does not require registration.
Second, one thing a little strange about onesuite.com is the username format, the username for user "sam" is in the form of "sam-voip.onesuite.com" with proxy "voip.onesuite.com", so the fully qualified name would be "sam-voip.onesuite.com@voip.onesuite.com", this cause some SIP software/broker to be confused.

However, without changing any config, once the new 2283 firmware is loaded, the onesuite.com VG works like a charm, that is good enough for me I am happy now

[daibaan]

Firmware Release 1.2.1(2283) has been posted. One enhancement includes is the
addition of options to support NAT traversal for SIP Gateway and URL calls
on SP1/2: You can now append the following URL parameters to each speed dial and
SIP Gateway VG1-4 access number, separated by ';',
   - ui=userid[:password]   //ui=user-info, password is optional
   - op=[m][n]          //option flags, i=ice, m=symmetric-rtp,
                                    //n=use-natted-address, s=stun

Thanks for the info, 2 questions regarding these enhancement:

Does the "ui" option overlaps the "AuthUserID/AuthPassword" options for VG? or vise versa?
Why is this options limited to VG1-4? can these options not be used for VG5-8?

[obi-support2]

Firmware Release 1.2.1(2283) has been posted. One enhancement includes is the
addition of options to support NAT traversal for SIP Gateway and URL calls
on SP1/2: You can now append the following URL parameters to each speed dial and
SIP Gateway VG1-8 access number, separated by ';',
  - ui=userid[:password]  
        user-info, password is optional
  - op=[ i ][ m ][ n ][ s ]
        option flags, i=ice, m=symmetric-rtp,
        n=use-natted-address, s=stun

Examples:
  SpeedDial = sp2(1234@sip.inum.net;ui=1000:xyz;op=sm)
  VG1-8 AccessNumber = SP1(sip.inum.net;user=1000;op=imns)
  Note that if userid or password is specified in VG1-8 AccessNumber,
  it overwrites the settings in    AuthUserID, and AuthPassword in the VG.
  If stun disabled in the main SP, then stun client is not enabled,
  and may lead to crash when doing URL dialing and stun specified.