You may also find RFC 4483 (Content-Indirection in SIP) useful, depending on support in the endpoints.
Michael 2009/6/30 Brett Tate <[email protected]>: > Yes; the RFCs currently require the same transport be used. > > Some vendors will likely accommodate what you are attempting. However just > because the UAC/proxy might be willing to receive the response doesn't mean > they will actually process it as you are hoping; thus it might it might be > hard to determine "if it is failed". > >> -----Original Message----- >> From: [email protected] [mailto:sip- >> [email protected]] On Behalf Of JC >> Sent: Tuesday, June 30, 2009 1:50 AM >> To: [email protected] >> Subject: [Sip-implementors] About Transport Selection in Response >> >> Hi All, >> >> I checked section "18.2.2 Sending Responses" in RFC3261 and section "5 >> Server Usage" in RFC 3263, maybe I missed something. My concern is >> whether it is mandatory for RESPONSE to use the same transport protocol >> as its REQUEST. Needn't think about TLS but UDP/TCP. For example, >> incoming REQUEST is "Via: SIP/2.0/UDP", can I use TCP to send its >> response. Needn't consider NAT etc. issues. Just wanna make sure SIP >> specs don't forbid it. Because sometimes incoming REQUEST is via UDP, >> and its RESPONSE takes big message body, can I use TCP to send REPONSE >> back. My expecting transport policy in the case is to try TCP firstly, >> if it is failed, will have to use UDP to resend mandatorily. >> >> Thanks and Regards, >> JC > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
