[SR-Users] Kamailio - Asterisk: Handling loss of SIP BYE and dangling channels

Benjamin Fitzgerald ben at letscorp.us
Fri Jan 8 22:32:47 CET 2016


Alex,

I think #1 fixed it for me! Thank you so much! I changed the RTP timeout on
a test account SIP account and immediately it resolved the issue.

You're right, sending a BYE would effectively synchronize them however I
did not think keepalive using OPTIONS scheme would send a BYE message in
the event of a dead RTP session. That's why I thought this scheme may not
work.

I was mistaken about referring to Kamailio as dialog stateful, it's just
easier for me to think about a call that way. When debugging this problem,
I pulled up the SIP dialog on my Homer server and saw the last message
being 200 OK sent to the SIP Client (after Invite/Trying) and the BYE was
never sent back from the client. I suppose I phrased this incorrectly as
Kamailio thinks the endpoint is in a call, when really it is just Asterisk
and I am personally associating the state with these transactions.

Yes, I recall when I initially read about SSTs, many people reported they
had difficulty getting them to function properly. So far it looks like I
will not have to implement any proxy-side measures.

Benjamin Fitzgerald
LETS Corporation
(925) 235-1154
ben at letscorp.us




*******Confidential Notice:
This message is intended only for the use of the individual or entity to
which it is addressed and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this message in error, please
delete this message from all computers and contact Orion Systems/LETS Corp
immediately by return e-mail and/or telephone at (925) 566-5600

On Fri, Jan 8, 2016 at 12:47 PM, Alex Balashov <abalashov at evaristesys.com>
wrote:

> Benjamin,
>
> On 01/08/2016 03:25 PM, Benjamin Fitzgerald wrote:
>
> 1. Sorry to be unclear, the Asterisk channel does not stay up
>> indefinitely. We do have a max timeout but since a large portion of our
>> business is based on conference calling, the timeout is rather large. I
>> will definitely change the RTP timeout as my first attempt.
>>
>
> Yes, but I was referring specifically to the RTP timeout. If the mobile
> endpoint goes away, it will stop sending RTP. If Asterisk detects that no
> RTP has been received in x seconds, it should hang up the channel, after
> prophylactically sending a BYE for the call in the direction of
> Kamailio/the mobile peer.
>
> I had been under the impression that Asterisk has a fairly conservative
> default RTP timeout anyway, but it seems I may be mistaken:
>
>
> https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L740
>
>
> https://github.com/asterisk/asterisk/blob/master/configs/samples/sip.conf.sample#L624
>
> (Not sure which SIP channel driver you're using.)
>
> 3. I'm not sure this will work in my case because the endpoint is
>> reachable, but client state is not in sync with the server: i.e.
>> Kamailio/Asterisk think it's in a call but the endpoint does not. If
>> sending OPTIONS could tell me if the endpoint thinks it's in a call or
>> not, then this could potentially work.
>>
>
> Would sending a BYE to both peers not have the effect of synchronising
> them forcefully to a state of "the call is hung up"?
>
> If you're concerned about sending a BYE to an endpoint that thinks the
> call is already hung up, don't be. In that case, it'll simply be rejected.
> You can't negatively affect the state of a dialog that's already dead.
>
> Curious, however: when you say "Kamailio/Asterisk think it's in a call",
> how does this apply to Kamailio?
>
> Stateful SIP proxies are transaction-stateful, not dialog-stateful.
>
> Thus, by default, Kamailio doesn't know anything about "calls", but only
> the SIP transactions of which they are made up, and only for so long as
> those transactions are active. The 'dialog' module allows Kamailio to be
> call-stateful, at the cost of additional statekeeping complexity, but you
> should only use this capability if you need it for something (e.g. limiting
> concurrent calls, keepalive/timeout as described previously, etc.)
>
> On a side note, is there a SIP message that I can send to a client to
>> have it report its state? (Registered, Auth Failed, In a call, etc.)
>>
>
> There's no standard query mechanism like this that I am aware of; the only
> way of disseminating such state information with which I'm familiar is
> presence, which is proactively pushed out by the endpoints and requires
> server-side support.
>
> 4. I do know about SIP Session Timers but chose to not use them during
>> the initial deployment (because of Asterisk channel timeout which I know
>> realize is too large). Maybe this will help in conjunction with the
>> above methods.
>>
>
> SSTs are rather bureaucratic and, in my experience, often incorrectly
> implemented or unsupported. In the SST conception of things, the roles in
> keepalive ping-pong are negotiated entirely between the UAs, and it is up
> to the UAs to maintain those roles. This goes wrong easily enough that
> server-side solutions such as periodic reinvites and other "pings" (like
> the Kamailio dialog module's OPTIONS pings) are a rather popular
> alternative.
>
> Would you mind expanding on endpoint defense? Specifically with mobile
>> client applications? I agree this would be the ideal solution, I'm just
>> not sure where to start here.
>>
>
> By "endpoint defence" I simply meant that detecting dead peers should be
> up to the SIP endpoints (mobile SIP client and Asterisk, by the sound of
> it) first and foremost, and that any proxy-side measures should be a
> secondary layer.
>
> -- Alex
>
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
> 303 Perimeter Center North, Suite 300
> Atlanta, GA 30346
> United States
>
> Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160108/6ecfb956/attachment.html>


More information about the sr-users mailing list