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 and retransmissions?
---greg
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 URI.
The trade-offs between stateless forward and stateful t_relay are described in http://www.iptel.org/ser/doc/seruser-html/x740.html#AEN839
If you do not not, whether to go stateful or stateless, you will be probably better if with stateful.
Cheers,
-Jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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 and retransmissions?
---greg
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 cannot.
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 practical impact.
-Jiri