[asterisk-bugs] [JIRA] (ASTERISK-29479) [patch] Channels are not put on hold for Session Progress with inactive audio

[Friendly Automation (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255424#comment-255424 ] 

Friendly Automation commented on ASTERISK-29479:
------------------------------------------------

Change 16108 merged by Friendly Automation:
res_pjsip_sdp_rtp: Evaluate remotely held for Session Progress

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

> [patch] Channels are not put on hold for Session Progress with inactive audio
> -----------------------------------------------------------------------------
>
>                 Key: ASTERISK-29479
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29479
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_sdp_rtp
>    Affects Versions: 16.18.0
>         Environment: Debian GNU/Linux 10 (buster) 64bit
>            Reporter: Bernd Zobl
>            Assignee: Bernd Zobl
>              Labels: patch
>         Attachments: session_progress.patch
>
>
> The fix for ASTERISK-28754 changed the behaviour of when channels were put on hold. In our particular case, a "Session Progress" to an outbound "INVITE" is no longer evaluated correctly.
> The `Session Progress` to an outbound INVITE seems not to be processed by `negotiate_incoming_sdp_stream()`, where, since ASTERISK-28754, the remotely held state is evaluated.
> The `Session Progress` is, however, processed by `apply_negotiated_sdp_stream()`, where the remotely_held state was evaluated before.
> My guess is that the evaluation was moved, since the `remotely_held` field is needed in `create_outgoing_sdp_stream()`, which is called after `negotiate_incoming_sdp_stream()` on an incoming offer.
> ---
> I'll attach a patch and submit it to gerrit, once the issue ID is generated.
> ---
> If I read the problem of ASTERISK-28754 correctly, the issue was that if two SIP phones A and B both hold their call the resulting audio attributes (sendrecv, sendonly, recvonly, inactive) were incorrect.
> I reproduced this by:
>   A calls B
>   A holds the call
>   B holds the call
>   A unholds the call
>   B unholds the call
> with and without `moh_passthrough` active.
> The wireshark trace of the SIP messages seems conclusive and does not change the SIP-behavior with the proposed patch.



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