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
