On Jul 19, 2007, at 5:04 PM, Jeroen van Bemmel wrote:
Hi,
A comment / clarification on outbound-10 section 5.3 Forwarding
requests, regarding flow token construction and incoming/outgoing
logic:
The text says to send a 430 (Flow Failed) "For connection-oriented
transports, if the flow no longer exists" (SHOULD)
This can be read as saying that if the original TCP connection no
longer exists, a 430 should be sent. However, if the UAC somehow
lost its connection and recovered, there would be a new TCP
connection with (likely) a different ephemeral port at the UAC.
There is a timing issue here. Two things could happen based on timing.
1) If the UA hasn't noticed that its original TCP connection failed,
or it noticed but the REGISTER for its new flow has not been received
or processed yet, then edge proxy (if any) should send a 430. If
there is another active flow, the authoritative proxy can try that
flow. The failed flow does not
2) The UA sent a new REGISTER to replace its original (failed) flow
and that request has been processed. The original flow would never
be attempted.
In both cases, the best possible thing that could happen will happen.
For the proposed flow token algorithm, this would cause the
described incoming/outgoing logic to fail (since the token no
longer matches an incoming flow from the UAC). Moreover, for
requests in the other direction ("incoming") the proxy would not be
able to locate the new flow, and send a 430 where it could have
done better.
Two thoughts:
1. To determine if a (non-REGISTER) request is incoming/outgoing,
it might be easier to simply say: 1 Via header --> outgoing, else
incoming.
In a proxy with a colocated UA (ex: the registration package or a
presence server), the proxy can emit "incoming" requests with 1 Via
header.
There are other options, the Edge proxy could check the request URI
for a Contact URI it has seen in REGISTER before. It could also be
based on Service-Route and/or Path.
This would require the Edge proxy to mirror registration state. We
had a requirement that outbound should work without requiring this
state mirroring.
Perhaps this draft need not explain all details, but it currently
only describes logic for mid-dialog requests, and appears to fail
in the above described case of TCP connection loss.
What you are describing is a mid-dialog flow switchover. This was so
controversial that we made this explicitly out of the scope of this
document. The document does not prevent an edge proxy from doing
this, but it doesn't describe how to do it either.
2. An alternative implementation could be to maintain a mapping of
Contact address ( IP/host+port ) to flow, which is updated each
time a REGISTER 200 OK comes by. If the UAC is using the same
Contact URIs as in its REGISTER (or a GRUU rewritten by the home
proxy), there is no need for a flow token at all: the Edge proxy
can use (IP/host+port part of) the request URI as an (hash) index
into the flow table (for incoming requests).
I'm not understanding where you propose to maintain this mapping. If
you want the edge proxy to keep per-flow state, I'm afraid we had a
strong consensus not to add mechanism that requires that approach.
If the UAC uses a GRUU in the Contact header, the edge proxy may not
need to Record-Route. However, that is a topic for either the GRUU
spec or another spec on mid-dialog Record-Routing to cover.
There are many other designs possible. Main point is that the
stateless flow token approach described seems suboptimal in case of
TCP connection loss (home proxy may be able to recover if the UAC
used 2 or more flows, but if all were lost and the backup edge
proxy also implemented this algorithm, ongoing dialogs would be lost)
Yes. And we decided for this document that losing those calls was
acceptable for this document. Other specification work can take up
that challenge, otherwise we will never make forward progress.
thanks,
-rohan
Regards,
Jeroen
_______________________________________________
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
