[Home]

Summary:ASTERISK-10472: Problems when doing an attended and unattended transfer with Thomson Phones
Reporter:Ramon Peek-Fares (ramonpeek)Labels:
Date Opened:2007-10-08 11:34:30Date Closed:2007-11-09 10:34:34.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Attended.zip
( 1) backtrace
( 2) Notify-trace.zip
( 3) UnAttended.zip
Description:When doing an attended transfer (party A -> B -> C) the phones A & B start ringing after they finished the active call, but there is no audio (ghostcalls)

When doing an unattended transfer the phone B (transferrer) start ringing immediatly after transfering the party A to C.

****** ADDITIONAL INFORMATION ******

This case is related to issues 10868 & 10696 which have been related to each other earlier.
On request of "mavince" (file-administrator)this new case is created since there still seems to be a significant difference between these two cases.
Comments:By: Ramon Peek-Fares (ramonpeek) 2007-10-08 11:51:39

OK let's elaborate somewhat more here..
Since there has already been quite somethings done to solve this issue..

First I did quite some digging into this issue myself.
Then with some help of Olle Johannson I discovered much similairity with issue 10868. So I had my original issue 10696 related to that one.
However there seemed to be differences between my issue and 10868
So again I needed  to create a new issue.... this one!

Attached you will find two zip files..
attended.zip -> containing the original issue during attended tranfers
unattended.zip -> containing the original issue during unattended tranfers
By: Ramon Peek-Fares (ramonpeek) 2007-10-08 12:03:49

When looking at issue 10868 I can see the same thing happening.
(2x INVITE to put the active call-leg on-hold)

However, when I look at the traces made during an unattended transfer I can see that putting the call-leg back into the MOH works fine. But that Asterisk starts re-inviting the transferrer after he has already transferred the RTP stream back to asterisk... which I now feel might be incorrect.

After that it's clear to see that the phone doesn't expect the message and ignores it, however asterisk start retransmitting the request after the T1 timer expires and thus a call is initiated with no RTP stream... (ghost calls.)

I am starting to believe that the problem is really occuring in an earlier state than where the current patch to rtp.c is written (in issue 10868).
Cause in my system too this patch solves the problem only partially on attended transfer, but the problem still exists on unattended transfers.
By: Ramon Peek-Fares (ramonpeek) 2007-10-08 12:11:34

I've installed revision 85023 of rtp.c (http://svn.digium.com/view/asterisk?view=rev&revision=85023)

This solves the issue of double re-invites where they where originally occuring.
It definitly is clear to me that this revision solves a great part of the problem.

However I'm now left with multiple reinvites at a later period in time (after the bridge was succesfully made).
According to Mavince (in issue 10868) this should have been solved with revision 84990 of channel.c  (http://svn.digium.com/view/asterisk?view=rev&revision=84990)
However when I apply that revision to my system, it crashes!!

What now?
By: Joshua C. Colp (jcolp) 2007-10-08 12:24:05

Please upload a backtrace of the crash then. Information on getting one is available in the doc directory.
By: Joshua C. Colp (jcolp) 2007-10-08 12:28:31

Is there actually an issue with the blind transfer? chan_sip purposely sends back a NOTIFY to tell the phone the transfer went fine. What the phone does with it is up to it.
By: Ramon Peek-Fares (ramonpeek) 2007-10-08 12:54:31

OK I've uploaded the backtrace...

About the blind-transfer...
You might be right..
However in the trace we can see the the INVITE that is being send,
is not being acknowlegded by the phone.

Is this because the phone is not doing what is supposed to?
Or is this because Asterisk shouldn't send the INVITE in this particulair situation. What do the RFC's say about this... (let look that up!)
By: Ramon Peek-Fares (ramonpeek) 2007-10-08 13:27:30

I've been looking into the blind-transfer issue for a bit..
I cannot seem to find any reason why Asterisk should inform the transferrer of a succesfull transfer using a second INVITE request.

The RFC says;
"Unless stated otherwise, the protocol for emitting and responding to
  a REFER request are identical to those for a BYE request in [1].  The
  behavior of SIP entities not implementing the REFER (or any other
  unknown) method is explicitly defined in [1]."

So why is Asterisk sending that second (re-)invite but also send a BYE?

Could anyone please clarify?
Since I don't mind blaming the manufacturer but then I better be correct in my reply saying; the phone should accept and acknowledge that second INVITE.
By: Digium Subversion (svnbot) 2007-10-08 14:46:51

Repository: asterisk
Revision: 85057

U   branches/1.4/main/rtp.c

------------------------------------------------------------------------
r85057 | file | 2007-10-08 14:46:50 -0500 (Mon, 08 Oct 2007) | 4 lines

Only update codec information if the channel has a technology private structure.
(issue ASTERISK-10472)
Reported by: ramonpeek

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-10-08 14:48:33

Repository: asterisk
Revision: 85058

_U  trunk/
U   trunk/main/rtp.c

------------------------------------------------------------------------
r85058 | file | 2007-10-08 14:48:32 -0500 (Mon, 08 Oct 2007) | 12 lines

Merged revisions 85057 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r85057 | file | 2007-10-08 17:06:33 -0300 (Mon, 08 Oct 2007) | 4 lines

Only update codec information if the channel has a technology private structure.
(issue ASTERISK-10472)
Reported by: ramonpeek

........

------------------------------------------------------------------------
By: Joshua C. Colp (jcolp) 2007-10-08 14:48:39

Okay all, try the above commit. It should solve the crashing issue.
By: Mark A Vince (mavince) 2007-10-08 15:49:37

Loaded new rtp.c... usual compile warnings... tried attended transfer with Polycom.... Asterisk crashed.. CLI trace below.. PSTN ->polycom(garrish) ->transfer to polycom (utano) ->crash

-- Executing [7323680452@pri_from_als:1] Macro("SIP/172.16.4.4-b7d14e80", "stdexten|0452|SIP/garrish") in new stack
   -- Executing [s@macro-stdexten:1]     -- Goto (macro-stdexten,s,4)
   -- Executing [s@macro-stdexten:4] Dial("SIP/172.16.4.4-b7d14e80", "SIP/garrish|30") in new stack
Extension Changed 0452 new state Ringing for Notify User utano
   -- Called garrish
Extension Changed 0452 new state Ringing for Notify User vince
       -- SIP/garrish-08a5edb0 is ringing
       -- SIP/garrish-08a5edb0 answered SIP/172.16.4.4-b7d14e80
Extension Changed 0452 new state InUse for Notify User utano
Extension Changed 0452 new state InUse for Notify User vince
   -- Native bridging SIP/172.16.4.4-b7d14e80 and SIP/garrish-08a5edb0
       -- Started music on hold, class 'sip', on SIP/172.16.4.4-b7d14e80
       -- Stopped music on hold on SIP/172.16.4.4-b7d14e80
       -- Started music on hold, class 'sip', on SIP/172.16.4.4-b7d14e80
       -- Executing [0451@mt_thorium:1] Macro("SIP/garrish-b7d11bb8", "stdexten|0451|SIP/utano") in new stack
   -- Executing [s@macro-stdexten:1]     -- Goto (macro-stdexten,s,4)
   -- Executing [s@macro-stdexten:4] Dial("SIP/garrish-b7d11bb8", "SIP/utano|30") in new stack
Extension Changed 0451 new state Ringing for Notify User garrish
   -- Called utano
Extension Changed 0451 new state Ringing for Notify User vince
       -- SIP/utano-08a535f8 answered SIP/garrish-b7d11bb8
Extension Changed 0451 new state InUse for Notify User garrish
   -- Native bridging SIP/garrish-b7d11bb8 and SIP/utano-08a535f8
Extension Changed 0451 new state InUse for Notify User vince
       -- Stopped music on hold on SIP/172.16.4.4-b7d14e80
thorium*CLI>
Disconnected from Asterisk server
Executing last minute cleanups
Asterisk cleanly ending (0).
[root@thorium asterisk]#
By: Ramon Peek-Fares (ramonpeek) 2007-10-08 15:59:28

Well it's almost midnight overhere.. and I'm on my way to bed..
Tommorow I'll try to do some more testing, allthough I'm in Brussels, Belgium at a conference incluiding the next day..(BTW: Kevin Flemming is there too)

I'll be back.. ;-)
By: Ramon Peek-Fares (ramonpeek) 2007-10-09 00:19:51

I've downloaded the new rtp.c and channel.c and attended tranfer is now really working as it should, thanks...

Allthough this works for me,  I wonder why it is not working for Mavince?

So Attended transfer is covered for me now.
But what about Blind Transfer, did you take a look at the traces?
And could you tell me who's really at fault, Asterisk or the Phone?
By: Ramon Peek-Fares (ramonpeek) 2007-10-09 00:20:55

P.S.: I'll do some more testing with this patch on our production system.
So please don't close this issue yet...
By: Mark A Vince (mavince) 2007-10-09 07:38:54

I did not download channel.c I don't think I can just drop it into my stable 1.4.11 like I did with rtp.c... Please advise

Probably why I didn't get the same results as ramonpeek
By: Ramon Peek-Fares (ramonpeek) 2007-10-09 08:58:56

Some more information about the blindtransfer part of this issue;

I just spoke to Kevin Fleming about this issue and he agrees with me that no re-INVITE should be send after a REFER is sent.
He thinks asterisk is doing this because of a timing issue during the handling of reinviting calling party A->C.
Probably we need to check the GOT_REFER flag somewhere else.. (just an idea)
By: Digium Subversion (svnbot) 2007-10-09 09:09:46

Repository: asterisk
Revision: 85093

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r85093 | file | 2007-10-09 09:09:45 -0500 (Tue, 09 Oct 2007) | 4 lines

Don't perform a reinvite if a transfer is in progress.
(issue ASTERISK-10472)
Reported by: ramonpeek

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-10-09 09:10:55

Repository: asterisk
Revision: 85094

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r85094 | file | 2007-10-09 09:10:55 -0500 (Tue, 09 Oct 2007) | 12 lines

Merged revisions 85093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r85093 | file | 2007-10-09 11:30:16 -0300 (Tue, 09 Oct 2007) | 4 lines

Don't perform a reinvite if a transfer is in progress.
(issue ASTERISK-10472)
Reported by: ramonpeek

........

------------------------------------------------------------------------
By: Joshua C. Colp (jcolp) 2007-10-09 09:11:02

ramonpeek: Try the above revision.

mavince: I will have a patch for you shortly.
By: Ramon Peek-Fares (ramonpeek) 2007-10-09 09:59:35

I've tried the patch and that indeed solves the problem!!
Thanks for the help i think this issue is now solved.

However I do see some other issue in the trace with the NOTIFY message that are being send by asterisk twice... which shouldn't happen since there is no active callleg anymore...

Perhaps I need to open a new case for that, right?
By: Joshua C. Colp (jcolp) 2007-10-09 10:05:10

That depends, what exactly is the issue with the NOTIFY packets?
By: Digium Subversion (svnbot) 2007-10-09 12:38:14

Repository: asterisk
Revision: 85155

_U  team/group/CDRfix5/
U   team/group/CDRfix5/CHANGES
U   team/group/CDRfix5/apps/app_adsiprog.c
U   team/group/CDRfix5/apps/app_dial.c
U   team/group/CDRfix5/apps/app_festival.c
U   team/group/CDRfix5/apps/app_minivm.c
U   team/group/CDRfix5/apps/app_zapras.c
U   team/group/CDRfix5/channels/chan_jingle.c
U   team/group/CDRfix5/channels/chan_local.c
U   team/group/CDRfix5/channels/chan_misdn.c
U   team/group/CDRfix5/channels/chan_sip.c
U   team/group/CDRfix5/doc/tex/localchannel.tex
U   team/group/CDRfix5/utils/astman.c
U   team/group/CDRfix5/utils/check_expr.c

------------------------------------------------------------------------
r85155 | murf | 2007-10-09 12:38:13 -0500 (Tue, 09 Oct 2007) | 41 lines

Merged revisions 85094,85097-85098,85140 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r85094 | file | 2007-10-09 08:31:27 -0600 (Tue, 09 Oct 2007) | 12 lines

Merged revisions 85093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r85093 | file | 2007-10-09 11:30:16 -0300 (Tue, 09 Oct 2007) | 4 lines

Don't perform a reinvite if a transfer is in progress.
(issue ASTERISK-10472)
Reported by: ramonpeek

........

................
r85097 | russell | 2007-10-09 09:10:14 -0600 (Tue, 09 Oct 2007) | 8 lines

Add jitterbuffer support for chan_local.  To enable it, you use the 'j' option
in the Dial command.  The 'j' option _must_ be used in conjunction with the 'n'
option.

This feature will allow you to use the existing jitterbuffer implementation to
put a jitterbuffer on incoming SIP calls connecting to Asterisk applications by
putting a local channel in the middle.

................
r85098 | russell | 2007-10-09 09:12:59 -0600 (Tue, 09 Oct 2007) | 2 lines

Note jitterbuffer support for chan_local in CHANGES

................
r85140 | tilghman | 2007-10-09 10:04:41 -0600 (Tue, 09 Oct 2007) | 2 lines

Remove redundant includes (patch by snuffy) (Closes issue ASTERISK-10476)

................

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-10-09 13:54:33

Repository: asterisk
Revision: 85156

_U  team/juggie/NoLossCDR/
U   team/juggie/NoLossCDR/CHANGES
U   team/juggie/NoLossCDR/Makefile
U   team/juggie/NoLossCDR/Makefile.rules
U   team/juggie/NoLossCDR/apps/app_adsiprog.c
U   team/juggie/NoLossCDR/apps/app_dial.c
U   team/juggie/NoLossCDR/apps/app_festival.c
U   team/juggie/NoLossCDR/apps/app_minivm.c
U   team/juggie/NoLossCDR/apps/app_queue.c
U   team/juggie/NoLossCDR/apps/app_zapras.c
U   team/juggie/NoLossCDR/build_tools/prep_tarball
U   team/juggie/NoLossCDR/channels/chan_jingle.c
U   team/juggie/NoLossCDR/channels/chan_local.c
U   team/juggie/NoLossCDR/channels/chan_misdn.c
U   team/juggie/NoLossCDR/channels/chan_sip.c
U   team/juggie/NoLossCDR/channels/chan_zap.c
U   team/juggie/NoLossCDR/configs/jabber.conf.sample
U   team/juggie/NoLossCDR/doc/tex/extensions.tex
U   team/juggie/NoLossCDR/doc/tex/localchannel.tex
U   team/juggie/NoLossCDR/include/asterisk/jabber.h
U   team/juggie/NoLossCDR/include/asterisk/pbx.h
U   team/juggie/NoLossCDR/main/ast_expr2.c
U   team/juggie/NoLossCDR/main/channel.c
U   team/juggie/NoLossCDR/main/db.c
U   team/juggie/NoLossCDR/main/manager.c
U   team/juggie/NoLossCDR/main/pbx.c
U   team/juggie/NoLossCDR/main/rtp.c
U   team/juggie/NoLossCDR/pbx/ael/ael-test/ref.ael-ntest10
U   team/juggie/NoLossCDR/pbx/ael/ael-test/ref.ael-test1
U   team/juggie/NoLossCDR/pbx/ael/ael-test/ref.ael-test18
U   team/juggie/NoLossCDR/pbx/ael/ael-test/ref.ael-test19
U   team/juggie/NoLossCDR/pbx/ael/ael-test/ref.ael-test3
U   team/juggie/NoLossCDR/pbx/ael/ael-test/ref.ael-test5
U   team/juggie/NoLossCDR/pbx/ael/ael-test/ref.ael-test8
U   team/juggie/NoLossCDR/pbx/ael/ael-test/ref.ael-vtest13
U   team/juggie/NoLossCDR/pbx/ael/ael-test/ref.ael-vtest17
U   team/juggie/NoLossCDR/pbx/pbx_ael.c
U   team/juggie/NoLossCDR/res/ael/ael.tab.c
U   team/juggie/NoLossCDR/res/ael/ael.y
U   team/juggie/NoLossCDR/res/ael/pval.c
U   team/juggie/NoLossCDR/res/res_features.c
U   team/juggie/NoLossCDR/res/res_jabber.c
U   team/juggie/NoLossCDR/res/res_limit.c
U   team/juggie/NoLossCDR/utils/astman.c
U   team/juggie/NoLossCDR/utils/check_expr.c
U   team/juggie/NoLossCDR/utils/conf2ael.c
U   team/juggie/NoLossCDR/utils/hashtest2.c

------------------------------------------------------------------------
r85156 | juggie | 2007-10-09 13:54:32 -0500 (Tue, 09 Oct 2007) | 149 lines

Merged revisions 84336,84380,84414,84447,84489,84521,84558,84591,84618,84647,84676,84703,84731,84753,84795,84828,84862,84901,84934,84944,84967,85000,85034,85067,85107,85155 via svnmerge from
https://origsvn.digium.com/svn/asterisk/team/group/CDRfix5

................
r84336 | root | 2007-10-01 19:50:25 -0400 (Mon, 01 Oct 2007) | 1 line

automerge commit
................
r84380 | root | 2007-10-02 10:51:57 -0400 (Tue, 02 Oct 2007) | 1 line

automerge commit
................
r84414 | root | 2007-10-02 14:54:27 -0400 (Tue, 02 Oct 2007) | 1 line

automerge commit
................
r84447 | root | 2007-10-02 15:05:14 -0400 (Tue, 02 Oct 2007) | 1 line

automerge commit
................
r84489 | root | 2007-10-02 16:52:18 -0400 (Tue, 02 Oct 2007) | 1 line

automerge commit
................
r84521 | root | 2007-10-03 11:16:13 -0400 (Wed, 03 Oct 2007) | 1 line

automerge commit
................
r84558 | root | 2007-10-03 15:15:01 -0400 (Wed, 03 Oct 2007) | 1 line

automerge commit
................
r84591 | root | 2007-10-03 19:15:04 -0400 (Wed, 03 Oct 2007) | 1 line

automerge commit
................
r84618 | root | 2007-10-03 22:14:18 -0400 (Wed, 03 Oct 2007) | 1 line

automerge commit
................
r84647 | root | 2007-10-04 11:15:10 -0400 (Thu, 04 Oct 2007) | 1 line

automerge commit
................
r84676 | root | 2007-10-04 13:14:22 -0400 (Thu, 04 Oct 2007) | 1 line

automerge commit
................
r84703 | root | 2007-10-04 18:15:13 -0400 (Thu, 04 Oct 2007) | 1 line

automerge commit
................
r84731 | root | 2007-10-04 19:14:25 -0400 (Thu, 04 Oct 2007) | 1 line

automerge commit
................
r84753 | root | 2007-10-04 22:15:12 -0400 (Thu, 04 Oct 2007) | 1 line

automerge commit
................
r84795 | root | 2007-10-05 13:15:18 -0400 (Fri, 05 Oct 2007) | 1 line

automerge commit
................
r84828 | root | 2007-10-05 15:15:14 -0400 (Fri, 05 Oct 2007) | 1 line

automerge commit
................
r84862 | root | 2007-10-05 16:15:16 -0400 (Fri, 05 Oct 2007) | 1 line

automerge commit
................
r84901 | root | 2007-10-07 12:15:32 -0400 (Sun, 07 Oct 2007) | 1 line

automerge commit
................
r84934 | root | 2007-10-07 12:22:13 -0400 (Sun, 07 Oct 2007) | 1 line

automerge commit
................
r84944 | root | 2007-10-07 13:14:34 -0400 (Sun, 07 Oct 2007) | 1 line

automerge commit
................
r84967 | root | 2007-10-08 00:15:22 -0400 (Mon, 08 Oct 2007) | 1 line

automerge commit
................
r85000 | root | 2007-10-08 11:15:24 -0400 (Mon, 08 Oct 2007) | 1 line

automerge commit
................
r85034 | root | 2007-10-08 12:15:23 -0400 (Mon, 08 Oct 2007) | 1 line

automerge commit
................
r85067 | root | 2007-10-08 16:15:25 -0400 (Mon, 08 Oct 2007) | 1 line

automerge commit
................
r85107 | root | 2007-10-09 11:15:33 -0400 (Tue, 09 Oct 2007) | 1 line

automerge cancel
................
r85155 | murf | 2007-10-09 13:58:43 -0400 (Tue, 09 Oct 2007) | 41 lines

Merged revisions 85094,85097-85098,85140 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r85094 | file | 2007-10-09 08:31:27 -0600 (Tue, 09 Oct 2007) | 12 lines

Merged revisions 85093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r85093 | file | 2007-10-09 11:30:16 -0300 (Tue, 09 Oct 2007) | 4 lines

Don't perform a reinvite if a transfer is in progress.
(issue ASTERISK-10472)
Reported by: ramonpeek

........

................
r85097 | russell | 2007-10-09 09:10:14 -0600 (Tue, 09 Oct 2007) | 8 lines

Add jitterbuffer support for chan_local.  To enable it, you use the 'j' option
in the Dial command.  The 'j' option _must_ be used in conjunction with the 'n'
option.

This feature will allow you to use the existing jitterbuffer implementation to
put a jitterbuffer on incoming SIP calls connecting to Asterisk applications by
putting a local channel in the middle.

................
r85098 | russell | 2007-10-09 09:12:59 -0600 (Tue, 09 Oct 2007) | 2 lines

Note jitterbuffer support for chan_local in CHANGES

................
r85140 | tilghman | 2007-10-09 10:04:41 -0600 (Tue, 09 Oct 2007) | 2 lines

Remove redundant includes (patch by snuffy) (Closes issue ASTERISK-10476)

................

................

------------------------------------------------------------------------
By: Ramon Peek-Fares (ramonpeek) 2007-10-09 17:20:57

I've uploaded a new trace "Notify-trace.zip"
This trace shows that after the refer 2 NOTIFY messages are being send.
This is correct..

However after these messages have been acknolegde asterisk retransmits these packages several times, and that's not right.
By: Mark A Vince (mavince) 2007-10-11 21:15:55

I loaded 1.4.13 last night. Using Polycom 600 phones, I can initiate an attended transfer to a third phone (A->B->C) A goes on Hold and B<->C are sending two way RTP. When I press the Transfer button again to connect A<->C, the call disconnects. It appears that the attended transfer fails right after a 491 between network and Asterisk server. Asterisk sends a BYE to disconnect the call.

Blind transfer works. The difference appears to be a matter of timing between SIP INVITES. Will report more tomorrow.

Conferencing work fine as well.

file - Should this problem continue under this issue or should another bug report be created.
By: Joshua C. Colp (jcolp) 2007-11-02 09:50:48

Please give the patch in 10946 a try. It seems as though the NOTIFY being sent to give status on the transfer is confusing chan_sip.
By: Ramon Peek-Fares (ramonpeek) 2007-11-05 07:31:03.000-0600

I've tried the proposed patch in issue 10946 and it indeed solves the issue of the multiple SIP NOTIFY messages being send after REFER.

However I have to agree with the author of the patch if this is the right way??
And if there are any side effects??

Perhalps Olle could shed some light on that question?
By: Digium Subversion (svnbot) 2007-11-07 19:09:31.000-0600

Repository: asterisk
Revision: 89097

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r89097 | file | 2007-11-07 19:09:28 -0600 (Wed, 07 Nov 2007) | 8 lines

Add support for allowing one outgoing transaction. This means if a response comes back out of order chan_sip will still handle it. I dream of a chan_sip with real transaction support.
(closes issue ASTERISK-10498)
Reported by: flefoll
(closes issue ASTERISK-10472)
Reported by: ramonpeek
(closes issue ASTERISK-9288)
Reported by: atca_pres

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-11-07 19:12:35.000-0600

Repository: asterisk
Revision: 89098

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r89098 | file | 2007-11-07 19:12:34 -0600 (Wed, 07 Nov 2007) | 16 lines

Merged revisions 89097 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r89097 | file | 2007-11-07 21:11:25 -0400 (Wed, 07 Nov 2007) | 8 lines

Add support for allowing one outgoing transaction. This means if a response comes back out of order chan_sip will still handle it. I dream of a chan_sip with real transaction support.
(closes issue ASTERISK-10498)
Reported by: flefoll
(closes issue ASTERISK-10472)
Reported by: ramonpeek
(closes issue ASTERISK-9288)
Reported by: atca_pres

........

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-11-09 10:34:34.000-0600

Repository: asterisk
Revision: 89131

_U  team/file/t38fun/
U   team/file/t38fun/apps/app_queue.c
U   team/file/t38fun/apps/app_voicemail.c
U   team/file/t38fun/cdr/cdr_tds.c
U   team/file/t38fun/channels/chan_sip.c
U   team/file/t38fun/codecs/codec_zap.c
U   team/file/t38fun/configs/extensions.ael.sample
U   team/file/t38fun/configs/res_odbc.conf.sample
U   team/file/t38fun/doc/valgrind.txt
U   team/file/t38fun/include/asterisk/lock.h
U   team/file/t38fun/main/config.c
U   team/file/t38fun/main/manager.c
U   team/file/t38fun/main/say.c
U   team/file/t38fun/main/srv.c
U   team/file/t38fun/main/tdd.c
U   team/file/t38fun/pbx/pbx_ael.c
U   team/file/t38fun/res/res_jabber.c
U   team/file/t38fun/res/res_musiconhold.c

------------------------------------------------------------------------
r89131 | file | 2007-11-09 10:34:31 -0600 (Fri, 09 Nov 2007) | 168 lines

Merged revisions 89032,89036-89037,89042,89045-89046,89053,89079,89085,89088,89090,89093,89095,89097,89099,89101,89103,89105,89111,89115,89119,89125 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r89032 | file | 2007-11-06 13:08:05 -0400 (Tue, 06 Nov 2007) | 4 lines

Make it so that if a peer is determined to be unreachable using qualify their devicestate will report back unavailable.
(closes issue ASTERISK-10551)
Reported by: pj

........
r89036 | murf | 2007-11-06 13:52:50 -0400 (Tue, 06 Nov 2007) | 1 line

closes issue ASTERISK-8547 - where the [catname](!) and [catname](othercat1,othercat2,...) notation gets dropped across a ConfigUpdate (or any other thing that would cause a config file to be written). While I was at it, I also cleaned up some of the destroy routines to free up comments, which was not being done. Made sure the new struct I introduced is also cleaned up properly at destruction time. My code handles multiple template inclusions. Many thanks to ssokol for his patch, which, while not literally used in the final merge, served as a foundation for the fix.
........
r89037 | russell | 2007-11-06 14:20:07 -0400 (Tue, 06 Nov 2007) | 11 lines

If someone were to delete the files used by an existing MOH class, and then
issue a reload, further use of that class could result in a crash due to
dividing by zero.  This set of changes fixes up some places to prevent this
from happening.

(closes issue ASTERISK-10500)
Reported by: jcomellas
Patches:
     res_musiconhold_division_by_zero.patch uploaded by jcomellas (license 282)
 Additional changes added by me.

........
r89042 | oej | 2007-11-06 14:53:37 -0400 (Tue, 06 Nov 2007) | 2 lines

Bug fixes to tdd support in zaptel.

........
r89045 | tilghman | 2007-11-06 15:09:06 -0400 (Tue, 06 Nov 2007) | 2 lines

We went to the trouble of creating a method of tracking failed trylocks, then never turned it on (oops).

........
r89046 | qwell | 2007-11-06 15:09:30 -0400 (Tue, 06 Nov 2007) | 4 lines

Correctly set the total number of channels from a zaptel transcoder board.

SPD-49, patch by Matthew Nicholson.

........
r89053 | russell | 2007-11-06 16:18:49 -0400 (Tue, 06 Nov 2007) | 3 lines

Fix init_classes() so that classes that actually do have files loaded aren't
treated as empty, and immediately destroyed ...

........
r89079 | tilghman | 2007-11-07 00:07:49 -0400 (Wed, 07 Nov 2007) | 5 lines

Suppress AEL warnings on load.
Reported by: eliel
Patch by: eliel
Closes issue ASTERISK-10703

........
r89085 | mmichelson | 2007-11-07 11:56:49 -0400 (Wed, 07 Nov 2007) | 5 lines

Fixing a segfault in the manager "core show channels concise" command.

(closes issue ASTERISK-10708, reported by arnd and patched by ys)


........
r89088 | murf | 2007-11-07 17:40:28 -0400 (Wed, 07 Nov 2007) | 1 line

In response to 10578, I just ran 1.4 thru valgrind; some of the config leakage I've already fixed, but it doesn't hurt to double check. I found and fixed leaks in res_jabber, cdr_tds, pbx_ael. Nothing major, tho.
........
r89090 | mmichelson | 2007-11-07 18:40:35 -0400 (Wed, 07 Nov 2007) | 6 lines

This patch makes it possible for SIP phones to dial extensions defined with '#' characters
in extensions.conf AND maintain their escaped characters when forming URI's

(closes issue ASTERISK-10265, reported by cahen, patched by me, code review by file)


........
r89093 | tilghman | 2007-11-07 19:39:37 -0400 (Wed, 07 Nov 2007) | 7 lines

The member refcount must be incremented, to avoid using it after deallocation.
A huge thanks go to lvl- for patiently providing the necessary valgrind output
that was necessary to finding this problem of memory corruption.
Reported by: lvl-
Patch by: tilghman
Closes issue ASTERISK-10699

........
r89095 | file | 2007-11-07 19:53:25 -0400 (Wed, 07 Nov 2007) | 4 lines

If callerid is configured in sip.conf use that for checking the presence of an extension in the dialplan.
(closes issue ASTERISK-10710)
Reported by: spditner

........
r89097 | file | 2007-11-07 21:11:25 -0400 (Wed, 07 Nov 2007) | 8 lines

Add support for allowing one outgoing transaction. This means if a response comes back out of order chan_sip will still handle it. I dream of a chan_sip with real transaction support.
(closes issue ASTERISK-10498)
Reported by: flefoll
(closes issue ASTERISK-10472)
Reported by: ramonpeek
(closes issue ASTERISK-9288)
Reported by: atca_pres

........
r89099 | file | 2007-11-07 21:28:56 -0400 (Wed, 07 Nov 2007) | 6 lines

Improve the devicestate logic for multiple devices. If any are available then the extension is considered available.
(closes issue ASTERISK-9843)
Reported by: nic_bellamy
Patches:
     sip-hinting-svn-branch-1.4.patch uploaded by nic (license 299)

........
r89101 | file | 2007-11-07 22:26:48 -0400 (Wed, 07 Nov 2007) | 4 lines

Do not add a sip: to the beginning of the To URI unless needed.
(closes issue ASTERISK-10331)
Reported by: goestelecom

........
r89103 | tilghman | 2007-11-08 00:55:19 -0400 (Thu, 08 Nov 2007) | 2 lines

Typo

........
r89105 | kpfleming | 2007-11-08 01:26:47 -0400 (Thu, 08 Nov 2007) | 2 lines

fix a glaring bug in the new SRV record handling that would cause incorrect weight sorting

........
r89111 | mmichelson | 2007-11-08 12:47:23 -0400 (Thu, 08 Nov 2007) | 5 lines

I made this same adjustment in trunk to fix a bug, and it makes sense to do it in 1.4 as
well. If an imapfolder is specified in voicemail.conf, don't ever explicitly connect to
INBOX since it may not exist.


........
r89115 | qwell | 2007-11-08 14:45:15 -0400 (Thu, 08 Nov 2007) | 4 lines

Avoid warnings on load when using sample configuration files.

Issue 11195, patch by eliel.

........
r89119 | mmichelson | 2007-11-08 17:00:08 -0400 (Thu, 08 Nov 2007) | 7 lines

Rework of the commit I made yesterday to use the already built-in
ast_uri_decode function as opposed to my home-rolled one. Also added
comments.

Thanks to oej for pointing me in the right direction


........
r89125 | qwell | 2007-11-08 19:52:35 -0400 (Thu, 08 Nov 2007) | 4 lines

Properly say the seconds here..

Issue 11203, fix described by vma.

........

------------------------------------------------------------------------