Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
troubleshooting:tm:t_relay [2009/03/20 19:45] 85.58.136.115 |
troubleshooting:tm:t_relay [2009/03/30 18:10] (current) 212.230.253.254 |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ===== t_relay() clarification ===== | ||
| + | |||
| + | The aim of this page is to clarify '' | ||
| + | |||
| + | The documentation of '' | ||
| + | |||
| + | |||
| + | === Server transaction creation === | ||
| + | |||
| + | > The coresponding transaction may or may not be already created. If not yet created, the function will automatically create it. | ||
| + | |||
| + | * Is always a server transaction created? | ||
| + | * //ibc: It seems that when '' | ||
| + | * //jh: I have verified that transaction is created when t_relay() returns -4 or -6. I suspect that transaction is also created with return value -5 and that it is NOT created when return value is -1, -2, or -3.// | ||
| + | * Also in case of failure? | ||
| + | * //ibc: The server transaction is not created in case of failure (negative return code of '' | ||
| + | * If so, in which cases a server transaction is **not** created? | ||
| + | * //ibc: In any negative response of '' | ||
| + | * Does it depend on the destination transport? | ||
| + | * //ibc: No.// | ||
| + | |||
| + | |||
| + | === Returned error codes === | ||
| + | |||
| + | > In case of error, the function returns the following codes: | ||
| + | > -1 - generic internal error | ||
| + | > -2 - bad message (parsing errors) | ||
| + | > -3 - no destination available (no branches were added or request already cancelled) | ||
| + | > -4 - bad destination (unresolvable address) | ||
| + | > -5 - destination filtered (black listed) | ||
| + | > -6 - generic send failed | ||
| + | |||
| + | * When "//-1 - generic internal error//" | ||
| + | * When "//-6 - generic send failed//" | ||
| + | * Do the returned codes depend on the type of destination transport protocol? | ||
| + | |||
| + | |||
| + | === Failure route invocation === | ||
| + | |||
| + | * In which cases '' | ||
| + | * //jh: I suspect that failure route is called only when t_relay() returns 1.// | ||
| + | * //ibc: Checked that if the destination host is down or doesn' | ||
| + | * In which cases '' | ||
| + | * //jh: I suspect that failure route is called only when t_relay() returns 1.// | ||
| + | * //ibc: Checked that if the destination host is down or doesn' | ||
| + | * //t_relay() returns nothing, auto-reply is generated and '' | ||
| + | * // | ||
| + | |||
| + | |||
| + | === Transport erros === | ||
| + | |||
| + | * What is exactly a " | ||
| + | * //jh: I suspect that UDP transport error results if sending out UDP packet fails, for example, when there is no route for the destination.// | ||
| + | * What is exactly a " | ||
| + | * //jh: I suspect that TCP transport error results if TCP connection to the destination cannot be establised.// | ||
| + | * //ibc: This means that having a default gw, sending an UDP SIP request to a non responding IP will cause t_relay() to return 1 and failure_route to be invoked, while the same request to the same destination using TCP will cause t_relay() to return -6 and failure_route not to be invoked. This is because the UDP request was successfully sent while the TCP connection couldn' | ||
| + | |||
| + | |||
