OpenSIPS ALG

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSIPS ALG

John Morris-6
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSIPS ALG

Bogdan-Andrei Iancu
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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSIPS ALG

Jeff Pyle
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" <[hidden email]> 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
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>  
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSIPS ALG

Bogdan-Andrei Iancu
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" <[hidden email]> 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
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>  
>>>      
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>    
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSIPS ALG

Robert Dyck
I like the idea that we could maintain a local registrar that accurately
reflects the remote registration. I would go so far as to say that it would
be useful to be able to optimize opensips as an ALG. Some people could use a
proxy as an edge device on a LAN. You could have several phones with the same
user name register with a service provider. Some service providers limit the
number of contacts per AOR. This would have the side effect of keeping the
signaling associated with forking on the LAN. By detecting local calls, media
could also be kept on the LAN. Such an edge device might have a dynamic IP
address. It would be helpful if opensips could conveniently be setup to fix
the contacts. Using the received address does not work when the phones are on
the same LAN as the proxy.

Opensips has a bias toward service providers. This is quite understandable.
However I feel with a bit of tweaking it could serve as an ALG for the home
owner or a small business.

On Wednesday 13 May 2009, Bogdan-Andrei Iancu wrote:

> 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" <[hidden email]> 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
> >>> [hidden email]
> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >> _______________________________________________
> >> Users mailing list
> >> [hidden email]
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSIPS ALG

Bogdan-Andrei Iancu
Hi Robert,

Interesting points of view :).

But there is a huge difference between a proxy acting as a mid-registrar
(with no auth knowledge, no user knowledge, but simply following the
master registrar decisions in a blind way) and proxy doing actually
account and registrar management (like you described in the scenario
with hiding registrations).

I'm not saying is not possible, but the question is where a proxy stops
and where an ALG starts :).

Anyhow, I will add on the TODO list the possibility to do a register at
reply time, so that we can use opensips as mid-registrar.

Regards,
Bogdan

Robert Dyck wrote:

> I like the idea that we could maintain a local registrar that accurately
> reflects the remote registration. I would go so far as to say that it would
> be useful to be able to optimize opensips as an ALG. Some people could use a
> proxy as an edge device on a LAN. You could have several phones with the same
> user name register with a service provider. Some service providers limit the
> number of contacts per AOR. This would have the side effect of keeping the
> signaling associated with forking on the LAN. By detecting local calls, media
> could also be kept on the LAN. Such an edge device might have a dynamic IP
> address. It would be helpful if opensips could conveniently be setup to fix
> the contacts. Using the received address does not work when the phones are on
> the same LAN as the proxy.
>
> Opensips has a bias toward service providers. This is quite understandable.
> However I feel with a bit of tweaking it could serve as an ALG for the home
> owner or a small business.
>
> On Wednesday 13 May 2009, Bogdan-Andrei Iancu wrote:
>  
>> 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" <[hidden email]> 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
>>>>> [hidden email]
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>          
>>>> _______________________________________________
>>>> Users mailing list
>>>> [hidden email]
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>        
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>    
>
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSIPS ALG

Robert Dyck
Knowing the status of a registration attempt would be useful. One would not
necessarily remove the local registration if the external attempt failed.
Local calling would still be possible. As well a remote family member for
example could take advantage of such dual registration and could take calls
that came through a service provider or calls that originated on the LAN.

Using dynamic DNS acquaintances could also call into the LAN without going
through a service provider. The UA only concerns itself with the username not
the domain. Using aliases and fixed IP addresses on the LAN you can even ring
individual phones.

I use my proxy much as I have described. I am currently back and forth between
two residences. Using an SPA3000 and my proxy, my PSTN calls ring at both
places. As well my wife and I call each other without going through the PSTN
or a voip service provider although the service provider handles the
voicemail.

I see myself as a SIP promoter. A good way for a beginner to get experience is
to set up a home or small office system. As I said before I understand that
Opensips must cater to the service provider but nurturing the newbies is
good. They are the future.

On Friday 22 May 2009, Bogdan-Andrei Iancu wrote:

> Hi Robert,
>
> Interesting points of view :).
>
> But there is a huge difference between a proxy acting as a mid-registrar
> (with no auth knowledge, no user knowledge, but simply following the
> master registrar decisions in a blind way) and proxy doing actually
> account and registrar management (like you described in the scenario
> with hiding registrations).
>
> I'm not saying is not possible, but the question is where a proxy stops
> and where an ALG starts :).
>
> Anyhow, I will add on the TODO list the possibility to do a register at
> reply time, so that we can use opensips as mid-registrar.
>
> Regards,
> Bogdan
>
> Robert Dyck wrote:
> > I like the idea that we could maintain a local registrar that accurately
> > reflects the remote registration. I would go so far as to say that it
> > would be useful to be able to optimize opensips as an ALG. Some people
> > could use a proxy as an edge device on a LAN. You could have several
> > phones with the same user name register with a service provider. Some
> > service providers limit the number of contacts per AOR. This would have
> > the side effect of keeping the signaling associated with forking on the
> > LAN. By detecting local calls, media could also be kept on the LAN. Such
> > an edge device might have a dynamic IP address. It would be helpful if
> > opensips could conveniently be setup to fix the contacts. Using the
> > received address does not work when the phones are on the same LAN as the
> > proxy.
> >
> > Opensips has a bias toward service providers. This is quite
> > understandable. However I feel with a bit of tweaking it could serve as
> > an ALG for the home owner or a small business.
> >
> > On Wednesday 13 May 2009, Bogdan-Andrei Iancu wrote:
> >> 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" <[hidden email]>
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
> >>>>> [hidden email]
> >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>>>
> >>>> _______________________________________________
> >>>> Users mailing list
> >>>> [hidden email]
> >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >> _______________________________________________
> >> Users mailing list
> >> [hidden email]
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSIPS ALG

John Morris-6
In reply to this post by Bogdan-Andrei Iancu
Bogdan,

I put this down for a little while, and just picked it up again. See below.

Bogdan-Andrei Iancu wrote:
 > 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

I think this is OK.  The purpose is just to record the location of the
registered phone.  If the registration fails, the "0x02" flag in the
save() statement prevents an incorrect response to the registration
to the UAC, and the ul entry should be harmless until it expires.

 > - Asterisk may change the Expire time while to saved the registration
 >  with the expire sent by client.

I don't understand this, but it sounds like a case where the expiration
date of the registration doesn't match that in the ul table?  I don't
know in what circumstances the ul entry in OpenSIPS would expire and
presumably be removed before the UAC's registration expires, leaving a
situation where OpenSIPS can't look up the UAC's location.  Can you comment?

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

Yes, it seems to be!

 > I will wait for you answer before moving further with the calling
 > stuff.

The registration seems to be the easy part of this configuration (or
else I haven't gotten far enough along to run into the difficulties that
lie ahead).  The hard part is multi-homed configuration of OpenSIPS and
RTPProxy; I've found few examples to crib from.

By the way, the test setup here is a little bit strange, though I don't
think it's causing the following problems.  Because I can't touch the
office gateway (the VPN router, here) for experimenting, the path is set
up to go through an Internet host with traffic tunneled through a VPN.

Zoiper NAT rtr, int. NAT rtr, ext. -->
192.168.7.60 192.168.7.1 221.221.241.189 -->

<-- Internet -->

<-- OpenSIPS eth0 OpenSIPS tun4 (VPN router) Asterisk
<-- 1.2.3.4 192.168.106.1 192.168.3.19

For the most part, the signaling seems to work.  OpenSIPS is passing
REGISTER, NOTIFY, OPTIONS, INVITE and the rest of the associated
dialogs (mostly) correctly.

One bit I'm a little confused about is Contact: header from Asterisk:

        Contact: <sip:*43@192.168.3.19>.

(See the INVITE "OK" response.)  This should be changed to the
external IP of OpenSIPS on its way back to Zoiper.  Should a
fix_nated_contact be used, or should this be done manually somehow,
since Asterisk isn't really NATted from OpenSIPS's perspective?

The next problem is with the RTP streams (see below for tcpdumps).
Zoiper and Asterisk both begin to send RTP packets to their respective
RTPProxy ports.  RTPProxy relays the Asterisk traffic back to the
Zoiper, but at its pre-NATted RFC1918 address.  None of the Zoiper
traffic is forwarded to Asterisk.

I've spent quite some time sorting through the documentation, but
haven't found the answer to these problems yet.  I'd also like to know,
since I really don't know what I'm doing here, whether I'm going down a
terribly foolish path either with this idea or with the structure of the
opensips.cfg file at the bottom.

Following are ngreps of the SIP traffic and tcpdumps of the RTP
traffic, all tagged with the interface name, and finally the
opensips.cfg.  RTPProxy is run as follows:

        /usr/bin/rtpproxy -u rtpproxy rtpproxy \
        -s unix:/var/run/rtpproxy.sock \
        -l 192.168.106.1/1.2.3.4 -t 0xB8 -m 35000 \
        -M 35019 -d DBUG

Sorry for the copious output.

       John


----------------------------------------------------------------------
Trace of the INVITE:

[... INVITE/407 Proxy Auth Required sequence deleted ...]

eth0: #
eth0: U 18:08:56.549561 221.221.241.189:5060 -> 1.2.3.4:5060
eth0: INVITE sip:*[hidden email];transport=UDP SIP/2.0.
eth0: Via: SIP/2.0/UDP
   192.168.7.60:5060;branch=z9hG4bK-d8754z-621e7cd587b50f77-1---d8754z-.
eth0: Max-Forwards: 70.
eth0: Contact: <sip:150@192.168.7.60:5060;transport=UDP>.
eth0: To: <sip:*[hidden email];transport=UDP>.
eth0: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
eth0: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
eth0: CSeq: 2 INVITE.
eth0: Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE,
   OPTIONS, INFO, SUBSCRIBE.
eth0: Content-Type: application/sdp.
eth0: Proxy-Authorization: Digest username="150",realm="asterisk",
   nonce="6e0d2196",uri="sip:*[hidden email];transport=UDP",
   response="1445b6b432b9b275b4880d71cf8e1c96",algorithm=MD5.
eth0: User-Agent: Zoiper rev.3938.
eth0: Content-Length: 171.
eth0: .
eth0: v=0.
eth0: o=Zoiper_user 0 0 IN IP4 192.168.7.60.
eth0: s=Idefisk_user.
eth0: c=IN IP4 192.168.7.60.
eth0: t=0 0.
eth0: m=audio 8000 RTP/AVP 0 3.
eth0: a=rtpmap:0 PCMU/8000.
eth0: a=rtpmap:3 GSM/8000.
eth0: a=sendrecv.
eth0:
eth0: #
eth0: U 18:08:56.775261 1.2.3.4:5060 -> 221.221.241.189:5060
eth0: SIP/2.0 100 Giving a try.
eth0: Via: SIP/2.0/UDP 1.2.3.4:5060;
   branch=z9hG4bK-d8754z-621e7cd587b50f77-1---d8754z-;
   rport=5060;received=221.221.241.189.
eth0: To: <sip:*[hidden email];transport=UDP>.
eth0: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
eth0: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
eth0: CSeq: 2 INVITE.
eth0: Server: OpenSIPS (1.5.0-notls (i386/linux)).
eth0: Content-Length: 0.
eth0: .
eth0:
tun4: #
tun4: U 18:08:56.775920 192.168.106.1:5060 -> 192.168.3.19:5060
tun4: INVITE sip:*[hidden email];transport=UDP SIP/2.0.
tun4: Record-Route: <sip:192.168.106.1;r2=on;lr;ftag=11409305>.
tun4: Record-Route: <sip:1.2.3.4;r2=on;lr;ftag=11409305>.
tun4: Via: SIP/2.0/UDP 192.168.106.1:5060;branch=z9hG4bK74c8.dacafed2.0.
tun4: Via: SIP/2.0/UDP 192.168.7.60:5060;rport=5060;
   received=221.221.241.189;
   branch=z9hG4bK-d8754z-621e7cd587b50f77-1---d8754z-.
tun4: Max-Forwards: 70.
tun4: Contact: <sip:150@192.168.106.1:5060;transport=UDP>.
tun4: To: <sip:*[hidden email];transport=UDP>.
tun4: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
tun4: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
tun4: CSeq: 2 INVITE.
tun4: Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE,
   OPTIONS, INFO, SUBSCRIBE.
tun4: Content-Type: application/sdp.
tun4: Proxy-Authorization: Digest username="150",realm="asterisk",
   nonce="6e0d2196",uri="sip:*[hidden email];transport=UDP",
   response="1445b6b432b9b275b4880d71cf8e1c96",algorithm=MD5.
tun4: User-Agent: Zoiper rev.3938.
tun4: Content-Length: 219.
tun4: .
tun4: v=0.
tun4: o=Zoiper_user 0 0 IN IP4 192.168.106.1.
tun4: s=Idefisk_user.
tun4: c=IN IP4 192.168.106.1.
tun4: t=0 0.
tun4: m=audio 35016 RTP/AVP 0 3.
tun4: a=rtpmap:0 PCMU/8000.
tun4: a=rtpmap:3 GSM/8000.
tun4: a=sendrecv.
tun4: a=oldmediaip:192.168.7.60.
tun4: a=nortpproxy:yes.
tun4:
eth0: #
eth0: U 18:08:57.058325 221.221.241.189:5060 -> 1.2.3.4:5060
eth0: INVITE sip:*[hidden email];transport=UDP SIP/2.0.
eth0: Via: SIP/2.0/UDP 192.168.7.60:5060;
   branch=z9hG4bK-d8754z-621e7cd587b50f77-1---d8754z-.
eth0: Max-Forwards: 70.
eth0: Contact: <sip:150@192.168.7.60:5060;transport=UDP>.
eth0: To: <sip:*[hidden email];transport=UDP>.
eth0: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
eth0: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
eth0: CSeq: 2 INVITE.
eth0: Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE,
   OPTIONS, INFO, SUBSCRIBE.
eth0: Content-Type: application/sdp.
eth0: Proxy-Authorization: Digest username="150",realm="asterisk",
   nonce="6e0d2196",uri="sip:*[hidden email];transport=UDP",
   response="1445b6b432b9b275b4880d71cf8e1c96",algorithm=MD5.
eth0: User-Agent: Zoiper rev.3938.
eth0: Content-Length: 171.
eth0: .
eth0: v=0.
eth0: o=Zoiper_user 0 0 IN IP4 192.168.7.60.
eth0: s=Idefisk_user.
eth0: c=IN IP4 192.168.7.60.
eth0: t=0 0.
eth0: m=audio 8000 RTP/AVP 0 3.
eth0: a=rtpmap:0 PCMU/8000.
eth0: a=rtpmap:3 GSM/8000.
eth0: a=sendrecv.
eth0:
eth0: #
eth0: U 18:08:57.058884 1.2.3.4:5060 -> 221.221.241.189:5060
eth0: SIP/2.0 100 Giving a try.
eth0: Via: SIP/2.0/UDP 1.2.3.4:5060;
   branch=z9hG4bK-d8754z-621e7cd587b50f77-1---d8754z-;
   rport=5060;received=221.221.241.189.
eth0: To: <sip:*[hidden email];transport=UDP>.
eth0: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
eth0: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
eth0: CSeq: 2 INVITE.
eth0: Server: OpenSIPS (1.5.0-notls (i386/linux)).
eth0: Content-Length: 0.
eth0: .
eth0:
tun4: #
tun4: U 18:08:57.295341 192.168.106.1:5060 -> 192.168.3.19:5060
tun4: INVITE sip:*[hidden email];transport=UDP SIP/2.0.
tun4: Record-Route: <sip:192.168.106.1;r2=on;lr;ftag=11409305>.
tun4: Record-Route: <sip:1.2.3.4;r2=on;lr;ftag=11409305>.
tun4: Via: SIP/2.0/UDP 192.168.106.1:5060;branch=z9hG4bK74c8.dacafed2.0.
tun4: Via: SIP/2.0/UDP 192.168.7.60:5060;rport=5060;
   received=221.221.241.189;
   branch=z9hG4bK-d8754z-621e7cd587b50f77-1---d8754z-.
tun4: Max-Forwards: 70.
tun4: Contact: <sip:150@192.168.106.1:5060;transport=UDP>.
tun4: To: <sip:*[hidden email];transport=UDP>.
tun4: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
tun4: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
tun4: CSeq: 2 INVITE.
tun4: Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS,
INFO, SUBSCRIBE.
tun4: Content-Type: application/sdp.
tun4: Proxy-Authorization: Digest username="150",realm="asterisk",
   nonce="6e0d2196",uri="sip:*[hidden email];transport=UDP",
   response="1445b6b432b9b275b4880d71cf8e1c96",algorithm=MD5.
tun4: User-Agent: Zoiper rev.3938.
tun4: Content-Length: 219.
tun4: .
tun4: v=0.
tun4: o=Zoiper_user 0 0 IN IP4 192.168.106.1.
tun4: s=Idefisk_user.
tun4: c=IN IP4 192.168.106.1.
tun4: t=0 0.
tun4: m=audio 35016 RTP/AVP 0 3.
tun4: a=rtpmap:0 PCMU/8000.
tun4: a=rtpmap:3 GSM/8000.
tun4: a=sendrecv.
tun4: a=oldmediaip:192.168.7.60.
tun4: a=nortpproxy:yes.
tun4:
tun4: #
tun4: U 18:08:57.536179 192.168.3.19:5060 -> 192.168.106.1:5060
tun4: SIP/2.0 100 Trying.
tun4: Via: SIP/2.0/UDP 192.168.3.19:5060;branch=z9hG4bK74c8.dacafed2.0;
   received=192.168.106.1.
tun4: Via: SIP/2.0/UDP 192.168.7.60:5060;rport=5060;
   received=221.221.241.189;
   branch=z9hG4bK-d8754z-621e7cd587b50f77-1---d8754z-.
tun4: Record-Route: <sip:192.168.106.1;r2=on;lr;ftag=11409305>.
tun4: Record-Route: <sip:1.2.3.4;r2=on;lr;ftag=11409305>.
tun4: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
tun4: To: <sip:*[hidden email];transport=UDP>.
eth0: #
eth0: U 18:08:57.541789 1.2.3.4:5060 -> 221.221.241.189:5060
eth0: SIP/2.0 200 OK.
eth0: Via: SIP/2.0/UDP 1.2.3.4:5060;rport=5060;
   received=221.221.241.189;
   branch=z9hG4bK-d8754z-621e7cd587b50f77-1---d8754z-.
eth0: Record-Route: <sip:192.168.106.1;r2=on;lr;ftag=11409305>.
eth0: Record-Route: <sip:1.2.3.4;r2=on;lr;ftag=11409305>.
eth0: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
eth0: To: <sip:*[hidden email];transport=UDP>;tag=as621c37a2.
eth0: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
eth0: CSeq: 2 INVITE.
eth0: User-Agent: Asterisk PBX.
eth0: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
   SUBSCRIBE, NOTIFY.
eth0: Supported: replaces.
eth0: Contact: <sip:*43@192.168.3.19>.
eth0: Content-Type: application/sdp.
eth0: Content-Length: 204.
eth0: .
eth0: v=0.
eth0: o=root 1501 1501 IN IP4 1.2.3.4.
eth0: s=session.
eth0: c=IN IP4 1.2.3.4.
eth0: t=0 0.
eth0: m=audio 35006 RTP/AVP 0.
eth0: a=rtpmap:0 PCMU/8000.
eth0: a=silenceSupp:off - - - -.
eth0: a=ptime:20.
eth0: a=sendrecv.
eth0: a=nortpproxy:yes.
eth0:
tun4: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
tun4: CSeq: 2 INVITE.
tun4: User-Agent: Asterisk PBX.
tun4: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
tun4: Supported: replaces.
tun4: Contact: <sip:*43@192.168.3.19>.
tun4: Content-Length: 0.
tun4: .
tun4:
tun4: #
tun4: U 18:08:57.541168 192.168.3.19:5060 -> 192.168.106.1:5060
tun4: SIP/2.0 200 OK.
tun4: Via: SIP/2.0/UDP 192.168.3.19:5060;branch=z9hG4bK74c8.dacafed2.0;
   received=192.168.106.1.
tun4: Via: SIP/2.0/UDP 192.168.7.60:5060;rport=5060;
   received=221.221.241.189;
   branch=z9hG4bK-d8754z-621e7cd587b50f77-1---d8754z-.
tun4: Record-Route: <sip:192.168.106.1;r2=on;lr;ftag=11409305>.
tun4: Record-Route: <sip:1.2.3.4;r2=on;lr;ftag=11409305>.
tun4: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
tun4: To: <sip:*[hidden email];transport=UDP>;tag=as621c37a2.
tun4: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
tun4: CSeq: 2 INVITE.
tun4: User-Agent: Asterisk PBX.
tun4: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
   SUBSCRIBE, NOTIFY.
tun4: Supported: replaces.
tun4: Contact: <sip:*43@192.168.3.19>.
tun4: Content-Type: application/sdp.
tun4: Content-Length: 182.
tun4: .
tun4: v=0.
tun4: o=root 1501 1501 IN IP4 192.168.3.19.
tun4: s=session.
tun4: c=IN IP4 192.168.3.19.
tun4: t=0 0.
tun4: m=audio 11948 RTP/AVP 0.
tun4: a=rtpmap:0 PCMU/8000.
tun4: a=silenceSupp:off - - - -.
tun4: a=ptime:20.
tun4: a=sendrecv.
tun4:


RTP packets start here:
eth0: 18:08:57.906935 IP 221.221.241.189.8000 > 1.2.3.4.35006: UDP,
length 172
eth0: 18:08:57.926913 IP 221.221.241.189.8000 > 1.2.3.4.35006: UDP,
length 172
eth0: 18:08:57.946936 IP 221.221.241.189.8000 > 1.2.3.4.35006: UDP,
length 172
[...]
tun4: 18:08:58.539710 IP 192.168.3.19.11948 > 192.168.106.1.35016: UDP,
length 172
eth0: 18:08:58.539819 IP 1.2.3.4.35006 > 192.168.7.60.8000: UDP, length 172
eth0: 18:08:58.547647 IP 221.221.241.189.8000 > 1.2.3.4.35006: UDP,
length 172
tun4: 18:08:58.560680 IP 192.168.3.19.11948 > 192.168.106.1.35016: UDP,
length 172
eth0: 18:08:58.560739 IP 1.2.3.4.35006 > 192.168.7.60.8000: UDP, length 172
eth0: 18:08:58.569607 IP 221.221.241.189.8000 > 1.2.3.4.35006: UDP,
length 172
eth0: 18:08:58.587601 IP 221.221.241.189.8000 > 1.2.3.4.35006: UDP,
length 172
tun4: 18:08:58.599667 IP 192.168.3.19.11948 > 192.168.106.1.35016: UDP,
length 172
eth0: 18:08:58.599728 IP 1.2.3.4.35006 > 192.168.7.60.8000: UDP, length 172
eth0: 18:08:58.607647 IP 221.221.241.189.8000 > 1.2.3.4.35006: UDP,
length 172
[...]

RTPProxy logs near this point:
May 30 18:08:55 horseman rtpproxy[1367]: INFO:handle_command: new
   session Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk., tag 11409305;1
   requested, type strong
May 30 18:08:55 horseman rtpproxy[1367]: INFO:handle_command: new
   session on a port 35016 created, tag 11409305;1
May 30 18:08:55 horseman rtpproxy[1367]: INFO:handle_command:
   pre-filling caller's address with 192.168.7.60:8000
[...]
May 30 18:08:56 horseman rtpproxy[1367]: INFO:handle_command: adding
   strong flag to existing session, new=1/0/0
May 30 18:08:56 horseman rtpproxy[1367]: INFO:handle_command: lookup on
   ports 35016/0, session timer restarted
[...]
May 30 18:08:57 horseman rtpproxy[1367]: INFO:handle_command: adding
   strong flag to existing session, new=1/0/0
May 30 18:08:57 horseman rtpproxy[1367]: INFO:handle_command: lookup on
   ports 35016/0, session timer restarted
[...]
May 30 18:08:57 horseman rtpproxy[1367]: INFO:handle_command: lookup on
   ports 35016/35006, session timer restarted
May 30 18:08:57 horseman rtpproxy[1367]: INFO:handle_command:
   pre-filling callee's address with 192.168.3.19:11948


eth0: #
eth0: U 18:09:03.553257 221.221.241.189:5060 -> 1.2.3.4:5060
eth0: BYE sip:*43@192.168.3.19 SIP/2.0.
eth0: Via: SIP/2.0/UDP 192.168.7.60:5060;
   branch=z9hG4bK-d8754z-8ae3d2f2611224da-1---d8754z-.
eth0: Max-Forwards: 70.
eth0: Route: <sip:1.2.3.4;r2=on;lr;ftag=11409305>.
eth0: Route: <sip:192.168.106.1;r2=on;lr;ftag=11409305>.
eth0: Contact: <sip:150@192.168.7.60:5060;transport=UDP>.
eth0: To: <sip:*[hidden email];transport=UDP>;tag=as621c37a2.
eth0: From:
"jman-test"<sip:[hidden email];transport=UDP>;tag=11409305.
eth0: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
eth0: CSeq: 3 BYE.
eth0: Proxy-Authorization: Digest username="150",realm="asterisk",
   nonce="6e0d2196",uri="sip:*43@192.168.3.19",
   response="ac91faccd6e8fef383b17d04757bbdc7",algorithm=MD5.
eth0: User-Agent: Zoiper rev.3938.
eth0: Content-Length: 0.
eth0: .
eth0:
tun4: #
tun4: U 18:09:03.553586 192.168.106.1:5060 -> 192.168.3.19:5060
tun4: BYE sip:*43@192.168.3.19 SIP/2.0.
tun4: Record-Route: <sip:192.168.106.1;r2=on;lr;ftag=11409305>.
tun4: Record-Route: <sip:1.2.3.4;r2=on;lr;ftag=11409305>.
tun4: Via: SIP/2.0/UDP 192.168.106.1:5060;branch=z9hG4bK84c8.ca5a3281.0.
tun4: Via: SIP/2.0/UDP 192.168.7.60:5060;rport=5060;
   received=221.221.241.189;
   branch=z9hG4bK-d8754z-8ae3d2f2611224da-1---d8754z-.
tun4: Max-Forwards: 70.
tun4: Contact: <sip:150@192.168.106.1:5060;transport=UDP>.
tun4: To: <sip:*[hidden email];transport=UDP>;tag=as621c37a2.
tun4: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
tun4: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
tun4: CSeq: 3 BYE.
tun4: Proxy-Authorization: Digest username="150",realm="asterisk",
   nonce="6e0d2196",uri="sip:*43@192.168.3.19",
   response="ac91faccd6e8fef383b17d04757bbdc7",algorithm=MD5.
tun4: User-Agent: Zoiper rev.3938.
tun4: Content-Length: 0.
tun4: .
tun4:

tun4: 18:09:03.576347 IP 192.168.3.19.11948 > 192.168.106.1.35016: UDP,
length 172
eth0: 18:09:03.576422 IP 1.2.3.4.35006 > 192.168.7.60.8000: UDP, length 172
tun4: 18:09:03.596299 IP 192.168.3.19.11948 > 192.168.106.1.35016: UDP,
length 172
eth0: 18:09:03.596354 IP 1.2.3.4.35006 > 192.168.7.60.8000: UDP, length 172
[...]

eth0: #
eth0: U 18:09:03.793383 1.2.3.4:5060 -> 221.221.241.189:5060
eth0: SIP/2.0 200 OK.
eth0: Via: SIP/2.0/UDP 1.2.3.4:5060;rport=5060;
   received=221.221.241.189;
   branch=z9hG4bK-d8754z-8ae3d2f2611224da-1---d8754z-.
eth0: Record-Route: <sip:192.168.106.1;r2=on;lr;ftag=11409305>.
eth0: Record-Route: <sip:1.2.3.4;r2=on;lr;ftag=11409305>.
eth0: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
eth0: To: <sip:*[hidden email];transport=UDP>;tag=as621c37a2.
eth0: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
eth0: CSeq: 3 BYE.
eth0: User-Agent: Asterisk PBX.
eth0: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
   SUBSCRIBE, NOTIFY.
eth0: Supported: replaces.
eth0: Contact: <sip:*43@192.168.3.19>.
eth0: Content-Length: 0.
eth0: .
eth0:
tun4: #
tun4: U 18:09:03.793193 192.168.3.19:5060 -> 192.168.106.1:5060
tun4: SIP/2.0 200 OK.
tun4: Via: SIP/2.0/UDP 192.168.3.19:5060;
   branch=z9hG4bK84c8.ca5a3281.0;received=192.168.106.1.
tun4: Via: SIP/2.0/UDP 192.168.7.60:5060;rport=5060;
   received=221.221.241.189;
   branch=z9hG4bK-d8754z-8ae3d2f2611224da-1---d8754z-.
tun4: Record-Route: <sip:192.168.106.1;r2=on;lr;ftag=11409305>.
tun4: Record-Route: <sip:1.2.3.4;r2=on;lr;ftag=11409305>.
tun4: From: "jman-test"<sip:[hidden email];transport=UDP>;
   tag=11409305.
tun4: To: <sip:*[hidden email];transport=UDP>;tag=as621c37a2.
tun4: Call-ID: Nzg5MTBmNDcwNzhmNjEwM2YwNjFjZTRhN2JlZDRjZDk..
tun4: CSeq: 3 BYE.
tun4: User-Agent: Asterisk PBX.
tun4: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
   SUBSCRIBE, NOTIFY.
tun4: Supported: replaces.
tun4: Contact: <sip:*43@192.168.3.19>.
tun4: Content-Length: 0.
tun4: .
tun4:

More RTPProxy logs:
[...]
May 30 18:09:09 horseman rtpproxy[1367]: INFO:process_rtp: session
   timeout
May 30 18:09:09 horseman rtpproxy[1367]: INFO:remove_session: RTP stats:
   752 in from callee, 0 in from caller, 752 relayed, 0 dropped
May 30 18:09:09 horseman rtpproxy[1367]: INFO:remove_session: RTCP
   stats: 3 in from callee, 0 in from caller, 3 relayed, 0 dropped
May 30 18:09:09 horseman rtpproxy[1367]: INFO:remove_session: session on
   ports 35010/35018 is cleaned up



----------------------------------------------------------------------
opensips.cfg:

debug=3
fork=yes
log_stderror=no

check_via=no    # (cmd. line: -v)
dns=no          # (cmd. line: -r)
rev_dns=no      # (cmd. line: -R)
auto_aliases=no
listen=udp:eth0
listen=udp:tun4
children=1
mhomed=1
disable_tcp=yes
disable_dns_blacklist=true

# ------------------ module loading ----------------------------------
mpath="/usr/lib/opensips/modules/"

loadmodule "mi_fifo.so"
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")

loadmodule "textops.so"
loadmodule "xlog.so"
loadmodule "signaling.so"
loadmodule "sl.so"

loadmodule "tm.so"
# -- tm params --
modparam("tm", "fr_inv_timer", 100)
modparam("tm", "fr_inv_timer_avp", "$avp(i:26)")
modparam("tm", "fr_timer", 10)
modparam("tm", "fr_timer_avp", "$avp(i:25)")
modparam("tm", "onreply_avp_mode", 1)

loadmodule "rr.so"

loadmodule "usrloc.so"
modparam("usrloc", "db_mode",   0)
modparam("usrloc", "nat_bflag", 6)

loadmodule "registrar.so"
modparam("registrar", "method_filtering", 1)

loadmodule "nathelper.so"
modparam("nathelper", "rtpproxy_sock", "/var/run/rtpproxy.sock")
modparam("nathelper|registrar", "received_avp", "$avp(i:42)")
modparam("nathelper", "ping_nated_only", 1)
modparam("nathelper", "sipping_bflag", 7)
modparam("nathelper", "sipping_from", "sip:[hidden email]")

# -------------------------  request routing logic -------------------

# main routing logic

route{
        xlog("L_ERR","Source IP:  $si, Received IP: $Ri, method:  $rm\n");

         if (uri==myself) {
                 sl_send_reply("404", "Not Found");
                 exit;
         };

         # NAT detection
         route(2);

         if (!method=="REGISTER") {
                xlog("L_ERR","! is_method REGISTER\n");
                 record_route();
         }

        if (is_method("REGISTER"))
        {
                xlog("L_ERR","is_method REGISTER\n");
                if (!save("location","0x02")) {
                        xlog("L_ERR","! save location\n");
                        sl_reply_error();
                } else {
                        xlog("L_ERR","saved location\n");
                }
        } else {
                xlog("L_ERR","! is_method REGISTER\n");
                if ($Ri == "192.168.106.1") {
                        xlog("L_ERR","looking up location\n");
                        if (!lookup("location")) {
                                switch ($retcode) {
                                        case -1:
                                                xlog("L_ERR","lookup location: no contact found\n");
                                        case -3:
                                                xlog("L_ERR","lookup location: internal error\n");
                                                t_newtran();
                                                t_reply("404", "Not Found");
                                                exit;
                                        case -2:
                                                xlog("L_ERR","lookup location: contact found, method not
supported\n");
                                                sl_send_reply("405", "Method Not Allowed");
                                                exit;
                                }
                        } else {
                                xlog("L_ERR"," contact found, socket:  $fs\n");
                        }
                }
        }

         if (loose_route()) {
                xlog("L_ERR","loose_route\n");
                 route(1);
         };

         route(1);
}

route[1] {
        # do rtpproxy
        route(3);

         if (!t_relay()) {
                 sl_reply_error();
         };
         exit;
}


route[2]{
         force_rport();
         if (nat_uac_test("19")) {
                 xlog("L_ERR","  nat_uac_test(19)");
                 if (method=="REGISTER") {
                         fix_nated_register();
                 } else {
                         fix_nated_contact();
                 };
                 setflag(5);
         };
}

route[3]{
        # start rtpproxy on INVITEs
       
         if (is_method("INVITE")) {
                 xlog("L_ERR","is_method INVITE\n");
                 t_on_branch("2");
                if (nat_uac_test("19")) {
                 xlog("L_ERR","  nat_uac_test(19): fix_nated_sdp");
                        fix_nated_sdp("8");
                }

                 if ($Ri == "192.168.106.1") {
                         xlog("L_ERR","  INVITE received on internal IP\n");
                         #if (rtpproxy_offer("FAI","192.168.254.1"))
                         if (rtpproxy_offer("FAI"))
                                 t_on_reply("3");
                 } else {
                         xlog("L_ERR","  INVITE received on external IP\n");
                         #if (rtpproxy_offer("FAE","1.2.3.4"))
                         if (rtpproxy_offer("FAE"))
                                 t_on_reply("3");
                 }
                 #t_on_reply("3");
                 t_on_failure("3");
         }
}

onreply_route[3] {
         xlog("L_ERR","onreply_route[3], source IP $si, method $rm\n");
         xlog("incoming reply\n");
         if (status=~"(183)|(2[0-9][0-9])") {
                 if ($Ri == "192.168.254.1") {
                         xlog("L_ERR","  INVITE reply received on
internal IP\n");
                         #fix_nated_sdp("2","1.2.3.4");
                         #if (rtpproxy_answer("FAI","1.2.3.4"))
                         if (rtpproxy_answer("FAI"))
                                 t_on_reply("1");
                 } else {
                         xlog("L_ERR","  INVITE reply received on
external IP\n");
                         #fix_nated_sdp("2","1.2.3.4");
                         #if (rtpproxy_answer("FAE","192.168.254.1"))
                         if (rtpproxy_answer("FAE"))
                                 t_on_reply("1");
                 }
         }
}

failure_route[3] {
         xlog("L_ERR","failure_route[3], source IP $si, method $rm\n");
         if (t_was_cancelled()) {
                 xlog("L_ERR","t_was_cancelled\n");
                 exit;
         }
}


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users