Re: Using TLS in the first hop - Bug in RFC 5630
Hadriel Kaplan <[email protected]> Thu, 15 Sep 2011 16:31:14 +0000
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
Oh I'm well aware of that. :) I assumed this whole discussion was theoretical. In *practice* using sips is tough. Some systems don't support it and will = choke on the scheme, while some systems seem to ignore the extra "s". And = there are real problems with it even if you do everything by the book. For= example, it's not like Alice's UA will actually have a TLS cert to be able= to be a TLS server/listen-socket, so you can't open a TLS connection to he= r UA regardless, ever. And with TCP in general you have to treat her Regis= tered Contact connection as an outbound-style flow (ie, like an alias'ed co= nnection-reuse), even if the UAC doesn't indicate RFC 5626 nor 5923. Once = you do that, using "sip" instead of "sips" contact works, or has so far for= us. YMMV. -hadriel On Sep 15, 2011, at 12:03 PM, I=F1aki Baz Castillo wrote: > 2011/9/15 Hadriel Kaplan <[email protected]>: >> No I mean if Bob wants to Refer Carol to Alice, or Alice to Carol (since= that Refer can be sent out of dialog to Alice's contact). > = > Initial requests sent to a Contact address rather than being sent to > an AoR are always problematic. The same occurs in attended trasfer > when the REFER is sent within the dialog and contains a Refer-To with > the endpoint Contact URI. Such URI could be no reachable if it's > between some kind of NAT's (regardless the user used STUN). > = > -- = > I=F1aki Baz Castillo > <[email protected]> _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is essentially closed and only used for finishing old business. Use [email protected] for questions on how to develop a SIP = implementation. Use [email protected] for new developments on the application of sip. Use [email protected] for issues related to maintenance of the core SIP spec= ifications.