Am 06.07.2011 08:28, schrieb Olle E. Johansson: > > 6 jul 2011 kl. 00.35 skrev Iñaki Baz Castillo: > >> 2011/7/5 Martin Hoffmann <[email protected]>: >>> Well, you shouldn't. You should use transport=tcp, because that >>> is the transport protocol you are using. That you want this >>> encrypted is indicated by the sips scheme of your SIP URI. >> >> It's like in HTTP world: >> >> - http:// means HTTP over TCP. - https:// means HTTP over TLS over >> TCP. >> >> Since HTTP just works over TCP, there is no reason for a >> ;transport param. But SIP protocol can work over different >> transport layers (TLS is not a transport layer). >> > You can not compare sips with https. Sorry. > > https puts a requirement for TLS all the way. > > SIPS: in RFC3261 did not. It's simply a request, a proposal. Now if > you don't want to change the properties of the original request, but > still require your infrastructure to use TLS for the next hop you do > not want to change to a SIPS: uri, which will put a new requirement > for the rest of the signalling. You want to add an attribute like > ";transport=tls".
If you do not change the RURI but add a Route header with "sips:" then it would influence only the next hop. Anyway, I still vote for transport=tls as it is unambiguous. klaus > > Yes, SIPS: is really messy and hard to understand. How would you guys > handle a Contact: with SIPS: ? Can you reuse a connection like > outbound? I guess not, since you have to verify the endpoint > certificate. > > /O _______________________________________________ sr-dev mailing > list [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
