aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authormmichelson <mmichelson@f38db490-d61c-443f-a65b-d21fe96a405b>2008-09-09 16:21:31 +0000
committermmichelson <mmichelson@f38db490-d61c-443f-a65b-d21fe96a405b>2008-09-09 16:21:31 +0000
commit45236613c24a1702df2b9571ab4ce940eae0ab4e (patch)
tree0ab7301e4bc578d9045f3cfd87bf405fae067d7e
parente675e4c379a83c0f6d632c9fc601f318fe66235c (diff)
Blocked revisions 142080 via svnmerge
................ r142080 | mmichelson | 2008-09-09 11:20:41 -0500 (Tue, 09 Sep 2008) | 29 lines Merged revisions 142079 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r142079 | mmichelson | 2008-09-09 11:19:17 -0500 (Tue, 09 Sep 2008) | 21 lines When determining if codecs used by SIP peers allow the media to be natively bridged, use the jointcapability instead of the peercapability. It seems that the intent of using the peercapability was to expand the choice of codecs for the call to increase the chances of being able to native bridge the channels. The problem is that if a codec were settled on for the native bridge and that wasn't a codec that was configured to be used by Asterisk for that peer, then Asterisk would send a REINVITE with no codecs in the SDP which is a bug no matter how you slice it. (closes issue #13076) Reported by: ramonpeek Patches: 13076.patch uploaded by putnopvut (license 60) Tested by: tbelder ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@142081 f38db490-d61c-443f-a65b-d21fe96a405b
0 files changed, 0 insertions, 0 deletions