> -----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 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. / Christian Jansson, Hotsip > 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 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
