On 07/07/2009 12:41 PM, Alex Balashov wrote: 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 -- Daniel-Constantin Mierla http://www.asipto.com/

Iñaki Baz Castillo schrieb: 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

On 07/07/2009 03:19 PM, Iñaki Baz Castillo wrote: 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 -- Daniel-Constantin Mierla http://www.asipto.com/

Hello Inaki, On 07/07/2009 03:42 PM, Iñaki Baz Castillo wrote: 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 -- Daniel-Constantin Mierla http://www.asipto.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)? Iñaki Baz Castillo wrote: -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775

Iñaki Baz Castillo wrote: 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... -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775

2009/7/7 Henning Westerholt <henning.westerholt(a)1und1.de>de>: 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. -- Iñaki Baz Castillo <ibc(a)aliax.net>

2009/7/7 Daniel-Constantin Mierla <miconda(a)gmail.com>om>: 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. 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. -- Iñaki Baz Castillo <ibc(a)aliax.net>

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. -------- 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). 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. ---------- ------------ 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. -- Iñaki Baz Castillo <ibc(a)aliax.net>

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ó: 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). 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 ---------------- 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... 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? 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. Well, I can assume that there will not appear a new SIP method creating a dialog in the next 5 years XD (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. 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. 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 Agree. Yes, it does. Well, it extends the cases in which keepalive could be required (not just registration). Well, I promise to investigate more about it. Most probably I needed this thread :) Regards. -- Iñaki Baz Castillo <ibc(a)aliax.net>

Daniel-Constantin Mierla schrieb: 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

Iñaki Baz Castillo schrieb: 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

Iñaki Baz Castillo schrieb: 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

Iñaki Baz Castillo schrieb: 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

Alex Balashov schrieb: 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

2009/7/7 Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt;om>: 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 &lt;ibc(a)aliax.net&gt;