[reSIProcate] Handling glare conditions in DUM

[Jason Fischl]

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 at avaya.com> 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 at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>