[OpenSIPS-Users] Problems passing BYE signal in v3.7

[Bogdan-Andrei Iancu]

Hi Alistiar,

The BYE is a sequential/indialog request, so you need to check your 
script on how these are handled. Usually they are routed via 
record_route() (if the routing mechanism is used in your cfg). See 
https://github.com/OpenSIPS/opensips/blob/3.6/etc/opensips.cfg#L110

IF you do not understand you cfg flow, maybe you can add this script 
tracing function on top of your cfg, so you can see how the execution 
goes step by step via the cfg: 
https://www.opensips.org/Documentation/Script-CoreFunctions-3-6#script_trace

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 30.01.2026 18:54, Alistair Cleminson wrote:
> Thanks for the tip, it turns out I'd completely misunderstood the 
> process. This configuration doesn't generate the errors & passes calls:
>
>             if (is_method("INVITE")) {
>                   $acc_extra(si) = $si;
>                   $acc_extra(fU) = $fU;
>                   $acc_extra(fd) = $fd;
>                   $acc_extra(rU) = $rU;
>                   $acc_extra(rd) = $rd;
>                   do_accounting("log|db","cdr|missed|failed");
>
>                   if (get_source_group($var(si))) {
>                         if (!alias_db_lookup("dbaliases")) {
>                               xlog("L_ERR", "LOG: DDI Alias not found, 
> time=[$Ts] from uri=[$fu] to uri=[$ru]");
>                               sl_send_reply(404, "Not Found");
>                         };
>
>                         $avp(site)=$(ruri.user{s.substr,0,5});
>                         route(ALLOW);
>                         exit; 
>                   }
>
>                   else {
>                         log(1, "Permissions RECORD FAIL\n");
>                         sl_send_reply(403, "Forbidden");
>                         exit;
>                   };
>
>             };
>
> I'm still not passing BYE packets successfully though. I'll dig a 
> little more before I ask again.
>
> thanks
> a.
>
> *From: *johan de clercq <johan at democon.be>
> *Date: *Thursday, 29 January 2026 at 9:41 am
> *To: *Alistair Cleminson <alistair.cleminson at wifinity.co.uk>
> *Subject: *Re: [OpenSIPS-Users] Problems passing BYE signal in v3.7
>
>
> 	
> You don't often get email from johan at democon.be. Learn why this is 
> important <https://aka.ms/LearnAboutSenderIdentification>
> 	
>
> *[CAUTION]* This email is from an external sender - Please be 
> cautious, particularly with any links and attachments. If you suspect 
> a phishing email, please report it to IT.
>
> maybe changing the 2 vars to avp's will fix the issue.
>
> On 1/27/26 17:27, Alistair Cleminson wrote:
>
>     Hi,
>
>     I've nearly completed the process of upgrading our ancient v1.7
>     deployment to v3.6. The new deployment is installed on Ubuntu
>     24.04 from the OpenSIPS repos. These servers are our inbound
>     hand-off from our upstream supplier, they take a call, inspect the
>     called number element against the database, and then pass it on to
>     the target system with the internal reference or decline the call.
>
>     I've never been a programmer and am much more familiar with
>     Asterisk, having inherited the platform & 'maintained' these hosts
>     for about ten years I'm far from fluent in the configuration
>     syntax but also much less terrified than I was when I first opened
>     the opensips.cfg file. Having said that, I've updated most of the
>     configuration and database backend to successfully accept, process
>     & pass on a call to our core voice platform with 2-way audio.
>
>     Unfortunately, when a call is terminated by either the called or
>     calling party the BYE signal is not passed to the other party
>     leaving the call hanging until they also hang up or an
>     intermediate system decides the call is in a stale state & drops it.
>
>     From what I can tell, this is the v1.7 code which would capture
>     the session related traffic and associate a BYE with a particular
>     call.
>
>     I think the problem is related to my attempt to convert the
>     depreciated  allow_source_address_group() function:
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20260202/07923a9e/attachment.html>