According to the Kamailio 1.5.x docs, force_rtp_proxy() is deprecated and rtpproxy_offer() and rtpproxy_answer() should be used instead.
Does that mean unforce_rtp_proxy() is also deprecated? If so, how should calls be cleaned up once a BYE is received? Is the orthodox approach to simply let the streams time out on their own, or should unforce_rtp_proxy() still be used here? What about when a CANCEL is received while the dialog is an early state -- should unforce_rtp_proxy() be used there too?
Thanks!
On 07/07/2009 12:14 PM, Alex Balashov wrote:
According to the Kamailio 1.5.x docs, force_rtp_proxy() is deprecated and rtpproxy_offer() and rtpproxy_answer() should be used instead.
Does that mean unforce_rtp_proxy() is also deprecated?
seems this one is not deprecated. I am still using the old style, I am going to look at the code for more insights.
From docs, rtpproxy_offer() and rtpproxy_answer() are like aliases to force_rtp_proxy(), having a more meaningful naming.
Cheers, Daniel
If so, how should calls be cleaned up once a BYE is received? Is the orthodox approach to simply let the streams time out on their own, or should unforce_rtp_proxy() still be used here? What about when a CANCEL is received while the dialog is an early state -- should unforce_rtp_proxy() be used there too?
Thanks!
Daniel-Constantin Mierla wrote:
On 07/07/2009 12:14 PM, Alex Balashov wrote:
According to the Kamailio 1.5.x docs, force_rtp_proxy() is deprecated and rtpproxy_offer() and rtpproxy_answer() should be used instead.
Does that mean unforce_rtp_proxy() is also deprecated?
seems this one is not deprecated. I am still using the old style, I am going to look at the code for more insights.
From docs, rtpproxy_offer() and rtpproxy_answer() are like aliases to force_rtp_proxy(), having a more meaningful naming.
I appreciate your efforts to find out, thank you.
My main concern, aside from whether to use unforce_rtp_proxy(), is to know what is the orthodox way to manipulate rtpproxy in response to CANCELs (at early dialog state as well as not) and BYEs. Also, per RFC 3261 an SDP answer may also come in an ACK, so I guess that needs to be handled too.
Just wondering if there is some reference implementation or boilerplate code that covers all the scenarios.
Thank you!
On 07/07/2009 12:41 PM, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
On 07/07/2009 12:14 PM, Alex Balashov wrote:
According to the Kamailio 1.5.x docs, force_rtp_proxy() is deprecated and rtpproxy_offer() and rtpproxy_answer() should be used instead.
Does that mean unforce_rtp_proxy() is also deprecated?
seems this one is not deprecated. I am still using the old style, I am going to look at the code for more insights.
From docs, rtpproxy_offer() and rtpproxy_answer() are like aliases to force_rtp_proxy(), having a more meaningful naming.
I appreciate your efforts to find out, thank you.
My main concern, aside from whether to use unforce_rtp_proxy(), is to know what is the orthodox way to manipulate rtpproxy in response to CANCELs (at early dialog state as well as not) and BYEs. Also, per RFC 3261 an SDP answer may also come in an ACK, so I guess that needs to be handled too.
Just wondering if there is some reference implementation or boilerplate code that covers all the scenarios.
From my point of view, since the rtp proxying applies to particular cases of SIP, audio/video calls, I would preferred to deal with only to functions: - rtpproxy_session_init(flags) - rtpproxy_session_update()
First one to be used with initial invite and the second for replies, re-invite, cancel, ack, bye. The other logic, like whether sdp is in invite/200ok or 200ok/ack could be hidden inside the module and/or rtpproxy.
I think there is room to add these functions, calling inside the other existing functions with the right flags. Existing functions can stay for the sake of flexibility, for those willing to deal with more complex config file coding.
Right now, I am not aware of the code that covers the all scenarios in one invocation, but there can be done in the config with some routes (partial pseudo-code): route[rtp_session_init] { if(!is_method("INVITE") || has_totag()) return; if(!has_sdp()) { setflag(nosdp); return; } ... force_rtp_proxy(); }
route[rtp_session_update] { if(is_method("CANCEL|BYE") { unforce_rtp_proxy(); return; } if(is_reply()) { if(isflagset(nosdp)) { ... } else { ... } return; } if(is_method("ACK") && has_sdp()) { ... } }
cc-ed the k users list, just in case someone pops up a better idea.
Cheers, Daniel
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
cc-ed the k users list, just in case someone pops up a better idea.
Having to invoke rtpproxy in each message (initial INVITE, reply, ACK?, re-INVITE...) makes the config file really ugly. While it provides flexibility (using different flags for offers and responses) I think it's not needed in most of the cases.
If would be really great a rtpproxy function working for transaction (instead of working for each message). For example:
if (is_method("INVITE")) { tran_use_rtpproxy(FLAGS); }
This "tran_use_rtpproxy()" could handle rtpproxy invocations for the request (if it has SDP) for the responses (if they have SDP), for ACK (if it's has SDP) and for CANCEL. It would add some info to the transaction and some callbacks to tm module to invoke rtpproxy functions. This is, a rtpproxy function depending on TM module.
Iñaki Baz Castillo schrieb:
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
cc-ed the k users list, just in case someone pops up a better idea.
Having to invoke rtpproxy in each message (initial INVITE, reply, ACK?, re-INVITE...) makes the config file really ugly. While it provides flexibility (using different flags for offers and responses) I think it's not needed in most of the cases.
If would be really great a rtpproxy function working for transaction (instead of working for each message). For example:
if (is_method("INVITE")) { tran_use_rtpproxy(FLAGS); }
In this case you can use mediaproxy or someone have to change the rtpproxy module to rely on dialog module to get information about session updates (as mediaproxy module does)
regards klaus
This "tran_use_rtpproxy()" could handle rtpproxy invocations for the request (if it has SDP) for the responses (if they have SDP), for ACK (if it's has SDP) and for CANCEL. It would add some info to the transaction and some callbacks to tm module to invoke rtpproxy functions. This is, a rtpproxy function depending on TM module.
2009/7/7 Klaus Darilion klaus.mailinglists@pernau.at:
If would be really great a rtpproxy function working for transaction (instead of working for each message). For example:
if (is_method("INVITE")) { tran_use_rtpproxy(FLAGS); }
In this case you can use mediaproxy or someone have to change the rtpproxy module to rely on dialog module to get information about session updates (as mediaproxy module does)
No, I don't want it based on dialog module (as Mediaproxy offers) since dialgo module has a great limitation: it doesn't handle the case in which various early-dialogs occur, and perhaps rtp/media-proxy is just required for natted branches. This is not possible with "engage_mediaproxy()" function.
What I mean is a *transaction* based function, so "tran_use_rtpproxy()" just should be invoked during initial INVITE request (not in responses, ACK or CANCEL), re-INVITE and BYE.
On 07/07/2009 03:19 PM, Iñaki Baz Castillo wrote:
2009/7/7 Klaus Darilion klaus.mailinglists@pernau.at:
If would be really great a rtpproxy function working for transaction (instead of working for each message). For example:
if (is_method("INVITE")) { tran_use_rtpproxy(FLAGS); }
In this case you can use mediaproxy or someone have to change the rtpproxy module to rely on dialog module to get information about session updates (as mediaproxy module does)
No, I don't want it based on dialog module
I second this one, it will add pretty much overload.
However, it can be very simple, even without tm support. If calling like rtpproxy_session_init() adds a nat=yes in the Record-Route, all processing can be done in rtpproxy_session_update() by discovery of that parameter or not.
rtpproxy_sessipn_update() can be done automatically by registering pre-script callbacks for requests and replies, so the config file will become very simple. It is not something complex to implement, just some spare time, the code is there, needs some re-structuring in new functions.
There will be a dependency on rr module, but I guess that is fine.
Cheers, Daniel
(as Mediaproxy offers) since dialgo module has a great limitation: it doesn't handle the case in which various early-dialogs occur, and perhaps rtp/media-proxy is just required for natted branches. This is not possible with "engage_mediaproxy()" function.
What I mean is a *transaction* based function, so "tran_use_rtpproxy()" just should be invoked during initial INVITE request (not in responses, ACK or CANCEL), re-INVITE and BYE.
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
No, I don't want it based on dialog module
I second this one, it will add pretty much overload.
However, it can be very simple, even without tm support. If calling like rtpproxy_session_init() adds a nat=yes in the Record-Route, all processing can be done in rtpproxy_session_update() by discovery of that parameter or not.
rtpproxy_sessipn_update() can be done automatically by registering pre-script callbacks for requests and replies, so the config file will become very simple. It is not something complex to implement, just some spare time, the code is there, needs some re-structuring in new functions.
There will be a dependency on rr module, but I guess that is fine.
Hi Daniel, please clarify me is your suggestion would require running (in the config script) the function rtpproxy_session_update() in onreply_route.
If this info is not appended to the transaction info (so doesn't use TM module) then it should be manually invoked in onreply_route, right?
What I suggested is that the rtpproxy function is just invoked for the request, it adds some info to the transaction so rtpproxy is also invoked in the response/ACK.
However, I think that nathelper should perform in a transparent way the detection of SDP so it wouldn't be required to inspect the body type in the config file (which makes it really ugly).
Regards.
Hello Inaki,
On 07/07/2009 03:42 PM, Iñaki Baz Castillo wrote:
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
No, I don't want it based on dialog module
I second this one, it will add pretty much overload.
However, it can be very simple, even without tm support. If calling like rtpproxy_session_init() adds a nat=yes in the Record-Route, all processing can be done in rtpproxy_session_update() by discovery of that parameter or not.
rtpproxy_sessipn_update() can be done automatically by registering pre-script callbacks for requests and replies, so the config file will become very simple. It is not something complex to implement, just some spare time, the code is there, needs some re-structuring in new functions.
There will be a dependency on rr module, but I guess that is fine.
Hi Daniel, please clarify me is your suggestion would require running (in the config script) the function rtpproxy_session_update() in onreply_route.
no. The script needs just rtpproxy_session_init(). All the rest is done automatically in the module.
Inside a module, you can register functions that are executed before executing the configuration file for each sip message.
So, here is what is needed: - registers callback functions for pre-script event for reply and request - if it is an initial invite, then skip processing in the callback - if it is a reply or a in-dialog request, search for Record-Route/Route headers matching "myself" - if the R-R/R headers have "nat=xyz", then process rtpproxy_session_update() - export to config file the function rtpproxy_session_init() that has to be called for initial invite and append to R-R the parameter "nat=xyz" (this should be configurable)
In the config file, just call rtpproxy_session_init() and that is. Probably this function needs some flags as parameter to control the behaviour, flags that could be added as value to nat parameter, if needed later.
Cheers, Daniel
If this info is not appended to the transaction info (so doesn't use TM module) then it should be manually invoked in onreply_route, right?
What I suggested is that the rtpproxy function is just invoked for the request, it adds some info to the transaction so rtpproxy is also invoked in the response/ACK.
However, I think that nathelper should perform in a transparent way the detection of SDP so it wouldn't be required to inspect the body type in the config file (which makes it really ugly).
Regards.
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
Hi Daniel, please clarify me is your suggestion would require running (in the config script) the function rtpproxy_session_update() in onreply_route.
no. The script needs just rtpproxy_session_init(). All the rest is done automatically in the module.
Inside a module, you can register functions that are executed before executing the configuration file for each sip message.
So, here is what is needed:
- registers callback functions for pre-script event for reply and request
- if it is an initial invite, then skip processing in the callback
- if it is a reply or a in-dialog request, search for Record-Route/Route
headers matching "myself"
- if the R-R/R headers have "nat=xyz", then process
rtpproxy_session_update()
- export to config file the function rtpproxy_session_init() that has to be
called for initial invite and append to R-R the parameter "nat=xyz" (this should be configurable)
In the config file, just call rtpproxy_session_init() and that is. Probably this function needs some flags as parameter to control the behaviour, flags that could be added as value to nat parameter, if needed later.
ok, that sounds really nice :)
I somewhat object to the idea that rtpproxy control socket functions should be exposed in the nathelper module. Why does mediaproxy get its own module? What if I want to relay media for some purpose other than far-end NAT traversal (for example, passive in-line tap / monitor-port based call recording)?
Iñaki Baz Castillo wrote:
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
Hi Daniel, please clarify me is your suggestion would require running (in the config script) the function rtpproxy_session_update() in onreply_route.
no. The script needs just rtpproxy_session_init(). All the rest is done automatically in the module.
Inside a module, you can register functions that are executed before executing the configuration file for each sip message.
So, here is what is needed:
- registers callback functions for pre-script event for reply and request
- if it is an initial invite, then skip processing in the callback
- if it is a reply or a in-dialog request, search for Record-Route/Route
headers matching "myself"
- if the R-R/R headers have "nat=xyz", then process
rtpproxy_session_update()
- export to config file the function rtpproxy_session_init() that has to be
called for initial invite and append to R-R the parameter "nat=xyz" (this should be configurable)
In the config file, just call rtpproxy_session_init() and that is. Probably this function needs some flags as parameter to control the behaviour, flags that could be added as value to nat parameter, if needed later.
ok, that sounds really nice :)
2009/7/7 Alex Balashov abalashov@evaristesys.com:
I somewhat object to the idea that rtpproxy control socket functions should be exposed in the nathelper module. Why does mediaproxy get its own module? What if I want to relay media for some purpose other than far-end NAT traversal (for example, passive in-line tap / monitor-port based call recording)?
AFAIK NAT signalling functions are now handled by nat-traversal module, more powerful than nathelper of mediaproxy (for signalling, not for media). So nathelper module remains just to control RtpProxy. Yes, it could be renamed to "rtpproxy" and NAT signalling functions be dropped from the module.
Iñaki Baz Castillo wrote:
2009/7/7 Alex Balashov abalashov@evaristesys.com:
I somewhat object to the idea that rtpproxy control socket functions should be exposed in the nathelper module. Why does mediaproxy get its own module? What if I want to relay media for some purpose other than far-end NAT traversal (for example, passive in-line tap / monitor-port based call recording)?
AFAIK NAT signalling functions are now handled by nat-traversal module, more powerful than nathelper of mediaproxy (for signalling, not for media). So nathelper module remains just to control RtpProxy. Yes, it could be renamed to "rtpproxy" and NAT signalling functions be dropped from the module.
Just what is the superior merit of nat-traversal vs. nathelper? I have continued to use nathelper, believing nat-traversal to be an artifice of the OpenSIPS camp since it was put out by AG Projects...
On Dienstag, 7. Juli 2009, Alex Balashov wrote:
I somewhat object to the idea that rtpproxy control socket functions should be exposed in the nathelper module. Why does mediaproxy get its own module? What if I want to relay media for some purpose other than far-end NAT traversal (for example, passive in-line tap / monitor-port based call recording)?
AFAIK NAT signalling functions are now handled by nat-traversal module, more powerful than nathelper of mediaproxy (for signalling, not for media). So nathelper module remains just to control RtpProxy. Yes, it could be renamed to "rtpproxy" and NAT signalling functions be dropped from the module.
Just what is the superior merit of nat-traversal vs. nathelper? I have continued to use nathelper, believing nat-traversal to be an artifice of the OpenSIPS camp since it was put out by AG Projects...
Hi Alex,
if i remember correctly one of the original ideas behind the nat-traversal module was to consolidate the helper functionality needed to support nat traversal into one module, instead of having two more or less redundant implementations in nathelper and mediaproxy modules. Not sure how the current state of integration is at the moment.. I also think that a clear separation of efforts would be a good thing.
If i understand the module docs correctly then nat_traversal seems to support better and/ or more efficient nat keep alive, among others. Its not restricted to only ping users from location table, for example.
Cheers,
Henning
2009/7/7 Henning Westerholt henning.westerholt@1und1.de:
if i remember correctly one of the original ideas behind the nat-traversal module was to consolidate the helper functionality needed to support nat traversal into one module, instead of having two more or less redundant implementations in nathelper and mediaproxy modules. Not sure how the current state of integration is at the moment.. I also think that a clear separation of efforts would be a good thing.
If i understand the module docs correctly then nat_traversal seems to support better and/ or more efficient nat keep alive, among others. Its not restricted to only ping users from location table, for example.
I use nat-traversal module and it's MUCH MUCH more powerful than nathelper, for sure. It allows NAT keepalive for non registered users when they are in a INVITE or SUBSCRIBE dialog.
Alex, please, take a look to nat-traversal full documentation.
On 07/07/2009 07:09 PM, Iñaki Baz Castillo wrote:
2009/7/7 Henning Westerholt henning.westerholt@1und1.de:
if i remember correctly one of the original ideas behind the nat-traversal module was to consolidate the helper functionality needed to support nat traversal into one module, instead of having two more or less redundant implementations in nathelper and mediaproxy modules. Not sure how the current state of integration is at the moment.. I also think that a clear separation of efforts would be a good thing.
If i understand the module docs correctly then nat_traversal seems to support better and/ or more efficient nat keep alive, among others. Its not restricted to only ping users from location table, for example.
I use nat-traversal module and it's MUCH MUCH more powerful than nathelper, for sure.
I do not agree at all with this, when comes to flexibility. nat_traversal main problem is the relying on dialog module, which adds lot of overhead to a proxy.
For presence, like for registration, the keepalive should be done by the endpoint (registrar, presence server), otherwise you get into scalability issues.
Cheers, Daniel
It allows NAT keepalive for non registered users when they are in a INVITE or SUBSCRIBE dialog.
Alex, please, take a look to nat-traversal full documentation.
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
I use nat-traversal module and it's MUCH MUCH more powerful than nathelper, for sure.
I do not agree at all with this, when comes to flexibility. nat_traversal main problem is the relying on dialog module, which adds lot of overhead to a proxy.
Not sure now if dialog module is fully required for all the cases... It's just required if you want to mantain nat keepalive for calls initiated by non registered users.
For presence, like for registration, the keepalive should be done by the endpoint (registrar, presence server), otherwise you get into scalability issues.
Imagine a presence agent machine (behind NAT) subscribing to the presence of some users without registering. How to mantain the keepalivee in Kamailio (without using nat_traversal module)? The dirty solution would be decrease the notification interval, that of course would be a wrong choice.
On 07/07/2009 07:27 PM, Iñaki Baz Castillo wrote:
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
I use nat-traversal module and it's MUCH MUCH more powerful than nathelper, for sure.
I do not agree at all with this, when comes to flexibility. nat_traversal main problem is the relying on dialog module, which adds lot of overhead to a proxy.
Not sure now if dialog module is fully required for all the cases... It's just required if you want to mantain nat keepalive for calls initiated by non registered users.
it does not bind to usrloc, so I think it has no idea who is registered or not, unless it is done via some parameters.
For presence, like for registration, the keepalive should be done by the endpoint (registrar, presence server), otherwise you get into scalability issues.
Imagine a presence agent machine (behind NAT) subscribing to the presence of some users without registering.
First I think that is not a typical use case, but more than that, imagine you have 100 000 presence sessions spread across couple presence servers and about the same number of calls going through your proxy.
Do you think it will deals nicely doing pings? While for calls, nat pinhole is handled by the registrars, same can be done by the presence servers.
Architectural point of view, it is even better doing so, as once there is no reply, the presence dialog can be destroyed and resources freed on server side. With nat_traversal approach, you consume twice resources in the server side, as you keep dialog attributes on proxy and presence server, therefore you double the scalability issues.
How to mantain the keepalivee in Kamailio (without using nat_traversal module)? The dirty solution would be decrease the notification interval, that of course would be a wrong choice.
Why would be that more wrong than sending keepalives from a stateful proxy? See above, you keep the dialog only once on server side.
Cheers, Daniel
El Martes, 7 de Julio de 2009, Daniel-Constantin Mierla escribió:
On 07/07/2009 07:27 PM, Iñaki Baz Castillo wrote:
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
I use nat-traversal module and it's MUCH MUCH more powerful than nathelper, for sure.
I do not agree at all with this, when comes to flexibility. nat_traversal main problem is the relying on dialog module, which adds lot of overhead to a proxy.
Not sure now if dialog module is fully required for all the cases... It's just required if you want to mantain nat keepalive for calls initiated by non registered users.
it does not bind to usrloc, so I think it has no idea who is registered or not, unless it is done via some parameters.
-------- REGISTER - called before save_location() or t_relay() (depending on whether the proxy that received the REGISTER is also handling registration for that subscriber or not). It will determine from either the stateless reply generated by save_location() or the TM relayed reply if the registration was successful and what is its expiration time. If the registration was successful it will mark the given NAT endpoint for keepalive for the registration condition using the detected expiration time. If the REGISTER request is discarded after nat_keepalive() was called or if it intercepts a negative reply it will have no effect and the registration condition will not be activated for that endpoint. --------
The INVITE case uses dialog module, but in order to avoid it, just don't invoke "nat_keepalive()" funtion for INVITE (the caller is already being pinged id it was registered behind NAT).
For presence, like for registration, the keepalive should be done by the endpoint (registrar, presence server), otherwise you get into scalability issues.
Imagine a presence agent machine (behind NAT) subscribing to the presence of some users without registering.
First I think that is not a typical use case, but more than that, imagine you have 100 000 presence sessions spread across couple presence servers and about the same number of calls going through your proxy.
Do you think it will deals nicely doing pings? While for calls, nat pinhole is handled by the registrars, same can be done by the presence servers.
Architectural point of view, it is even better doing so, as once there is no reply, the presence dialog can be destroyed and resources freed on server side. With nat_traversal approach, you consume twice resources in the server side, as you keep dialog attributes on proxy and presence server, therefore you double the scalability issues.
Not true, just *one* keep alive is performed per *source* (public IP:port):
---------- A user agent's NAT entry point may be kept alive for one or multiple of the conditions listed above. Even when a NAT endpoint is kept alive for more than one condition, only one keepalive message is sent to that NAT endpoint. The presence of multiple conditions for a NAT endpoint, only guarantees that the network visibility for a user agent based on a certain condition will be available while that condition is true, independently of the other conditions. When all the conditions to keepalive a NAT endpoint will disappear, that endpoint will be removed from the list with the NAT endpoints that need to be kept alive. ----------
How to mantain the keepalivee in Kamailio (without using nat_traversal module)? The dirty solution would be decrease the notification interval, that of course would be a wrong choice.
Why would be that more wrong than sending keepalives from a stateful proxy? See above, you keep the dialog only once on server side.
------------ SUBSCRIBE - called before handle_subscribe() or t_relay() (depending on whether the proxy that received the SUBSCRIBE is also handling subscriptions for that subscriber or not). It will determine from either the stateless reply generated by handle_subscribe() or the TM relayed reply if the subscription was successful and what is its expiration time. If the subscription was successful it will mark the given NAT endpoint for keepalive for the subscription condition using the detected expiration time. If the SUBSCRIBE request is discarded after nat_keepalive() was called or if it intercepts a negative reply it will have no effect and the subscription condition will not be activated for that endpoint. It should be called for every SUBSCRIBE received, not only the ones that start a subscription (do not have a to tag), because it needs to update (extend) the expiration time for the subscription. ---------------
I think this is much better than decreasing notifications interval just because there could be users registered behind NAT. NAT keepalive should not be performed by an application (SIP presence) IMHO.
Also, imagine other typical case:
a) Using nathelper:
- UA behind NAT uses a domain with SRV failover (servers 1.1.1.1 and 2.2.2.2). - It sends the REGISTER to 1.1.1.1. - Registration expires in 10 minutes. - Proxy 1.1.1.1 mantains the keepalive. - Proxy 1.1.1.1 crashes. - UA sends an INVITE and since 1.1.1.1 doesn't respond it sends it to 2.2.2.2. - The call is established. - After 3 minutes the calleed sends a BYE. - This BYE wont reach the UA since proxy 2.2.2.2 is not mantaining NAT keepalive => Problems
b) Using nat_traversal:
- UA behind NAT uses a domain with SRV failover (servers 1.1.1.1 and 2.2.2.2). - It sends the REGISTER to 1.1.1.1. - Registration expires in 10 minutes. - Proxy 1.1.1.1 mantains the keepalive (REGISTER). - Proxy 1.1.1.1 crashes. - UA sends an INVITE and since 1.1.1.1 doesn't respond it sends it to 2.2.2.2. - The call is established. - Proxy 2.2.2.2 mantains keepalive for the call duration. - After 3 minutes the calleed sends a BYE. - This BYE will reach the UA since proxy 2.2.2.2 is mantaining NAT keepalive => OK.
Other solutions to make the above escenario working with nathelper module would be:
1) The UA mantains the keepalive with the registrar server and *with* the definitive server it sent the INVITE to (after SRV failover). How many UA's do it?
2) The UA mantain the keepalive with the registar. When detecting server failure it sends a new REGISTER to the following server (SRV).
3) Decrease the registration expiration in the server (bad idea).
Sincerely, I think nat_traversal provides much better NAT solutions than the limited nathelper module. Using dialgo module is not required at all (as I explained above), it is required just in the case you want to mantain keepalive for calls initiated by non registered users.
Regards.
On 07/07/2009 08:33 PM, Iñaki Baz Castillo wrote:
El Martes, 7 de Julio de 2009, Daniel-Constantin Mierla escribió:
On 07/07/2009 07:27 PM, Iñaki Baz Castillo wrote:
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
I use nat-traversal module and it's MUCH MUCH more powerful than nathelper, for sure.
I do not agree at all with this, when comes to flexibility. nat_traversal main problem is the relying on dialog module, which adds lot of overhead to a proxy.
Not sure now if dialog module is fully required for all the cases... It's just required if you want to mantain nat keepalive for calls initiated by non registered users.
it does not bind to usrloc, so I think it has no idea who is registered or not, unless it is done via some parameters.
REGISTER - called before save_location() or t_relay() (depending on whether the proxy that received the REGISTER is also handling registration for that subscriber or not). It will determine from either the stateless reply generated by save_location() or the TM relayed reply if the registration was successful and what is its expiration time. If the registration was successful it will mark the given NAT endpoint for keepalive for the registration condition using the detected expiration time. If the REGISTER request is discarded after nat_keepalive() was called or if it intercepts a negative reply it will have no effect and the registration condition will not be activated for that endpoint.
so it duplicated info stored by the usrloc module. It is what I meant by keeping twice information. Nathelper fetches the contact details from usrloc.
From what seems here, definitely does not deal with PATH extension.
The INVITE case uses dialog module, but in order to avoid it, just don't invoke "nat_keepalive()" funtion for INVITE (the caller is already being pinged id it was registered behind NAT).
For presence, like for registration, the keepalive should be done by the endpoint (registrar, presence server), otherwise you get into scalability issues.
Imagine a presence agent machine (behind NAT) subscribing to the presence of some users without registering.
First I think that is not a typical use case, but more than that, imagine you have 100 000 presence sessions spread across couple presence servers and about the same number of calls going through your proxy.
Do you think it will deals nicely doing pings? While for calls, nat pinhole is handled by the registrars, same can be done by the presence servers.
Architectural point of view, it is even better doing so, as once there is no reply, the presence dialog can be destroyed and resources freed on server side. With nat_traversal approach, you consume twice resources in the server side, as you keep dialog attributes on proxy and presence server, therefore you double the scalability issues.
Not true, just *one* keep alive is performed per *source* (public IP:port):
Well, again, maybe you misunderstood me in the first place. Because it is a duplication of data about endpoints in memory (in usrloc and nat_traversal, or presence server and dialog module), you get problems in scalability.
As you won't use nathelper, nat pings are performed only by nat_traversal, so if to cope with crashes of the box, you need a replication mechanism to a backup, so registered users are reachable when backup becomes alive, in the case of shared IP HA.
With usrloc and nathelper, that is solved, as data is stored in db or replicated with t_replicate().
A user agent's NAT entry point may be kept alive for one or multiple of the conditions listed above.
I understood that an endpoint is pinged only once if you call nat traversal for register, invite and subscribe. It not about this king of duplicated resources. It is about storing info about the endpoint in nat_traversal, usrloc and presence server. While the last two already have it and need it for normal behavior, the first is doing it at extra expenses.
Also, note that you need to do nat pinging from the presence server only when you allow subscriptions from non-registered UA (again, very corner case). Otherwise, just having it done only by registrar is enough.
Even when a NAT endpoint is kept alive for more than one condition, only one keepalive message is sent to that NAT endpoint. The presence of multiple conditions for a NAT endpoint, only guarantees that the network visibility for a user agent based on a certain condition will be available while that condition is true, independently of the other conditions. When all the conditions to keepalive a NAT endpoint will disappear, that endpoint will be removed from the list with the NAT endpoints that need to be kept alive.
How to mantain the keepalivee in Kamailio (without using nat_traversal module)? The dirty solution would be decrease the notification interval, that of course would be a wrong choice.
Why would be that more wrong than sending keepalives from a stateful proxy? See above, you keep the dialog only once on server side.
SUBSCRIBE - called before handle_subscribe() or t_relay() (depending on whether the proxy that received the SUBSCRIBE is also handling subscriptions for that subscriber or not). It will determine from either the stateless reply generated by handle_subscribe() or the TM relayed reply if the subscription was successful and what is its expiration time. If the subscription was successful it will mark the given NAT endpoint for keepalive for the subscription condition using the detected expiration time. If the SUBSCRIBE request is discarded after nat_keepalive() was called or if it intercepts a negative reply it will have no effect and the subscription condition will not be activated for that endpoint. It should be called for every SUBSCRIBE received, not only the ones that start a subscription (do not have a to tag), because it needs to update (extend) the expiration time for the subscription.
I think this is much better than decreasing notifications interval just because there could be users registered behind NAT.
If they are registered, then registrar will take care, you do not need any other nat pinging. We talk about non registered users.
NAT keepalive should not be performed by an application (SIP presence) IMHO.
SIP is an application level protocol. So the special handling should be done by the end point that understands the message. What happens if I send a custom request? Should the proxy perform pinging? If it is not creating a dialog, the case of MESSAGE? Or it does, case of SUBSCRIBE?
IMO, it is totally broken to assume things in a router/proxy. Do it on endpoints, like it is now with registrar.
Also, imagine other typical case:
a) Using nathelper:
- UA behind NAT uses a domain with SRV failover (servers 1.1.1.1 and 2.2.2.2).
- It sends the REGISTER to 1.1.1.1.
- Registration expires in 10 minutes.
- Proxy 1.1.1.1 mantains the keepalive.
- Proxy 1.1.1.1 crashes.
What happens if someone calls that UA right now?
- UA sends an INVITE and since 1.1.1.1 doesn't respond it sends it to 2.2.2.2.
If I am not wrong, in this case should register again, since the previous proxy is no longer available.
What happens if proxy 1.1.1.1 is restarted. Does it restore the hash table of natted endpoints?
- The call is established.
- After 3 minutes the calleed sends a BYE.
- This BYE wont reach the UA since proxy 2.2.2.2 is not mantaining NAT
keepalive => Problems
b) Using nat_traversal:
- UA behind NAT uses a domain with SRV failover (servers 1.1.1.1 and 2.2.2.2).
- It sends the REGISTER to 1.1.1.1.
- Registration expires in 10 minutes.
- Proxy 1.1.1.1 mantains the keepalive (REGISTER).
- Proxy 1.1.1.1 crashes.
UA is no longer reachable, maybe called party was also on 1.1.1.1.
In case of shared IP, or load balancer+PATH, it is reachable and there is no problem with calling or being called.
For me looks like you try to argument that nat_traversal is better for a bad designed voip platform. Sometimes, if you are lucky (ua1 registered on .1 and ua2 registered on .2), you get ability to call, but never to be called.
It is not clear to me that it supports proxy restart -- I admit I havent investigated the code nor used the module.
I simply fail to see the reason of one extra place to store data to be able to do to nat pings.
- UA sends an INVITE and since 1.1.1.1 doesn't respond it sends it to 2.2.2.2.
- The call is established.
- Proxy 2.2.2.2 mantains keepalive for the call duration.
- After 3 minutes the calleed sends a BYE.
- This BYE will reach the UA since proxy 2.2.2.2 is mantaining NAT keepalive
=> OK.
Other solutions to make the above escenario working with nathelper module would be:
- The UA mantains the keepalive with the registrar server and *with* the
definitive server it sent the INVITE to (after SRV failover). How many UA's do it?
- The UA mantain the keepalive with the registar. When detecting server
failure it sends a new REGISTER to the following server (SRV).
- Decrease the registration expiration in the server (bad idea).
Sincerely, I think nat_traversal provides much better NAT solutions than the limited nathelper module.
Just your opinion. I think it is the opposite. nat_traversal limits you to one box for good servicing, otherwise no scalability and no HA for proper voip servicing.
Cheers, Daniel
Using dialgo module is not required at all (as I explained above), it is required just in the case you want to mantain keepalive for calls initiated by non registered users.
Regards.
First of all, I love these kind of discussions, the best way to learn :)
El Martes, 7 de Julio de 2009, Daniel-Constantin Mierla escribió:
REGISTER - called before save_location() or t_relay() (depending on whether the proxy that received the REGISTER is also handling registration for that subscriber or not). It will determine from either the stateless reply generated by save_location() or the TM relayed reply if the registration was successful and what is its expiration time. If the registration was successful it will mark the given NAT endpoint for keepalive for the registration condition using the detected expiration time. If the REGISTER request is discarded after nat_keepalive() was called or if it intercepts a negative reply it will have no effect and the registration condition will not be activated for that endpoint.
so it duplicated info stored by the usrloc module. It is what I meant by keeping twice information. Nathelper fetches the contact details from usrloc.
Ok, I get you now. However, if you don't use db_mode=0 in usrloc, then there is a MySQL query retrieving the natted contacts from usrloc table. nat_traversal store them always in memory (not sure if it's a better approach).
From what seems here, definitely does not deal with PATH extension.
Not 100% sure, but I read this in the doc:
---------------- 1.7.1. $keepalive.socket(nat_endpoint)
Returns the local socket used to send messages to the given NAT endpoint URI. The socket has the form proto:ip:port. The NAT endpoint URI is in the form: sip:ip:port[;transport=xxx] with transport missing if UDP. If the requested NAT endpoint URI is present in the internal keepalive table for any condition, it will return its associated local socket, else it will return null. The nat_endpoint can be a string or another pseudo-variable. This can be useful to restore the sending socket when relaying messages to a given user agent in multi-proxy environments. Consider an example where 2 proxies are involved, P1 and P2. A user agent registers by sending a REGISTER request to P1. P1 will call nat_keepalive() but because it determines that P2 should actually handle the user registration will forward the request to P2. Now assume P2 receives an incoming INVITE for this user. It will determine that the registration came through P1 and will forward the request to P1. P2 should also include the NAT endpoint URI where this request is to be relayed. This information should have been provided by P1 when it relayed the REGISTER request to P2. The means to do this is out of the scope of this example, but one can either use the path extension or custom headers to do this. When P1 receives the INVITE it will use the NAT endpoint URI it has received along with the request to determine the socket to send out the request, which should be the same as the one where the registration request was originally received. In the example below lets assume that P2 provided the original NAT endpoint address in a custom header called X-NAT-URI and that it also provides a custom ----------------
As you won't use nathelper, nat pings are performed only by nat_traversal, so if to cope with crashes of the box, you need a replication mechanism to a backup, so registered users are reachable when backup becomes alive, in the case of shared IP HA.
With usrloc and nathelper, that is solved, as data is stored in db or replicated with t_replicate().
With nat_traversal there is other approach: Use nat_keepalive() for REGISTER and INVITE. When the server 1 crashes and server 2 begin running, it has no NAT keepalive information, but if it's receives a call from a natted UA, it will keepalive it (INVITE).
However, it's true that it couldn't receive calls from server 2... hum...
Also, note that you need to do nat pinging from the presence server only when you allow subscriptions from non-registered UA (again, very corner case). Otherwise, just having it done only by registrar is enough.
Perhaps I miss something, but how could a presence server (running behind the proxy) perform nat keepalive just for natted users? note that SIP signalling is NAT fixed on the proxy. Perhaps using a custom header or paremter "nat=yes"? In any case, how would Kamailio presence server mantain the keepalive for non registered natted subscribers?
NAT keepalive should not be performed by an application (SIP presence) IMHO.
SIP is an application level protocol. So the special handling should be done by the end point that understands the message. What happens if I send a custom request? Should the proxy perform pinging? If it is not creating a dialog, the case of MESSAGE? Or it does, case of SUBSCRIBE?
IMHO it's clear that the only requests requiring NAT keepalive are: - REGISTER: to receive calls. - INVITE: to receive in-dialog requests. - SUBSCRIBE: to receive in-dialog requests.
IMO, it is totally broken to assume things in a router/proxy. Do it on endpoints, like it is now with registrar.
Well, I can assume that there will not appear a new SIP method creating a dialog in the next 5 years XD
Also, imagine other typical case:
a) Using nathelper:
- UA behind NAT uses a domain with SRV failover (servers 1.1.1.1 and
2.2.2.2). - It sends the REGISTER to 1.1.1.1.
- Registration expires in 10 minutes.
- Proxy 1.1.1.1 mantains the keepalive.
- Proxy 1.1.1.1 crashes.
What happens if someone calls that UA right now?
(note that in this case I mean using "nathelper"). UA wouldn't receive that call even if it arrives to server 2 since server 2 (a different IP) has no way to communicate with UA.
- UA sends an INVITE and since 1.1.1.1 doesn't respond it sends it to
2.2.2.2.
If I am not wrong, in this case should register again, since the previous proxy is no longer available.
What about if UA receives a 503 since the server 1 cannot route more outgoing calls but it can route calls to users? I'm really not sure of the expected behaviour in UA.
What happens if proxy 1.1.1.1 is restarted. Does it restore the hash table of natted endpoints?
Well, when Kamailio/OpenSIPS is *properly* stopped, the NAT keepalive info is stored:
/var/run/kamailio# cat keepalive_state # Automatically generated file from internal keepalive state. Do NOT modify! sip:222.231.250.231:5065 udp:93.141.79.216:5062 1245776309 0 sip:222.231.250.213:5060 udp:93.141.79.216:5062 1245776051 0 sip:84.84.127.147:5061 udp:93.141.79.216:5060 1245776226 0
b) Using nat_traversal:
- UA behind NAT uses a domain with SRV failover (servers 1.1.1.1 and
2.2.2.2). - It sends the REGISTER to 1.1.1.1.
- Registration expires in 10 minutes.
- Proxy 1.1.1.1 mantains the keepalive (REGISTER).
- Proxy 1.1.1.1 crashes.
UA is no longer reachable, maybe called party was also on 1.1.1.1.
In case of shared IP, or load balancer+PATH, it is reachable and there is no problem with calling or being called.
Agree.
It is not clear to me that it supports proxy restart -- I admit I havent investigated the code nor used the module.
Yes, it does.
I simply fail to see the reason of one extra place to store data to be able to do to nat pings.
Well, it extends the cases in which keepalive could be required (not just registration).
Sincerely, I think nat_traversal provides much better NAT solutions than the limited nathelper module.
Just your opinion. I think it is the opposite. nat_traversal limits you to one box for good servicing, otherwise no scalability and no HA for proper voip servicing.
Well, I promise to investigate more about it. Most probably I needed this thread :)
Regards.
On 07/07/2009 10:30 PM, Iñaki Baz Castillo wrote:
First of all, I love these kind of discussions, the best way to learn :)
:-)
[...] Ok, I get you now. However, if you don't use db_mode=0 in usrloc, then there is a MySQL query retrieving the natted contacts from usrloc table.
This happens only on db mode only. Otherwise, usrloc records are stored in memory and sync'ed to db from time to time. A restart of same instance or a start of another one on a different server, will get up-to-date data.
nat_traversal store them always in memory (not sure if it's a better approach).
From what seems here, definitely does not deal with PATH extension.
Not 100% sure, but I read this in the doc:
1.7.1. $keepalive.socket(nat_endpoint)
the 'socket' column in usrloc table.
As you won't use nathelper, nat pings are performed only by nat_traversal, so if to cope with crashes of the box, you need a replication mechanism to a backup, so registered users are reachable when backup becomes alive, in the case of shared IP HA.
With usrloc and nathelper, that is solved, as data is stored in db or replicated with t_replicate().
With nat_traversal there is other approach: Use nat_keepalive() for REGISTER and INVITE. When the server 1 crashes and server 2 begin running, it has no NAT keepalive information, but if it's receives a call from a natted UA, it will keepalive it (INVITE).
.. right, if destination is not behind nat, otherwise won't do it since the call does not complete.
However, it's true that it couldn't receive calls from server 2... hum...
Also, note that you need to do nat pinging from the presence server only when you allow subscriptions from non-registered UA (again, very corner case). Otherwise, just having it done only by registrar is enough.
Perhaps I miss something, but how could a presence server (running behind the proxy) perform nat keepalive just for natted users? note that SIP signalling is NAT fixed on the proxy. Perhaps using a custom header or paremter "nat=yes"? In any case, how would Kamailio presence server mantain the keepalive for non registered natted subscribers?
presence server has anything needed to rich the UA within the subscribe dialog. It uses it for sending notifies. It needs to send some messages periodically.
NAT keepalive should not be performed by an application (SIP presence) IMHO.
SIP is an application level protocol. So the special handling should be done by the end point that understands the message. What happens if I send a custom request? Should the proxy perform pinging? If it is not creating a dialog, the case of MESSAGE? Or it does, case of SUBSCRIBE?
IMHO it's clear that the only requests requiring NAT keepalive are:
- REGISTER: to receive calls.
- INVITE: to receive in-dialog requests.
- SUBSCRIBE: to receive in-dialog requests.
but these are application level decisions. You can use REGISTER to publish a CPL documents(cpl-c support it), in that case you don't need keepalive.
IMO, it is totally broken to assume things in a router/proxy. Do it on endpoints, like it is now with registrar.
Well, I can assume that there will not appear a new SIP method creating a dialog in the next 5 years XD
[...]
What happens if someone calls that UA right now?
(note that in this case I mean using "nathelper"). UA wouldn't receive that call even if it arrives to server 2 since server 2 (a different IP) has no way to communicate with UA.
I was refering to the cases when you have shared IP HA or a load balancer in front with path extension.
[...]
It is not clear to me that it supports proxy restart -- I admit I havent investigated the code nor used the module.
Yes, it does.
OK, probably still limited in a way. usrloc does immediate or periodic db updates (depending on parameter value), so if there is "unexpected" crash, none or very limited data is lost. And you have path support.
I simply fail to see the reason of one extra place to store data to be able to do to nat pings.
Well, it extends the cases in which keepalive could be required (not just registration).
ok, then should do it only for those cases.
Sincerely, I think nat_traversal provides much better NAT solutions than the limited nathelper module.
Just your opinion. I think it is the opposite. nat_traversal limits you to one box for good servicing, otherwise no scalability and no HA for proper voip servicing.
Well, I promise to investigate more about it. Most probably I needed this thread :)
I think with next next stable release, we need some order in the nat handling. Right now there are too many things that bring confusion due to poor documentation or overlapping functionality.
Over the years I used only the nathelper module, without hitting some limitation, the only annoying thing from my point of view is the complex config, issue addressed earlier in this thread, which can be solved nicely.
Cheers, Daniel
Daniel-Constantin Mierla schrieb:
On 07/07/2009 08:33 PM, Iñaki Baz Castillo wrote:
El Martes, 7 de Julio de 2009, Daniel-Constantin Mierla escribió:
On 07/07/2009 07:27 PM, Iñaki Baz Castillo wrote:
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
I use nat-traversal module and it's MUCH MUCH more powerful than nathelper, for sure.
I do not agree at all with this, when comes to flexibility. nat_traversal main problem is the relying on dialog module, which adds lot of overhead to a proxy.
Not sure now if dialog module is fully required for all the cases... It's just required if you want to mantain nat keepalive for calls initiated by non registered users.
it does not bind to usrloc, so I think it has no idea who is registered or not, unless it is done via some parameters.
REGISTER - called before save_location() or t_relay() (depending on whether the proxy that received the REGISTER is also handling registration for that subscriber or not). It will determine from either the stateless reply generated by save_location() or the TM relayed reply if the registration was successful and what is its expiration time. If the registration was successful it will mark the given NAT endpoint for keepalive for the registration condition using the detected expiration time. If the REGISTER request is discarded after nat_keepalive() was called or if it intercepts a negative reply it will have no effect and the registration condition will not be activated for that endpoint.
so it duplicated info stored by the usrloc module. It is what I meant by keeping twice information. Nathelper fetches the contact details from usrloc.
From what seems here, definitely does not deal with PATH extension.
I think the concept of nat_traversal correctly is focused on using outbound proxies - e.g. you have several outbound proxies (multiple SRV or A records) which relay the signaling to the core proxies (registrars, presence servers ...).
In such a setup there is no need for PATH support as the nat_traversal will be done on the outbound proxy. Further, scalability is also not a problem. Of course multiple OBPs will be needed for availability and NAT traversal load (including media relay) - but this reduces load on the core proxies which do not have to deal with NAT traversal.
It just probably a matter of preference if you have multiple registrars/presence servers which also do NAT traversal and activation of media relay, or if you prefer to have OBPs which deal with all the NAT traversal issues and keep the core proxies simple.
regards klaus
2009/7/8 Klaus Darilion klaus.mailinglists@pernau.at:
From what seems here, definitely does not deal with PATH extension.
I think the concept of nat_traversal correctly is focused on using outbound proxies - e.g. you have several outbound proxies (multiple SRV or A records) which relay the signaling to the core proxies (registrars, presence servers ...).
In such a setup there is no need for PATH support as the nat_traversal will be done on the outbound proxy.
I don't understand this. PATH is required when a registration is done through an outbound proxy, so the registrar routes request for that AoR using also through the outbound proxy (the RURI is the Contact of the REGISTER but the request is sent to the OBP.
Iñaki Baz Castillo schrieb:
2009/7/8 Klaus Darilion klaus.mailinglists@pernau.at:
From what seems here, definitely does not deal with PATH extension.
I think the concept of nat_traversal correctly is focused on using outbound proxies - e.g. you have several outbound proxies (multiple SRV or A records) which relay the signaling to the core proxies (registrars, presence servers ...).
In such a setup there is no need for PATH support as the nat_traversal will be done on the outbound proxy.
I don't understand this. PATH is required when a registration is done through an outbound proxy, so the registrar routes request for that AoR using also through the outbound proxy (the RURI is the Contact of the REGISTER but the request is sent to the OBP.
E.g.: client <--->OBP<---->Registrar
If the Registrar does the NAT traversal, the NAT traversal mechanism must take into account the PATH, that means either:
- send OPTION requests to the client using a pre loaded route via the OBP - send OPTION requests or emtpy CRLF packets with spoofed source IP (the IP of the OBP)
If the OBP does the NAT traversal, the NAT traversal mechanism need not take care about PATH because there is no SIP proxy between the client and the OBP.
regards klaus
2009/7/8 Klaus Darilion klaus.mailinglists@pernau.at:
I don't understand this. PATH is required when a registration is done through an outbound proxy, so the registrar routes request for that AoR using also through the outbound proxy (the RURI is the Contact of the REGISTER but the request is sent to the OBP.
E.g.: client <--->OBP<---->Registrar
If the Registrar does the NAT traversal, the NAT traversal mechanism must take into account the PATH, that means either:
- send OPTION requests to the client using a pre loaded route via the OBP
- send OPTION requests or emtpy CRLF packets with spoofed source IP (the IP
of the OBP)
If the OBP does the NAT traversal, the NAT traversal mechanism need not take care about PATH because there is no SIP proxy between the client and the OBP.
Yes, but what I mean is that in the above escenario PATH is required in order client to receive calls from Registrar (forget NAT now).
Iñaki Baz Castillo schrieb:
2009/7/8 Klaus Darilion klaus.mailinglists@pernau.at:
I don't understand this. PATH is required when a registration is done through an outbound proxy, so the registrar routes request for that AoR using also through the outbound proxy (the RURI is the Contact of the REGISTER but the request is sent to the OBP.
E.g.: client <--->OBP<---->Registrar
If the Registrar does the NAT traversal, the NAT traversal mechanism must take into account the PATH, that means either:
- send OPTION requests to the client using a pre loaded route via the OBP
- send OPTION requests or emtpy CRLF packets with spoofed source IP (the IP
of the OBP)
If the OBP does the NAT traversal, the NAT traversal mechanism need not take care about PATH because there is no SIP proxy between the client and the OBP.
Yes, but what I mean is that in the above escenario PATH is required in order client to receive calls from Registrar (forget NAT now).
of course, the registrar always needs to support PATH. But the NAT-traversal mechanism only needs to support NAT if it is not running on the OBP, but behind the OBP.
regards klaus
2009/7/8 Klaus Darilion klaus.mailinglists@pernau.at:
Yes, but what I mean is that in the above escenario PATH is required in order client to receive calls from Registrar (forget NAT now).
of course, the registrar always needs to support PATH. But the NAT-traversal mechanism only needs to support NAT if it is not running on the OBP, but behind the OBP.
ok :)
Iñaki Baz Castillo schrieb:
Sincerely, I think nat_traversal provides much better NAT solutions than the limited nathelper module. Using dialgo module is not required at all (as I explained above), it is required just in the case you want to mantain keepalive for calls initiated by non registered users.
MAybe you can help porting nat_traversal to sip-router, it is not completed yet: http://sip-router.org/wiki/devel/kamailio-integration
regards klaus
2009/7/8 Klaus Darilion klaus.mailinglists@pernau.at:
Iñaki Baz Castillo schrieb:
Sincerely, I think nat_traversal provides much better NAT solutions than the limited nathelper module. Using dialgo module is not required at all (as I explained above), it is required just in the case you want to mantain keepalive for calls initiated by non registered users.
MAybe you can help porting nat_traversal to sip-router, it is not completed yet: http://sip-router.org/wiki/devel/kamailio-integration
And it would be a good Git exercise :) I cannot promise right now but I'll try it.
Alex Balashov schrieb:
Iñaki Baz Castillo wrote:
2009/7/7 Alex Balashov abalashov@evaristesys.com:
I somewhat object to the idea that rtpproxy control socket functions should be exposed in the nathelper module. Why does mediaproxy get its own module? What if I want to relay media for some purpose other than far-end NAT traversal (for example, passive in-line tap / monitor-port based call recording)?
AFAIK NAT signalling functions are now handled by nat-traversal module, more powerful than nathelper of mediaproxy (for signalling, not for media). So nathelper module remains just to control RtpProxy. Yes, it could be renamed to "rtpproxy" and NAT signalling functions be dropped from the module.
Just what is the superior merit of nat-traversal vs. nathelper? I have continued to use nathelper, believing nat-traversal to be an artifice of the OpenSIPS camp since it was put out by AG Projects...
It was developed by AG while they where still working with Kamailio. Then there was the fork. I think new features and bugfixes are now only with OpenSIPs (I think they also did some changes to dialog module for nat_traversal reasons).
regards klaus
On 07/07/2009 06:36 PM, Alex Balashov wrote:
I somewhat object to the idea that rtpproxy control socket functions should be exposed in the nathelper module.
maybe there was some misunderstanding. What we discussed here is not when to use rtpproxy, but if you do it for initial invite, then all subsequent requests in the dialog will be automatically handled.
When and why one does rtp relaying is still a decision of the script writer. From this perspective, maybe suggested name for RR parameter is not the best, should be something "rtpp=yes".
Cheers, Daniel
Why does mediaproxy get its own module? What if I want to relay media for some purpose other than far-end NAT traversal (for example, passive in-line tap / monitor-port based call recording)?
Iñaki Baz Castillo wrote:
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
Hi Daniel, please clarify me is your suggestion would require running (in the config script) the function rtpproxy_session_update() in onreply_route.
no. The script needs just rtpproxy_session_init(). All the rest is done automatically in the module.
Inside a module, you can register functions that are executed before executing the configuration file for each sip message.
So, here is what is needed:
- registers callback functions for pre-script event for reply and
request
- if it is an initial invite, then skip processing in the callback
- if it is a reply or a in-dialog request, search for
Record-Route/Route headers matching "myself"
- if the R-R/R headers have "nat=xyz", then process
rtpproxy_session_update()
- export to config file the function rtpproxy_session_init() that
has to be called for initial invite and append to R-R the parameter "nat=xyz" (this should be configurable)
In the config file, just call rtpproxy_session_init() and that is. Probably this function needs some flags as parameter to control the behaviour, flags that could be added as value to nat parameter, if needed later.
ok, that sounds really nice :)
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
cc-ed the k users list, just in case someone pops up a better idea.
Having to invoke rtpproxy in each message (initial INVITE, reply, ACK?, re-INVITE...) makes the config file really ugly. While it provides flexibility (using different flags for offers and responses) I think it's not needed in most of the cases.
If would be really great a rtpproxy function working for transaction (instead of working for each message). For example:
if (is_method("INVITE")) { tran_use_rtpproxy(FLAGS); }
This "tran_use_rtpproxy()" could handle rtpproxy invocations for the request (if it has SDP) for the responses (if they have SDP), for ACK (if it's has SDP) and for CANCEL. It would add some info to the transaction and some callbacks to tm module to invoke rtpproxy functions. This is, a rtpproxy function depending on TM module.
-
Alex Balashov -
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Klaus Darilion