Re: [OpenSIPS-Users] How to manage REFER Packet

2021-03-10 Thread Donat Zenichev
Good day Vinayak.

Firstly you'd better take into account that a sequence for processing REFER
is much different from how the INVITE method is being processed.
So it's known that so called hand-shake consists of the following messages
exchange: INVITE - 100 - 180/183 (optionally) - 200OK/202 Accepted - ACK
There is no complexity here and the way how it works is clear.

Now getting to the REFER method.
The REFER method likely falls in the category of in-dialog requests.
And in the predominant majority of cases can only be used within the
existing dialog (to implement an attended/unattended transfer).

The superficial view/sequence of messages will be as follows:
- firstly A side (who makes a transfer) sends REFER (to local proxy/B2B)
and awaits the arrival of 202.
(and by doing this also subscribes for an event)
- secondly local proxy/B2B invites a third party into the call (the further
behavior depends on if this is an attended/unattended transfer)
- (let's say it's unattended) then as soon as third party takes a call,
local proxy/B2B notifies (with NOTIFY method) the A party about the
happened event.
So: NOTIFY - 200OK
Which begets in its turn a normal call clearing from the A side (BYE -
200OK)
- while A side was processing the happened event, local proxy/B2B took
charge of re-invitation of the B party (with newer signaling/media
information).
- a call between B and C side is now established (through the proxy/B2B)

You might as well read this RFC document:
https://tools.ietf.org/html/rfc3515
which is dedicated to the REFER method in particular.

Personally I haven't ever faced such a scenario, which would require such a
conversion of REFER to INVITE.
Is there a good reason for doing that?

It sounds entirely quite tricky, since a normal logic for processing REFER
already entails usage of INVITE.
But not to convert REFER into INVITE, but to engage a third party into the
call. Meanwhile REFER method keeps on doing its job.

Even if you still want to do that,
you need to write an OpenSIPS logic, which would be capable of handling the
full sequence for the REFER method (your leg with FreeSWITCH).
Keep it proper all the way during the call.
And on the other hand would be capable of conversion and processing the
usual INVITE sequence (the leg with A side).
Which doesn't look to me like a simple thing to do.

Best regards


On Mon, Mar 8, 2021 at 9:13 AM Vinayak Makwana 
wrote:

> Hello Everyone,
>  I would like to manage REFER packet with opensips script
>  In my case i want manage REFER packet like whenever i opensips proxy
> getting REFER packet from freeswitch at that time i need to convert this
> REFER packet into INVITE packet from opensips script and send to the
> endpoint.
> Is their  any possibilities where I can manage this thing in opensips
> 3.1.x ?
> Please suggest me.
>
> My scenario like this:
>
> AopensipsB(Freswitch)
>   |   -INVITE --->|   ---INVITE-->   |
>
>   |   <-200OK ---|  <---200OK--|
>   |  <-INVITE ---   |   <---REFER|
>
> *Disclaimer*
> In addition to generic Disclaimer which you have agreed on our website,
> any views or opinions presented in this email are solely those of the
> originator and do not necessarily represent those of the Company or its
> sister concerns. Any liability (in negligence, contract or otherwise)
> arising from any third party taking any action, or refraining from taking
> any action on the basis of any of the information contained in this email
> is hereby excluded.
>
> *Confidentiality*
> This communication (including any attachment/s) is intended only for the
> use of the addressee(s) and contains information that is PRIVILEGED AND
> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying
> of this communication is prohibited. Please inform originator if you have
> received it in error.
>
> *Caution for viruses, malware etc.*
> This communication, including any attachments, may not be free of viruses,
> trojans, similar or new contaminants/malware, interceptions or
> interference, and may not be compatible with your systems. You shall carry
> out virus/malware scanning on your own before opening any attachment to
> this e-mail. The sender of this e-mail and Company including its sister
> concerns shall not be liable for any damage that may incur to you as a
> result of viruses, incompleteness of this message, a delay in receipt of
> this message or any other computer problems.
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 

Best regards,
Donat Zenichev
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Handling missing BYEs

2021-03-10 Thread Mark Allen
Just a follow-up for fix notes. We've got OpenSIPS sitting behind a
firewall with a 1:1 port map from an external IP. The Contact HF for the
INVITE going out from OpenSIPS to the NATed UAC used the internal IP
address for the OpenSIPS box, not the external IP. Set OpenSIPS to fix it
and all working fine now. Thanks for the help

On Wed, 10 Mar 2021 at 10:39, Mark Allen  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  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  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@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> *0333 332   |  x-on.co.uk   |   **
>>    
>>    **  |  Coronavirus
>> **
>> |  Practice Index Reviews *
>>
>> THE ITSPA AWARDS 2020  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  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@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] do_routing() Question

2021-03-10 Thread Mark Farmer
Perfect! Many thanks :)

Mark.


On Wed, 10 Mar 2021 at 12:58, Marcin Groszek  wrote:

> Yes, rule_attrs will populate with C flag.
> On 3/10/2021 5:37 AM, Mark Farmer wrote:
>
> Hi everyone
>
> If I call:
> (do_routing(3, "C",,$var(rule_attrs))
>
> Will the rule_attrs pvar be populated when the C flag is set? The doc
> mentions that the GW is not set and the RURI is not altered which is what I
> want but I would like to have the attributes loaded at that point.
>
> Many thanks
> Mark.
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> --
> Best Regards:
> Marcin Groszek
> Business Voip Resource.http://www.voipplus.net
>
>

-- 
Mark Farmer
farm...@gmail.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] do_routing() Question

2021-03-10 Thread Marcin Groszek

Yes, rule_attrs will populate with C flag.

On 3/10/2021 5:37 AM, Mark Farmer wrote:

Hi everyone

If I call:
(do_routing(3, "C",,$var(rule_attrs))

Will the rule_attrs pvar be populated when the C flag is set? The doc 
mentions that the GW is not set and the RURI is not altered which is 
what I want but I would like to have the attributes loaded at that point.


Many thanks
Mark.


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Best Regards:
Marcin Groszek
Business Voip Resource.
http://www.voipplus.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] Opensips 3.1 as HEP server

2021-03-10 Thread Saurabh Chopra
Hi All,

I am trying to configure a HEP server on Opensips 3.1.0 but while testing
my server is crashing abruptly.

I am following the configuration defined under section 6.1 Homer5
integration on " https://www.opensips.org/Documentation/Tutorials-Tracing "

Below is the sample configuration at my opensips server.

log_level=4
log_stderror=no
log_facility=LOG_LOCAL5
socket=hep_udp:104.131.xx.xx:6xxx



























































*loadmodule "proto_hep.so"loadmodule "sipcapture.so"modparam("sipcapture",
"db_url", "mysql://:x@localhost/homerdb")modparam("sipcapture",
"hep_capture_on", 1)modparam("sipcapture", "hep_route", "HEPR")###
Routing Logic # main request routing logicroute{if($rm =~
"REGISTER") {$var(table) = "sip_capture_registration";
  }else if($rm =~ "(INVITE|UPDATE|BYE|ACK|PRACK|REFER|CANCEL)$")
{$var(table) = "sip_capture_call";}else
if($rm =~ "(NOTIFY)$" && is_present_hf("Event") && $hdr(Event)=~"refer;")
  {$var(table) = "sip_capture_call";}
else if($rm =~ "(INFO)$"){$var(table) =
"sip_capture_call";}else if($rm =~ "(OPTIONS)$" ){
  $var(table) = "sip_capture_rest";}else {
  $var(table) = "sip_capture_rest";}#$var(utc) = "%Y%m%d";
  xlog("WRITING NEWLY CAME PACKET INTO ($var(table))!\n");
if($var(table) == "sip_capture_call")
sip_capture("sip_capture_call_%Y%m%d");else if($var(table) ==
"sip_capture_registration")
sip_capture("sip_capture_registration_%Y%m%d");else
sip_capture("sip_capture_rest_%Y%m%d");}route[HEPR] {
hep_get("11", $var(vid), $var(data));if ( $var(data) == "SIP" ) {
  hep_resume_sip();}$var(proto) = $(var(data){s.int
});### anything but xlog shall be droppedif (
$var(proto) != 87 )exit;hep_get("0x0011",
"utf8-string", $var(vendor), $var(correlation));
report_capture($var(correlation_id), "rtcp_log", $var(proto_type));
#report_capture("logs_capture", $var(correlation));exit;}*

Any prompt help would be highly appreciated.

Best Regards
Saurabh Chopra
+918861979979
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Handling missing BYEs

2021-03-10 Thread Johan De Clercq
@Callum Guy  indeed :-)

Op wo 10 mrt. 2021 om 12:47 schreef 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  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  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  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@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users

>>>
>>>
>>> *0333 332   |  x-on.co.uk   |   **
>>>    
>>>    **  |  Coronavirus
>>> **
>>> |  Practice Index Reviews *
>>>
>>> THE ITSPA AWARDS 2020  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  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@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> *0333 332   |  x-on.co.uk   |   **
>    
>    **  |  Coronavirus
> **
> |  Practice Index Reviews *
>
> THE ITSPA AWARDS 2020  AND Best
> ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks
> of the

Re: [OpenSIPS-Users] Handling missing BYEs

2021-03-10 Thread 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  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  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  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@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> *0333 332   |  x-on.co.uk   |   **
>>    
>>    **  |  Coronavirus
>> **
>> |  Practice Index Reviews *
>>
>> THE ITSPA AWARDS 2020  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  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@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-- 





*0333 332   |  x-on.co.uk   |   ** 
    
   **  |  Coronavirus 
**  |  
Practice Index Reviews *


THE ITSPA 
AWARDS 2020  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-o

[OpenSIPS-Users] do_routing() Question

2021-03-10 Thread Mark Farmer
Hi everyone

If I call:
(do_routing(3, "C",,$var(rule_attrs))

Will the rule_attrs pvar be populated when the C flag is set? The doc
mentions that the GW is not set and the RURI is not altered which is what I
want but I would like to have the attributes loaded at that point.

Many thanks
Mark.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Handling missing BYEs

2021-03-10 Thread Mark Allen
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  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  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@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> *0333 332   |  x-on.co.uk   |   **
>    
>    **  |  Coronavirus
> **
> |  Practice Index Reviews *
>
> THE ITSPA AWARDS 2020  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  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@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Handling missing BYEs

2021-03-10 Thread Callum Guy
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  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@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-- 





*0333 332   |  x-on.co.uk   |   ** 
    
   **  |  Coronavirus 
**  |  
Practice Index Reviews *


THE ITSPA 
AWARDS 2020  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  
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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users