2011/7/13 Brez Borland <brez...@gmail.com>: > I see two options when caller wants to use TLS to the first hop(at least), > and doesn't want to be contacted back in clear SIP: > 1) Use SIPS. > 2) Use SIP, but never be contacted "directly", but rather at least through > it's outbound proxy.
Using SIPS in the RURI has no point in current Internet so I expect that using TLS between the client and his outbound proxy is good enough. RFC 5630 says that, for that, the client should use SIP in all the headers (including Contact) and sent the request via TLS (Via: SIP/2.0/TLS). But after the dialog is established, the route set would have a SIPS URI in the first position (added by the outbound proxy), so in-dialog requests from the caller would have a top most Route with SIPS, which means that Contact URI MUST be SIPS (so, the caller should migrate the SIP Contact of the initial INVITE to SIPS for the in-dialog request). That's the "bug" I see in the spec. Using SIPS in the Contact of the initial INVITE (and just there) would fix the issue above, but contradicts RFC 5630 :( > Option (1) is straight forward. > With option (2), two techniques come in mind: > a) Use rfc5626, the outbound. I must read this RFC :) > b) Utilize the rfc3327 (Path Header Extension). Yes, but it tries to accomplish the opposite of what I asked (TLS just in client -> proxy path). > I think that true problem here is the caller inserting an IP addresses, > instead of host/domain names. Substitute the IP address for host name and > the problem is gone, IMHO. Why? I don't get what you mean, could you please detail it please? Best regards. -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
