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

From: Thomas Froment <[email-masked]>
Date: Fri, 28 Sep 2007 14:26:47 +0200

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

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 28 Sep 2007 15:51:39 +0300

Thomas Froment writes:

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

those transports are mandated by ietf, but not in practice widely
implemented.  so a solution cannot make an assumption that all mandated
transports are always supported.

-- juha

---

From: Thomas Froment <[email-masked]>
Date: Fri, 28 Sep 2007 15:04:11 +0200

> transports are always supported.
So well, I assume we don't try to specify a standard for those who don't 
support it, so what is your proposal?

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 28 Sep 2007 16:12:31 +0300

> support it, so what is your proposal?

ask alcatel-lucent, cisco, etc., who make and sell such equipment.

-- juha

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 30 Sep 2007 20:24:00 +0200

At 15:04 28/09/2007, Thomas Froment wrote:
>So well, I assume we don't try to specify a standard for those who don't support it, so what is your proposal?

IMO, a clean solution to that is to have record-routing as SHOULD for proxies. 

For a variety of reasons, record-routing is used almost everywhere, and
there are like troubles if it is not. It should be disabled only for
a good reason, and in such case whoever does so should be careful 
about side-effects.

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/