[SR-Users] how to use fix_nated_sdp("2") with multiple media types

Daniel-Constantin Mierla miconda at gmail.com
Tue Oct 9 13:11:34 CEST 2012


Hello,

from the trace it seems that mcu is on a private network. Also, rtpproxy 
seems to be configured to listen on a private address. But then the 
response is sent to a public address.

First, is the routing between the two networks configured on the server 
where kamailio/rtpproxy runs? rtproxy should be on public interface to 
be able to talk with the clients on the public network.

Then, with rtpproxy, each side has to send a packet in order to know 
where to send the packets. Does MCU send packets? If not you can try to 
add flag 'r' for messages coming from it.

If the networks are not interconnected at ip layer, then you should use 
rtpproxy in bridge mode. That requires more flags to rtpproxy_manage() 
parameter as well as extra command line parameter for rtpproxy application.

One example of doing bridging with kamailio and rtpproxy is presented in 
the tutorial:
- http://kb.asipto.com/kamailio:kamailio-mixed-ipv4-ipv6

Should give a better view of how to do it, practically you have to 
listen on a second ipv4 address instead of ipv6.

For the future, if you give the ngrep, give also the INVITE requests 
along with the 200ok, in that way we can spot what is wrong with the 
call better.

Cheers,
Daniel

On 10/9/12 12:57 PM, MARINA SERRANO MONTES wrote:
> Hi Daniel,
>
> I'm sorry, but the traffic between rtpproxy and MCU and from MCU to 
> rtpproxy is not received.
>
> I have used "rtpproxy_manage()" in onreply_route[ ]…and I can observe 
> traffic from endpoint to RTPPROXY is sent and received but, from 
> rtpproxy to MCU and from MCU to rtpproxy I cannot receive any traffic.
> Is it possible RTPPROXY don't know where must send traffic to MCU?
>
> Many thanks.
>
> Br,
> Marina
>
> I attach the SIP messages:
>
> U 10.95.94.142:5070 -> 10.95.92.94:5070
> SIP/2.0 200 OK.
> From: "iPhone 4S de Marina Serrano 
> Montes"<sip:34625721615 at yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
> To: 
> <sip:831234 at yarn.com>;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
> Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
> CSeq: 14479 INVITE.
> User-Agent: OTT VIDEO MCU Ver 5.
> Supported: replaces.
> Via: SIP/2.0/UDP 
> 195.235.93.8:5070;received=10.95.92.94;branch=z9hG4bK6525.28425344.0;i=1.
> Via: SIP/2.0/TCP 
> 192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjx56lPnLFFvtElMX6Tw1Yc7pJglWsTHl3.
> Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
> Contact: <sip:831234 at 10.95.94.142:5070>.
> Content-Type: application/sdp.
> Content-Length: 347.
> .
> v=0.
> o=RV-MCU 64398330 64398330 IN IP4 10.95.94.142.
> s=RV MCU Session.
> b=CT:128.
> t=0 0.
> m=audio 6448 RTP/AVP 0 101.
> c=IN IP4 10.95.94.142.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=sendrecv.
> m=video 10046 RTP/AVP 96.
> c=IN IP4 10.95.94.143.
> b=TIAS:64000.
> a=rtpmap:96 H263-1998/90000.
> a=fmtp:96 QCIF=2.
> a=sendrecv.
>
>
> T 10.95.92.94:5070 -> 88.30.60.53:49220 [AP]
> SIP/2.0 200 OK.
> From: "iPhone 4S de Marina Serrano 
> Montes"<sip:34625721615 at yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
> To: 
> <sip:831234 at yarn.com>;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
> Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
> CSeq: 14479 INVITE.
> User-Agent: OTT VIDEO MCU Ver 5.
> Supported: replaces.
> Via: SIP/2.0/TCP 
> 192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjx56lPnLFFvtElMX6Tw1Yc7pJglWsTHl3.
> Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
> Contact: <sip:831234 at 10.95.94.142:5070>.
> Content-Type: application/sdp.
> Content-Length: 363.
> .
> v=0.
> o=RV-MCU 64398330 64398330 IN IP4 10.95.92.94.
> s=RV MCU Session.
> b=CT:128.
> t=0 0.
> m=audio 15460 RTP/AVP 0 101.
> c=IN IP4 10.95.92.94.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=sendrecv.
> m=video 15018 RTP/AVP 96.
> c=IN IP4 10.95.92.94.
> b=TIAS:64000.
> a=rtpmap:96 H263-1998/90000.
> a=fmtp:96 QCIF=2.
> a=sendrecv.
> a=nortpproxy:yes.
>
>
> T 88.30.60.53:49220 -> 10.95.92.94:5070 [AP]
> ACK sip:831234 at 10.95.94.142:5070 SIP/2.0.
> Via: SIP/2.0/TCP 
> 192.168.1.68:49220;rport;branch=z9hG4bKPjFfoWDPVHXuFQpNkwdK8MaC.O81exyyN6.
> Max-Forwards: 70.
> From: "iPhone 4S de Marina Serrano Montes" 
> <sip:34625721615 at yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
> To: sip:831234 at yarn.com;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
> Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
> CSeq: 14479 ACK.
> Route: <sip:195.235.93.8:5070;transport=TCP;lr>.
> Content-Length:  0.
> .
>
>
> U 10.95.92.94:5070 -> 10.95.94.142:5070
> ACK sip:831234 at 10.95.94.142:5070 SIP/2.0.
> Via: SIP/2.0/UDP 195.235.93.8:5070;branch=z9hG4bKcydzigwkX;i=1.
> Via: SIP/2.0/TCP 
> 192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjFfoWDPVHXuFQpNkwdK8MaC.O81exyyN6.
> Max-Forwards: 69.
> From: "iPhone 4S de Marina Serrano Montes" 
> <sip:34625721615 at yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
> To: sip:831234 at yarn.com;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
> Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
> CSeq: 14479 ACK.
> Content-Length:  0.
> .
>
>
> From: Daniel-Constantin Mierla <miconda at gmail.com 
> <mailto:miconda at gmail.com>>
> Reply-To: "miconda at gmail.com <mailto:miconda at gmail.com>" 
> <miconda at gmail.com <mailto:miconda at gmail.com>>
> Date: martes 9 de octubre de 2012 11:47
> To: Marina Serrano Montes <marinas at tid.es <mailto:marinas at tid.es>>
> Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - 
> Users Mailing List" <sr-users at lists.sip-router.org 
> <mailto:sr-users at lists.sip-router.org>>, Vicente Hernando 
> <vhernando at systemonenoc.com <mailto:vhernando at systemonenoc.com>>
> Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple 
> media types
>
> Hello,
>
> in the onreply_route block use rtpproxy_manage(), not fix_nated_sdp().
>
> Cheers,
> Daniel
>
> On 10/9/12 10:57 AM, MARINA SERRANO MONTES wrote:
>> Hi Daniel,
>>
>> Thanks. But, I think there is any think I have not understand.
>> I have my route[MCU] module with the following code:
>>
>> route [MCU]{
>> if (uri=~"^sip:[7,8][0-9]+@"){
>> xlog("Forward to MCU");
>> rewritehost("10.95.94.142");
>> rewriteport("5070");
>> rtpproxy_manage();
>> t_relay();
>>  t_on_reply("CHANGE_SDP");
>> xlog("after forward to MCU");
>> exit;
>>     }
>>
>> }
>>
>> onreply_route[CHANGE_SDP] {
>> xlog("CHANGE_SDP");
>>
>> if(t_check_status("(200)|(183)"))
>> {
>> if(has_body("application/sdp"))
>> {
>> if(search("IN IP4 10.95.94.142"))
>> {
>> xlog("search IN IP4 .142");
>> *fix_nated_sdp("2", "195.235.93.8"); *//where 195.235.93.8 -->public 
>> IP of sip server with rtpproxy
>> }
>>
>> }
>> }
>>
>> }
>>
>>
>> If I comment t_on_reply("CHANGE_SDP") line, I can observe traffic 
>> from MCU to rtpproxy is received (testing using tcpdump), but traffic 
>> from endpoint to rtpproxy is not received and therefore, input 
>> traffic MCU is null. In this case, using only: 
>> rtpproxy_manage(),* the IP in SDP are not replaced by rtpproxy IP.*
>>
>> If I don't comment  t_on_reply("CHANGE_SDP"), in this case, I force 
>> to replace IP using "fix_nated_sdp("2", publicIP)" and I can observe 
>> using tcpdump in server than traffic from endpoint from rtpproxy is 
>> received, but traffic from rtpproxy to MCU is not received and 
>> traffic from MCU to rtpproxy is not received.
>>
>> My question is, how can I set up using "rtpproxy_manage(),…."to allow 
>> all there traffic will be routed rightly through rtpproxy?
>> Should I add any new line in my config file? Anything to change?
>>
>> Many thanks.
>>
>>
>> I attach part of the full route file:
>> # Main SIP request routing logic
>> # - processing of any incoming SIP request starts with this route
>> # - note: this is the same as route { ... }
>> request_route {
>> # NAT detection
>> route(NATDETECT);
>>
>>
>> ### only initial requests (no To tag)
>> t_check_trans();
>>
>> # record routing for dialog forming requests (in case they are routed)
>> # - remove preloaded route headers
>> remove_hf("Route");
>>
>>         if (is_method("INVITE"))
>>  record_route_preset("195.235.93.8:5070;transport=TCP");
>>
>> if (is_method("INVITE|SUBSCRIBE"))
>> record_route();
>>
>> # account only INVITEs
>> if (is_method("INVITE"))
>> {
>> setflag(FLT_ACC); # do accounting
>> }
>>
>>         #ggb: TCP connection reuse
>>         if (proto != UDP) {
>>                 add_contact_alias();
>>         }
>>
>> # dispatch requests to foreign domains
>> route(SIPOUT);
>>
>> ### requests for my local domains
>>
>> if ($rU==$null)
>> {
>> # request with no Username in RURI
>> sl_send_reply("484","Address Incomplete");
>> exit;
>> }
>> route(MCU);
>>
>>
>> route(RELAY);
>>
>> }
>>
>>
>> route[RELAY] {
>>
>> # enable additional event routes for forwarded requests
>> # - serial forking, RTP relaying handling, a.s.o.
>> if (is_method("INVITE|SUBSCRIBE")) {
>> t_on_branch("MANAGE_BRANCH");
>> t_on_reply("MANAGE_REPLY");
>> }
>> if (is_method("INVITE")) {
>> t_on_failure("MANAGE_FAILURE");
>> }
>>
>> if (!t_relay()) {
>> sl_reply_error();
>> }
>> exit;
>> }
>>
>> # Caller NAT detection route
>> route[NATDETECT] {
>> #!ifdef WITH_NAT
>> force_rport();
>> if (nat_uac_test("19")) {
>> if (is_method("REGISTER")) {
>> xlog("fix_nated_register");
>> fix_nated_register();
>> } else {
>> xlog("fix_nated_contact");
>> fix_nated_contact();
>> }
>> setflag(FLT_NATS);
>> }
>> #!endif
>> return;
>> }
>>
>> # RTPProxy control
>> route[NATMANAGE] {
>> #!ifdef WITH_NAT
>> if (is_request()) {
>> if(has_totag()) {
>> if(check_route_param("nat=yes")) {
>> setbflag(FLB_NATB);
>> }
>> }
>> }
>> if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
>> return;
>>
>>  rtpproxy_manage("", "195.235.93.8");
>>
>> if (is_request()) {
>> if (!has_totag()) {
>> add_rr_param(";nat=yes");
>> }
>> }
>> if (is_reply()) {
>> if(isbflagset(FLB_NATB)) {
>> fix_nated_contact();
>> }
>> }
>> #!endif
>> return;
>> }
>>
>> # Routing to foreign domains
>> route[SIPOUT] {
>> if (!uri==myself)
>> {
>> append_hf("P-hint: outbound\r\n");
>> route(RELAY);
>> }
>> }
>>
>>
>> # manage outgoing branches
>> branch_route[MANAGE_BRANCH] {
>> xdbg("new branch [$T_branch_idx] to $ru\n");
>> route(NATMANAGE);
>> }
>>
>> # manage incoming replies
>> onreply_route[MANAGE_REPLY] {
>> xdbg("incoming reply\n");
>>
>>         #ggb: TCP connection reuse
>>         add_contact_alias();
>>
>> if(status=~"[12][0-9][0-9]")
>> route(NATMANAGE);
>> }
>>
>> onreply_route[CHANGE_SDP] {
>> xlog("CHANGE_SDP");
>>
>> if(t_check_status("(200)|(183)"))
>> {
>> if(has_body("application/sdp"))
>> {
>> if(search("IN IP4 10.95.94.142"))
>> {
>> xlog("search IN IP4 .142");
>> fix_nated_sdp("2", "195.235.93.8");
>> }
>>
>> }
>> }
>>
>> }
>>
>> # manage failure routing cases
>> failure_route[MANAGE_FAILURE] {
>> route(NATMANAGE);
>>
>> if (t_is_canceled()) {
>> exit;
>> }
>>
>> #!ifdef WITH_BLOCK3XX
>> # block call redirect based on 3xx replies.
>> if (t_check_status("3[0-9][0-9]")) {
>> t_reply("404","Not found");
>> exit;
>> }
>> #!endif
>>
>> }
>> route [MCU]{
>> if (uri=~"^sip:[7,8][0-9]+@"){
>> xlog("Forward to MCU");
>> rewritehost("10.95.94.142");
>> rewriteport("5070");
>> rtpproxy_manage();
>> t_relay();
>>  t_on_reply("CHANGE_SDP");
>> xlog("after forward to MCU");
>> exit;
>>         }
>>
>> }
>> *
>> *
>>
>> Br,
>> Marina
>>
>> From: Daniel-Constantin Mierla <miconda at gmail.com 
>> <mailto:miconda at gmail.com>>
>> Reply-To: "miconda at gmail.com <mailto:miconda at gmail.com>" 
>> <miconda at gmail.com <mailto:miconda at gmail.com>>
>> Date: martes 9 de octubre de 2012 00:18
>> To: Marina Serrano Montes <marinas at tid.es <mailto:marinas at tid.es>>
>> Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - 
>> Users Mailing List" <sr-users at lists.sip-router.org 
>> <mailto:sr-users at lists.sip-router.org>>, Vicente Hernando 
>> <vhernando at systemonenoc.com <mailto:vhernando at systemonenoc.com>>
>> Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple 
>> media types
>>
>> Hello,
>>
>> you should not set the second parameter of rtpproxy_manage(...), let 
>> it be the one returned by rtpproxy.
>>
>> And yes, all the occurrences of IP addresses in c= lines will be 
>> replaced by the rtpproxy ip, but providing different ports for each 
>> media stream.
>>
>> Practically the rtp streams are going from end device to rtpproxy and 
>> then based on port will be delivered to different IPs of the MCU. 
>> Also, the MCU will send from different IPs to RTPProxy on different 
>> ports and from there to the end device.
>>
>> Cheers,
>> Daniel
>>
>> On 10/8/12 6:05 PM, MARINA SERRANO MONTES wrote:
>>> Hi Daniel,
>>>
>>> I have tested using "rtpproxy_manage("", public IP), but in this 
>>> case, it replaces all the c= lines with this public IP, included 
>>> c=lines in media descriptions and then, the rtp traffic is not 
>>> routing to the right IP in MCU.
>>>
>>> Have I to set up any value/param….to route rtp traffic through 
>>> rtpproxy in sip server and then it will dispatch RTP packets to MCU?
>>>
>>> Thanks.
>>>
>>> Br,
>>> Marina
>>>
>>> From: Daniel-Constantin Mierla <miconda at gmail.com 
>>> <mailto:miconda at gmail.com>>
>>> Reply-To: "miconda at gmail.com <mailto:miconda at gmail.com>" 
>>> <miconda at gmail.com <mailto:miconda at gmail.com>>
>>> Date: lunes 8 de octubre de 2012 16:04
>>> To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - 
>>> Users Mailing List" <sr-users at lists.sip-router.org 
>>> <mailto:sr-users at lists.sip-router.org>>
>>> Cc: Vicente Hernando <vhernando at systemonenoc.com 
>>> <mailto:vhernando at systemonenoc.com>>, Marina Serrano Montes 
>>> <marinas at tid.es <mailto:marinas at tid.es>>
>>> Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple 
>>> media types
>>>
>>> Hello,
>>>
>>> I understood that Marina is looking for the option of being able to 
>>> use different IP addresses for updating various c= lines in SDP.
>>>
>>> fix_nated_sdp(...) can work only with one IP address given as second 
>>> parameter (or taken for source address of the packet).
>>>
>>> Perhaps fix_nated_sdp(...) can be easily extended to support a list 
>>> of ip addresses in the second parameter. For now the solution is to 
>>> use rtpproxy to rewrite all the IP addresses in c= lines with the IP 
>>> address of the rtpproxy. RTPProxy will then dispatch RTP to the 
>>> right IP address assigned for each media stream.
>>>
>>> Regarding the patch sent by Vicente, I just replied on sr-dev 
>>> mailing list.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 10/8/12 3:25 PM, Vicente Hernando wrote:
>>>> Hello Marina,
>>>>
>>>> there is a bug in sdp parser about c IPs which are not correctly 
>>>> reset for non existent c values in streams.
>>>>
>>>> I have still not uploaded it to master branch, sorry.
>>>>
>>>> May be it is related to your issue, in this link you have the 
>>>> attached patch.
>>>>
>>>> http://lists.sip-router.org/pipermail/sr-dev/2012-September/016440.html
>>>>
>>>>
>>>> Kind regards,
>>>> Vicente.
>>>>
>>>> On 10/08/2012 01:18 PM, MARINA SERRANO MONTES wrote:
>>>>> Hi,
>>>>>
>>>>> I have a doubt about how to use "fix_nated_sdp("2")" function when 
>>>>> we have an scenario with multiple media types (audio and video) 
>>>>> and the param "c" in sdp for each media type has a different IP.
>>>>> We are using a SCOPIA 400 MCU to multi-party in a call, and it 
>>>>> will set up different IP to send RTP depend on media type.
>>>>>
>>>>> I have tested this function, but it rewrites always all the "c" 
>>>>> parameter with the same value.
>>>>>
>>>>> Is there any option to use the function or to rewrite "c" value 
>>>>> for each media type independently?
>>>>>
>>>>> Many thanks.
>>>>>
>>>>> Br,
>>>>> Marina
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede 
>>>>> consultar nuestra política de envío y recepción de correo 
>>>>> electrónico en el enlace situado más abajo.
>>>>> This message is intended exclusively for its addressee. We only 
>>>>> send and receive email on the basis of the terms set out at:
>>>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>>> sr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at 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, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
>>> Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Este mensaje se dirige exclusivamente a su destinatario. Puede 
>>> consultar nuestra política de envío y recepción de correo 
>>> electrónico en el enlace situado más abajo.
>>> This message is intended exclusively for its addressee. We only send 
>>> and receive email on the basis of the terms set out at:
>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>
>> -- 
>> Daniel-Constantin Mierla -http://www.asipto.comhttp://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
>> Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu
>>
>> ------------------------------------------------------------------------
>>
>> Este mensaje se dirige exclusivamente a su destinatario. Puede 
>> consultar nuestra política de envío y recepción de correo electrónico 
>> en el enlace situado más abajo.
>> This message is intended exclusively for its addressee. We only send 
>> and receive email on the basis of the terms set out at:
>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
> -- 
> Daniel-Constantin Mierla -http://www.asipto.comhttp://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
> Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu
>
> ------------------------------------------------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede 
> consultar nuestra política de envío y recepción de correo electrónico 
> en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send 
> and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121009/9ffb91ef/attachment-0001.htm>


More information about the sr-users mailing list