[asterisk-dev] [Code Review] RTP Timestamp changes after transfer, but the SSRC does not and the markerbit ist not set.

[David Vossel]

> On 2010-07-01 16:46:34, David Vossel wrote:
> > Does this only occur during a SIP_REFER or INVITE with replaces?  If so could we not just indicate this update after the ast_do_masquerade function gets called in chan_sip?
> 
> Terry Wilson wrote:
>     If it was a SIP-specific issue, I would but it also affects SCCP and probably every other RTP-using channel. We could make the patch more targeted by updating all of the channel technologies that use RTP...but, since we are by definition changing the source of the audio with a masquerade anyway, it might be correct to change the SSRC and set the marker bit whenever we do it.
>     
>     That said, masquerades are kind of scary. So, I figured I'd ask around and see what might break (since we've broken things in this area once before by making ast_rtp_update_source() change the SSRC which broke DTMF. This seems safer than that change was, though.

This patch doesn't look like it is going to break anything to me, but I have a few more comments.  Does it make more sense to do this in ast_do_masquerade after the masquerade has occured instead of ast_channel_masquerade which sets up the masquerade to happen later?  Also, since we are indicating this on the channel, it will get passed through over IAX2.  Is there any reason we would ever want this control frame to be passed through there since it should only affect RTP?


- David


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


On 2010-07-01 13:11:06, Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/758/
> -----------------------------------------------------------
> 
> (Updated 2010-07-01 13:11:06)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> From the bug report:
> 
> On every SIP transfer (Example: A calls B / B places A on hold / B calls C / A sends transfer to Asterisk PBX) the outgoing RTP traffic from Asterisk to the transfer target (RTP to C) is broken. Asterisk is changing the RTP timestamp massively, but the SSRC stays on the old value and the marker bit is also not set. As soon as the new timestamp is smaller than the old timestamp value, the transfer target rejects the RTP packets after the transfer (not really, it's just not played), so i get one way audio.
> 
> This patch queues an AST_CONTROL_SRCCHANGE frame for every channel masquerade. This will cause the RTP SSRC to change and marker bit to be set on all masquerades.
> 
> If anyone can think of a case where this is a bad thing, please comment!
> 
> 
> This addresses bug 17007.
>     https://issues.asterisk.org/view.php?id=17007
> 
> 
> Diffs
> -----
> 
>   /trunk/main/channel.c 273427 
> 
> Diff: https://reviewboard.asterisk.org/r/758/diff
> 
> 
> Testing
> -------
> 
> Compiles and runs. A user has reported it fixes an SCCP issue they were experiencing. Another user reported initially that it fixed their issue, then responded later that they were "still having some SSRC problems" but have not elaborated whether or not the problems are actually related to the initial report. They also posted a patch that they said fixed all of their issues that should essentially be doing the same thing, but only for chan_sip, which would not fix the more general issue that affects any channel that uses RTP.
> 
> It has been almost a week since I requested more info and have not heard anything back from them. It could be an unrelated issue or it could be an indication that there was a side-effect.
> 
> 
> Thanks,
> 
> Terry
> 
>