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.