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

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 Apr 2005 13:20:18 +0100

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
> 

_______________________________________________
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: Miguel Garcia <[email-masked]>
Date: Wed, 06 Apr 2005 15:31:34 +0300

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