| Summary: | ASTERISK-29936: app_confbridge / translate: unable to build translation path | ||||
| Reporter: | N A (InterLinked) | Labels: | |||
| Date Opened: | 2022-02-24 14:32:24.000-0600 | Date Closed: | |||
| Priority: | Minor | Regression? | |||
| Status: | Open/New | Components: | Applications/app_confbridge Applications/app_originate Channels/chan_sip/Video | ||
| Versions: | 18.9.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) translatebug.txt | |||
| Description: | When two peers through a ConfBridge and Originate with the h264 codec try to bridge together, the ConfBridge fails because it's unable to build a translation path. Error is starting codec invalid.
Before confbridge, the interesting bit is that the write format and read format before are h264, but after the write format is slin/ulaw and the read format is h264. Not sure if that means anything. Yes, I know I'm using chan_sip for this, but chan_pjsip crashes if I try to set up a video call so that doesn't really pan out. Removing h264 from the list of codecs in Originate fixes the problem, but obviously that disables video support. With core debug 5, here's what's in that area: {noformat} [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: bridge_softmix.c:709 softmix_bridge_join: SIP/ATAxMicroSIP1-00000073: [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: channel.c:5580 ast_set_read_format_path: Channel SIP/ATAxMicroSIP1-00000073 setting read format path: h264 -> slin [2022-02-24 20:52:02] WARNING[21379][C-0000009f]: translate.c:494 ast_translator_build_path: No translator path: (starting codec is not valid) [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: channel.c:5826 set_format: Channel SIP/ATAxMicroSIP1-00000073 setting write format path: slin -> ulaw [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: dsp.c:512 ast_tone_detect_init: Setup tone 1100 Hz, 500 ms, block_size=160, hits_required=21 [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: dsp.c:512 ast_tone_detect_init: Setup tone 2100 Hz, 2600 ms, block_size=160, hits_required=116 [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: bridge_channel.c:301 ast_bridge_channel_leave_bridge_nolock: Setting 0x7f01cc523aa0(SIP/ATAxMicroSIP1-00000073) state from:0 to:1 [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: bridge_softmix.c:772 softmix_bridge_join: [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: bridge_softmix.c:2458 softmix_bridge_stream_topology_changed: SIP/ATAxMicroSIP1-00000073: [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: bridge_softmix.c:2466 softmix_bridge_stream_topology_changed: SIP/ATAxMicroSIP1-00000073: Not in SFU mode [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: stasis_bridges.c:290 bridge_snapshot_update_create: Update: 0x7f01cc300b78 Old: 22bd1255-c2b2-4082-b1c6-44c6203db65b New: 22bd1255-c2b2-4082-b1c6-44c6203db65b [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: stasis_bridges.c:270 bridge_snapshot_update_dtor: Update: 0x7f01cc300b78 Old: 22bd1255-c2b2-4082-b1c6-44c6203db65b New: 22bd1255-c2b2-4082-b1c6-44c6203db65b [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: res_rtp_asterisk.c:4398 ast_rtp_change_source: (0x56469edf7d90) RTP changing ssrc from 1365169695 to 1195060383 due to a source change [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: res_rtp_asterisk.c:4402 ast_rtp_change_source: (0x56469edf7d90) RTP changing ssrc for SRTP from 1365169695 to 1195060383 [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: res_srtp.c:606 ast_srtp_add_stream: Adding new policy for SSRC 1195060383 [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: res_srtp.c:636 ast_srtp_change_source: Couldn't remove stream (13) [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: bridge_channel.c:359 ast_bridge_channel_restore_formats: Bridge is returning 0x7f01cc523aa0(SIP/ATAxMicroSIP1-00000073) to write format h264 [2022-02-24 20:52:02] DEBUG[21383]: channel_internal_api.c:682 ast_channel_nativeformats_set: <initializing>: Formats: (nothing) [2022-02-24 20:52:02] DEBUG[21383]: channel_internal_api.c:692 ast_channel_nativeformats_set: Channel is being initialized or destroyed [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: bridge.c:972 ast_bridge_destroy: Bridge 22bd1255-c2b2-4082-b1c6-44c6203db65b: telling all channels to leave the party [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: bridge.c:338 bridge_dissolve: Bridge 22bd1255-c2b2-4082-b1c6-44c6203db65b: dissolving bridge with cause 16(Normal Clearing) [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: bridge_channel.c:301 ast_bridge_channel_leave_bridge_nolock: Setting 0x7f01cc252980(CBAnn/oe9-00000213;2) state from:0 to:2 [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: bridge.c:299 bridge_queue_action_nodup: Bridge 22bd1255-c2b2-4082-b1c6-44c6203db65b: queueing action type:13 sub:1001 [2022-02-24 20:52:02] DEBUG[21379][C-0000009f]: pbx.c:2938 pbx_extension_helper: Launching 'DumpChan' [2022-02-24 20:52:02] -- Executing [s@astrex-local:7] DumpChan("SIP/ATAxMicroSIP1-00000073", "") in new stack {noformat} | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2022-02-24 14:32:25.984-0600 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: Joshua C. Colp (jcolp) 2022-02-24 15:16:55.819-0600 Please also include the Originate being done. You also commented on ASTERISK-29198, did you determine that this is a different thing? By: N A (InterLinked) 2022-02-24 15:24:05.714-0600 > You also commented on ASTERISK-29198, did you determine that this is a different thing? I've noticed that in random places, usually on calls that aren't video-related at all. Removing the h264 from Originate does fix that. It seems different, because that issue doesn't occur when I'm actually trying to make a video call. It is possible however that it's all part of a larger issue, namely that Asterisk is poorly managing / inconsistent with codecs, in a way that is exemplified with mixed audio + video calls. Direct SIP -> SIP calls through Asterisk work just fine with SIP or PJSIP. When ConfBridge and Originate are added, this causes Asterisk to crash with PJSIP, or this to happen with SIP. The issues with PJSIP and SIP, interestingly, seem completely unrelated - just weird bugs encountered in each case. The Originate is essentially this: {noformat} same => n,Originate(Local/${filteredpeername}@outgoing,exten,outgoing-ring,${EXTEN},1,,C(slin,h264)a) {noformat} The local channel @ outgoing will join a ConfBridge, and the SIP peer also joins that bridge. outgoing-ring is a local channel which then gets bridged to another SIP peer in a similar reverse process, e.g. the call is: SIP -peer > Originate local, then join ConfBridge -> Local channel(s) -> ConfBridge -> SIP peer By: Joshua C. Colp (jcolp) 2022-02-24 16:27:23.569-0600 Your use of "crash" is confusing. Crash generally refers to Asterisk itself crashing. When this was initially reported I removed "crash" because Asterisk itself wasn't crashing. Now you've stated that PJSIP is crashing, is Asterisk crashing with it? If it is, then that should be tracked on another issue with backtrace. By: Joshua C. Colp (jcolp) 2022-02-24 16:31:09.443-0600 And does this occur with Originate in AMI as well, or is this strictly limited to the Originate dialplan application? By: N A (InterLinked) 2022-02-24 16:31:59.518-0600 Yes, it's a bug in PJSIP that causes Asterisk to crash. I wasn't sure if you changed "crash" to "fail" for another reason. It's this one I already reported here: ASTERISK-29907 It doesn't crash with SIP, but this behavior is not correct, either. Maybe it's time for a third SIP channel driver to make Asterisk go round ;) By: Joshua C. Colp (jcolp) 2022-02-24 16:32:49.392-0600 I changed "crash" to "fail" because you filed this in regards to chan_sip and provided information which clearly showed that Asterisk was not crashing. By: N A (InterLinked) 2022-02-24 16:35:28.874-0600 I don't actually think it's anything to do with originate, per se, it's just that the option in originate is what allows me to add codecs to the call, or otherwise it's just slin. The problem goes away if no h264. So more properly, it occurs when slin + h264. If such a thing existed, something like Set(CODECS()=slin,h264) and $\{CODECS()} would probably replicate the issue as well. By: N A (InterLinked) 2022-02-24 16:36:21.827-0600 > I changed "crash" to "fail" because you filed this in regards to chan_sip and provided information which clearly showed that Asterisk was not crashing. Yes, but my specific comment there was about PJSIP, which does cause a crash. SIP does not. In any case, that's really the other issue I linked, not this one. | ||||