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

[Bernd Zobl (JIRA)]

Bernd Zobl created ASTERISK-29479:
-------------------------------------

             Summary: [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
         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)