aboutsummaryrefslogtreecommitdiffstats
path: root/cdr
diff options
context:
space:
mode:
authormmichelson <mmichelson@f38db490-d61c-443f-a65b-d21fe96a405b>2009-05-28 15:44:01 +0000
committermmichelson <mmichelson@f38db490-d61c-443f-a65b-d21fe96a405b>2009-05-28 15:44:01 +0000
commit2cfb4e9356383639f03db0c5a6313df460df94ce (patch)
treecf66a2d536564e770112d1360e6b0ee1c174d037 /cdr
parent749b0a28aa52ced06029581d91cc6d31db2b9665 (diff)
Merged revisions 197606 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk ................ r197606 | mmichelson | 2009-05-28 10:32:19 -0500 (Thu, 28 May 2009) | 22 lines Recorded merge of revisions 197588 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r197588 | mmichelson | 2009-05-28 10:27:49 -0500 (Thu, 28 May 2009) | 16 lines Allow for media to arrive from an alternate source when responding to a reinvite with 491. When we receive a SIP reinvite, it is possible that we may not be able to process the reinvite immediately since we have also sent a reinvite out ourselves. The problem is that whoever sent us the reinvite may have also sent a reinvite out to another party, and that reinvite may have succeeded. As a result, even though we are not going to accept the reinvite we just received, it is important for us to not have problems if we suddenly start receiving RTP from a new source. The fix for this is to grab the media source information from the SDP of the reinvite that we receive. This information is passed to the RTP layer so that it will know about the alternate source for media. Review: https://reviewboard.asterisk.org/r/252 ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@197619 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'cdr')
0 files changed, 0 insertions, 0 deletions