Hi Bogdan.
Thanks for the help, script_trace helps a lot. However, one problem appears to
be our Asterisk sending BYEs to the OpenSIPS management IP, rather than the
service IP - the other is no BYEs appearing from our upstream provider, so
there may yet be some NAT fiddling in the network.
This is a tcpdump of a short test call from the OpenSIPS host, repeating lines
have been cropped.
18:37:20.965341 IP <SUPPLIER_IP_1>.5060 > <OSIPS_SVC_IP>.5060: SIP: INVITE
sip:<OUR_DDI>@<OSIPS_SVC_IP> SIP/2.0
18:37:20.976766 IP <OSIPS_SVC_IP>.5060 > <SUPPLIER_IP_1>.5060: SIP: SIP/2.0 100
Giving it a try
18:37:20.976914 IP <OSIPS_SVC_IP>.5060 > <AST_SVC_IP>.5060: SIP: INVITE
sip:<INTERNAL_NO>@<AST_SVC_IP> SIP/2.0
18:37:20.980867 IP <AST_SVC_IP>.5060 > <OSIPS_SVC_IP>.5060: SIP: SIP/2.0 100
Trying
18:37:20.983652 IP <AST_SVC_IP>.5060 > <OSIPS_SVC_IP>.5060: SIP: SIP/2.0 180
Ringing
18:37:20.983956 IP <OSIPS_SVC_IP>.5060 > <SUPPLIER_IP_1>.5060: SIP: SIP/2.0 180
Ringing
...
18:37:24.494830 IP <AST_SVC_IP>.5060 > <OSIPS_SVC_IP>.5060: SIP: SIP/2.0 200 OK
18:37:24.512790 IP <OSIPS_SVC_IP>.5060 > <SUPPLIER_IP_1>.5060: SIP: SIP/2.0 200
OK
...
18:37:27.994889 IP <AST_SVC_IP>.5060 > <OSIPS_SVC_IP>.5060: SIP: SIP/2.0 200 OK
18:37:27.995144 IP <OSIPS_SVC_IP>.5060 > <SUPPLIER_IP_1>.5060: SIP: SIP/2.0 200
OK
18:37:31.995201 IP <AST_SVC_IP>.5060 > <OSIPS_SVC_IP>.5060: SIP: SIP/2.0 200 OK
...
18:37:43.995343 IP <AST_SVC_IP>.5060 > <OSIPS_SVC_IP>.5060: SIP: SIP/2.0 200 OK
<-- Hangup
...
18:37:55.995731 IP <AST_SVC_IP>.5060 > <OSIPS_SVC_IP>.5060: SIP: SIP/2.0 200 OK
18:37:56.495480 IP <AST_SVC_IP>.5060 > <OSIPS_MGMT_IP>.5060: SIP: BYE
sip:<CALLERS_DDI>@<SUPPLIER_IP_2>:5060 SIP/2.0
18:37:56.994867 IP <AST_SVC_IP>.5060 > <OSIPS_MGMT_IP>.5060: SIP: BYE
sip:<CALLERS_DDI>@<SUPPLIER_IP_2>:5060 SIP/2.0
...
18:38:23.994375 IP <AST_SVC_IP>.5060 > <OSIPS_MGMT_IP>.5060: SIP: BYE
sip:<CALLERS_DDI>@<SUPPLIER_IP_2>:5060 SIP/2.0
18:38:27.995061 IP <AST_SVC_IP>.5060 > <OSIPS_MGMT_IP>.5060: SIP: BYE
sip:<CALLERS_DDI>@<SUPPLIER_IP_2>:5060 SIP/2.0
and the headers from an INVITE packet
18:44:04.428866 IP <OSIPS_SVC_IP>.5060 > <AST_SVC_IP>.5060: SIP: INVITE
sip:<INTERNAL_NO>@<AST_SVC_IP> SIP/2.0
E..Jb-@.@...%<n.%<n......6+.INVITE sip:<INTERNAL_NO>@<AST_SVC_IP> SIP/2.0
Record-Route: <sip:<OSIPS_MGMT_IP>:5060;lr;did=e9f.c2eba4c6>
Record-Route: <sip:<SUPPLIER_IP_3>;lr;ftag=gK0e701262;did=e9f.85477a97>
Via: SIP/2.0/UDP <OSIPS_MGMT_IP>:5060;branch=z9hG4bK421c.1ab0cbb5.0
Via: SIP/2.0/UDP <SUPPLIER_IP_3>:5060;branch=z9hG4bK421c.ffa73133.0
Via: SIP/2.0/UDP <SUPPLIER_IP_2>:5060;branch=z9hG4bK0eB8733317d12c9fc4b
From: <sip:<CALLERS_DDI>@<SUPPLIER_IP_4>;user=phone>;tag=gK0e701262
To: <sip:<OUR_DDI>@<SUPPLIER_IP_3>;user=phone>
Call-ID: 355393690_100431806@<SUPPLIER_IP_2>
CSeq: 493596 INVITE
Max-Forwards: 68
Allow:
INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf,
application/dtmf-relay, multipart/mixed
Contact: <sip:<CALLERS_DDI>4@<SUPPLIER_IP_2>:5060>
P-Asserted-Identity: <sip:<CALLERS_DDI>@<SUPPLIER_IP_2>:5060;user=phone>
...
In the configuration I've set:
socket=udp:<OSIPS_SVC_IP>:5060 as <OSIPS_MGMT_IP>:5060
If a call is allowed through the INVITE path I previously posted, a routing
block with a variation in the $ru value will send it to the appropriate
internal host.
route[ALLOW]{
if ($ru =~ "sip:111[0-9]@*"){
$avp(routegroup) = $(avp(site){s.int});
do_routing($avp(routegroup));
route(REJECT);
exit;
}
...
Does it look like I've misconfigured something, or is Asterisk skipping a host
& sending the BYEs to the host one beyond its peer?
Asterisk has no knowledge of the OpenSIPS management IPs in its configuration.
Thanks again,
Al.
From: Bogdan-Andrei Iancu <[email protected]>
Date: Monday, 2 February 2026 at 9:31 am
To: OpenSIPS users mailling list <[email protected]>, Alistair Cleminson
<[email protected]>
Subject: Re: [OpenSIPS-Users] Problems passing BYE signal in v3.7
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.opensips-solutions.com/>
https://www.siphub.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:
<snip>
From: johan de clercq <[email protected]><mailto:[email protected]>
Date: Thursday, 29 January 2026 at 9:41 am
To: Alistair Cleminson
<[email protected]><mailto:[email protected]>
Subject: Re: [OpenSIPS-Users] Problems passing BYE signal in v3.7
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.
<snip>
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
