[OpenSIPS-Users] OpenSIPS ALG

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed May 13 15:02:51 CEST 2009


Hi Jeff,

theoretically yes, because you have all the needed information 
(hmm...maybe except the NAT status from request, but you can store it 
via transaction)....Practically, the save() function does expect to 
receive a request only, so it must be changed to work with a reply also.

Regards,
Bogdan

Jeff Pyle wrote:
> I've thought a lot about this as well, although I haven't taken it nearly as
> far as John has.
>
> A thought:  is it possible to do a save() in the reply route, only upon a
> 200 OK from the end registrar?
>
>
> - Jeff
>
>
>
> On 5/12/09 5:09 AM, "Bogdan-Andrei Iancu" <bogdan at voice-system.ro> wrote:
>
>   
>> Hi John,
>>
>> This mid-registrar approach may work but it is not 100% correct as
>> OpenSIPS (as mid-registrar) does not obey the actions of the final
>> registrar (Asterisk). Ex:
>>     - Asterisk may forbid the registration and you already saved the
>> registration on OpenSIPS
>>     - Asterisk may change the Expire time while to saved the
>> registration with the expire sent by client.
>>
>> Anyhow, ignoring this aspects, lets go further :) :
>>  
>> 1) is the registration scenario working ok? if not what is the exact
>> problem (some trace will help).
>>
>> I will wait for you answer before moving further with the calling stuff.
>>
>> Regards,
>> Bogdan
>>
>> John Morris wrote:
>>     
>>> After several days of playing with OpenSIPS 1.5.0 and RTPProxy 1.2.0, I
>>> have a partially working SIP+RTP ALG configuration, and have gotten stuck.
>>>  I could use some general advice from the list.
>>>
>>> The company has an Asterisk/FreePBX server on an internal network, and the
>>> CEO wants to use a SIP phone from outside.  Because the sip alg iptables
>>> module isn't working, and in preparation for another project, I started
>>> investigating OpenSIPS for use as a border proxy to connect phones across
>>> NAT (and, the next project, to route a SIP trunk over a VPN from the
>>> network of a DSL+phone company that intermittently blocks SIP traffic in
>>> hopes of plugging revenue leaks).
>>>
>>> The network looks like this:
>>>
>>> SIP UA <-> home NAT gateway <-> Internet <-> OpenSIPS server/NAT router
>>> <-> Asterisk
>>>
>>> The standard opensips.cfg file doesn't work as is.  The SIP phone needs to
>>> register to the Asterisk server directly.  In addition, it seems there is
>>> extra logic needed to support multiple network interfaces (mhomed=1 only
>>> partially solves the problem).
>>>
>>> The way I've gone with this in testing is to relay REGISTERs to Asterisk,
>>> but after a save("location","0x02") to enable a lookup("location") on
>>> messages originating from the PBX.  The phone is configured with an
>>> outbound proxy, and all packets to the proxy matching "uri==myself" are
>>> thrown away.  This worked great on the single-interfaced, internal test
>>> installation.  Now that there are multiple interfaces involved, things are
>>> breaking again; ACKs and BYEs are sent out the wrong interface, and
>>> RTPProxy is behaving strangely in bridged mode.
>>>
>>> There seem to be no good configuration examples for either multi-homed
>>> proxies or for proxies that relay REGISTERs.  This makes me think that I'm
>>> going about this the wrong way.
>>>
>>> Also, I have looked at other software, like siproxd, opensbc and uh, that
>>> other b2bua that functions as an SBC, but none of those seem to allow this
>>> REGISTER pass-through function.
>>>
>>> What is the best approach for this scenario?  The above approach of
>>> relaying REGISTERs to Asterisk?  Is there maybe another approach where
>>> phones register to OpenSIPS directly, and OpenSIPS in turn somehow sends
>>> another REGISTER to Asterisk?  Or am I missing the idea completely?
>>>
>>> I'd appreciate general pointers about how to proceed.  I've been putting
>>> some Asterisk and FreePBX tutorials and CentOS RPMs on
>>> http://www.zultron.com, mostly aimed at small office-like environments.
>>> Looking through various lists, this seems a highly sought-after
>>> configuration.  If I succeed, I'll document it in hopes of filling the gap
>>> in this sort of example.
>>>
>>> Thanks
>>>
>>>     John
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>   
>>>       
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>     
>
>
>   




More information about the Users mailing list