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

From: [email-masked]
Date: Fri, 13 Jul 2001 11:30:33 -0600

I haven't heard further on this thread.  Do we have WG concensus the
transport parm should be allowed in RR?

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

That is what I was talking about. I agree that we 
should allow the transport parm in the RR. 

/sean 

>-----Original Message----- 
>From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>Sent: Wednesday, June 27, 2001 10:01 AM 
>To: [email-masked]; [email-masked] 
>Subject: RE: [Sip] Maintaining transport between servers (was: 
>Transport 
>p arm in Rec ord-Route) 
> 
> 
> 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]
<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) 
> 
> 
> 
>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]
<mailto:[email-masked]>  
>< mailto:[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
<http://www.ietf.org/mailman/listinfo/sip>  
>< http://www.ietf.org/mailman/listinfo/sip
<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 
>> 
> 

_______________________________________________
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