Subject: RE: [Sip] Maintaining transport between servers (was: Transport p arm in Rec ord-Route)

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 27 Jun 2001 09:43:15 -0500

I thought we agree the RR could be asymmetric. That is
the RR could be different in either direction to allow
for the types of variations that you are speaking of.

/sean

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, June 27, 2001 9:19 AM
>To: [email-masked]
>Subject: [Sip] Maintaining transport between servers (was: Transport
>parm in Rec ord-Route)
>
>
>
> I had another thought on this prompting me to rename the 
>thread.  The goal
>is to use the same transport between two servers for subsequent
>transactions.  Simply putting the transport in a record-route has an
>undesirable side affect.  That route could be used by the hop 
>on either side
>of the server that added it.  In the original example, if UAS sent a
>subsequent request it might try to do it over TLS when all 
>that is needed
>there is UDP.  We need some mechanism in SIP to communicate a desired
>transport between two specific servers in the Route list that 
>will work for
>subsequent requests in either direction.
>
>John
>
>
>
>> We have encountered a problem with the requirement in 16.3 where
>>Record-Route MUST NOT contain the transport parameter.  I 
>realize this was
>>designed to handle the possibility of requiring a UA that 
>does not support
>a
>>particular transport to use said transport, resulting in a failure.
>>However, this also causes problems when the proxy must use only one
>>transport for all transactions.  Take for example a proxy (B) 
>in a private
>>network that has a TLS connection with a trusted peer proxy 
>(A) on the open
>>Internet.  The flow for an Invite might be something like:
>>
>>UAC -> proxy (A) -> proxy (B) -> UAS
>>
>> Now if both proxies are record-routed without the transport parm, the
>>initial transaction could be setup on TLS OK based on proxy 
>(A) routing
>>decisions, but if a subsequent transaction such as BYE came 
>from the UAC,
>>proxy (A) would see a Route header with no transport parm, 
>use it as the
>>req-URI which, lacking a transport parm results in using 
>default UDP (see
>>reference below).  Since proxy (B) only trusts and listens 
>for requests
>over
>>a TLS connection, the request fails.
>>
>>From section 2, descrition of URL parameters:
>>
>>UDP is to be assumed when no explicit transport parameter is included.
>>
>> Perhaps some new verbage is needed describing proxy 
>behaviour and how to
>>select the transport protocol when not specified, i.e. look 
>for open TLS or
>>TCP sockets to the destination first.  This still might not 
>help if for
>>example the transport was TCP and the socket timed out due to 
>inactivity.
>>There may be other ways around this problem I have not 
>thought through yet.
>>Comments?
>>
>>
>>John Hearty
>>Level3
>>
>
>_______________________________________________
>Sip mailing list  http://www.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: [email-masked]
Date: Wed, 27 Jun 2001 09:01:02 -0600

Are you referring to the discussions involving a proxy being able to add
the RR looking a certain way in the request, and modify the RR in the
response to look different to the other side?  That would work to solve my
latest concern.  We still need to get past the verbage disallowing the
transport parm in the RR.
 
John

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 8:43 AM
To: Hearty, John; [email-masked]
Subject: RE: [Sip] Maintaining transport between servers (was: Transport p
arm in Rec ord-Route)

/sean 

>From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>>There may be other ways around this problem I have not 
<http://www.ietf.org/mailman/listinfo/sip>