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@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@202.180.1.1>;tag=as45a8ade4 To: <sip:022334455@147.202.1.1>;tag=4c813866c894f124i1 Contact: <sip:022998877@202.180.1.1> Call-ID: 0818dfa10f1da0f25daa4759332d3c55(a)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@147.202.1.1>;tag=4c813866c894f124i1 From: "user" <sip:022998877@202.180.1.1>;tag=as45a8ade4 Call-ID: 0818dfa10f1da0f25daa4759332d3c55(a)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@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(a)lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users