29 Sep
2008
29 Sep
'08
2:22 p.m.
samuel wrote:
The Call-ID hash is used to send all requests of the
same dialog to the
same endpoint (proxy,application server,gateway,whatever...). The
reason after this behaviour is not to have these SIP endpoints sharing
the status of all the dialogs (not many applications out there share
this status and therefore you are required to send all within-dialog
messages to the same SIP instance).
simple: to send the BYE to the same gateway you sent the INVITE...
This does not guarantee fare load distribution....that's why depending
on what you are dispatching you can hash on several headers (if you
don't have to keep dialog state,...)
Yes, but is that not a relatively minor use case that applies to
situations in which stateful transaction forwarding (TM module) is not
used?
Meaning, if I t_relay() an INVITE to a gateway selected by dispatcher,
subsequent provisional responses and in-dialog requests will be passed
between the original endpoints without further intervention.
If it didn't work that way, round-robin and random wouldn't work as
algorithms because the next message would be sent to another server.
So, stateless forwarding aside (why would you want to do that in a
dispatcher load balancing or failover scenario?), why do these hash
algorithms make any sense to use?
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599