Re: [reSIProcate] Handling glare conditions in DUM
Hi Bill,
I'm not sure I fully understood the call flows you are having problems
with. Can you elaborate? What call flow(s) are causing dum to assert?
Can you show both sides of the b2bua in the flow?
Jason
On 2/21/07, Kovar, William (Bill) <bkovar@xxxxxxxxx> wrote:
I was wondering if someone might shed some light on how it would be possible
to handle a glare condition with DUM.
I have a situation where an endpoint INVITE is answered and then I receive
an ACK. Upon receipt of the ACK I want to immediately REFER the call
(in-dialog REFER). However, the endpoint, right after sending the ACK is
sending me a re-invite that glares with the Refer I send. My Refer gets a
491 from the endpoint and I resend the Refer again. However, in other
situations I get a re-invite from the endpoint at the same time that I am
sending a re-invite (I send first). Since I am a B2B and need to shuffle
these re-invites, I run into problems with DUM being in a state (dum.mstate)
that I can't get at that is causing assertions. Basically, my endpoint (a
switch) always sends me a re-invite after it sends ACK.
Is there a way to queue up either one of these transactions with DUM to
resolve the glare condition??
TIA for your thoughts...
Bill Kovar
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel