> > * 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)?
IETF SIP provides no mechanism to avoid first trying "congestion controlled transport protocol, such as TCP". However if I recall correctly, RFC 3261 and/or RFC 3263 provides some service related flexibility to act differently without being non compliant. > 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. Unfortunately, that is how RFC 3261 section 18.1.1 works unless able to remember/notice failure to open TCP connection more quickly to avoid the "significant delay". Resolution would require a proprietary or configurable solution to ignore the RFC 3261 section 18.1.1 requirement. "If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP." _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
