Subject: [Sip] Question on section 3.4 of draft-ietf-sip-outbound-10

From: "Jonathan Cumming" <[email-masked]>
Date: Mon, 1 Oct 2007 15:32:48 +0100

Cullen, Rohan,

I am concerned about the value and practicality of section 3.4 of
draft-ietf-sip-outbound-10, and would like to understand the reasoning
behind the text "(and not a subsequent flow with the same addresses)",
as this is not discussed in the mandatory text and this characteristic
is not provided by the example flow token generation algorithm in
section 5.2.

In detail, section 3.4 states the following:

  "When the Edge
   Proxy receives a registration, it needs to create an identifier value
   that is unique to this flow (and not a subsequent flow with the same
   addresses) and put this identifier in the Path header URI."

I presume that reason that subsequent connections between identical
addresses are treated as different flows is that the remote address and
port may have been reallocated to a different device.  Therefore, after
a connection failure, a request to the UA routed using the flow
identifier could go to a different device.  Is this text trying to
protect against this unusual situation (which would be rejected by the
UA), or is there a rather more practical reason for blurring the layers?

Why should a recovered connection be viewed differently from a previous
one, as long as the UA is still contactable over that flow?

Many thanks,
Jonathan

Cullen, Rohan,

I am concerned about the value and practicality of section 3.4 of
draft-ietf-sip-outbound-10, and would like to understand the reasoning
behind the text "(and not a subsequent flow with the same addresses)",
as this is not discussed in the mandatory text and this characteristic
is not provided by the example flow token generation algorithm in
section 5.2.

In detail, section 3.4 states the following:

  "When the Edge
   Proxy receives a registration, it needs to create an identifier value
   that is unique to this flow (and not a subsequent flow with the same
   addresses) and put this identifier in the Path header URI."

I presume that reason that subsequent connections between identical
addresses are treated as different flows is that the remote address and
port may have been reallocated to a different device.  Therefore, after
a connection failure, a request to the UA routed using the flow
identifier could go to a different device.  Is this text trying to
protect against this unusual situation (which would be rejected by the
UA), or is there a rather more practical reason for blurring the layers?

Why should a recovered connection be viewed differently from a previous
one, as long as the UA is still contactable over that flow?

Many thanks,
Jonathan

Cullen, Rohan,

I am concerned about the value and practicality of section 3.4 of
draft-ietf-sip-outbound-10, and would like to understand the reasoning
behind the text "(and not a subsequent flow with the same addresses)",
as this is not discussed in the mandatory text and this characteristic
is not provided by the example flow token generation algorithm in
section 5.2.

In detail, section 3.4 states the following:

  "When the Edge
   Proxy receives a registration, it needs to create an identifier value
   that is unique to this flow (and not a subsequent flow with the same
   addresses) and put this identifier in the Path header URI."

I presume that reason that subsequent connections between identical
addresses are treated as different flows is that the remote address and
port may have been reallocated to a different device.  Therefore, after
a connection failure, a request to the UA routed using the flow
identifier could go to a different device.  Is this text trying to
protect against this unusual situation (which would be rejected by the
UA), or is there a rather more practical reason for blurring the layers?

Why should a recovered connection be viewed differently from a previous
one, as long as the UA is still contactable over that flow?

Many thanks,
Jonathan

_______________________________________________
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