[asterisk-bugs] [JIRA] (ASTERISK-27252) RTP: One way audio with direct media and strictrtp=yes.

[Friendly Automation (JIRA)]

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

Friendly Automation commented on ASTERISK-27252:
------------------------------------------------

Change 6410 merged by Jenkins2:
AST-2017-008: Improve RTP and RTCP packet processing.

[https://gerrit.asterisk.org/6410|https://gerrit.asterisk.org/6410]

> RTP: One way audio with direct media and strictrtp=yes.
> -------------------------------------------------------
>
>                 Key: ASTERISK-27252
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27252
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 13.17.1, 14.6.1
>            Reporter: Richard Mudgett
>            Assignee: Richard Mudgett
>
> The patch for ASTERISK-27013 broke the direct media RTP learning case that the "always learning" patch (80b8c2349c427a94a428670f1183bdc693936813) was created for in the first place.
> The broken scenario is as follows:
> {noformat}
> PhoneA --> Ast1 --> Ast2 --> PhoneB
> {noformat}
> When PhoneA calls PhoneB, you get one way audio where PhoneA cannot hear PhoneB when Ast2 sets up direct media between Ast1 and PhoneB.  When PhoneB answers in this scenario RTP media initially flows through Ast2 to get to PhoneA.  Ast2 notices that direct media is possible so it reinvites Ast1 and PhoneB to send media directly between them.  Since the reinvites can happen quickly and there is usually a delay of around 500 ms in actually switching the RTP streams, the strictrtp learning code may not have learned the first stream source before it needs to relearn for the second stream source.  Under these conditions, the recent strictrtp change causes Ast1 to learn and lock onto the first RTP source from Ast2 even though the reinvites change the media stream to come directly from PhoneB.
> If PhoneB places the call on hold and then takes the call off hold, PhoneA will be able to hear PhoneB.



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