[Home]

Summary:ASTERISK-29512: bridge_softmix: Not reinviting in all cases with video
Reporter:Aidar Kamalov (aidar.kamalov@gmail.com)Labels:
Date Opened:2021-07-07 02:22:45Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:Bridges/bridge_softmix Channels/chan_pjsip Resources/res_stasis
Versions:18.5.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) 4channels.pcap
( 1) add_to_bridge_second_time.pcap
( 2) add_to_bridge.pcap
( 3) messages
( 4) pjsip.conf
Description:I believe it is a bug, what do you think?

I have an asterisk ARI and one sip client with a camera and two without a camera. Camera client calling (with video params in SDP) to asterisk and call goes to a stasis application. Stasis adds a channel to the existing bridge.

After this stasis application originates a call (INVITE without video params in sdp) to the first client without a camera and adds created channels to the same bridge. Because of there is a video source in the bridge - asterisk makes a reinvite with video params in SDP to the first client. So the first client is able to see video from the camera client.

Next stasis application originates a call (INVITE without video params in sdp) to the second client without a camera and adds created channels to the same bridge. But there is no reinvite from asterisk to the second client. So, the second client is not able to see video from the camera client.

There is the bridge with three channels now. And only one client can see video from the camera client.
The question is why asterisk sends reinvite only to the first client?

PS. When I am adding in ari swagger the first client (who already can see video) to the same bridge again - asterisk immediately send reinvite with video sdp to the second client, and both clients now can see video from camera client.
Comments:By: Asterisk Team (asteriskteam) 2021-07-07 02:22:48.681-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: Joshua C. Colp (jcolp) 2021-07-07 03:33:21.993-0500

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. The specific steps or actions you took that caused you to encounter the problem.
2. The behavior you expected and the location of documentation that led you to that expectation.
3. The behavior you actually encountered.

To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

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


By: Aidar Kamalov (aidar.kamalov@gmail.com) 2021-07-08 08:47:24.730-0500

messages is asterisk logs

add_to_bridge.pcap - sip trace after add all channels to the bridge, but before add 2222's channel second time(again)

add_to_bridge_second_time.pcap - sip trace after add 2222's chanel to the bridge again
By: Aidar Kamalov (aidar.kamalov@gmail.com) 2021-07-08 08:47:37.608-0500

1. get the latest asterisk (Asterisk 18.5.0 in my case)
2. setup ARI
3. create a simple ARI application, that just answers calls and connect application to asterisk
4. setup 3 pjsip users (1111,2222,3333 in my case) with context that going to stasis application
5. 1111 call with a video camera
6. 2222 and 3333 call without a camera
7. go to swagger http://ari.asterisk.org and create a bridge
8. move 1111's channel to the created bridge
9. move 2222's channel to the created bridge - after this you can see in sip trace - asterisk send reinvite to 2222 with video sdp
10.move 3333's channel to the created bridge - after this you can see in sip trace - asterisk DON'T send reinvite to 3333 with video sdp
11.there are 3 channels in the bridge now
12.if you second time add 2222's channel to the bridge AGAIN - after this you can see in sip trace - asterisk send reinvite to 3333 with video sdp

By: Aidar Kamalov (aidar.kamalov@gmail.com) 2021-07-08 08:54:27.399-0500

this is my simple python2 stasis application:

#!/usr/bin/env python

import threading
import logging
import ari
from channel import *

logging.basicConfig(level=logging.ERROR)
client = ari.connect('http://ATERISK_IP:8080', 'asterisk', 'asterisk')

def stasis_start_cb(channel_obj, ev):
   """Handler for StasisStart"""
   channel = channel_obj.get('channel')
   channel.answer()
   return

if __name__ == '__main__':
   print("Stasis application starting")
   client.on_channel_event('StasisStart', stasis_start_cb)
   client.run(apps='ccng')

By: Aidar Kamalov (aidar.kamalov@gmail.com) 2021-07-08 08:57:23.157-0500

I am expecting that asterisk send reinvite with video sdp to 3333's channel immediately after I add channel to bridge.
But asterisk send reinvite to 2222 but not to 3333.
By: Benjamin Keith Ford (bford) 2021-07-08 12:20:21.531-0500

This sounds very familiar to an issue I've run into in the past. If you are able to, can you try having 1111 connect with video, 2222 connect with video, 3333 connect without video, see what happens, and then have another channel (e.g., 4444) join without video?
By: Aidar Kamalov (aidar.kamalov@gmail.com) 2021-07-09 06:07:39.481-0500

I have called to stasis from 1111 and 2222 with video, 3333 and 4444 without video.
After this I have added channels, step by step, to the created bridge.

I have got 2 reinvites with video sdp from asterisk to 2222 and 3333.
I have attached sip trace file named 4channels.pcap from asterisk host.

By: George Joseph (gjoseph) 2021-07-09 09:26:15.597-0500

Did this work some time in the past or are you trying this for the first time?
If it did work in the past, what version were you using?

By: Aidar Kamalov (aidar.kamalov@gmail.com) 2021-07-09 14:49:58.568-0500

I have tried this for the first time. Also I have tried this on older 18 and 16 versions
By: George Joseph (gjoseph) 2021-07-12 08:00:01.899-0500

oops, I should have asked for this earlier...  Can you attach the full pjsip configurations for each of the extensions?


By: Aidar Kamalov (aidar.kamalov@gmail.com) 2021-07-12 08:14:56.741-0500

attached my pjsip.conf
By: Aidar Kamalov (aidar.kamalov@gmail.com) 2021-07-12 08:17:00.795-0500

also, I have tried without these params. On asterisk and clients without NAT
direct_media=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes