[Home]

Summary:ASTERISK-29403: media: Early media not relayed to calling leg
Reporter:Stanislav Abramenkov (silentindark)Labels:
Date Opened:2021-04-23 01:09:17Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:Channels/chan_sip/General Resources/res_rtp_asterisk
Versions:16.17.0 Frequency of
Occurrence
Related
Issues:
Environment:Debian 10.9Attachments:( 0) ast_11_7_0_and_16_17_0_both_call_legs.png
( 1) ast_11_7_0_both_call_legs.png
( 2) ast_11_7_0_dump.txt
( 3) ast_11_7_0_full.log
( 4) ast_16_17_0_both_call_legs.png
( 5) ast_16_17_0_call_leg_1.txt
( 6) ast_16_17_0_call_leg_2.txt
( 7) ast_16_17_0_dump.txt
( 8) ast_16_17_0_full_with_debug_10.log
( 9) ast_16_17_0_full_with_debug_new.log
(10) ast_16_17_0_full.log
(11) extensions.conf
(12) pic1.jpeg
(13) pic2.jpeg
(14) sip.conf
Description:Shortly:
Asterisk can't bridge or detect the second call leg without Answer()ing on early media.

I will try to describe the problem in more detail. Seems that asterisk 16.17.0 have issue with detecting early media.

I have two asterisk servers.
One of server is running old asterisk version - 11.7.0
And second server has version - 16.17.0

Both servers have connection to Oracle SBC.
Description of call flow:
asterisk (Public IP) ==> SBC (Public IP) ==> other system

When the call made from asterisk 11.7.0 to SBC, then SBC will send this call to other system and if extension not found, then other system plays notification (early media) caller in asterisk hears it, so first and second call legs are properly connected. (picture "pic1" in attachment)

On new system with asterisk 16.17.0, it doesn't happen, caller only hears dialing tone, but in trace (tcpdump) we see early media notification. And RTP of early media can be played in wireshark. (picture "pic2" in attachment)

SIP trunk configurations are same on both servers:

{noformat}
[sbctrunk1]
description=earlym
deny=0.0.0.0/0.0.0.0
disallow=all
type=friend
allow=alaw
allow=g722
host=public_ip
permit=public_ip
transport=tcp,udp
port=5060
qualifyfreq=60
qualify=3000
canreinvite=no
dtmfmode=auto
progressinband=never
nat=no
directrtpsetup=no
directmedia=no
context=sbctrunk1
insecure=port,invite
promiscredir=yes
accountcode=sbctrunk1
{noformat}

Dial plan:

{noformat}
exten => _X.,1,NoOP(TEST)
exten => _X.,n,Dial(SIP/${EXTEN}@sbctrunk1,,)
exten => _X.,n,Hangup()
{noformat}
Comments:By: Asterisk Team (asteriskteam) 2021-04-23 01:09:18.152-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].
By: Stanislav Abramenkov (silentindark) 2021-04-23 01:30:02.934-0500

call flow
By: Joshua C. Colp (jcolp) 2021-04-23 04:17:18.958-0500

Thanks for the report and debug. However we also need protocol specific debug captured at the time of the issue. Please include the following:

* Asterisk log files generated using the instructions on the Asterisk wiki [1], with the appropriate protocol debug options enabled, e.g. 'pjsip set logger on' if the issue involves the chan_pjsip channel driver.
* Configuration information for the relevant channel driver, e.g. pjsip.conf.
* A wireshark compatible packet capture, captured at the same time as the Asterisk log output.

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Joshua C. Colp (jcolp) 2021-04-23 04:17:38.106-0500

Additionally chan_sip is community supported.
By: Stanislav Abramenkov (silentindark) 2021-04-23 06:40:35.069-0500

call flow
By: Stanislav Abramenkov (silentindark) 2021-04-23 06:41:14.862-0500

SIP flow
By: Joshua C. Colp (jcolp) 2021-04-23 06:46:34.286-0500

The attached information does not include the Asterisk debug logs which are needed to show what Asterisk is actually doing.
By: Stanislav Abramenkov (silentindark) 2021-04-23 06:50:49.080-0500

asterisk settings
By: Joshua C. Colp (jcolp) 2021-04-23 06:51:16.438-0500

As well, we need to see ALL call legs involved. Not just the outgoing leg.
By: Stanislav Abramenkov (silentindark) 2021-04-23 06:57:53.053-0500

I will attach log files soon.
By: Stanislav Abramenkov (silentindark) 2021-04-23 07:39:25.086-0500

full.log from asterisk-16.17.0
By: Joshua C. Colp (jcolp) 2021-04-23 07:43:02.864-0500

The given log contains only verbose messages and not debug messages.
By: Stanislav Abramenkov (silentindark) 2021-04-23 07:55:09.353-0500

full.log from asterisk-11.7.0
By: Joshua C. Colp (jcolp) 2021-04-23 08:03:43.687-0500

To consolidate my comments down:

What is needed is debug level logs which include the SIP traffic for ALL call legs. Right now there's only verbose logs which do not provide any information on what Asterisk is doing internally besides dialplan execution. It would also be useful to have "rtp set debug on" output to look at media flow.
By: Joshua C. Colp (jcolp) 2021-04-23 08:04:55.636-0500

I'd also like to reiterate that chan_sip is community supported, so if accepted the issue will remain open but a community member may or may not investigate things.
By: Stanislav Abramenkov (silentindark) 2021-04-23 08:27:51.579-0500

full.log file with debug 10
By: Stanislav Abramenkov (silentindark) 2021-04-23 08:39:13.271-0500

Please, let me know, if I can provide additional information.
By: Joshua C. Colp (jcolp) 2021-04-23 08:46:25.987-0500

So this is now a debug log, but it does not include the SIP traffic for ALL call legs or the "rtp set debug on".

The debug log does show a constant "[Apr 23 15:59:23] DEBUG[19360][C-00023c94] res_rtp_asterisk.c: (0x7f30cc095020) RTP setting the marker bit due to a source update" but I don't see why that would occur, although chan_sip does have various places where it sets it.
By: Stanislav Abramenkov (silentindark) 2021-04-23 09:22:29.980-0500

Do you mean that
asterisk (Public IP) ==> SBC (Public IP) - one call leg
phone (Public IP) connected to asterisk (Public IP) - second call leg?
By: Joshua C. Colp (jcolp) 2021-04-23 09:24:39.236-0500

Yes, to Asterisk those are two separate calls and two different call legs.
By: Stanislav Abramenkov (silentindark) 2021-04-24 11:20:11.131-0500

fresh logs, both call legs
By: Joshua C. Colp (jcolp) 2021-04-26 06:52:14.042-0500

Is it possible for you to test with PJSIP as well to see if this is isolated to chan_sip?
By: Stanislav Abramenkov (silentindark) 2021-04-26 07:52:48.653-0500

I will try to test with PJSIP
By: Stanislav Abramenkov (silentindark) 2021-04-26 09:49:12.383-0500

The issue is not present with PJSIP. Looks like that chan_sip is affected to the problem.
By: Joshua C. Colp (jcolp) 2021-04-26 09:53:34.839-0500

I have marked this as acknowledged, then. The chan_sip module is community supported and there is no time frame on if or when this would get looked into.
By: Sean Bright (seanbright) 2021-04-26 12:49:43.173-0500

FWIW, I am not able to replicate this with 16 from git as of 5ace782583c45c7e3a0dcdb7e786f9cbd469fede.
By: Stanislav Abramenkov (silentindark) 2021-05-10 02:05:42.455-0500

I tried last asterisk 16.18.0, issue is still present.