[Kamailio-Users] Proxying media on reinvite

Daniel-Constantin Mierla miconda at gmail.com
Tue Oct 28 11:08:01 CET 2008


You do check for a "nat=yes" in Route header, but you didn't added that 
parameter to Record-Route:

http://kamailio.org/docs/modules/1.4.x/rr.html#add-rr-param-id

Cheers,
Daniel


On 10/23/08 05:46, CSB wrote:
> We have the following scenario:
> Nated UAC receives INVITE
> Call is established, we proxy audio
> Far end sends Re-INVITE (to inform UAC to use UDPTL)
> We don't proxy audio so call fails
>
> So I need to understand how the appropriate way to force us to proxy the
> audio when the far end of a reinvite is NATed.
>
> Relevant parts of openser.cfg (OpenSER 1.3.2): We're using mediaproxy.
>
> modparam("usrloc", "nat_bflag", 6)
>
> route {
>         # -----------------------------------------------------------------
>         # Record Route Section
>         # -----------------------------------------------------------------
>         #If it's an INVITE & client is NATed,
>         if (method=="INVITE" && client_nat_test("3")) { 
>                 #Record-route and specify the record-route header explicitly
>                 record_route_preset("64.38.1.1:5060;nat=yes"); # insert IP
> address
>                 #xlog("invite and nated so record_route_preset");
>         #If not Nated and not REGISTER then normal record-route
>         } else if (method!="REGISTER") {
>                 record_route();
>                 xlog("not register and not nated so record_route");
>         };
>         #if (method!="REGISTER") {
>         #       record_route();
>         #};
>         # -----------------------------------------------------------------
>         # Loose Route Section
>         # -----------------------------------------------------------------
>         if (loose_route()) {
>                 #Ensure we are dealing with a re-INVITE. Only connected
> calls have tag=
>                 #entry in the To header. So if it's loose routed and doesn't
> have totag
>                 #and it's an invite or reply then something's wrong
>                 xlog("loose_route");
>                 if ((method=="INVITE"  || method=="REFER") && !has_totag())
> {
>                         sl_send_reply("403", "Forbidden");
>                         xlog("403 in lr");
>                         return;
>                 };
>
>                 if (method=="INVITE") {
>
>                         if (!allow_trusted()) {
>                                 xlog("!allow_ trusted for r-uri <$ru>");
>                                 if (!proxy_authorize("","subscriber")) {
>                                         proxy_challenge("domain.com","1");
>                                         return;
>                                 } else if (!check_from()) {
>                                         sl_send_reply("403", "Use From=ID");
>                                         return;
>                                 };
>                                 consume_credentials();
>                         };
>
>                         #check client is nated or that we've already
> identified it's nated
>                         if (client_nat_test("3") ||
> search("^Route:.*;nat=yes")) { 
>                                 setbflag(6);
>                                 xlog("Recipient is nated so setbflag 6 and
> use mediaproxy: r-uri <$ru>");
>                                 use_media_proxy();
>                         };
>                 };
>                 route(1);
>                 return;
>         };
> }
>
> route[1] {
>
>         # -----------------------------------------------------------------
>         # Default Message Handler
>         # -----------------------------------------------------------------
>
>         #Call reply_route(1) to intercept response messages heading to the
> client
>         t_on_reply("1");
>         #Try to relay the message to its destination
>         if (!t_relay()) {
>                 #If it can't and it's an INVITE or ACK end the media
> proxying
>                 log(1,"route[1] !t_relay");
>                 if (method=="INVITE" || method=="ACK") {
>                         end_media_session();
>                 };
>
>                 sl_reply_error();
>         } else {
>                 log(1,"route[1] t_relay");
>         };
> }
> onreply_route[1]
>
> #Handles message that are returned to the sender i.e. response to caller's
> original request
> {
>         xlog("hit onreply_route(1). rs $rs si $si rm $rm ru $ru tu $tu fu
> $fu rr $rr");
>
>         if (isbflagset(6)) {
>                 xlog("flag(6) is set for $fu . We're currently in
> onreply_route(1)");
>         };
>         if (isbflagset(7)) {
>                 xlog("flag(7) is set for $fu . We're currently in
> onreply_route(1)");
>         };
>         if (status=~"(180)|(183)|2[0-9][0-9]") {
>                 xlog("status matches for $fu . We're currently in
> onreply_route(1)");
>         };
>         if ((isbflagset(6) || isbflagset(7)) &&
> (status=~"(180)|(183)|2[0-9][0-9]")) {
>
>                 #Check the SDP payload length. Assume if we have something
> we can call mediaproxy
>                 if (!search("^Content-Length:[ ]*0")) {
>                         log(1,"using media proxy in onreply_route(1)");
>                         use_media_proxy();
>                 };
>         };
>
>         if (client_nat_test("1")) {
>                 fix_nated_contact();
>         };
> }
>
> The re-invite looks like this:
> INVITE sip:6422334455 at 58.28.1.1:5061 SIP/2.0
> Via: SIP/2.0/UDP 202.180.1.1:5060;branch=z9hG4bK251fed3b;rport
> Route: <sip:147.202.1.1;lr=on;ftag=as45a8ade4>
> From: "user" <sip:022998877 at 202.180.1.1>;tag=as45a8ade4
> To: <sip:022334455 at 147.202.1.1>;tag=4c813866c894f124i1
> Contact: <sip:022998877 at 202.180.1.1>
> Call-ID: 0818dfa10f1da0f25daa4759332d3c55 at 202.180.1.1
> CSeq: 103 INVITE
> User-Agent: UAS
> Max-Forwards: 70
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> Supported: replaces
> Content-Type: application/sdp
> Content-Length: 349
>
> v=0
> o=root 5466 5467 IN IP4 202.180.1.1
> s=session
> c=IN IP4 202.180.1.1
> t=0 0
> m=image 4724 udptl t38
> a=T38FaxVersion:0
> a=T38MaxBitRate:9600
> a=T38FaxFillBitRemoval:0
> a=T38FaxTranscodingMMR:0
> a=T38FaxTranscodingJBIG:0
> a=T38FaxRateManagement:transferredTCF
> a=T38FaxMaxBuffer:72
> a=T38FaxMaxDatagram:72
> a=T38FaxUdpEC:t38UDPRedundancy
>
> Our OK looks like this:
> SIP/2.0 200 OK
> To: <sip:022334455 at 147.202.1.1>;tag=4c813866c894f124i1
> From: "user" <sip:022998877 at 202.180.1.1>;tag=as45a8ade4
> Call-ID: 0818dfa10f1da0f25daa4759332d3c55 at 202.180.1.1
> CSeq: 103 INVITE
> Via: SIP/2.0/UDP 202.180.1.1:5060;branch=z9hG4bK251fed3b;rport=5060
> Record-Route: <sip:147.202.1.1;lr=on;ftag=as45a8ade4>
> Contact: 6422334455 <sip:6422334455 at 58.28.1.1:5061>
> Server: Linksys/SPA2102-5.1.9
> Content-Length: 265
> Content-Type: application/sdp
>
> v=0
> o=- 69685 69685 IN IP4 192.168.1.113
> s=-
> c=IN IP4 192.168.1.113
> t=0 0
> m=image 16386 udptl t38
> a=T38FaxVersion:0
> a=T38MaxBitRate:14400
> a=T38FaxRateManagement:transferredTCF
> a=T38FaxMaxBuffer:200
> a=T38FaxMaxDatagram:200
> a=T38FaxUdpEC:t38UDPRedundancy
>
> Unfortunately this code doesn't result in the c record of the OK being
> updated to the server IP (it is still the private IP of the UAC). In the
> loose route section, the re-invite doesn't pass (client_nat_test("3") ||
> search("^Route:.*;nat=yes")) so we don't use mediaproxy. In the on-reply
> route bflag(6) is not set. I don't understand why bflag(6) is not set since
> the r-uri is to a registered user that has bflag(6) set (at least that's how
> I understand it).
>
> Could anyone point me in the right direction? 
>
> Thanks
>
> Cameron
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com





More information about the Users mailing list