summaryrefslogtreecommitdiff
path: root/main/asterisk.exports.in
diff options
context:
space:
mode:
authorMatthew Jordan <mjordan@digium.com>2013-03-08 03:54:38 +0000
committerMatthew Jordan <mjordan@digium.com>2013-03-08 03:54:38 +0000
commit12748bc7354d55c460e38f1001e9cb2692c529a6 (patch)
treed4777a075b35a566f9b771b86f763e79b26a0621 /main/asterisk.exports.in
parent3f0ea90ce65e93705347f47221862fc9e345a1b3 (diff)
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
Diffstat (limited to 'main/asterisk.exports.in')
0 files changed, 0 insertions, 0 deletions