Quote from: OBi-Guru on March 15, 2011, 11:25:04 AM
@plugger2: There is a new beta firmware that supports the direct gateway calling on OBi110 (on all 8 Voice Gateways).
If you like to test drive this, please send email to support@obihai.com with your OBi number (and add your device to OBiTALK portal) - we can update your device.
Example: VoiceServices->VoiceGateway1->AccessNumber = sp1(mysp.com:5062) or sp2(192.168.1.100)
OK, I've had a chance to try this version of the firmware out, and it seems to basically work, but with what appears to a significant bug.
The bug is that the authentication strings stored with the gateway (AuthUserID and AuthPassword) are not being used when a SIP gateway call is being placed. Rather the authentication strings (AuthUserName and AuthPassword) stored with the Voice Service (SP1 or SP2) under "SIP credentials" seem to be used instead.
The net effect is that a call via the SIP gateway will only correctly authenticate if the authentication strings associated with the gateway match those already set-up in the target Voice Service. So, for example, setting AccessNumber in gateway 1 to
sp1(mysp.com:5062)
will only work if the authentication strings AuthUserName and AuthPassword stored for SP1 happen to be valid for
mysp.com.
This is the pattern I discovered when trying out the gateway configurations so far: On all SIP providers I tried to configure as a a gateway service, the authentication will succeed and the call will go through if and only if the authentication details for the SIP provider are also already stored in the AuthUserName and AuthPassword in the target Voice Service. The authentication strings AuthUserID and AuthPassword specified in the gateway configuration seem to be ignored.
I'm guessing that the intended behaviour is that when making a SIP gateway call the authentication strings stored with the gateway configuration (AuthUserID and AuthPassword) are intended to override the authentication strings (AuthUserName and AuthPassword) stored with the target Voice Service SP1 or SP2 under "SIP credentials".
If I might make a suggestion, these authentication strings in "SIP credentials" more properly belong in the ITSP Profiles anyway, along with the ProxyServer info etc. already stored in the SIP page there.
My reasoning is as follows: The authentication information specific to a particular SIP ProxyServer isn't generally usable in any other context, so it makes sense to bind the information more tightly to a particular SIP ProxyServer. (Indeed, having this information split up led me, and apparently some others, to some headscratching when initially trying the get my two registered ISTPs set-up -- I had missed that I had to set the SP2 Service X_ServProvProfile to "B" in order to get the ProxyServer configured in ITSP Profile B to match up with the authentication strings I had entered in SP2 "SIP credentials".)