Re: [reSIProcate] Handling glare conditions in DUM
It would be extremely helpful if you could send us the logging output so we'd know which assertion we've hit.
Best regards, Byron Campen 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
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature