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
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
