Subject: "next hope", was: RE: [Sip] Question on SIPS and Contact URI

From: Milinski Alexander <[email-masked]>
Date: Thu, 7 Apr 2005 09:55:06 +0200

Hi Miguel,
"next hope" is a nice typo in this context :-)
Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miguel Garcia
Sent: Thursday, April 07, 2005 9:05 AM
To: Peterson, Jon
Cc: [email-masked]; Elwell John
Subject: Re: [Sip] Question on SIPS and Contact URI

I think it is widely agreed that SIPS is underspecified. Although this 
give us a hint for future work, probably we should provide guidelines 
for those facing problems in real deployments. I suspect Jon already 
mentioned those guidelines:

a) if a proxy changes a transport protocol, it should double record 
route. In my opinion this does not apply to mandatory transport 
protocols in the UA, e.g, a proxy that changes from UDP to TCP, because 
both are implemented in User Agents.

b) in case a UA receives a SIP request that creates a dialog, whose next 
hope (Contact or Record-Route) contains a non-supported transport 
protocol, the UA should reject the dialog. I would assume that a Warning 
header could provide further information about the failure.

Is this reasonable for the time being?

/Miguel

"Peterson, Jon wrote:

> Paul is certainly correct that SIPS is underspecified, and I think that with the advent of certain other tools for SIP (notably jennings-sipping-outbound) it will be possible for us to revisit SIPS and come up with a more coherent story.
> 
> That much said, I think this issue of providing a Contact header in a dialog-forming request which uses a transport unsupported by the recipient is broader than SIPS. If the recipient only supports UDP, and receives a request with a Contact header containing a ;transport=TCP parameter, what is supposed to happen? This has been a much-discussed problem for some years. The conventional answer is that a proxy server that changes the transport (where this is understood to include converting from TLS to unsecured TCP, even) must Record-Route itself and remain in the path of future signaling within a dialog. This of course results in inefficiency when the recipient UA does in fact support the transport protocol given in the Contact, but the proxy has no way to anticipate this capability.
> 
> The more transport protocols we specify for SIP (yes, I'm talking to you, SCTP), the more sorts of problems along these lines we will face.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>>Elwell, John
>>Sent: Wednesday, April 06, 2005 5:20 AM
>>To: Samuel Osorio Calvo; [email-masked]; Elwell, John
>>Cc: [email-masked]
>>Subject: RE: [Sip] Question on SIPS and Contact URI
>>
>>
>>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
> 
> 

-- 
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

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 07 Apr 2005 11:05:58 +0300

It was on purpose ;-)

/Miguel