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

[David Vossel]

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


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?

- David


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
> 
>