Greetings,
An OpenSER REQUEST-ROUTE that statefully t_relay()s an INVITE request will automatically pass back a provisional "100 Trying" response to the sender.
The problem I have is that I have a database operation that occurs in my main REQUEST-ROUTE that can potentially, under certain unfavourable circumstances, be somewhat latent. This operation must run before the relaying can occur, since its results are used to rewrite the RURI, etc. When the operation lags, sometimes it exhausts the T-timers and results in retransmission of the INVITE, or, for equipment configured in a particularly conservative way, even a failure.
So, what I need is some way to pass a provisional "100 Trying" at the beginning of the REQUEST-ROUTE immediately in order to placate the sender.
I can't just reply statelessly, because I need the stateful processing for other things related to call accounting, so I must use 'tm.' And if I send a stateless "100 Trying" reply, the subsequent t_relay() will not know that and duplicate it, and although as far as I know this does not violate the RFC, it is still a situation I would like to avoid in principle.
What I need to know is if there is some way in 'tm' to disable automatic provisional responses in a temporary or ephemeral fashion, or else to disable them entirely and then re-enable them later.
Thank you so much in advance for all of your help!
-- Alex
Hello,
On 07/25/08 03:07, Alex Balashov wrote:
Greetings,
An OpenSER REQUEST-ROUTE that statefully t_relay()s an INVITE request will automatically pass back a provisional "100 Trying" response to the sender.
The problem I have is that I have a database operation that occurs in my main REQUEST-ROUTE that can potentially, under certain unfavourable circumstances, be somewhat latent. This operation must run before the relaying can occur, since its results are used to rewrite the RURI, etc. When the operation lags, sometimes it exhausts the T-timers and results in retransmission of the INVITE, or, for equipment configured in a particularly conservative way, even a failure.
So, what I need is some way to pass a provisional "100 Trying" at the beginning of the REQUEST-ROUTE immediately in order to placate the sender.
I can't just reply statelessly, because I need the stateful processing for other things related to call accounting, so I must use 'tm.' And if I send a stateless "100 Trying" reply, the subsequent t_relay() will not know that and duplicate it, and although as far as I know this does not violate the RFC, it is still a situation I would like to avoid in principle.
What I need to know is if there is some way in 'tm' to disable automatic provisional responses in a temporary or ephemeral fashion, or else to disable them entirely and then re-enable them later.
Thank you so much in advance for all of your help!
relay functions from tm take a parameter that can disable sending the provisional reply.
http://www.openser.org/docs/modules/1.3.x/tm.html#AEN345
Cheers, Daniel
Daniel-Constantin Mierla wrote:
Hello,
On 07/25/08 03:07, Alex Balashov wrote:
Greetings,
An OpenSER REQUEST-ROUTE that statefully t_relay()s an INVITE request will automatically pass back a provisional "100 Trying" response to the sender.
The problem I have is that I have a database operation that occurs in my main REQUEST-ROUTE that can potentially, under certain unfavourable circumstances, be somewhat latent. This operation must run before the relaying can occur, since its results are used to rewrite the RURI, etc. When the operation lags, sometimes it exhausts the T-timers and results in retransmission of the INVITE, or, for equipment configured in a particularly conservative way, even a failure.
So, what I need is some way to pass a provisional "100 Trying" at the beginning of the REQUEST-ROUTE immediately in order to placate the sender.
I can't just reply statelessly, because I need the stateful processing for other things related to call accounting, so I must use 'tm.' And if I send a stateless "100 Trying" reply, the subsequent t_relay() will not know that and duplicate it, and although as far as I know this does not violate the RFC, it is still a situation I would like to avoid in principle.
What I need to know is if there is some way in 'tm' to disable automatic provisional responses in a temporary or ephemeral fashion, or else to disable them entirely and then re-enable them later.
Thank you so much in advance for all of your help!
relay functions from tm take a parameter that can disable sending the provisional reply.
Hah.
"do not generate an 100 trying provisional reply when building the transaction. By default one is generated. Useful if you already pushed an stateless 100 reply from script."
Thank you, Daniel-Constantin. From this, the only viable and necessary conclusion to draw is that I'm a flat-out idiot for completely overlooking this plainly obvious-as-day fact in what I imagined to be effective RTFMing. :-)
-
Alex Balashov -
Daniel-Constantin Mierla