[asterisk-bugs] [JIRA] (ASTERISK-22128) ARI/bridges: chan_sip channels with directmedia=yes - Asterisk doesn't retake the media when the technology changes from native rtp

[Jonathan Rose (JIRA)]

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

Jonathan Rose updated ASTERISK-22128:
-------------------------------------

    Description: 
Let's start with the weird...

If directmedia=no for each channel, pushing two chan_sip channels in stasis applications into a bridge created by stasis will still make them become native RTP bridges with all of the media path details that implies (basically directmedia is active). This is mentioned in the related linked issue.

This works fine aside from that unexpected detail. When a third channel enters, the bridge becomes softmix and the media reverts to flowing through Asterisk, however... if directmedia=yes and a third channel enters the bridge, the bridge technology will change, but the media will not be redirected to go through Asterisk. I discovered this while working on music on hold, but it also happens in the same way with play on bridge function I committed earlier.

Reproduction Instructions:

exten => 1,1,Answer()
exten => 1,n,Stasis(hello)

Have a websocket client connected with the hello application. You can do that with http://www.websocket.org/echo.html using the address ws://127.0.0.1:8088/ari/events?app=hello

provided that you have websocket configured.

Have both directmedia=yes SIP peers call into '1' so that they are put in stasis. Use Stasis to push both channels into a stasis bridge and they should be in a native RTP bridge.

At this point, use {code}POST /bridges/{bridgeId}/play{code} with the bridgeID and sound:demo-congrats in order to try to play sound to the bridge. The Announcer channel should enter the bridge and the bridge technology should change, but the SIP channels will not reroute their RTP through Asterisk.

Meanwhile if directmedia=no, everything should be the same, but the RTP go through Asterisk as it should when softmix starts.

  was:
Let's start with the weird...

If directmedia=no for each channel, pushing two chan_sip channels in stasis applications into a bridge created by stasis will still make them become native RTP bridges with all of the media path details that implies (basically directmedia is active). This is mentioned in the related linked issue.

This works fine aside from that unexpected detail. When a third channel enters, the bridge becomes softmix and the media reverts to flowing through Asterisk, however... if directmedia=yes and a third channel enters the bridge, the bridge technology will change, but the media will not be redirected to go through Asterisk. I discovered this while working on music on hold, but it also happens in the same way with play on bridge function I committed earlier.

Reproduction Instructions:

exten => 1,1,Answer()
exten => 1,n,Stasis(hello)

Have a websocket client connected with the hello application. You can do that with http://www.websocket.org/echo.html using the address ws://127.0.0.1:8088/ari/events?app=hello

provided that you have websocket configured.

Have both directmedia=yes SIP peers call into '1' so that they are put in stasis. Use Stasis to push both channels into a stasis bridge and they should be in a native RTP bridge.

At this point, use POST /bridges/{bridgeId}/play with the bridgeID and sound:demo-congrats in order to try to play sound to the bridge. The Announcer channel should enter the bridge and the bridge technology should change, but the SIP channels will not reroute their RTP through Asterisk.

Meanwhile if directmedia=no, everything should be the same, but the RTP go through Asterisk as it should when softmix starts.

    
> ARI/bridges: chan_sip channels with directmedia=yes - Asterisk doesn't retake the media when the technology changes from native rtp
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-22128
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22128
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Bridges/Native, Resources/res_stasis_http
>    Affects Versions: SVN, 12
>            Reporter: Jonathan Rose
>
> Let's start with the weird...
> If directmedia=no for each channel, pushing two chan_sip channels in stasis applications into a bridge created by stasis will still make them become native RTP bridges with all of the media path details that implies (basically directmedia is active). This is mentioned in the related linked issue.
> This works fine aside from that unexpected detail. When a third channel enters, the bridge becomes softmix and the media reverts to flowing through Asterisk, however... if directmedia=yes and a third channel enters the bridge, the bridge technology will change, but the media will not be redirected to go through Asterisk. I discovered this while working on music on hold, but it also happens in the same way with play on bridge function I committed earlier.
> Reproduction Instructions:
> exten => 1,1,Answer()
> exten => 1,n,Stasis(hello)
> Have a websocket client connected with the hello application. You can do that with http://www.websocket.org/echo.html using the address ws://127.0.0.1:8088/ari/events?app=hello
> provided that you have websocket configured.
> Have both directmedia=yes SIP peers call into '1' so that they are put in stasis. Use Stasis to push both channels into a stasis bridge and they should be in a native RTP bridge.
> At this point, use {code}POST /bridges/{bridgeId}/play{code} with the bridgeID and sound:demo-congrats in order to try to play sound to the bridge. The Announcer channel should enter the bridge and the bridge technology should change, but the SIP channels will not reroute their RTP through Asterisk.
> Meanwhile if directmedia=no, everything should be the same, but the RTP go through Asterisk as it should when softmix starts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira