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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
