Sipura/Linksys style gateways

<< < (3/8) > >>

murzik:
It is a little unclear how to use it. ???

MichiganTelephone:
I must admit that this thread in particular leaves me scratching my head wondering exactly what is being discussed. What I'd like to know, if anyone has the time and patience to explain it, is first of all a typical usage scenario for a Voice Gateway as it currently exists in the OBi devices — just something to help me understand why you might want to use one. And for bonus points, without saying that it's like the SPA3102 (because that means nothing to me in this context, since I've never attempted to use multiple gateways on an SPA3102), please explain what additional functionality is desired.

I just keep thinking this might possibly be a useful feature (certainly the Obihai developers thought so) if anyone actually knew how to use it, but right now I don't get it at all! ??? If this is something that's only useful if you are running OBiAPP then for the moment it probably wouldn't be useful to me personally, but I'd still like to be able to keep up with these discussions.

plugger2:
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".)

plugger2:
Quote from: MichiganTelephone on March 16, 2011, 02:18:39 am

I must admit that this thread in particular leaves me scratching my head wondering exactly what is being discussed. What I'd like to know, if anyone has the time and patience to explain it, is first of all a typical usage scenario for a Voice Gateway as it currently exists in the OBi devices — just something to help me understand why you might want to use one.

Probably discussion that really doesn't belong in this thread -- OBi's P2P gateway concept is sufficiently different enough to warrant it's own discussion. Perhaps you could start a separate thread in the appropriate subforum on this topic (since it's discussing an existing feature rather than a feature request).

Quote from: MichiganTelephone on March 16, 2011, 02:18:39 am

And for bonus points, without saying that it's like the SPA3102 (because that means nothing to me in this context, since I've never attempted to use multiple gateways on an SPA3102), please explain what additional functionality is desired.

I just keep thinking this might possibly be a useful feature (certainly the Obihai developers thought so) if anyone actually knew how to use it, but right now I don't get it at all! ??? If this is something that's only useful if you are running OBiAPP then for the moment it probably wouldn't be useful to me personally, but I'd still like to be able to keep up with these discussions.

Briefly, a SIP gateway account (in the Sipura/Linksys SPA jargon) is a non-registrable SIP service provider account. Being unregistrable, you cannot receive incoming calls from the account you have configured as a gateway account. Instead, you can only make outgoing calls using the config information.

Why have these, rather than a a number of fully registrable accounts in the style of SP1 and SP2? The answer is that these gateway accounts are light on additional hardware requirements. Almost nothing, in fact. By way of contrast, to keep n accounts registered, you have to have n SIP sessions running in parallel, with all the I/O requirements (and therefore hardware requirements) that implies.

Typically, users will have the need of more SIP accounts they can choose to dial out on, rather than have a large number of indial numbers they can receive calls on (the SPA3102 only had one fully registrable SIP account available, but had four additional gateway accounts to choose from to dial out on.) So by adding these lightweight "gateway" accounts, Sipura/Linksys came up with a clever way of leveraging the hardware they had available to become something very powerful indeed.

By adding 8 SIP gateway accounts to the two fully registrable SIP interfaces SP1 and SP2, OBiHAI wll have effectively doubled the capacity of the SPA3102, which is very appealing indeed! :-)

Navigation

[0] Message Index

[#] Next page

[*] Previous page