Hi guys!
I have a question about "Proxy Route Processing"
I have following request comes to my OpenSER (xxx.xxx.xxx.xxx is IP of this OpenSER):
PRACK sip:1111@xxx.xxx.xxx.xxx:5060;nat=yes SIP/2.0 Via: SIP/2.0/UDP 192.168.100.77:5060;branch=z9hG4bK_00179A52BC45_T59048F1A From: "Vit-Horosho" sip:vit-horosho@xxx.xxx.xxx.xxx;tag=00179A52BC45_T1304371222 To: sip:1111@xxx.xxx.xxx.xxx:5060;tag =0015E9A0D47D_T1002915332 Call-ID: CALL_ID3_00179A52BC45_T2098965184@192.168.100.77 RAck: 1909013112 135588358 INVITE CSeq: 135588359 PRACK Contact: sip:vit-horosho@192.168.100.77:5060 Route: sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222 Content-Length: 0
As we reading in RFC3261 "16.12 Summary of Proxy Route Processing" part: 1. Request-URI must be rewrited based on location service 2. Route header must be removed because it indicate this proxy 3. Proxy will forward the request to the resource indicated by the URI in the topmost Route header field value (but we have not this Route after step 2) or in the Request-URI if no Route header field is present (so it must be forwarded to URI getted on step 1)
But when I inspect OpenSER debug messages I found the following:
0(99796) parse_headers: flags=200 0(99796) is_preloaded: No 0(99796) grep_sock_info - checking if host==us: 11==11 && [xxx.xxx.xxx.xxx] == [xxx.xxx.xxx.xxx] 0(99796) grep_sock_info - checking if port 5060 matches port 5060 0(99796) after_strict: Next hop: 'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222' is loose router 0(99796) parse_headers: flags=ffffffffffffffff 0(99796) rewrite_uri: Rewriting Request-URI with 'sip:xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222' 0(99796) after_strict: The last route URI: 'sip:xxx.xxx.xxx.xxx;lr=on;ftag=00179A52BC45_T1304371222' 0(99796) parse_headers: flags=ffffffffffffffff
So request is not forwarded as I expect
Is it my misconfiguration or my misunderstood of RFC3261 ?
(the part of openser.cfg followed):
----------- cut here ----------------
# we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol record_route();
#xdbg("\n\troute[0]: before loose_route() ou=$ou; ru=$ru\n"); # subsequent messages withing a dialog should take the # path determined by record-routing if ( loose_route() ) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); # route(1); };
force_rport();
[ request processing with lookup() and actually route(1) followed ]
----------- /cut here ----------------