I know there is a long thread about voice gateways (http://www.obitalk.com/forum/index.php?topic=371.0), but I it went a little off-topic, so I'd rather start a new one.
I am trying to set up voice gateway (VG1). Something like call with us or Betamax. For testing, I set up that toll-free calls go through this gateway.
I have OBi202; SP1 is Google Voice, SP2 and SP3 are SIP providers, and SP4 is empty.
If I specify SP4(sip.callwithus.com) as VG1 access number, I get fast busy. Why? I thought the whole point of the gateway was to send the calls to the providers not configured as SPx!
If I specify SP2() or SP3(), the call goes fine; but once connected - I can't hear anything. Why would it be? I enabled NAT for call with us; but there is no way to specify it in the gateway. However, SP3 is CallWithUs with NAT enabled. I guess, I am back to my original question - what is the purpose of this SPx in the access number?!
I remember, many years ago I configured gateway in SPA3102 (I think); and it was quite straightforward. I realize that these gateways started as part of OBiTalk, which I don't know much, and don't particularly care. But I thought it's not available for SIP routes as well.
Also, I am familiar with tf.callwithus.com. The question is about gateway setup; not about particular servers for particular provider.
Felix,
As you have noted, the SPx trunk used for a Voice Gateway does need to be configured for SIP and enabled before it can be used. However, it does not need to have a "real" account configured. The following "fake" account will work for your sp4 example:
Service Providers -> ITSP Profile D -> SIP -> ProxyServer : 127.0.0.1
Voice Services -> SP4 Service -> Enable : (checked)
Voice Services -> SP4 Service -> AuthUserName : (any letters or numbers)
Voice Services -> SP4 Service -> X_ServProvProfile : D
Voice Services -> SP4 Service -> X_RegisterEnable : unchecked
The limitations of using Voice Gateways listed in the ObiDeviceAdminGuide are:
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.
Having said all that, I use Voice Gateways on "real" and "fake" SIP configured trunks with very few problems.
Thanks, ianobi
Calling through fake SP didn't work; but I didn't spend too much time on it. I set up callcentric and the calls are successful. That is, I can hear the other part. So, it looks like the problem is callwithus-specific.
Unfortunately, if CWU requires NAT, and gateway is not using NAT setting - the conclusion is that CWU is not compatible with OBI voice gateways. That would be most unfortunate, since CWU is an outgoing-only service, and as such is a perfect use case for gateway...
For the "fake" account I should have added:
Voice Services -> SP4 Service -> X_RegisterEnable : unchecked
Added to original post.
thanks, unchecking X_RegisterEnable solved that problem. Now, if I could only solve the big problem ::)
You might try this:
- 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.
This info in buried in the past release notes. I didn't see it mentioned the last time I looked at the Admin Guide. I don't know what combination (one or more) of the 4 parameters (;op=imns) might fix your issue, iif any.
AWESOME! op=s fixed the issue! Apparently, op=s picks stun settings from the specified SP. So, when I tried fake SP that didn't have stun settings - it didn't work; however, when I added stun information to it, it started working!
Thanks! Maybe one day OBi documentation will match its functionality... maybe not. >:(