[OpenSIPS-Users] Handling missing BYEs

[Callum Guy]

Might be a case of adding in a record_route() call in the appropriate
place, hard to say without a trace :)

On Wed, 10 Mar 2021 at 10:42, Mark Allen <mark at allenclan.co.uk> wrote:

> Hi Callum - thanks for that!
>
> Yes - it's generating the BYE at the Linux end but not sending it to the
> remote OpenSIPS IP address but rather to an address on the local LAN -
> hence the problem. Thanks for your help.
>
> Cheers,
>
> Mark
>
>
>
> On Wed, 10 Mar 2021 at 09:26, Callum Guy <callum.guy at x-on.co.uk> wrote:
>
>> Hi Mark,
>>
>> It sounds like you may be having issues with the proxy not keeping itself
>> in path for certain call scenarios.
>>
>> Are you able to provide a SIP trace and/or opensips config? Also if
>> you're running Blink on a Linux system, can you get a SIP trace there to
>> see if the BYE is being generated and sent somewhere else?
>>
>> Callum
>>
>> On Tue, 9 Mar 2021 at 16:32, Mark Allen <mark at allenclan.co.uk> wrote:
>>
>>> I'm seeing some odd behaviour which also leads into a broader question
>>>
>>> I have a NATed Blink app running on Linux on my home LAN. It connects to
>>> an OpenSIPS 3.1 server in on our office LAN which is a mid-registrar for an
>>> Asterisk server. I'm running sngrep on the OpenSIPS box to watch the
>>> traffic.
>>>
>>> If I call from the Blink app to another extension it all connects and
>>> audio works correctly. If I hangup in Blink, a BYE is sent via OpenSIPS to
>>> Asterisk - all good so far.
>>> If I call from another extension to the Blink app it all connects and
>>> audio works correctly. However, if I hangup in the Blink app, no BYE is
>>> sent to OpenSIPS.
>>>
>>> In most situations, this is merely inconvenient because, with the loss
>>> of RTP traffic, Asterisk generates a BYE after about 35 seconds to tidy
>>> everything up. However, if I'm doing an attended transfer, the BYE is
>>> needed to exit the call so that the transfer completes successfully. At the
>>> moment, if I hangup in the Blink app, there's a wait of 35 seconds until
>>> Asterisk creates the BYE before the call transfer is completed.
>>>
>>> While I'm mostly using Blink, I've seen similar failures to send BYEs
>>> from other apps. Does OpenSIPS offer anything that could help with this?
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> *0333 332 0000  |  x-on.co.uk <https://www.x-on.co.uk>  |   **
>> <https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel>
>>   <https://twitter.com/xonuk> **  |  Coronavirus
>> <https://www.x-on.co.uk/service/surgery-connect/coronavirus.htm>**
>> |  Practice Index Reviews <https://practiceindex.co.uk/gp/x-on>*
>>
>> THE ITSPA AWARDS 2020 <http://www.itspa.org.uk/itspa-awards> AND Best
>> ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks
>> of the Internet Telephony Services Providers' Association, used under
>> licence.
>>
>> *From April 1st 2021 our office address will change to: Units 22-24
>> Riduna Park, Melton IP12 1QT.*
>>
>> X-on is a trading name of Storacall Technology Ltd a limited company
>> registered in England and Wales.
>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel
>> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
>> The information in this e-mail is confidential and for use by the
>> addressee(s) only. If you are not the intended recipient, please notify
>> X-on immediately on +44(0)333 332 0000 and delete the
>> message from your computer. If you are not a named addressee you must not
>> use, disclose, disseminate, distribute, copy, print or reply to this email. Views
>> or opinions expressed by an individual
>> within this email may not necessarily reflect the views of X-on or its
>> associated companies. Although X-on routinely screens for viruses,
>> addressees should scan this email and any attachments
>> for viruses. X-on makes no representation or warranty as to the absence
>> of viruses in this email or any attachments.
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-- 





*0333 332 0000  |  x-on.co.uk <https://www.x-on.co.uk>  |   ** 
<https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel> 
  <https://twitter.com/xonuk> **  |  Coronavirus 
<https://www.x-on.co.uk/service/surgery-connect/coronavirus.htm>**  |  
Practice Index Reviews <https://practiceindex.co.uk/gp/x-on>*


THE ITSPA 
AWARDS 2020 <http://www.itspa.org.uk/itspa-awards> AND Best ITSP - Mid 
Market, Best Software and Best Vertical Solution are trade marks of the 
Internet Telephony Services Providers' Association, used under licence.

*From April 1st 2021 our office address will change to: Units 22-24 Riduna 
Park, Melton IP12 1QT.*

X-on
is a trading name of Storacall Technology Ltd 
a limited company registered in
England and Wales.

Registered Office : 
Avaland House, 110 London Road, Apsley, Hemel Hempstead,
Herts, HP3 9SD. 
Company Registration No. 2578478.

The information in this e-mail is 
confidential and for use by the addressee(s)
only. If you are not the 
intended recipient, please notify X-on immediately on +44(0)333 332 0000 
and delete the
message from your computer. If you are not a named addressee 
you must not use,
disclose, disseminate, distribute, copy, print or reply 
to this email. Views
or opinions expressed by an individual
within this 
email may not necessarily
reflect the views of X-on or its associated 
companies. Although X-on routinely
screens for viruses, addressees should 
scan this email and any attachments
for
viruses. X-on makes no 
representation or warranty as to the absence of viruses
in this email or 
any attachments.










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210310/40ec85db/attachment-0001.html>