RE: [Sip] SIPS question

[hisham.khartabil@nokia.com]

Removing this restriction seems to fix the problem, I think.

"Independent
   of which URI is used as input to the procedures of [4], if the
   Request-URI specifies a SIPS resource, the UAC MUST follow the
   procedures of [4] as if the input URI were a SIPS URI."

But also, would mandating that: if a REGISTER has a sips-uri contact, the To-header must contain a sips-uri work? and visa versa? 

eg: UA2 registers with sips-uri in both To-header and contact-header (sips in both or neither, but not mixed).

In this case, UA2 home proxy will reject the request with 404 if UA1 sends a request with sip-uri. UA2 can also reject the request directly if it doesn't want to accept requests not using TLS.

Regards,
Hisham

> -----Original Message-----
> From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Monday, November 04, 2002 1:55 PM
> To: Peterson, Jon
> Cc: 'Anders Kristensen'; sip@ietf.org
> Subject: Re: [Sip] SIPS question
> 
> 
> 
> Hi,
> 
> > >Also, it's not only about mid-session requests, even if 
> that may be so in
> > >most cases. Assume the Request-URI for the initial INVITE 
> is SIPS-URI, but
> > the
> > >UAC uses an outbound proxy, ie using a pre-configured 
> Route with SIP-URI.
> >
> > The design of SIPS used as the 'remote target', as the AoR of the
> > destination, necessitates that this first hop go over TLS. 
> Look, as I said,
> > outbound proxies are proxy servers, proxy servers MUST 
> support TLS, and
> > entities that support TLS MUST support SIPS. Converting 
> this Route header to
> > a TLS route is plausible and allowed by the spec.
> 
> Yes, but the problem is again if the UAC doesn't support TLS. 
> Assume the UAC
> gets the Request-URI SIPS-URI from some "external source" 
> (ENUM, data base,
> whatever...), but since it uses an outbound proxy, using a 
> predefined Route with
> SIP-URI, it doesn't care about the Request-URI SIPS-URI.
> 
> I don't know if that scenario is "allowed" or not, but my 
> point was that the
> problem would be the same as for mid-session requests.
> 
> > We considered both transport parameters (transport=tls was 
> obsoleted in
> > favor of SIPS, as I'm sure you recall) and 
> Require/Supported option tags in
> > our deliberations about SIPS. The point is that we wanted a resource
> > identifier that indicates directly that it should be 
> contacted securely.
> 
> Another option would be that the URI in the TO header, which 
> IS end-to-end,
> would be used to indicate if to use TLS or not. That would 
> not allow that TLS is
> used between specific hops only, though.
> 
> Now, however, TLS would be used for the mid-session requests 
> EVEN if the record
> routing proxies insert SIP-URI in the Record-Route headers, 
> and/or the UAC
> inserts SIP-URI in the Contact header, since the TO header 
> URI would not change.
> 
> Now TLS would always be used for the whole session, and not 
> only for the INVITE,
> but I assume that is how most people intend to use it anyway. Or?
> 
> But, I still think the easiest fix would be to change the 
> text as proposed
> earlier. Then, we may have to write something about the 
> outbound proxy scenario
> - or use Jonathan's proposal to use TLS only if the previous 
> hop used TLS
> (assuming we want to use TLS end-to-end ONLY, that is).
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip