[asterisk-bugs] [JIRA] (ASTERISK-29479) [patch] Channels are not put on hold for Session Progress with inactive audio
Friendly Automation (JIRA)
noreply at issues.asterisk.org
Tue Jun 22 08:01:33 CDT 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Friendly Automation closed ASTERISK-29479.
------------------------------------------
Resolution: Fixed
> [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)
More information about the asterisk-bugs
mailing list