Sipura/Linksys style gateways

[plugger2]

It would be nice to have "gateway" support for SIP Voice service providers that don't require registration, a la the SPA3102 for example. Indeed, when I saw the feature list for the OBi 110 included 8 gateways I thought "cool, that would give me configurability for up to 10 VSPs, lots of backup/fallback/trunk possibilities there."

Of course, now I realise that for an OBi110, the term "gateway" means something different to the term "gateway" on a SPA3102 or related device. But would it be difficult to extend the functionality of the OBi110 to allow for the configuration of non-registrable old-style "gateways"? Being limited to two VSPs is a tad restrictive, I feel. I'm currently using 3 out of the 5 available on my SPA3102, and with the additional power of the OBi110, I can easily think of how I could use even more configuration slots.

You may need to rethink your naming conventions in order to avoid confusion. Or perhaps you could just extend the functionality of the existing 8 OBi110 gateways to allow them to be configured for a VSP as well as for other OBi boxes? 

Anyone else support this idea?

[OBi-Guru]

Well, the gateway concept is great for connection from other OBi devices, and registration is not required either.
The beauty of obi to obi connection is that it frees up any kind of external IP addressing, static, DMZ or port forwarding issues.

[QBZappy]

plugger2,

Hi,
I think using the Obi as a gateway in the fashion you were originally thinking is possible if you adopt a different approach. With every Obi unit you connect to, you have an additional 2 Service Providers. Two units will give you 4 Service Providers. You could build up from there. You might need to be creative with the dial plan to achieve the desired use scenario.

[plugger2]

Well, the gateway concept is great for connection from other OBi devices, and registration is not required either.
The beauty of obi to obi connection is that it frees up any kind of external IP addressing, static, DMZ or port forwarding issues.

I wasn't suggesting this should be an either/or thing. The OBi gateway concept is very cool, and great if you have a use for it. What I'm suggesting is a way to make more SIP VSPs available.  The limit of two that are configurable at the moment is a real limitation. I've currently got three VSPs I'm using for my home use SPA3102 dialplan -- going over to the OBi110 I'll have to drop that down to two, and that will be at a cost.

One of the potentially useful things about having a list of outdial only "gateway" accounts (in the SPA3102 sense) is trunking: If a particular VSP is being used by someone on the ph line, for example, and the AA gets a request to place a call using that VSP, at the moment: No dice! But if it could refer to a trunk group of multiple separate accounts for that VSP, it just has to find one that is free, and Bingo!

Lots of VSPs have no monthly fee "pay as you go" accounts available. Get a few of these, put them in your trunk group for that VSP, and Bob's your proverbial uncle. The need will become even more apparent once the AA can handle more than one request at a time, I think.

I want my SIP gateway accounts! _And_ I want to be able to put them into trunk groups! :-)  

[Thunderbird1]

I'm compelled to agree with plugger2's suggestion.

I'm in a similar boat where I currently utilize 7 VSPs through my SPA3K - 1 via Line 1, 4 via gateways and 2 via the dial plan. When I first read that the Obi110 supported 8 gateways I thought "great" - a welcome improvement on the SPA. But further reading of the admin guide and as confirmed by Obi-Guru, the gateways only relate to Obi devices. Hhmm .... maybe no so great

No doubt some users will find the current gateway implementation a handy feature. Personally, I can't see myself using it in it's current form.

As plugger2 mentioned, being able to trunk group a number of gateways with the ability of a call to hunt through the VSPs would be a handy feature.

Anyway, just a little feedback & to add my interest/support for true gateway operability.

[murzik]

I am in the same boat. Have only 2 VSP is very limiting. That even makes OBi unusable for me. 
I am using few VSP for different international destinations.

[plugger2]

I am in the same boat. Have only 2 VSP is very limiting. That even makes OBi unusable for me.  
I am using few VSP for different international destinations.

I bought the OBi110 with the idea it would replace my Linksys SPA3102, but as it turns out, to work around the limitations of the the two SIP ITSP configuration limit on the OBi, I'm daisy-chaining the OBi110 into the SPA3102 (OBi110 FXO port into the SPA3102 FXS port), and can access the SIP gateway configs on the SPA3102 that way.

What I have to do is to dial a **8 prefix on a call  want handled by the SPA3102, so it is forced to the FXO line port, and then let the SPA3102 dialplan route the call from there. If I put a double prefix in front of the number (e.g. **8**2), then the first prefix is used by the OBI110, and the second prefix is used by the SPA3102 dialplan, if I want to override the default dialplan selection on the SPA3102. So it's a bit clunky, but it does work.

To make it even slicker, in order to make it as if there is one master dialplan controlling access to SP1, SP2 on the OBi110, as well as Line 1, the PSTN line and the 4 SIP gateways on the SPA3102, I'd have to write some digitmaps on the OBi to append the prefixes automatically. I haven't bothered to do that yet, but may do, "just 'cos".

In any case, instead of replacement for my SPA3102, the OBi110 has sort of become an add-on accessory to it! Which is cool, I guess, (at least as a workaround until OBiHAI properly address this particular design shortcoming), because I must admit I still have a soft spot for my venerable SPA3102! :-)

 

[murzik]

I am in the same boat. Have only 2 VSP is very limiting. That even makes OBi unusable for me.  
I am using few VSP for different international destinations.

I bought the OBi110 with the idea it would replace my Linksys SPA3102, but as it turns out, to work around the limitations of the the two SIP ITSP configuration limit on the OBi, I'm daisy-chaining the OBi110 into the SPA3102 (OBi110 FXO port into the SPA3102 FXS port), and can access the SIP gateway configs on the SPA3102 that way.

What I have to do is to dial a **8 prefix on a call  want handled by the SPA3102, so it is forced to the FXO line port, and then let the SPA3102 dialplan route the call from there. If I put a double prefix in front of the number (e.g. **8**2), then the first prefix is used by the OBI110, and the second prefix is used by the SPA3102 dialplan, if I want to override the default dialplan selection on the SPA3102. So it's a bit clunky, but it does work.

To make it even slicker, in order to make it as if there is one master dialplan controlling access to SP1, SP2 on the OBi110, as well as Line 1, the PSTN line and the 4 SIP gateways on the SPA3102, I'd have to write some digitmaps on the OBi to append the prefixes automatically. I haven't bothered to do that yet, but may do, "just 'cos".

In any case, instead of replacement for my SPA3102, the OBi110 has sort of become an add-on accessory to it! Which is cool, I guess, (at least as a workaround until OBiHAI properly address this particular design shortcoming), because I must admit I still have a soft spot for my venerable SPA3102! :-)

 

This may be very cool, but I personally see no reason of doing anything like this.
I think it would be much easy and less expensive just to use SPA3102 + sipsorcery, instead of SPA3102 + OBI110. I cannot justify cost of Obi110 if I have to use 3102 in addition to it.

[OBi-Guru]

@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)

[murzik]

@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.

Can I participate as well?

[murzik]

It is a little unclear how to use it. 

[plugger2]

@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)

Email sent. Do I need to make any adjustments to my config on the Auto Provisioning page for the update to work? I currently have both Auto Firmware Update and Auto Provisioning set to "disabled".

[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]

@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]

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).

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! :-)


 

[murzik]

I have exactly same results as plugger2.
I have to admit, that even with Voice gateway authentication bug, Obi is much more useful for me then before.

[plugger2]

Obi is much more useful for me then before.

How is it more useful with the bug? As it is, it means you are still limited to two usable SIP account configurations...

[murzik]

I am using same user name and password for all sip accounts  So I am able properly authenticate with gateway.

[plugger2]

I am using same user name and password for all sip accounts  So I am able properly authenticate with gateway.

All my SIP accounts have different userids... typically they are the DID associated with the account (so they can't be the same).

[OBi-Guru]

Authentication issue will be corrected as plugger2 pointed out.  Will advise further soon.  Thank you.