Subject: Re: [Sip] RR-fix: open issue on transport protocol parameter

From: Robert Sparks <[email-masked]>
Date: Mon, 1 Oct 2007 13:51:14 -0500

Actually, I don't think either of these proposals is the solution for  
this particular issue.

Jiri hit it on the head - the problem with the scenario you describe  
was at P2 - it _really_
needed to record-route.

There's already some text in 3261 that pushes in this direction and  
probably what we want
to do is just make that more clear in this document. The essence is  
that if you are a proxy
and you change the transport characteristics as you forward a  
message, you need to record-route.

RjS

On Sep 28, 2007, at 7:26 AM, Thomas Froment wrote:

> Before issuing a new version, draft http://www.ietf.org/internet- 
> drafts/draft-ietf-sip-record-route-fix-00.txt still contains (at  
> least) one open issue deserving the WG attention:
>
> It is located in section "6. Usage of transport parameter", and  
> question is marked as "[Note: these two suggestions have to be  
> discussed]" at the end of this section.
>
> I will still try to summarize the problem:
> This is related to a common practice in proxy implementors to  
> support  double Record-Route AND put the transport protocol  
> parameters. This practice is acceptable as long as all SIP elements  
> that MAY be in the path of subsequent requests support that  
> transport. This "restriction" needs  an explanation: let's imagine  
> you have two proxies "P1" and "P2" on  the path of an initial  
> request. P1 is record-route and changes the  transport from UDP to  
> SCTP because P2 URI resolves to SCTP transport  applying [RFC3263],  
> and consequently decides to put two Record-Route,  one with  
> P1;transport=UDP, another one with P1;transport=SCTP. The  problem  
> arises if P2 is not record-route, because the next SIP  element  
> after P2 will be asked to reach P1 using SCTP transport for any  
> subsequent request from callee, and this SIP element MAY NOT  
> support that transport.
>
> Today, two propositions have been identified to handle this situation:
>
> - The first solution is to add to section 4.1 "Selecting a  
> transport  protocol" of [RFC3263] which states that "If the URI  
> specifies a transport protocol in the transport parameter, that  
> transport  protocol SHOULD be used.", the following statement: "if  
> this protocol  is not supported the procedures described in this  
> document SHOULD be
>   followed as if the transport parameter was not set on URI".
>
> - Another solution is to RECOMMEND to NOT put any transport  
> parameter  on Record-Route URI if the transport is a a transport  
> protocol not mandated by RFC3261 (i.e. a transport different from  
> UDP, TCP or
>   TLS).
>
>
> Are any of these propositions considered as acceptable?  
> preferences? better suggestions? any help is very welcome,
>
> Thomas
>
>
>
>
>
> _______________________________________________
> 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: Dean Willis <[email-masked]>
Date: Tue, 2 Oct 2007 11:49:12 -0500

On Oct 1, 2007, at 1:51 PM, Robert Sparks wrote:

> Actually, I don't think either of these proposals is the solution  
> for this particular issue.
>
> Jiri hit it on the head - the problem with the scenario you  
> describe was at P2 - it _really_
> needed to record-route.
>

And not only that, the proxy either needs to double-record or do a  
reverse patch-up on responses.

--
Dean

---

From: Thomas Froment <[email-masked]>
Date: Wed, 17 Oct 2007 15:17:13 +0200

Ok, I will try to make it in version -01,
any other comment on the draft? ... any volunteer reviewer(s)?
Thomas