Don't reset the RTP address on a glare re-INVITE
authorMatthew Jordan <mjordan@digium.com>
Fri, 8 Mar 2013 03:54:38 +0000 (03:54 +0000)
committerMatthew Jordan <mjordan@digium.com>
Fri, 8 Mar 2013 03:54:38 +0000 (03:54 +0000)
commit12748bc7354d55c460e38f1001e9cb2692c529a6
treed4777a075b35a566f9b771b86f763e79b26a0621
parent3f0ea90ce65e93705347f47221862fc9e345a1b3
Don't reset the RTP address on a glare re-INVITE

Originally, way back in r201583, we added the alternate RTP address so
that the RTP engine would expect to receive audio from a new source
when a glare re-INVITE occurred. In r382589, we remove the alternate
RTP source, as the 'secret' probation mode allows for switching to a new
RTP source when a previous source stops sending RTP. At the time, it
seemed appropriate to set the RTP source based on the information in the
glared re-INVITE.

Unfortunately, that doesn't work so well - in a glared re-INVITE that occurs
with no SDP - such as in a connected line update that glances - we'll set
the RTP source to an invalid address. In subsequent re-INVITE requests from
this Asterisk instance, we'll then send an invalid media address, which will
result in the remote side sending a 488. Whoops.

There isn't any need to reset the RTP source - if we're using strictrtp, we'll
simply synchronize to a new source when we stop getting packets from the old
one. If we aren't using strictrtp, then again there shouldn't be a problem.

Note that the Asterisk Test Suite's connectedline test caught this error.

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382670 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channels/chan_sip.c