TLS is hop by hop. If your next hop (outbound) proxy does not require you to send using TLS, then you can insert a route-header in the request pointing to that proxy and have a sips request-URI. The proxy then needs to forward that request using TLS (if there are no other route headers).
If your next hop requires TLS (its address is sips), but you don't support TLS, then you shouldn't send the request with a sips URI, you may try with a sip URI though. /Hisham > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of ext > [EMAIL PROTECTED] > Sent: Thursday, November 06, 2003 6:40 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [Sip-implementors] Fw: sips URL on non-TLS transport > > > > > > > Reposting as there were no responses to this mail. > > ================ > Hi, > What is the expected behaviour from an entity that > receives a request with a sips URL in the Request-URI > but coming on a non-TLS transport. Is this a legal > scenario ? If not, is there a specific response code > to handle this kind of error. > Also, if it is not an error, what would be the > appropriate Contact to insert in the response - sip > or sips. The caller probably didn't support TLS but > used a sips URL in the initial request so as to > ensure secure communication. But if we assume this > and insert a sips URL in the Contact, then the > endpoint will be forced to use TLS for subsequent > messages in the dialog (per Sec 8.1.2). > > Any pointers are welcome. > > Thanks in advance, > Subhash Nayak > Hughes Software Systems > http://www.hssworld.com > > > > _______________________________________________ > 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
