https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r290648 | dvossel | 2010-10-06 16:08:19 -0500 (Wed, 06 Oct 2010) | 12 lines
Fixes gtalk outbound DTMF to work properly.
Outbound DTMF with gtalk needs to be done within the RTP stream. I discovered
this after investigating a packet capture from the gmail client. Instead of
performing jingle signaling DTMF, the gtalk servers expect all DTMF to arrive
on the RTP stream using RFC2833 way of doing things. Chan_gtalk also had an issue
with negotiating RTP payload type 106 for the telephony-event and then sending
DTMF as payload 101. This has been resolved by always negotiating 101 as the payload
type like we do everywhere else. With this patch, incoming google voice calls forwarded
to Asterisk via gtalk work.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@290649 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r290542 | twilson | 2010-10-05 21:35:51 -0700 (Tue, 05 Oct 2010) | 6 lines
Don't try to send RTP when remote_address is null
It is possible for ast_rtp_stop() to be called which will clear the remote
address and cause the sendto to fail and spam warnings. Don't send in this
case.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@290543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r290255 | tilghman | 2010-10-04 18:23:11 -0500 (Mon, 04 Oct 2010) | 18 lines
Merged revisions 290254 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r290254 | tilghman | 2010-10-04 18:14:59 -0500 (Mon, 04 Oct 2010) | 11 lines
Change new pattern matcher to regard dashes the same as the old pattern matcher -- as visual candy to be ignored.
Also change the AEL parser to not generate dashes within extensions, as those
dashes would be ignored. Update the AEL tests to match this behavior.
(closes issue #17366)
Reported by: murf
Patches:
20100727__issue17366.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@290256 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289840 | jpeeler | 2010-10-01 21:43:45 -0500 (Fri, 01 Oct 2010) | 29 lines
Merged revisions 289798 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289798 | jpeeler | 2010-10-01 18:01:31 -0500 (Fri, 01 Oct 2010) | 22 lines
Merged revisions 289797 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289797 | jpeeler | 2010-10-01 17:58:38 -0500 (Fri, 01 Oct 2010) | 15 lines
Change RFC2833 DTMF event duration on end to report actual elapsed time.
The scenario here is with a non P2P early media session. The reported time
length of DTMF presses are coming up short when sending to the remote side.
Currently the event duration is a running total that is incremented when sending
continuation packets. These continuation packets are only triggered upon
incoming media from the remote side, which means that the running total probably
is not going to end up matching the actual length of time Asterisk received
DTMF. This patch changes the end event duration to be lengthened if it is
detected that the end event is going to come up short.
Review: https://reviewboard.asterisk.org/r/957/
ABE-2476
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289701 | jpeeler | 2010-10-01 11:22:19 -0500 (Fri, 01 Oct 2010) | 28 lines
Merged revisions 289700 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289700 | jpeeler | 2010-10-01 11:21:04 -0500 (Fri, 01 Oct 2010) | 21 lines
Merged revisions 289699 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289699 | jpeeler | 2010-10-01 11:20:00 -0500 (Fri, 01 Oct 2010) | 14 lines
Ensure user portion of SIP URI matches dialplan when using encoded characters.
This commit takes a simliar approach to 288112 and checks the dialplan to
determine the proper action for an incoming contact header as to whether or not
it should be decoded or not. sip_new was blindly always decoding the extension,
which also caused the outgoing contact header to be incorrect as well as failing
to match the encoded extension in the dialplan.
(closes issue #17892)
Reported by: wdoekes
Patches:
bug17892-1.patch uploaded by jpeeler (license 325)
Tested by: wdoekes
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On every incoming subscribe there is a iteration through all dialogs to find old subscribes and delete them. This is slow and not RFC conform. This was only needed in 1.2 cause a subscribe was not deleted when a dialog was destroyed, after 1.4 a subscribe get removed when its dialog is destroyed.
Review: https://reviewboard.asterisk.org/r/901/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289549 | rmudgett | 2010-09-30 14:28:36 -0500 (Thu, 30 Sep 2010) | 17 lines
Merged revision 289547 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r289547 | rmudgett | 2010-09-30 14:16:36 -0500 (Thu, 30 Sep 2010) | 10 lines
In chan_misdn, the DivertingLegInformation2 DivertingNr is garbage when the number is restricted.
The same thing happens with DivertingLegInformation1 DivertedTo number.
The misdn_PresentedNumberUnscreened_extract() extracted the Unscreened
PartyNumber field unconditionally. It now checks the presented number
unscreened type to see if the PartyNumber was even present.
JIRA ABE-2595
..........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289552 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289426 | russell | 2010-09-30 10:39:45 -0500 (Thu, 30 Sep 2010) | 22 lines
Merged revisions 289425 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289425 | russell | 2010-09-30 10:37:29 -0500 (Thu, 30 Sep 2010) | 15 lines
Merged revisions 289424 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289424 | russell | 2010-09-30 10:34:29 -0500 (Thu, 30 Sep 2010) | 8 lines
Fix a crash in app_sms.
Since the data being passed to the generator callback is on the stack of the
SMS() application, we must ensure that the generator is stopped before the
application exits.
ABE-2587
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289427 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289340 | qwell | 2010-09-29 16:12:43 -0500 (Wed, 29 Sep 2010) | 22 lines
Merged revisions 289339 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289339 | qwell | 2010-09-29 16:03:47 -0500 (Wed, 29 Sep 2010) | 15 lines
Merged revisions 289338 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289338 | qwell | 2010-09-29 15:56:26 -0500 (Wed, 29 Sep 2010) | 8 lines
Allow a manager originate to succeed on forwarded devices.
The timeout to wait for an answer was being set to 0 when a device forwarded to another
extension. We don't always need the timeout set like this, so make it an optional
parameter, and don't use it in this case.
ABE-2544
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289099 | bbryant | 2010-09-28 14:18:02 -0400 (Tue, 28 Sep 2010) | 28 lines
Merged revisions 289095 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289095 | bbryant | 2010-09-28 14:14:19 -0400 (Tue, 28 Sep 2010) | 21 lines
Merged revisions 289094 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289094 | bbryant | 2010-09-28 14:10:19 -0400 (Tue, 28 Sep 2010) | 14 lines
Fixes an issue with the Newchannel AMI event during the Masquerading process.
Fixes an issue with the Newchannel AMI event during the Masquerading process,
where no Newchannel AMI event was generated for the psuedo channel used during
the masquerading process.
(closes issue #17987)
Reported by: RadicAlish
Patches:
newchannel.patch.txt uploaded by RadicAlish (license 1122)
Tested by: RadicAlish
Review: https://reviewboard.asterisk.org/r/937/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289131 65c4cc65-6c06-0410-ace0-fbb531ad65f3
