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