We have a discussion about "optional or mandatory" in relation to the
tag "transport=tcp" in the contact header and the meaning of TCP in the
VIA header. In RFC2543 and 3261 there is no clear message how it should
work. Exactly: Is the "transport=tcp" tag in the contact field always mandatory if
the optional header field "Contact" is used.
Note that the Contact field is NOT optional in INVITE and 200 OK (INVITE); see Table 2, rfc3261. Basically any request that establishes a session (and this includes SUBSCRIBE) needs to insert a Contact field.
The underneath transaction is done in one TCP connection and it is working with most of end devices. But one end device is switching back to UDP for the ACK message because there is no "transport=tcp" at least in the 200 OK message.
This behavior is what you will get and is correct under the current implementation of the protocol. The default transport for SIP is UDP (see Table 1, rfc3261) and most implementations support UDP more readily than they do TCP. Thus, absence any 'transport=tcp' guidelines, they will revert to UDP.
> Is this behaviour correct if each message indicates TCP in the VIA > field ?
Note that the Via field is used to route >>responses<<, not requests. The Contact field is used to route subsequent requests within the dialog. Thus, the initial INVITE/200 OK can happen over TCP, but subsequent requests like ACK or BYE will degenerate to UDP if the 'transport=tcp' is omitted.
Example: Following trace is a example how it works at the moment. But one provider of end devices says this is incorrect, because transport is mandatory.
transport is not a mandatory parameter.
- vijay -- Vijay K. Gurbani [EMAIL PROTECTED],research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
