[Users] Proxy Route Processing

[Klaus Darilion]

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.
>