[asterisk-dev] [Code Review] Revert contantssrc change in favor of a more focused fix

[Kevin Fleming]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/540/#review1639
-----------------------------------------------------------



/trunk/include/asterisk/rtp_engine.h
<https://reviewboard.asterisk.org/r/540/#comment3651>

    This is out of sync with trunk; the AST_RTP_PROPERTY_MAX value must be the last one in the enum.



/trunk/res/res_rtp_asterisk.c
<https://reviewboard.asterisk.org/r/540/#comment3652>

    How does this differ from what ast_rtp_new_source() does?



/trunk/res/res_rtp_asterisk.c
<https://reviewboard.asterisk.org/r/540/#comment3653>

    Can you document what the purpose of this 'data' element of the SRCUPDATE frame is? I don't think I've seen that usage in the tree before.


- Kevin


On 2010-03-05 00:55:13, Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/540/
> -----------------------------------------------------------
> 
> (Updated 2010-03-05 00:55:13)
> 
> 
> Review request for Asterisk Developers and Russell Bryant.
> 
> 
> Summary
> -------
> 
> This change basically reverts the change reviewed in https://reviewboard.asterisk.org/r/374/ and instead limits the updating of the RTP synchronization source to only those times when we detect that the other side of the conversation has changed the ssrc.
> 
> The problem is that SRCUPDATE control frames are sent many times where we don't want a new ssrc, including whenever Asterisk has to send DTMF in a normal bridge. This is also not the first time that this mistake has been made. The initial implementation of the ast_rtp_new_source function also changed the ssrc--and then it was removed because of this same issue. Then, we put it back in again to fix a different issue. Instead, I think we should make a very limited change and just update the ssrc when we see it change.
> 
> This issue affects mantis issues 5413 (srtp doesn't like the ssrc changing), 15642 (sonus dtmf), 16292 (Exchange UM dtmf), and probably 16438 and 16714.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 244504 
>   /trunk/include/asterisk/rtp_engine.h 244504 
>   /trunk/res/res_rtp_asterisk.c 244504 
> 
> Diff: https://reviewboard.asterisk.org/r/540/diff
> 
> 
> Testing
> -------
> 
> So far...it compiles. I'm trying to devise a simple way to replicate the original issue which was a reinvite sent to asterisk which results in an ssrc change in the rtp sent to asterisk.
> 
> 
> Thanks,
> 
> Terry
> 
>