[asterisk-dev] [Code Review] Change SSRC when a peer sends a re-invite

[Terry Wilson]

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

(Updated 2009-09-24 16:33:29.458999)


Review request for Asterisk Developers and Russell Bryant.


Summary (updated)
-------

Asterisk doesn't honor marker bit when reinvited to already-bridged RTP streams, resulting in far-end stack discarding packets with "old" timestamps that are actually part of a new stream.  This patch sends AST_CONTROL_SRCUPDATE whenever there is a reinvite, unless the 'constantssrc' is set to true in sip.conf.

The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server
Call comes in from ITSP, Asterisk dials the app server which sends a re-invite back to Asterisk--not to negotiate to send media directly to the ITSP, but to indicate that it's changing the stream it's sending to Asterisk.  The app server generates a new SSRC, sequence numbers, timestamps, and sets the marker bit on the new stream.  Asterisk passes through the teimstamp of the new stream, but does not reset the SSRC, sequence numbers, or set the marker bit.

When the timestamp on the new stream is older than the timestamp on the original stream, the ITSP (which doesn't know there has been any change) discards the new frames because it thinks they are too old.  This patch addresses this by changing the SSRC on a stream update unless constantssrc=true is set in sip.conf.


Diffs
-----

  /branches/1.4/channels/chan_sip.c 219719 
  /branches/1.4/include/asterisk/rtp.h 219719 
  /branches/1.4/main/rtp.c 219719 

Diff: https://reviewboard.asterisk.org/r/374/diff


Testing
-------

Verified that the control message is queued on reinvite (via hold on a polycom phone), except when constantssrc=true in either global or peer config.


Thanks,

Terry