News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Contact header on gateway call

Started by Stewart, September 30, 2011, 08:25:38 AM

Previous topic - Next topic

Stewart

Using an OBi110 running 1.3.0 (Build: 2575), I'm trying to set up a system to make inexpensive calls from a prepaid cell phone (Orange) in Paris.

I have SP1 registered to ippi, SP2 registered to Phonepower, and VG1 set up for Voxbeam.  From the cell, I call the ippi number to trigger a callback.  The AA calls me back on Voxbeam; the call goes through fine.  I send DTMF to the AA and it places an outbound call on Phonepower.  The calls get bridged properly and I can talk.

However, when I hang up the cell, the OBi doesn't get the BYE from Voxbeam, because the contact header in the INVITE has the OBi's private IP.  I don't know why this should be; the STUN request is properly answered and the SDP on that INVITE has the correct public IP in the (o) and (c) entries.  The AccessNumber entry for Voice Gateway1 is SP2(sbc.voxbeam.com;ui=17758301234;op=ns) (I also tried op=s) (Voxbeam does not challenge the original INVITE, as it authenticates by IP address.)

Any ideas on what may be wrong?

Thanks,

Stewart

RonR

Voice Gateways used with SIP providers have a number of limitations.  The OBi 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.

Stewart

QuoteVoice Gateways used with SIP providers have a number of limitations.  The OBi will ...
Yes, I had read that in the (somewhat outdated) manual.  However, the official post at http://www.obitalk.com/forum/index.php?topic=9.0 says:

Quote
- Added options to support NAT traversal for SIP Gateway and URL calls on SP1/2.
  You may now append these URL parameters to speed dial and SIP Gateway VG1-8 access number, separated by ';',
   - ui=userid[:password]
   - ui=user-info, password is optional
   - op=[ i ][ m ][ n ][ s ]        ;option flags, i=ice,  -m=symmetic-rtp, n=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.

RonR

I hope you find a solution.  A typical answer from Obihai is:

Quote from: OBiSupport on September 27, 2011, 05:44:33 PM
As the suggested work-around does not work for your application, there is no solution.

RonR

Quote from: Stewart on September 30, 2011, 11:49:31 AM
QuoteVoice Gateways used with SIP providers have a number of limitations.  The OBi will ...
Yes, I had read that in the (somewhat outdated) manual.  However, the official post at http://www.obitalk.com/forum/index.php?topic=9.0 says:
.
.
.

The newly updated manual:

OBi Device Administration Guide
Version 28.09.11: 28 September 2011
This Revision: Revised for firmware version 1.3

makes no mention of:

Quote
- Added options to support NAT traversal for SIP Gateway and URL calls on SP1/2.
  You may now append these URL parameters to speed dial and SIP Gateway VG1-8 access number, separated by ';',
   - ui=userid[:password]
   - ui=user-info, password is optional
   - op=[ i ][ m ][ n ][ s ]        ;option flags, i=ice,  -m=symmetic-rtp, n=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.

Stewart

Thanks for the manual pointer -- I was not aware that it had been updated.

However, it appears to have been updated incorrectly.  The new manual makes no mention of the ui= parameter in Access Number, yet that is obviously working, because the number set there displays on the cell phone (and is not present anywhere else in the config).  I'd greatly appreciate it if an OBi engineer could please state which of these features have / have not been actually implemented, and which, if any, are scheduled for a future release.

Stewart

It turns out that the behavior is indeed as the release notes say; the new manual does not reflect the improvements.

The problem was caused by the Orange Livebox router to which the OBi was connected.  It apparently has a SIP ALG (which AFAIK cannot be disabled).  On the Phonepower registration, it was rewriting the Via header received tag (in the 200 OK response) back to the the private IP of the OBi.  This didn't affect the Phonepower service at all, since they handle all NAT traversal at the server.  However, it resulted in the OBi not having the proper Contact address for Voxbeam (which does not handle NAT traversal).  And evidently, the ALG didn't correctly translate the Contact address, either.

Fortunately, Phonepower offers the option of registering on an alternate port.  By connecting to port 12060, it got the ALG out of the picture (apparently the Livebox ALG only monitors port 5060).  The Via received tag from Phonepower now has the correct public IP and the OBi puts it in the Contact header to Voxbeam.  The BYE manages to find its way back to the OBi, it correctly drops the outbound leg, and I'm a happy camper :)

Everton

Stewart:

As a VOIP Power User and given the various Routers that exist, is there a generalized setup (SIP Ports, STUN, etc.) you could recommend with the OBi110/100, which would minimize a lot of the problems users are having that is being blame on the OBi device, when in fact, a lot of these problems are router related?

My second questions relates to your specific setup and the use of essentially three providers to initiate a single call.  Could the OBi110 be configured so that a single call from your Pre-Paid Cell your ippi DID (configured on SP1) and the call routed to the destination via the AA, without a callback and without the need for Phonepower being included in the mix?  I'm a novice user, with very limited VOIP knowledge, but why couldn't the last leg of the call be done using Voxbeam, even with the callback approach?  That is, when the AA calls your cell back on Voxbeam, couldn't the second channel (if there is such a thing) of Voxbeam be used for the call to the final destination number?

Quote from: Stewart on October 01, 2011, 12:18:58 AM
It turns out that the behavior is indeed as the release notes say; the new manual does not reflect the improvements.

The problem was caused by the Orange Livebox router to which the OBi was connected.  It apparently has a SIP ALG (which AFAIK cannot be disabled).  On the Phonepower registration, it was rewriting the Via header received tag (in the 200 OK response) back to the the private IP of the OBi.  This didn't affect the Phonepower service at all, since they handle all NAT traversal at the server.  However, it resulted in the OBi not having the proper Contact address for Voxbeam (which does not handle NAT traversal).  And evidently, the ALG didn't correctly translate the Contact address, either.

Fortunately, Phonepower offers the option of registering on an alternate port.  By connecting to port 12060, it got the ALG out of the picture (apparently the Livebox ALG only monitors port 5060).  The Via received tag from Phonepower now has the correct public IP and the OBi puts it in the Contact header to Voxbeam.  The BYE manages to find its way back to the OBi, it correctly drops the outbound leg, and I'm a happy camper :)

Stewart

#8
Everton:

I can't recommend a general setup, because providers are very different.  Most of the quality-oriented ones, e.g. Callcentric and VoIP.ms, proxy audio through their servers and generally handle NAT mapping and keep-alive on their end.  Turn off STUN and any NAT related settings in the ATA, turn off (or somehow avoid) any SIP ALG in the router, and you should be fine.  For providers where audio flows directly to/from their carrier, you need to make your system appear as if it's on a public IP.  Unfortunately, many (most?) consumer routers have quirks that make it difficult, so you may need to experiment.  Most providers offer configuration examples on their Web sites; some have a list of routers known to be incompatible.

My setup is unusual:  We live in the US and have Phonepower as our primary service.  However, we have a small apartment in Paris and stay here for six to eight weeks, twice a year.  Phone service bundled with FTTH service from Orange includes "unlimited" free calling to landlines in 100+ countries, but has no BYOD access; I brought an OBi, primarily to be able to use the Orange service from elsewhere.  We have prepaid cell service here, because all postpaid services for smartphones, i.e. that include a data plan, require a minimum 12 month contract; we'd be paying continuously for an expensive service used only 3-4 months per year.

Prepaid plans don't require a contract and have inexpensive data options.  Although incoming calls are free, outbound domestic calls are a steep 0.50 €/min.; international is even higher.  The usual solution (with smartphones) is to use the click-to-call service offered by many providers -- it rings both your cell and the destination, and bridges the calls.  Some even have apps that integrate with the phone's contact list and do it all automatically.  The cost with most VoIP providers to FR mobile is quite reasonable, typically ranging from $0.05 to $0.20/min.  Unfortunately, a bureaucratic snafu caused a delay of several days getting the data plans activated, so I set up the OBi to do callback.

I chose Phonepower for the outbound leg (when calling the US), because those calls are free on our existing "unlimited" plan, and the caller ID sent is known by our contacts.  PP is not suitable for the trigger call, because our IP phones here (not connected through OBi) would ring and disturb anyone at home.  I happened to have a Paris DID with ippi (obtained because of a previous bureaucratic snafu, where the Orange home phone didn't work for ten days), so I used that for the trigger.  For the inbound leg, I didn't want to use either ippi (expensive at 0.15 €/min.) or Phonepower (audio proxied through their California server would add four trips across the Pond to round-trip latency).  I happened to have a Voxbeam account (another long story); their $0.0361/min. rate is excellent and the media server is only 14 ms from here.  Bottom line: we can call the US from our cell phones for less than $0.04/min., get excellent quality, with only a little more hassle than click-to-call.