Christian Jansson wrote:
-----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: den 2 juli 2004 14:56 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Confusion in Contact header
When Bob's phone receives the initial request, it may well not be
direct
from Alice - but rather from some proxy. The address used, and the transport used, then reflect the preferences of that proxy rather than Alice.
The Contact returned thus reflects what is likely to be a different
path
from Alice to Bob. Bob's phone can't draw any strong conclusions from the initial connection about what to put in the contact. It would probably best served by putting the most general form of address it is capable of and permitted by the protocol to use in that case.
So what is the most general form of address? Do you mean a domain name?
I don't mean the most general form that 3261 permits - I mean the most general form that the endpoint is capable of supporting.
I don't think many UAs will have that. If it is an IP number without transport parameter, UDP should be used according to RFC 3263. Not very flexible if you prefer TCP but can handle UDP. Signalling over UDP without implementing a lot of other drafts and RFCs is not what I consider a safe solution. Adding transport=TCP shows what transport the UA prefers, but it fails to inform that other transports are supported but not preferred.
If the UA has a domain name with srv records, then that is ideal because it can indicate all the transports it supports.
If not, then it will have to pick something, guessing what will work for the caller. But unless the caller connected directly on the initial invite, the UAS has no info to use to guess the capabilities of the caller. It can look at Record-Route headers, if present, and compare to the Via headers, to see if the final hop on the initial invite is likely to be the final hop for other requests within the dialog. If so, it could use that to help decide.
But this is pretty far fetched and futile. If this is going to be any kind of problem, then the best solution is probably to ensure there is always proxy in the path, either by Record-Routing, or by using a GRUU. And then ensure the proxy has a domain name and srv records, and that the proxy is capable of communicating using whatever the endpoint provides.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
