[Devel] rr-callbacks and dst-uri for Path and NAT

[Andreas Granig]

Bogdan-Andrei Iancu wrote:
> I did some thinking on this matter and I think it might not be the case. 
> If you have a PATH hdr stored on the contact record, means that there is 
> a proxy (minimum) between the register and the UAC. Now, we have to cases:
>    - that proxy has public address - in this case no received is set, so 
> there is no problem
>    - that proxy has private address and advertise it - in this case 
> there is an received and for sure you want to use it to get to that 
> proxy (and not to use the private advertised addr).
> 
> please correct me if I'm wrong about something.

I'm not quite sure if we're talking exactly about the same here. Let me 
give an example to clear this up:

If you have a REGISTER like "UAC1 -> (NAT) -> P1 -> R1", where P1 is the 
outbound proxy of UAC and R1 is the Registrar, then P1 would add a Path 
"Path: <sip:own-addr;lr;received=nat-addr>", and R1 would simply store that.

I assume here that P1 knows the address of R1 and it's directly 
reachable. So R1 won't have a received-addr and would just store the 
Contact of UAC with the Path of P1. This scenario (the handling of Path 
in R1) is already covered by my previous patch.

Now assume a subsequent request "UAC2 -> R1 -> P1 -> (NAT) -> UAC1". In 
this case, R1 recognizes the stored Path, inserts it as Route-HF and 
sends the request to the first uri of the Path (not to the address in 
the received-param of the Path nor to the received-address of the 
previous REGISTER). P1 receives this request and uses the received-param 
of the Route-HF, which it had inserted to Path during the registration, 
as next hop address to traverse UAC1's NAT. And therefore it has to 
parse the params of the first Route HF and set the destination-uri 
according to the received-param.

This is the intention of the parameter, namely NAT-traversal for 
outbound proxies which do not act as registrars but are only load 
balancers for example. This has nothing to do with the Path handling on 
R1, although the question there is if it's correct to use the Path-uri 
in favour of the received-address for the next hop...

Hope this clears that up...

Andy