Maybe the new dialog module can be used to store state of dialogs in
shared storage (e.g. DB)...
On 5/9/06, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
Hi Cseke,
Cseke Tamas wrote:
Mike Williams wrote:
If you use only transaction statefulness (the
only stateful mode the
stable branch of OpenSER can do), this should not be a problem, as
the INVITE and BYE messages are separate transactions. If you account
to the same backend, you should maintain accounting consistency, too.
---Mike
That means, if one proxy dies during the session, the UA'll make a DNS
SRV lookup, find the other proxy, and send the BYE to it instead of
the proxy, which served the INVITE?
not quite - all sequential request (within the dialog) are routed based
on the route set (the Record Route hdr added by the proxies on the
path). The headers contains IP addresses, so basically no DNS lookup is
done for sequential requests. An alternative will be to configure your
proxy to put DNS name instead of IP in the RR hdr.
Beacause of openser is only transaction stateful
it don't know nothing
about the session eg: to which INVITE belongs to this BYE?
right
I planned to use TM module t_replicate function
to replicate all
messages to all proxy, it 's no sense, if openser doesn't maintain the
states of dialog, isn't it?
right
regards,
bogdan
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users