[asterisk-bugs] [JIRA] Closed: (ASTERISK-15795) [patch] endless wait for RTP in certain scenarios

[Walter Doekes (JIRA)]

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

Walter Doekes closed ASTERISK-15795.
------------------------------------

    Resolution: Cannot Reproduce

I'm thinking this probably already works.

I've seen similar issues where I needed the asterisk to begin sending which worked, but only if one of the timing resource module was loaded.

Closing now to reduce open bugs.

> [patch] endless wait for RTP in certain scenarios
> -------------------------------------------------
>
>                 Key: ASTERISK-15795
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-15795
>             Project: Asterisk
>          Issue Type: New Feature
>          Components: Channels/chan_sip/General
>    Affects Versions: 1.8.7.1
>            Reporter: Walter Doekes
>         Attachments: ast1424-17012-sdp-direction-passive-POC.diff, ast1430rc3-17012-sdp-direction-passive-POC.diff, issue15795_rtp_prodding_1.8.patch, issue15795_rtp_prodding_WIP.patch
>
>
> A Dialogic machine that I'm peering with has the ability to go into passive mode for RTP traffic (adding a=direction:passive to the SDP body). I haven't figured out why/when it does so, but when it does -- and it always does in my current setup -- everyone ends up waiting for data and no RTP stream gets set up.
> ****** STEPS TO REPRODUCE ******
> When asterisk bridges a call from X to Y through itself, the following sequence of SIP INVITE and 200 OK occurs (A is the asterisk machine):
> (1) X INVITEs A (with a=direction:passive in the SDP)
> (2) A INVITEs Y
> (3) Y 200 OKs A (with a=direction:passive in the SDP)
> (4) A 200 OKs X
> Both X and Y wait for data. They've marked that they'll be waiting for asterisk to make the first move. Asterisk also waits for data. The result: no media.
> ****** ADDITIONAL INFORMATION ******
> The issue occurs on 1.4.24. I've browsed the 1.6 source and the bug reports and haven't found any indications that in newer versions this issue is tackled. After filing this report, I'll check 1.4.30 to be on the safe side.
> I've created a patch which forces asterisk to send some data. It's merely a proof-of-concept and lacks the following:
> (1) I don't know what a reasonable audio frame looks like, that should be fixed.
> (2) The 1000 ms wait after ast_answer is arbitrary but increases the chance that the peer has seen and parsed our 200 OK with our session information. It would probably be better to begin sending data right away, and keep doing it until we get the first replies.
> (3) The fix need possibly only be applied if both peers have sent "a=direction:passive". I'm not sure whose job it is to begin communicating.
> (4) I don't know if the locking I've used is right or if I need to free anything after the ast_sched_add.
> It does however seem to work and not conflict with the regular calls that are not affected by the problem.
> Regards,
> Walter Doekes
> OSSO B.V.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira