[asterisk-bugs] [JIRA] (ASTERISK-30051) No video after un-hold

[Maximilian Fridrich (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-30051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maximilian Fridrich updated ASTERISK-30051:
-------------------------------------------

    Description: 
During a call with audio and video, when one participant holds the call and then un-holds, the participant that initiated the hold sees no video.

The issue occurs only when {{moh_passthrough=yes}} is set in pjsip.conf.

It occurs most of the time, however sometimes there is video as expected. Furthermore, when Asterisk is built with the DEBUG_THREADS option, the issue does not occur at all.

The attached trace shows the un-hold re-INVITE of the UA (packet no. 31) with _sendrecv/sendrecv_, Asterisk sending _sendonly/sendonly_ to the second call leg (no. 33), then sending another re-INVITE to the second call leg with _sendrecv/sendonly_ (no. 36) . So Asterisk is ultimately setting the video stream of the second call sendonly from its perspective, which is why the UA of the first leg does not receive video.

  was:
During a call with audio and video, when one participant holds the call and then un-holds, the participant that initiated the hold sees no video.

The issue occurs only when {{moh_passthrough=yes}} is set in pjsip.conf.

It occurs most of the time, however sometimes there is video as expected. Furthermore, when Asterisk is built with the DEBUG_THREADS option, the issue does not occur at all.

The attached trace shows the un-hold re-INVITE of the UA (packet no. 31) with _sendrecv/sendrecv_, Asterisk sending _sendonly/sendonly_ to the second call leg (no. 33), then sending another re-INVITE to the second call leg with _sendrecv/sendonly_ (no. 36) . So Asterisk is ultimately setting the video stream of the second call sendonly from its perspective, which is why the UA of the first leg does not receive video.

The dialplan only executes Dial(PJSIP/endpoint).


> No video after un-hold
> ----------------------
>
>                 Key: ASTERISK-30051
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30051
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 16.16.0, 18.11.1, 19.3.3
>         Environment: Linux 5.13.0, 20.04.1-Ubuntu, x86_64
>            Reporter: Maximilian Fridrich
>         Attachments: extensions.conf, pjsip.conf, unhold_video_bug_sip.pcapng
>
>
> During a call with audio and video, when one participant holds the call and then un-holds, the participant that initiated the hold sees no video.
> The issue occurs only when {{moh_passthrough=yes}} is set in pjsip.conf.
> It occurs most of the time, however sometimes there is video as expected. Furthermore, when Asterisk is built with the DEBUG_THREADS option, the issue does not occur at all.
> The attached trace shows the un-hold re-INVITE of the UA (packet no. 31) with _sendrecv/sendrecv_, Asterisk sending _sendonly/sendonly_ to the second call leg (no. 33), then sending another re-INVITE to the second call leg with _sendrecv/sendonly_ (no. 36) . So Asterisk is ultimately setting the video stream of the second call sendonly from its perspective, which is why the UA of the first leg does not receive video.



--
This message was sent by Atlassian JIRA
(v6.2#6252)