I guess what I'm asking is what does stateful do?
Does it take control of all requests relating
to the current call-id from that point on? So my
may route logic does not need to think about ACKs
>At 07:08 PM 12/9/2002, Greg Fausak wrote:
>>Has this documentation always been available?
>>This is definately making a difference for me!
>We just released this documentation update.
>Yes, forward is built-in, t_relay/t_relay_to is
>part of tm modules. forward(<host>,<port>) or
>t_relay_to("<host>", "<port>") sends a request
>to the address in params. forward(uri:host, uri:port)
>and t_relay() sends a request to the address in current
>The trade-offs between stateless forward and stateful
>t_relay are described in
>If you do not not, whether to go stateful or stateless,
>you will be probably better if with stateful.
>Jiri Kuthan http://iptel.org/~jiri/ >
>Serusers mailing list
>serusers at lists.iptel.org
At 08:09 PM 12/9/2002, Greg Fausak wrote:
>Thank you for the reply.
>I guess what I'm asking is what does stateful do?
>Does it take control of all requests relating
>to the current call-id from that point on? So my
>may route logic does not need to think about ACKs
Routing logic is same for both statefuly and stateless.
The real difference is that some proxy services need to be
built on top of stateful and will not work otherwise.
For example, t_relay forks, forward does not.
t_relay can be used to account transactions, forward
As for retransmissions: with stateful processing, ser
retransmits on UAC behalf. With stateless processing,
UAC retransmits and the retranmission get statelessly
propagated through proxy. Not of dramatically big