[SR-Users] Terminate dialogs on [websocket:closed]

[Daniel-Constantin Mierla]

Hello Takeshi,

so do you expect a re-INVITE after the websocket connection is closed?

You may want to check also the dialog keepalive features, it might just
be enough to enable it, but of course it may take longer to detect when
one leg of the call is gone.

Also, typically with PSTN gateways works to set session timers (see sst
module).

Cheers,
Daniel

On 10/02/16 12:27, mayamatakeshi wrote:
> Hi Daniel,
>
> Yes, that will solve it.
> Then when i get the in-dialog INVITE i can revert the lifetime back to
> the original value.
> Thanks and regards,
> Takeshi
>
> On Wed, Feb 10, 2016 at 5:59 PM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>     perhaps you can just lower the dialog lifetime in the websocket
>     event route, then dialog will take care of sending the BYEs,
>     without the need to store additional information in hash table.
>
>     Cheers,
>     Daniel
>
>
>     On 09/02/16 23:37, mayamatakeshi wrote:
>>     Hello,
>>     I am using module websocket and it works very well.
>>     However I would like to send BYE to the other end if event
>>     [websocket:closed] happens.
>>     From the docs I can see websocket module itself doesn't provide
>>     for this.
>>
>>     I was considering doing something like this:
>>       - use module htable to match $si:$sp to dialogs
>>       - use event_route[dialog:start] to insert dialog info to my
>>     htable under $si:$sp of Websocket side of the call
>>       - use event_route[dialog:end] to remove dialog info from htable
>>       - use event_route[websocket:closed] to iterate over entries in
>>     the htable under key $si:$sp and call dlg_get() and dlg_bye().
>>
>>     Obs: in the above, there is a risk of losing some dialogs as
>>     insertion in htable cannot be done atomically, but I am fine with
>>     it as it it not expected to happen as WebSocket users would only
>>     infrequently generate simultaneous calls. 
>>
>>     However before going with this, I would like to ask for other
>>     possible approaches.
>>
>>     Regards,
>>     Takeshi
>>
>>
>>
>>     _______________________________________________
>>     SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>     sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>     -- 
>     Daniel-Constantin Mierla
>     http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda
>     Book: SIP Routing With Kamailio - http://www.asipto.com
>     http://miconda.eu
>
>
>     _______________________________________________
>     SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>     list
>     sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
http://miconda.eu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160210/3a3b7764/attachment.html>