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 at 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 at xxx.xxx.xxx.xxx>;tag=00179A52BC45_T1304371222
> To: <sip:1111 at xxx.xxx.xxx.xxx:5060>;tag =0015E9A0D47D_T1002915332
> Call-ID: CALL_ID3_00179A52BC45_T2098965184 at 192.168.100.77> RAck: 1909013112 135588358 INVITE
> CSeq: 135588359 PRACK
> Contact: <sip:vit-horosho at 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 at 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.
>