[SR-Users] how to use fix_nated_sdp("2") with multiple media types
Daniel-Constantin Mierla
miconda at gmail.com
Tue Oct 9 11:47:00 CEST 2012
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.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/16090dfb/attachment-0001.htm>
More information about the sr-users
mailing list