[Home]

Summary:ASTERISK-29638: res_pjsip_session: No video after early media
Reporter:Michael Auracher (MichaelAUM)Labels:
Date Opened:2021-09-10 04:05:30Date Closed:2022-04-26 10:45:33
Priority:MinorRegression?Yes
Status:Closed/CompleteComponents:Resources/res_pjsip_session
Versions:16.10.0 18.6.0 Frequency of
Occurrence		Constant
Related
Issues:
is a clone ofASTERISK-29655 res_pjsip_session: No video to caller if no camera available
Environment:Alpine Linux (in Docker), various versions. All Asterisk versions >16.9Attachments:( 0) caller-and-callee-video.pcap
( 1) caller-video-sendonly.pcap
( 2) caller-video-sendonly-18.2.1.pcap
( 3) debug_log_caller-and-callee-video.log
( 4) debug_log_caller-video-sendonly.log
( 5) debug_log_caller-video-sendonly-18.2.1.lig
( 6) debug_log_caller-video-sendonly-18.6.0.log
( 7) debug_log_caller-video-sendonly-18.6.0.pcap
( 8) pjsip_devices.conf
( 9) pjsip_transports.conf
(10) pjsip.conf
Description:This issue is 100% reproducable on all Asterisk versions > 16.9.0
Setup: Asterisk with default config, only devices are configured.
Codecs: h264 + any audio codec

Reproduce:
(Tested with Yealink-T58V, Yealink-VP530, Grandstream-GXV3275  (all early media enabled) to a  Grandstream-GXV3275 (or any other device supporting early media)

1. Call from a video phone
2. Preview video is displayed on GXV3275 (OK)
3. Answer call on GXV3275

Actual result: No Video is shown on on caller display
Expected result: Video is shown on on caller display

Happens after the changes introduced in https://issues.asterisk.org/jira/browse/ASTERISK-28783 in
https://gerrit.asterisk.org/c/asterisk/+/13954/2/res/res_pjsip_session.c

Workaround: patched file by reverting the changes from ASTERISK-28783


Details:

11:28:47.1228 :  [11153]: res_pjsip_session.c:4230 session_on_tsx_state:  Topology: Pending: (null topology)  Active:  <0:audio-0:audio:sendrecv (g722|alaw|ulaw)> <1:video-1:video:sendrecv (h264)>

Than we get: "Pending media state exists"

res_pjsip_session.c:2302 sip_session_refresh:  PJSIP/132-00000000: DP:  <0:audio-0:audio:sendrecv (g722|alaw|ulaw)> <1:video-1:video:recvonly (h264)> → this will be used
res_pjsip_session.c:2303 sip_session_refresh:  PJSIP/132-00000000: DA:  <0:audio-0:audio:sendrecv (g722|alaw|ulaw)> <1:video-1:video:sendrecv (h264)>
res_pjsip_session.c:2304 sip_session_refresh:  PJSIP/132-00000000: CP: (null topology)
res_pjsip_session.c:2305 sip_session_refresh:  PJSIP/132-00000000: CA:  <0:audio-0:audio:sendrecv (g722|alaw|ulaw)> <1:video-1:video:sendrecv (h264)>

The first channel in the bridge is PJSIP/200-00000001 (the caller) which has :
   Topology: Pending: (null topology)  Active:  <0:audio-0:audio:sendrecv (g722|alaw|ulaw)> <1:video-1:video:sendonly (h264)>
Which is the “Early media” state in this test case

This  is the resulting topology although the SIP 200 OK + SDP video:sendrecv is set by the Grandstream:

11:28:47.1237 :  [11153]: res_pjsip_session.c:2194 sip_session_refresh:  PJSIP/132-00000000: New SDP? yes  Queued? yes DP:  <0:audio-0:audio:sendrecv (g722|alaw|ulaw)> <1:video-1:video:recvonly (h264)>  DA:  <0:audio-0:audio:sendrecv (g722|alaw|ulaw)> <1:video-1:video:sendrecv (h264)>
11:28:47.1237 :  [11153]: res_pjsip_session.c:2266 sip_session_refresh:  PJSIP/132-00000000: Pending media state exists
11:28:47.1238 :  [11153]: res_pjsip_session.c:2300 sip_session_refresh:  PJSIP/132-00000000: Active media state exists and is not equal to pending
11:28:47.1243 :  [11153]: res_pjsip_session.c:1945 resolve_refresh_media_states:  PJSIP/132-00000000: Changed NP stream state from sendrecv to recvonly


Then an INVITE is sent to the Grandstream and the video is turned off.

Comments:By: Asterisk Team (asteriskteam) 2021-09-10 04:05:38.903-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-09-10 04:57:31.428-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: Michael Auracher (MichaelAUM) 2021-09-10 07:23:38.590-0500

Caller-and-callee-video: both devices have video enabled (incoming and outgoing) -> result: after 'Answer' no video sent to the caller, but still sent to the callee.

caller-video-sendonly: the caller device has incoming video disabled (intended use case) -> result: after 'Answer' video to the callee is stopped but works after a few seconds
(Note: in v16.10 and 18.2 the video on the callee also stopped, but I cannot reproduce this on my current 18.6.0 now)


By: Michael Auracher (MichaelAUM) 2021-09-10 08:01:31.108-0500

I was able to reproduce the second issue by using 18.2.1
-> No video after 'Answer' on the callee side, although the caller should send.

By: Michael Auracher (MichaelAUM) 2021-09-10 08:02:57.266-0500

Now I was able to reproduce the second issue again using the latest version.
I don't know, what I had done wrong before.
(Attached debug_log_caller-video-sendonly-18.6.0*)
By: George Joseph (gjoseph) 2021-09-15 08:02:39.394-0500

Thinking more about this...
Try enabling {{accept_multiple_sdp_answers}} in both the pjsip {{system}} settings and the settings for the endpoint.

By: Michael Auracher (MichaelAUM) 2021-09-15 09:26:27.838-0500

Unfortunately accept_multiple_sdp_answers did not solve the issue.
By: Friendly Automation (friendly-automation) 2022-04-26 10:45:34.815-0500

Change 18371 merged by Friendly Automation:
core_unreal & app_dial: Flip stream direction of second channel.

[https://gerrit.asterisk.org/c/asterisk/+/18371|https://gerrit.asterisk.org/c/asterisk/+/18371]
By: Friendly Automation (friendly-automation) 2022-04-26 10:48:45.366-0500

Change 18386 merged by Friendly Automation:
app_dial: Flip stream direction of outgoing channel.

[https://gerrit.asterisk.org/c/asterisk/+/18386|https://gerrit.asterisk.org/c/asterisk/+/18386]
By: Friendly Automation (friendly-automation) 2022-04-26 10:48:51.715-0500

Change 18385 merged by Friendly Automation:
app_dial: Flip stream direction of outgoing channel.

[https://gerrit.asterisk.org/c/asterisk/+/18385|https://gerrit.asterisk.org/c/asterisk/+/18385]
By: Friendly Automation (friendly-automation) 2022-04-26 12:22:48.470-0500

Change 18387 merged by Friendly Automation:
app_dial: Flip stream direction of outgoing channel.

[https://gerrit.asterisk.org/c/asterisk/+/18387|https://gerrit.asterisk.org/c/asterisk/+/18387]
By: Friendly Automation (friendly-automation) 2022-05-05 08:15:49.037-0500

Change 18497 merged by Friendly Automation:
core_unreal: Flip stream direction of second channel.

[https://gerrit.asterisk.org/c/asterisk/+/18497|https://gerrit.asterisk.org/c/asterisk/+/18497]
By: Friendly Automation (friendly-automation) 2022-05-05 08:15:58.077-0500

Change 18419 merged by Friendly Automation:
core_unreal: Flip stream direction of second channel.

[https://gerrit.asterisk.org/c/asterisk/+/18419|https://gerrit.asterisk.org/c/asterisk/+/18419]
By: Friendly Automation (friendly-automation) 2022-05-05 08:17:17.016-0500

Change 18496 merged by Friendly Automation:
core_unreal: Flip stream direction of second channel.

[https://gerrit.asterisk.org/c/asterisk/+/18496|https://gerrit.asterisk.org/c/asterisk/+/18496]