Victor Gamov wrote:
Klaus Darilion wrote:
Hi Klaus!
The PRACK is an in-dialog request. There is no
need to lookup() for
in-dialog requests as the route and the destination are already known.
In your case the PRACK looks buggy, as the IP address in the RURI is
the same as the IP address in the Route header. For loose-router
in-dialog requests the RURI must be the destination SIP URI (the URI
in the Contact: header of the INVITE) -
Yes this R-URI coming from INVITE Contact: header
and this URI can't be the IP address of the
proxy but must be the IP
address of the caller.
Very strange assertion. If I follow this logic then I cann't start SIP
client on the same IP-address as SIP-proxy.
You are starting the SIP client on the same PC as the SIP proxy? Then of
course it is valid. I was thinking that the SIP client will have another
IP address.
btw: is the problem solved now?
regards
klaus
If you want the whole truth you have to read RFC
3261. (in dialog
requests and loose-routing)
I reread this (not simple) RFC periodically :-)
Now I look into issue 12 and 16 and I not found nothing wrong in request
from my clients.
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
Now I'll explain my point of view.
As I reading in loose_route() documentation:
"The loose_route function analyzes the Route: headers in the requests.
If there is no Route: header, the function returns FALSE and routing
should be done with normal lookup functions. If a Route: header is
found, the function returns 1 and behaves as described in section 16.12
of RFC 3261."
When we looking into 16.12 we found that
"1. The proxy will inspect the Request-URI. If it indicates a
resource owned by this proxy, the proxy will replace it with
the results of running a location service. Otherwise, the
proxy will not change the Request-URI."
OK. sip:1111@xxx.xxx.xxx.xxx:5060;nat=yes is R-URI owned by this proxy.
So I can do lookup() or other my own transformation on it (really I do
this transformations after loose_route() ).
"2. The proxy will inspect the URI in the topmost Route header
field value. If it indicates this proxy, the proxy removes it
from the Route header field (this route node has been
reached)."
Yes, the topmost Route header indicates this proxy. So proxy must remove
it simply. But at this point loose_route() rewrite R-URI:
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
But why?
Moreover, if loose_route() does not find that this Route indicate this
proxy why it changes R-URI? The Route value have lr=on parameter and
this must be treated as loose-route proxy.
May be I don't understand loose_route() properly and I don't must use it
for all requests coming to my proxy?
Or may be I still don't understand RFC properly?
Thanks!
P.S. I remove loose_route() from config and everything works OK.