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(a)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 ----------------