Thanks for the info. One follow-on query, see inline below KR> -----Original Message----- From: Brett Tate [mailto:[email protected]] Sent: Thursday, August 23, 2012 4:22 PM To: Kumar Ramadoss (WT01 - GMT-Telecom Equipment); [email protected] Subject: RE: Query on Transport parameter in Contact header
> Few queries on transport protocol to be used within the SIP dialog: > > > * Is it acceptable to change the transport protocol (tcp, > udp,..) for a new request within a SIP dialog? Yes; however if I recall correctly, this excludes CANCEL and non-2xx's ACK. > Assuming that the new request within the SIP dialog has size > more than 1300 bytes and need to use TCP as transport protocol? Yes; see above and RFC 3261 section 18.1.1. > * In case, if a SIP entity want to force UDP protocol to be > used always for all messages within a SIP dialog, should it > need to set the transport parameter in the Contact Header as > "UDP"? No; however this assumes that something doesn't indicate that another transport (such as TCP) can be used and the other side is willing/able to use it. It also assumes that the next hop is willing/able to fall back to UDP per RFC 3261 section 18.1.1 and you are not listing for another transport (i.e. in case they try it). KR> OK, however, take the foll. Case: One of the nodes supports only UDP, so should it necessarily set the transport parameter in Contact header to "udp" to ensure that the peer ALWAYS tries to send first over UDP (even though payload size > 1300 bytes) - according to RFC 3261 (or any other RFC)? In our case, the first request (INVITE) is < 1300 bytes, so it is sent over UDP as default, however, a Re-INVITE in the same dialog is longer than 1300 bytes, so the peer is trying first over TCP, and subsequently (after a significant delay which is unacceptable), tries to send over UDP. > * Will it be possible to use UDP protocol only between 2 SIP > entities for all messages across dialogs? Yes; however this assumes that you don't have a fragmentation, size, or security reason which would require another transport. See above for more details. > Is there a possibility to negotiate this transport parameter > beforehand between 2 entities (via OPTIONS ?) ? >From an IETF SIP negotiation perspective, no. However from a service, >configuration, or proprietary perspective, the two devices might allow such >behavior. Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
