[sr-dev] [tracker] Task changed: Extending TM timeout/408 handling

[sip-router]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has been changed.  The changes are listed below.  For full information about what has changed, visit the URL and click the History tab.

FS#55 - Extending TM timeout/408 handling
User who did this: Iñaki Baz Castillo (ibc)
Task details edited:
-------
Hi, let's suppose the following case:
SR receives an INVITE and performs serial or parallel forking to gw1 and gw2.

Three cases:


case a)
- gw1 replies 480.
- gw2 replies 408.

case b)
- gw1 replies 480.
- gw2 replies 180 and fr_inv_timer expires so a local 408 is generated.

case c)
- gw1 replies 480.
- gw2 replies nothing and fr_timer expires so a local 408 is generated.


In any case, after the transaction fails I handle the winning response in failure_route in which I get a 408. But there is no way to determine which of the above 3 cases took place.

For cases "a" and "b" the 408 could be a good choice (also the 480) but in case "c" I'd strongly prefer using the 480. But there is no way, in failure_route, to determine if our case is "a", "b" or "c".

A non reliable pseudo-workaround is setting a transaction flag(RINGIN_RECEIVED) so when inspecting the 408 in failure_route we can "determine" if fr_timer expired (case "c") or not (cases "a" or "b"). This is not reliable as the flag could be set by other branch in which 1XX was received.


Possible solutions:



SOLUTION 1)

When fr_timer expires a new status code is locally generated, i.e. 478 "No response received at all". Such code would have lowest priority. The admin could choose to send a 500 error upstream if the final chosen response is a 478 (which just makes sense for the server), or perhaps the server itself could automatically map a final 487 response to a 500 (as it does with 503).

Using this approach the above cases would choose the following final response:
a) 408
b) 408
c) 480


SOLUTION 2)

Generate local 503 if fr_timer expires. According to RFC 3261 there are two posibilities if the transport layer fails:
- Timeout, no response, so 408 is locally generated.
- Transport error so 503 is locally generated. Transport error can occur in both TCP and UDP:

In TCP a transport error means that the TCP connection failed.
In UDP a transport error means that the UAC received a ICMP indicating "UDP port 5060 unreachable".
The transport error for UDP is not handled by TM as it doesn't rely on the received ICMP. Also it seems that such ICMP mechanism is not interoperable between different TCP/IP stacks.

Anyhow, I would suggest that when fr_timer expires (in UDP) a locally generated 503 could make sense. Why not? If there is no response at all for a transaction then there is some kind of network issue or perhaps the remote server is down/congested. 503 seems suitable for me, even if RFC 3261 doesn't state it.

PS: As far as I know, other SIP stacks uses internal codes (like 7XX) to indicate such kind of errors (transport error, transport timeout...). I think something like that is a real need even if RFC 3261 didn't consider it (as they didn't consider NAT).

Using this approach the above cases would choose the following final response:
a) 408
b) 408
c) 480




Opinions?
-------

More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=55

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.