Klaus / Daniel
Thanks again for assistance with this.
I've tried the solution based on add_contact_alias() and handle_ruri_alias() and it works perfectly.
Richard
On 22 June 2012 13:47, Klaus Darilion klaus.mailinglists@pernau.at wrote:
On 22.06.2012 13:50, Richard Brady wrote:
Thanks guys, fantastic answers.
You mention that NAT detection happens before save() and the flag is set by lookup() which makes much more sense. However, if Kamailio is not the registrar, as is the case with my current project, those functions are not called, so an alternative is needed. There are clearly several options.
The solution I have gone for is to replace fix_nated_register() with fix_nated_contact() so that the REGISTER request is relayed with a modified Contact header containing the external ip:port of the client.
The cleanest solution would be to use add_contact_alias() and handle_ruri_alias(). The do not change the contact but put the public address into a uri parameter. Thus, the URI seen by the client is always the one it sends: http://www.kamailio.org/docs/modules/3.2.x/modules_k/nathelper.html#id255043...
That is then stored by the registrar (FreeSWITCH in my case) and used later to originate calls for that user. The FreeSWITCH know to send those calls to Kamailio through either use of the Path header and module in Kamailio, or through static configuration of fs_path or proxy parameters in FreeSWITCH.
This is fine.
The works for the first INVITE to the registered client behind NAT. But that client sends back a 200 OK with a Contact header containing its private IP address, and so fix_nated_contact() needs to be invoked on that response, and normally it would be due to FLB_NATB being set, but if Kamailio was not the registrar then that flag is not set. So I need to detect NAT on the client at the time of receiving the reply, or alternatively by having the registrar store a cookie and setting it based on that.
You are correct. For in-dialog messages received from SIP clients I would always use add_contact_alias() and remove the NAT flags completely.
I suppose then my next question then is can I call nat_uac_test() on a UAS?
Today, almost any SIP clients are SIP symmetric. This means, that they receive SIP from the some port/connection where they send. Thus, skip the NAT tests completely and always use add_contact_alias() for messages receive from SIP clients and handle_ruri_alias() for messages sent to SIP clients.
Depending on if you use Freeswitch also as media relay you can also remove the media proxy stuff from the Kamailio config.
On important thing is NAT-keep-alive. This is usually done by nathelper module by querying the location table for contact with NAT-flag set. Thus, either you do NAT keep-alive by freeswitch (e.g sending OPTIONS requests) or do it in your Kamailio proxy (e.g. set the nat_bflag http://www.kamailio.org/docs/modules/3.2.x/modules_k/usrloc.html#id2541477 and call save("location","0x02") before relaying REGISTER to freeswitch. Then Kamailio will do NAT-pinging. Note, if you want to keep-alive only for successfully registered clients, you man want to call save() in the reply-route of the REGISTER request).
regards Klaus
This is a great thread, really full of answers and concepts for me atleast. :)
On Mon, Jun 25, 2012 at 5:57 PM, Richard Brady rnbrady@gmail.com wrote:
Klaus / Daniel
Thanks again for assistance with this.
I've tried the solution based on add_contact_alias() and handle_ruri_alias() and it works perfectly.
Richard
On 22 June 2012 13:47, Klaus Darilion klaus.mailinglists@pernau.at wrote:
On 22.06.2012 13:50, Richard Brady wrote:
Thanks guys, fantastic answers.
You mention that NAT detection happens before save() and the flag is set by lookup() which makes much more sense. However, if Kamailio is not the registrar, as is the case with my current project, those functions are not called, so an alternative is needed. There are clearly several options.
The solution I have gone for is to replace fix_nated_register() with fix_nated_contact() so that the REGISTER request is relayed with a modified Contact header containing the external ip:port of the client.
The cleanest solution would be to use add_contact_alias() and handle_ruri_alias(). The do not change the contact but put the public address into a uri parameter. Thus, the URI seen by the client is always
the
one it sends:
http://www.kamailio.org/docs/modules/3.2.x/modules_k/nathelper.html#id255043...
That is then stored by the registrar (FreeSWITCH in my case) and used later to originate calls for that user. The FreeSWITCH know to send those calls to Kamailio through either use of the Path header and module in Kamailio, or through static configuration of fs_path or proxy parameters in FreeSWITCH.
This is fine.
The works for the first INVITE to the registered client behind NAT. But that client sends back a 200 OK with a Contact header containing its private IP address, and so fix_nated_contact() needs to be invoked on that response, and normally it would be due to FLB_NATB being set, but if Kamailio was not the registrar then that flag is not set. So I need to detect NAT on the client at the time of receiving the reply, or alternatively by having the registrar store a cookie and setting it based on that.
You are correct. For in-dialog messages received from SIP clients I would always use add_contact_alias() and remove the NAT flags completely.
I suppose then my next question then is can I call nat_uac_test() on a UAS?
Today, almost any SIP clients are SIP symmetric. This means, that they receive SIP from the some port/connection where they send. Thus, skip the NAT tests completely and always use add_contact_alias() for messages
receive
from SIP clients and handle_ruri_alias() for messages sent to SIP
clients.
Depending on if you use Freeswitch also as media relay you can also
remove
the media proxy stuff from the Kamailio config.
On important thing is NAT-keep-alive. This is usually done by nathelper module by querying the location table for contact with NAT-flag set.
Thus,
either you do NAT keep-alive by freeswitch (e.g sending OPTIONS
requests) or
do it in your Kamailio proxy (e.g. set the nat_bflag
http://www.kamailio.org/docs/modules/3.2.x/modules_k/usrloc.html#id2541477
and call save("location","0x02") before relaying REGISTER to freeswitch. Then Kamailio will do NAT-pinging. Note, if you want to keep-alive only
for
successfully registered clients, you man want to call save() in the reply-route of the REGISTER request).
regards Klaus
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 6/25/12 3:34 PM, SamyGo wrote:
This is a great thread, really full of answers and concepts for me atleast. :)
looks like we will have a new wiki page with the digested content of this thread :-)
Cheers, Daniel
On Mon, Jun 25, 2012 at 5:57 PM, Richard Brady <rnbrady@gmail.com mailto:rnbrady@gmail.com> wrote:
Klaus / Daniel Thanks again for assistance with this. I've tried the solution based on add_contact_alias() and handle_ruri_alias() and it works perfectly. Richard On 22 June 2012 13:47, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> wrote: > > > On 22.06.2012 13:50, Richard Brady wrote: >> >> Thanks guys, fantastic answers. >> >> You mention that NAT detection happens before save() and the flag is set >> by lookup() which makes much more sense. However, if Kamailio is not the >> registrar, as is the case with my current project, those functions are >> not called, so an alternative is needed. There are clearly several >> options. >> >> The solution I have gone for is to replace fix_nated_register() with >> fix_nated_contact() so that the REGISTER request is relayed with a >> modified Contact header containing the external ip:port of the client. > > > The cleanest solution would be to use add_contact_alias() and > handle_ruri_alias(). The do not change the contact but put the public > address into a uri parameter. Thus, the URI seen by the client is always the > one it sends: > http://www.kamailio.org/docs/modules/3.2.x/modules_k/nathelper.html#id2550431 > > >> That is then stored by the registrar (FreeSWITCH in my case) and used >> later to originate calls for that user. The FreeSWITCH know to send >> those calls to Kamailio through either use of the Path header and module >> in Kamailio, or through static configuration of fs_path or proxy >> parameters in FreeSWITCH. > > > This is fine. > > >> The works for the first INVITE to the registered client behind NAT. But >> that client sends back a 200 OK with a Contact header containing its >> private IP address, and so fix_nated_contact() needs to be invoked on >> that response, and normally it would be due to FLB_NATB being set, but >> if Kamailio was not the registrar then that flag is not set. So I need >> to detect NAT on the client at the time of receiving the reply, or >> alternatively by having the registrar store a cookie and setting it >> based on that. > > > You are correct. For in-dialog messages received from SIP clients I would > always use add_contact_alias() and remove the NAT flags completely. > >> >> I suppose then my next question then is can I call nat_uac_test() on a >> UAS? > > > Today, almost any SIP clients are SIP symmetric. This means, that they > receive SIP from the some port/connection where they send. Thus, skip the > NAT tests completely and always use add_contact_alias() for messages receive > from SIP clients and handle_ruri_alias() for messages sent to SIP clients. > > Depending on if you use Freeswitch also as media relay you can also remove > the media proxy stuff from the Kamailio config. > > On important thing is NAT-keep-alive. This is usually done by nathelper > module by querying the location table for contact with NAT-flag set. Thus, > either you do NAT keep-alive by freeswitch (e.g sending OPTIONS requests) or > do it in your Kamailio proxy (e.g. set the nat_bflag > http://www.kamailio.org/docs/modules/3.2.x/modules_k/usrloc.html#id2541477 > and call save("location","0x02") before relaying REGISTER to freeswitch. > Then Kamailio will do NAT-pinging. Note, if you want to keep-alive only for > successfully registered clients, you man want to call save() in the > reply-route of the REGISTER request). > > regards > Klaus _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
I had this thread already starred here in inbox, a wiki page is definitely going to be bookmarked.
On Mon, Jun 25, 2012 at 9:44 PM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
On 6/25/12 3:34 PM, SamyGo wrote:
This is a great thread, really full of answers and concepts for me atleast. :)
looks like we will have a new wiki page with the digested content of this thread :-)
Cheers, Daniel
On Mon, Jun 25, 2012 at 5:57 PM, Richard Brady rnbrady@gmail.com wrote:
Klaus / Daniel
Thanks again for assistance with this.
I've tried the solution based on add_contact_alias() and handle_ruri_alias() and it works perfectly.
Richard
On 22 June 2012 13:47, Klaus Darilion klaus.mailinglists@pernau.at wrote:
On 22.06.2012 13:50, Richard Brady wrote:
Thanks guys, fantastic answers.
You mention that NAT detection happens before save() and the flag is
set
by lookup() which makes much more sense. However, if Kamailio is not
the
registrar, as is the case with my current project, those functions are not called, so an alternative is needed. There are clearly several options.
The solution I have gone for is to replace fix_nated_register() with fix_nated_contact() so that the REGISTER request is relayed with a modified Contact header containing the external ip:port of the client.
The cleanest solution would be to use add_contact_alias() and handle_ruri_alias(). The do not change the contact but put the public address into a uri parameter. Thus, the URI seen by the client is
always the
one it sends:
http://www.kamailio.org/docs/modules/3.2.x/modules_k/nathelper.html#id255043...
That is then stored by the registrar (FreeSWITCH in my case) and used later to originate calls for that user. The FreeSWITCH know to send those calls to Kamailio through either use of the Path header and
module
in Kamailio, or through static configuration of fs_path or proxy parameters in FreeSWITCH.
This is fine.
The works for the first INVITE to the registered client behind NAT. But that client sends back a 200 OK with a Contact header containing its private IP address, and so fix_nated_contact() needs to be invoked on that response, and normally it would be due to FLB_NATB being set, but if Kamailio was not the registrar then that flag is not set. So I need to detect NAT on the client at the time of receiving the reply, or alternatively by having the registrar store a cookie and setting it based on that.
You are correct. For in-dialog messages received from SIP clients I
would
always use add_contact_alias() and remove the NAT flags completely.
I suppose then my next question then is can I call nat_uac_test() on a UAS?
Today, almost any SIP clients are SIP symmetric. This means, that they receive SIP from the some port/connection where they send. Thus, skip
the
NAT tests completely and always use add_contact_alias() for messages
receive
from SIP clients and handle_ruri_alias() for messages sent to SIP
clients.
Depending on if you use Freeswitch also as media relay you can also
remove
the media proxy stuff from the Kamailio config.
On important thing is NAT-keep-alive. This is usually done by nathelper module by querying the location table for contact with NAT-flag set.
Thus,
either you do NAT keep-alive by freeswitch (e.g sending OPTIONS
requests) or
do it in your Kamailio proxy (e.g. set the nat_bflag
http://www.kamailio.org/docs/modules/3.2.x/modules_k/usrloc.html#id2541477
and call save("location","0x02") before relaying REGISTER to freeswitch. Then Kamailio will do NAT-pinging. Note, if you want to keep-alive only
for
successfully registered clients, you man want to call save() in the reply-route of the REGISTER request).
regards Klaus
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
On Jun 25, 2012, at 8:57 AM, Richard Brady wrote:
Klaus / Daniel
Thanks again for assistance with this.
I've tried the solution based on add_contact_alias() and handle_ruri_alias() and it works perfectly.
Richard
Do you have an example of the cfg you can share?
Fred http://qxork.com
Hi guys, sorry for the delay.
Do you have an example of the cfg you can share?
Sure thing. See attached. This doesn't contain the Path header, as I have statically configured fs_path in the dialplan on FreeSWITCH.
I am exploring a possible bug in FreeSWITCH where is advertising the wrong transport in the Contact header. More on that in the FreeSWITCH mailing-list.
Richard
-
Daniel-Constantin Mierla -
Fred Posner -
Richard Brady -
SamyGo