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.
Paul
[EMAIL PROTECTED] wrote:
Hi implementors ! I have a very very basic question with regard to the Contact that should be inserted in SIP messages. Consider [EMAIL PROTECTED] calls [EMAIL PROTECTED] Bob's phone listens on UDP, TCP and TLS ports and receives the request on one of these transports. Now, what is the Contact that it should insert in the response and subsequent INVITE requests?
a) sip:[EMAIL PROTECTED] b) sip:[EMAIL PROTECTED];transport=udp c) sip:[EMAIL PROTECTED];transport=tcp
a) seems logical to me as it does not specify the transport-param and therefore implies that the UA listens on both UDP and TCP. But what if Alice made the call on TCP and inserted a transport=tcp param in its Contact in the INVITE request. Or what if the last hop to Bob was on TCP. Does any of this imply that Bob should also insert transport=tcp in the response and subsequent messages ? In general, what are the factors that Bob's phone should consider before inserting a Contact ?
Going through the RFC I found that it is pretty clear about the above scenario with regard to SIPS URLs. Quoting Sec 12.2.2: UAS Behaviour: "The URI provided in the Contact header field MUST be a SIP or SIPS URI. If the request that initiated the dialog contained a SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record-Route header field, the Contact header field in the response MUST be a SIPS URI."
Can we apply the same rules when it comes to URLs containing a transport=xxx parameter ?
Another question: If the URL contained transport=tls (which is now deprecated), can the UA interpret it similar to a SIPS URL i.e. can the UA treat it like a SIPS URL for all its processing (i.e. apply the RFC rules as though it received a SIPS URL...)
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
