Subject: RE: [Sip] Question on SIPS and Contact URI

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 Apr 2005 14:23:17 +0100

Miguel,

This would depend on the UAS that does not support TLS rejecting an INVITE
request containing a SIPS URI in the Contact header field. This certainly is
not spelled out.
If the UAS simply accepts the request, the UAC will not know and will not
retry the request with a SIP URI. Then the UAS will be unable to send any
requests on the dialog, including BYE.

John

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: 06 April 2005 13:32
> To: Elwell, John
> Cc: Samuel Osorio Calvo; [email-masked]
> Subject: Re: [Sip] Question on SIPS and Contact URI
> 
> John:
> 
> The problem is that a SIP URI is never equivalent to a SIPS 
> URI (Section 
> 19.1.4 in RFC 3261), so you can't simply say I use the same 
> URI without 
> the "s" in "sips".
> 
> In your example, if the UAS does not support TLS, and no 
> proxy recorded 
> the route, the session should fail. I think this bit is probably not 
> spelled out in RFC 3261, but I guess this is how it should be. The 
> caller could retry again without TLS, perhaps.
> 
> /Miguel
> 
> Elwell, John wrote:
> 
> > Thanks Samuel and Miguel for your responses.
> > 
> > Yes, it was the case where the UA does not support TLS that 
> was the real
> > driver for the question - non-support by a proxy was an 
> afterthought and
> > shouldn't (in theory) be a problem.
> > 
> > So if I send an INVITE request (say) to a SIPS URI and 
> place a SIPS URI in
> > the Contact header field, if the last proxy forwards it on 
> a non-TLS link to
> > the UAS, then my real question is whether I can depend on 
> that working,
> > i.e., will the destination UA be able to send me subsequent 
> requests in that
> > dialog?
> > 
> > Samuel suggests that the non-TLS UA would still use the SIPS URI for
> > subsequent requests. My idea was that it might convert it 
> to a SIP URI. I
> > guess either should satisfy my concern that my UA will 
> still be able to
> > receive requests from the non-TLS UA. Any other opinions?
> > 
> > John
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Samuel Osorio Calvo [mailto:[email-masked]] 
> >>Sent: 06 April 2005 12:53
> >>To: [email-masked]; 
> >>[email-masked]; [email-masked]
> >>Cc: [email-masked]
> >>Subject: Re: [Sip] Question on SIPS and Contact URI
> >>
> >>When the caller starts a dialog with a SIPS URI, it forces 
> >>that all proxies in the path use TLS and since TLS is a 
> >>mandatory feature for SIP proxies, the request MUST have 
> >>followed a TLS path.
> >>However, RFC 3261 does not mandates anything about the last 
> >>hop (UA-->outbound proxy  OR  egress proxy-->remote UA). 
> >>Thus, the final proxy, applying local policies, might send 
> >>the SIPS request using another transport mechanism to the UA 
> >>because RFC 3261 does not mandates UAs to support TLS.
> >>
> >>Hence, as far as I know, the UA not supporting TLS will use 
> >>the standard SIP forwarding mechanisms (Via, Route, Contact, 
> >>...)  and will probably insert sips: URI in the subsequent 
> >>replies and request. These messages will be taken by the 
> >>proxy, which will use TLS where applicable:
> >>Something like:
> >>
> >>Dialog initiating request:
> >>UA1---???--->outbound 
> >>proxy--TLS-->P1----TLS--->P2----TLS--->Egress proxy--????--->UA2
> >>
> >>reply & within dialog messages:
> >>UA2---???--->Egress proxy---TLS-->outbound proxy----???--->UA1
> >>(P1 and P2 have not inserted Record-Route headers).
> >>
> >>??? will be fixed by local policy and UA supported features, 
> >>it can be UDP, TCP, SCTP,.........
> >>
> >>
> >>Hope it helps and please correct me if I am not right,
> >>
> >>Samuel Osorio.
> >>
> >>
> >>Unclassified.
> >>
> >>>>>Miguel Garcia <[email-masked]> 04/06/05 12:23PM >>>
> >>
> >>The first proxy not supporting TLS? Hmmm... I thought that RFC 3261 
> >>mandates proxies to support TLS (besides UDP and TCP), so the 
> >>case would 
> >>not exist.
> >>
> >>/Miguel
> >>
> >>Elwell, John wrote:
> >>
> >>
> >>>I cannot find anything that specifies how a SIP UA should 
> >>
> >>behave when it
> >>
> >>>receives a SIPS URI in a Contact header during a dialog 
> >>
> >>(target refresh) or
> >>
> >>>during dialog establishment if the transport is not TLS. 
> >>
> >>The implication is
> >>
> >>>that all future requests to that contact must be sent using 
> >>
> >>TLS, even though
> >>
> >>>TLS has not been used up to now for this dialog. Is that 
> >>
> >>correct? What would
> >>
> >>>a UA do that does not support TLS? What if the first proxy that has
> >>>record-routed does not support TLS? One solution might be 
> >>
> >>to convert the URI
> >>
> >>>to a SIP URI for sending future requests.
> >>>
> >>>John
> >>>
> >>>
> >>>_______________________________________________
> >>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip 
> >>>This list is for NEW development of the core SIP Protocol
> >>>Use [email-masked] for questions on current sip
> >>>Use [email-masked] for new developments on the application of sip
> >>>
> >>
> >>-- 
> >>Miguel A. Garcia           tel:+358-50-4804586
> >>sip:[email-masked] 
> >>Nokia Research Center      Helsinki, Finland
> >>
> >>
> >>_______________________________________________
> >>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip 
> >>This list is for NEW development of the core SIP Protocol
> >>Use [email-masked] for questions on current sip
> >>Use [email-masked] 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 [email-masked] for questions on current sip
> >>Use [email-masked] for new developments on the application of sip
> >>
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Apr 2005 10:43:16 -0400

Jonathan and I discovered issues with sip/sips related to GRUU, which 
Jonathan brought up at last meeting. It became apparent that the whole 
subject is underspecified in 3261.

I think the answer needs to be that a sip and sips uri that differ only 
in the scheme name must be understood to identify either the same 
resource or no resource. This allows the derivation of a candidate uri 
of one type given a uri of the other type. This candidate is then not 
guaranteed to work, but if it does work will be the right thing.

	Paul