6 Jul
2011
6 Jul
'11
11:03 a.m.
Am 06.07.2011 08:28, schrieb Olle E. Johansson:
6 jul 2011 kl. 00.35 skrev Iñaki Baz Castillo:
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
2011/7/5 Martin Hoffmann
<martin.hoffmann(a)telio.ch>ch>:
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". 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).
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 sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev