[prev in list] [next in list] [prev in thread] [next in thread]
List: sr-users
Subject: Re: [SR-Users] BYE Race Condition
From: Brandon Armstead <brandon () cryy ! com>
Date: 2012-07-31 7:25:19
Message-ID: CACr1DbApMW3DxtuEUBgJ315uAo3qzPU9xt5YxCJUEaOCEawfZA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Daniel,
I will try this -- and get back to you. I noticed the 408 timeout as
well -- and thought that this call flow was strange. Thanks!
Sincerely,
Brandon Armstead
On Mon, Jul 30, 2012 at 1:03 AM, Daniel-Constantin Mierla <miconda@gmail.com
> wrote:
> Hello,
>
> first, such race can happen always and it is ok from sip rfc point of
> view. The carrier UA should have received the BYE from the other side and
> close the dialog, then ignore the rest. So it is a broken UA implementation
> imo.
>
> Let's say you just drop the 481, then the BYE will time out (408)? Is the
> carrier UA still complaining? You can make a failure route for BYE and if
> it is 481, then use t_reply("408", "Timeout") if that makes the UA happier.
>
> Cheers,
> Daniel
>
>
> On 7/28/12 8:42 PM, Brandon Armstead wrote:
>
> Hello,
>
> I am running into an issue where there is a race condition happening.
> I am looking for opinions / ideas on how to handle the following below
> scenario.
>
> Scenario.
>
> UAC places an outbound call -> upstream carrier.
>
> The call is disconnected on both ends at the exact same time,
>
> UAC -> sends BYE upstream
>
> Upstream Carrier -> sends BYE downstream
>
> Upstream 200 OK's the BYE
>
> UAC sends 481 back to Upstream Carrier for their generated BYE.
>
> The upstream carrier is complaining about receiving the relayed 481
> responses -- so my first thought was simply to drop() these from relaying
> upstream.
>
> I am curious how other people are handling this?
>
> Would you suggest simply dropping the relay from being sent back
> upstream on the 481?
>
> Would you simply always 200 OK a downstream BYE from trusted carriers
> regardless of UAC response, and create separate transaction to send BYE
> downstream?
>
> Thank you as always. Look forward to your thoughts / suggestions /
> ideas.
>
> Sincerely,
> Brandon Armstead
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing \
> listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - \
> http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep \
> 23-26, 2012 - http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, \
> Sep 10-12, 2012 - http://asipto.com/u/kpw
>
[Attachment #5 (text/html)]
Daniel,<div><br></div><div> I will try this -- and get back to you. I noticed the \
408 timeout as well -- and thought that this call flow was strange. \
Thanks!</div><div><br></div><div>Sincerely,</div><div>Brandon Armstead<br> \
<div><br><div class="gmail_quote">On Mon, Jul 30, 2012 at 1:03 AM, Daniel-Constantin \
Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" \
target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
first, such race can happen always and it is ok from sip rfc point
of view. The carrier UA should have received the BYE from the other
side and close the dialog, then ignore the rest. So it is a broken
UA implementation imo.<br>
<br>
Let's say you just drop the 481, then the BYE will time out (408)?
Is the carrier UA still complaining? You can make a failure route
for BYE and if it is 481, then use t_reply("408", "Timeout") \
if that makes the UA happier.<br>
<br>
Cheers,<br>
Daniel<div><div class="h5"><br>
<br>
<div>On 7/28/12 8:42 PM, Brandon Armstead
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">Hello,
<div><br>
</div>
<div> I am running into an issue where there is a race condition
happening. I am looking for opinions / ideas on how to handle
the following below scenario.</div>
<div><br>
</div>
<div>Scenario.</div>
<div>
<br>
</div>
<div>UAC places an outbound call -> upstream carrier.</div>
<div><br>
</div>
<div>The call is disconnected on both ends at the exact same time,</div>
<div><br>
</div>
<div>UAC -> sends BYE upstream</div>
<div><br>
</div>
<div>Upstream Carrier -> sends BYE downstream</div>
<div><br>
</div>
<div>Upstream 200 OK's the BYE</div>
<div><br>
</div>
<div>UAC sends 481 back to Upstream Carrier for their generated
BYE.</div>
<div><br>
</div>
<div>
The upstream carrier is complaining about receiving the relayed
481 responses -- so my first thought was simply to drop() these
from relaying upstream.</div>
<div><br>
</div>
<div>I am curious how other people are handling this?</div>
<div><br>
</div>
<div>Would you suggest simply dropping the relay from being sent
back upstream on the 481?</div>
<div><br>
</div>
<div>Would you simply always 200 OK a downstream BYE from trusted
carriers regardless of UAC response, and create separate
transaction to send BYE downstream?</div>
<div><br>
</div>
<div>Thank you as always. Look forward to your thoughts /
suggestions / ideas.</div>
<div><br>
</div>
<div>Sincerely,</div>
<div>Brandon Armstead</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a href="mailto:sr-users@lists.sip-router.org" \
target="_blank">sr-users@lists.sip-router.org</a> <a \
href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" \
target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><span \
class="HOEnZb"><font color="#888888"> </font></span></pre><span class="HOEnZb"><font \
color="#888888"> </font></span></blockquote><span class="HOEnZb"><font \
color="#888888"> <br>
<pre cols="72">--
Daniel-Constantin Mierla - <a href="http://www.asipto.com" \
target="_blank">http://www.asipto.com</a> <a href="http://twitter.com/#!/miconda" \
target="_blank">http://twitter.com/#!/miconda</a> - <a \
href="http://www.linkedin.com/in/miconda" \
target="_blank">http://www.linkedin.com/in/miconda</a> Kamailio Advanced Training, \
Seattle, USA, Sep 23-26, 2012 - <a href="http://asipto.com/u/katu" \
target="_blank">http://asipto.com/u/katu</a> Kamailio Practical Workshop, \
Netherlands, Sep 10-12, 2012 - <a href="http://asipto.com/u/kpw" \
target="_blank">http://asipto.com/u/kpw</a></pre> </font></span></div>
</blockquote></div><br></div></div>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic