[Home]

Summary:ASTERISK-12832: [patch] Potential spiral detected problem
Reporter:Martin Vit (festr)Labels:
Date Opened:2008-10-06 16:38:12Date Closed:2009-06-03 10:51:14
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 13630_temporary.1.6.uri_match_too.patch
( 1) 13630_temporary.patch
( 2) 13630.patch
( 3) call_forward_trunk1.diff
Description:I'm testing OpenSER (kamailio 1.4) and asterisk 1.4. Call is coming from PSTN -> Asterisk A -> OpenSER ---> back to asterisk A. When the first INVITE comes to OpenSER, I'm rewriting RURI and sends the INVITE back to the same Asterisk (simple Call forward). And this does not work.

From asterisk debug:
chan_sip.c handle_request_invite: Asterisk Potential spiral detected. Original RURI was sip:222352038@openser, new RURI is sip:11114@AsteriskA
chan_sip.c create_addr: No such host: 11114

As you see, there is problem that 11114 is treat as peerorhost and the code in chan_sip.c below this debug prints: create_addr(p, peerorhost);



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

I've collected relevant data from sip debug. (lines must not corespond to 1.4.22 version, i'm testing it on my slightly modified chan_sip.c but the result is same as vanilla 1.4.22)








Asterisk -> kamailio initial invite
--------------------

Reliably Transmitting (no NAT) to kamailio:5060:
INVITE sip:222352038@kamailio SIP/2.0
Via: SIP/2.0/UDP AsteriskA:5060;branch=z9hG4bK214e42e9;rport
From: "unknown" <sip:kamtest@lam.cz>;tag=as105a2893
To: <sip:222352038@kamailio>
Contact: <sip:kamtest@AsteriskA>
Call-ID: 563895d164e5fd0d2989a424337842aa@lam.cz
CSeq: 102 INVITE
User-Agent: LAM PBX
Max-Forwards: 70
Date: Tue, 07 Oct 2008 05:46:00 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 262

kamailio -> asterisk response
-----------------------------

<--- SIP read from kamailio:5060 --->
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP AsteriskA:5060;branch=z9hG4bK214e42e9;rport=5060
From: "unknown" <sip:kamtest@lam.cz>;tag=as105a2893
To: <sip:222352038@kamailio>
Call-ID: 563895d164e5fd0d2989a424337842aa@lam.cz
CSeq: 102 INVITE
Server: Kamailio (1.4.1-tls (i386/linux))
Content-Length: 0

kamailio -> asterisk new INVITE (rewrited RURI)
-----------------------------------------------

<--- SIP read from kamailio:5060 --->
INVITE sip:11114@AsteriskA SIP/2.0
Via: SIP/2.0/UDP kamailio;branch=z9hG4bKc155.da80fcf4.0
Via: SIP/2.0/UDP AsteriskA:5060;branch=z9hG4bK214e42e9;rport=5060
From: "test" <sip:222352038@kamailio>;tag=as105a2893
To: <sip:222352038@kamailio>
Contact: <sip:kamtest@AsteriskA>
Call-ID: 563895d164e5fd0d2989a424337842aa@lam.cz
CSeq: 102 INVITE
User-Agent: LAM PBX
Max-Forwards: 69
Date: Tue, 07 Oct 2008 05:46:00 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 262
<------------->
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 0: INVITE sip:11114@AsteriskA SIP/2.0 (39)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 1: Via: SIP/2.0/UDP kamailio;branch=z9hG4bKc155.da80fcf4.0 (61)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 2: Via: SIP/2.0/UDP AsteriskA:5060;branch=z9hG4bK214e42e9;rport=5060 (70)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 3: From: "test" <sip:222352038@kamailio>;tag=as105a2893 (58)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 4: To: <sip:222352038@kamailio> (34)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 5: Contact: <sip:kamtest@AsteriskA> (37)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 6: Call-ID: 563895d164e5fd0d2989a424337842aa@lam.cz (48)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 7: CSeq: 102 INVITE (16)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 8: User-Agent: LAM PBX (19)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 9: Max-Forwards: 69 (16)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 10: Date: Tue, 07 Oct 2008 05:46:00 GMT (35)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 11: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY (66)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 12: Supported: replaces (19)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 13: Content-Type: application/sdp (29)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 14: Content-Length: 262 (19)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 15:  (0)
...
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4665 find_call: = Found Their Call ID: 563895d164e5fd0d2989a424337842aa@lam.cz Their Tag  Our tag: as105a2893
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:15754 handle_request: **** Received INVITE (5) - Command in SIP INVITE
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:1721 parse_sip_options: Begin: parsing SIP "Supported: replaces"
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:1729 parse_sip_options: Found SIP option: -replaces-
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:1735 parse_sip_options: Matched SIP option: replaces
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:14177 handle_request_invite: Potential spiral detected. Original RURI was sip:222352038@kamailio, new RURI is sip:11114@AsteriskA
[Oct  7 05:46:00] WARNING[6512]: chan_sip.c:2949 create_addr: No such host: 11114


asterisk -> kamailio new INVITE (this is bad invite with bad number and host)
-------------------------------------------------------------------------------

Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:1662 initialize_initreq: Initializing already initialized SIP dialog 563895d164e5fd0d2989a424337842aa@lam.cz (presumably reinvite)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 0: INVITE sip:222352038@kamailio SIP/2.0 (43)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 1: Via: SIP/2.0/UDP AsteriskA:5060;branch=z9hG4bK69e86331;rport (65)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 2: From: "unknown" <sip:kamtest@lam.cz>;tag=as105a2893 (51)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 3: To: <sip:222352038@kamailio> (34)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 4: Contact: <sip:kamtest@AsteriskA> (37)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 5: Call-ID: 563895d164e5fd0d2989a424337842aa@lam.cz (48)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 6: CSeq: 103 INVITE (16)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 7: User-Agent: LAM PBX (19)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 8: Max-Forwards: 70 (16)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 9: Date: Tue, 07 Oct 2008 05:46:00 GMT (35)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 10: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY (66)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 11: Supported: replaces (19)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 12: Content-Type: application/sdp (29)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 13: Content-Length: 262 (19)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4875 parse_request: Header 14:  (0)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: v=0 (3)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: o=root 6551 6552 IN IP4 AsteriskA (38)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: s=session (9)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: c=IN IP4 AsteriskA (23)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: t=0 0 (5)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: m=audio 18052 RTP/AVP 8 3 0 101 (31)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: a=rtpmap:8 PCMA/8000 (20)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: a=rtpmap:3 GSM/8000 (19)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: a=rtpmap:0 PCMU/8000 (20)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: a=rtpmap:101 telephone-event/8000 (33)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: a=fmtp:101 0-16 (15)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: a=ptime:20 (10)
[Oct  7 05:46:00] DEBUG[6512]: chan_sip.c:4907 parse_request: Line: a=sendrecv (10)
Reliably Transmitting (no NAT) to kamailio:5060:
INVITE sip:222352038@kamailio SIP/2.0
Via: SIP/2.0/UDP AsteriskA:5060;branch=z9hG4bK69e86331;rport
From: "unknown" <sip:kamtest@lam.cz>;tag=as105a2893
To: <sip:222352038@kamailio>
Contact: <sip:kamtest@AsteriskA>
Call-ID: 563895d164e5fd0d2989a424337842aa@lam.cz
CSeq: 103 INVITE
User-Agent: LAM PBX
Max-Forwards: 70
Date: Tue, 07 Oct 2008 05:46:00 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 262
Comments:By: Mark Michelson (mmichelson) 2008-10-06 17:25:29

The problem here is that the spiral logic is making an assumption that 11114 is a peer that has registered to Asterisk. Since it is not, we then fall back and see if 11114 is a valid hostname to send the INVITE to. The problem is that we should handle this error condition and instead use the portion after the @ in the RURI to determine where to send the packet. In the worst of circumstances, where the entire RURI is invalid, we should respond with a 404.

I will work on a patch for this.
By: Mark Michelson (mmichelson) 2008-10-06 17:30:07

I have removed the patch since it did not compile.


By: Mark Michelson (mmichelson) 2008-10-06 17:37:14

I have uploaded 13630.patch.

While it is untested, I do hope it will solve the issue for you. Please test it and report results. Thank you!
By: Martin Vit (festr) 2008-10-06 18:06:11

And what if the invite is for us(asterisk)? (route to DAHDI for example).

I'll check this patch tomorrow. Thanks.
By: Martin Vit (festr) 2008-10-07 02:57:00

I've tested the patch. Warning about peer host is gone but invite is still behaving weired

[Oct  7 16:06:49] DEBUG[7021]: chan_sip.c:14179 handle_request_invite: Potential spiral detected. Original RURI was sip:222352038@kamailio, new RURI is sip:11114@AsteriskA
...
[Oct  7 16:06:49] DEBUG[7021]: chan_sip.c:4875 parse_request: Header 0: INVITE sip:222352038@AsteriskA SIP/2.0 (43)

asterisk is sending invite to itself with Original RURI and bad things happen (another loops detected)
By: Mark Michelson (mmichelson) 2008-10-07 09:21:11

Ah, I see what you're saying now. 11114@AsteriskA describes an extension in the dialplan to dial out some other technology. I'll work on a patch to address this.
By: Martin Vit (festr) 2008-10-07 09:39:38

exactly.
By: Mark Michelson (mmichelson) 2008-10-13 14:55:16

I'm changing this back to assigned from "ready for testing" since I misunderstood the problem somewhat when writing the first patch. This is going to require a lot more thought and testing before I can submit a patch.
By: Mark Michelson (mmichelson) 2008-10-14 14:40:40

As a holdover until something "real" can be done here, I'm going to put a patch which should make this work for you. At least it worked here.

The way this works is to set the channel's "call_forward" variable to the new RURI that is in the spiralled INVITE. This works as a more generic version of spiral support and should allow for a call to be spiralled to a non-SIP technology.

Since this essentially turns a spiral into a call forward, there are some things to keep in mind about this solution. First, if you are ignoring call forwarding by using the 'i' option for Dial or Queue, then your spirals will not work correctly.

Also, in my tests, I always saw a message about "Remote host can't match request CANCEL ..." This is something that will have to be worked out in future patches.
By: Mark Michelson (mmichelson) 2008-10-14 14:42:45

13630_temporary.patch is a patch which will treat a spiral like a call forward as I described above.
By: Martin Vit (festr) 2008-10-15 11:14:43

This patch works for me. Thank you very much!

debug:

   -- Now forwarding SIP/kamtest-081e2be8 to 'Local/u222352038@gw' (thanks to SIP/gw-081e7f88)

show channels:

Channel              Location             State   Application(Data)
Local/u222352038@gw- u222352038@gw:2      Up      VoiceMail(u222352038)
Local/u222352038@gw- (None)               Up      (None)
SIP/kamtest-081e2be8 222352038@client:1   Up      Dial(SIP/gw/222352038)

it is ok that the call is transfered to Local channel? For me it is not problem but i'm thinking if it is necessary.
By: Leif Madsen (lmadsen) 2009-01-09 14:07:12.000-0600

Marking as Ready for Review as someone tested and says the patch works for them!
By: Walter Schober (walter_s) 2009-02-03 07:37:39.000-0600

Since it didn't work for me I patched chan_sip.c with attached

This patch is for the 1.6.0.5, but should work for 1.4.23 as well.
Any suggestions welcome.  

The idea behind: If the request has no to-tag and we are really
pedantic, let's check the Request URI, too, and, if different put her
into routing (extensions.conf!) again. In my opinion the CallID as a single check for dialog matching is very poor. See chan_sip.c:6070 ff. in find_call().

See also Thread "strange spiral handling in chan_sip" in [asterisk-dev].
By: Leif Madsen (lmadsen) 2009-02-03 08:02:03.000-0600

Marking as "Needs License" until the license is approved. Thanks for your contribution!
By: Olle Johansson (oej) 2009-02-03 14:22:14.000-0600

The code in this part of Asterisk is seriously bad. I am not sure that using a forward makes it better, but it's one solution. If the outbound request forked and we only got one of the forks, the forward might be premature since the other fork might answer before our call is answered.

There are multiple bug reports on similar issues and patches in the bug tracker. This needs serious time and thinking.
By: Leif Madsen (lmadsen) 2009-02-09 13:14:55.000-0600

License submitted and accepted. Thanks!
By: Digium Subversion (svnbot) 2009-05-12 15:28:18

Repository: asterisk
Revision: 193954

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r193954 | mmichelson | 2009-05-12 15:28:18 -0500 (Tue, 12 May 2009) | 18 lines

Update spiral support in trunk and 1.6.X to match what is in 1.4.

In 1.4, a SIP spiral is treated the same way as a call forward. This
works much better than what is currently in trunk and 1.6.X. The code
in trunk and 1.6.X did not create a new call to the recipient of the spiral,
instead trying to continue the same call. In addition to just being plain
wrong, this also had the side effect of only being able to spiral calls
to other SIP channels.

With this in place, as long as call forwards are honored, SIP spirals
will work properly. This means that it will work for outbound calls
made  by the Queue, Dial, and Page applications. For originated calls and
spool calls, however, the spiral will not work properly until a generic
call forward mechanism is introduced into Asterisk.

(relates to issue ASTERISK-12832)


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

http://svn.digium.com/view/asterisk?view=rev&revision=193954
By: Digium Subversion (svnbot) 2009-05-12 15:50:35

Repository: asterisk
Revision: 193960

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r193960 | mmichelson | 2009-05-12 15:50:35 -0500 (Tue, 12 May 2009) | 24 lines

Merged revisions 193954 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r193954 | mmichelson | 2009-05-12 15:28:13 -0500 (Tue, 12 May 2009) | 18 lines
 
 Update spiral support in trunk and 1.6.X to match what is in 1.4.
 
 In 1.4, a SIP spiral is treated the same way as a call forward. This
 works much better than what is currently in trunk and 1.6.X. The code
 in trunk and 1.6.X did not create a new call to the recipient of the spiral,
 instead trying to continue the same call. In addition to just being plain
 wrong, this also had the side effect of only being able to spiral calls
 to other SIP channels.
 
 With this in place, as long as call forwards are honored, SIP spirals
 will work properly. This means that it will work for outbound calls
 made  by the Queue, Dial, and Page applications. For originated calls and
 spool calls, however, the spiral will not work properly until a generic
 call forward mechanism is introduced into Asterisk.
 
 (relates to issue ASTERISK-12832)
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=193960
By: Digium Subversion (svnbot) 2009-05-12 15:51:10

Repository: asterisk
Revision: 193961

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r193961 | mmichelson | 2009-05-12 15:51:10 -0500 (Tue, 12 May 2009) | 24 lines

Merged revisions 193954 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r193954 | mmichelson | 2009-05-12 15:28:13 -0500 (Tue, 12 May 2009) | 18 lines
 
 Update spiral support in trunk and 1.6.X to match what is in 1.4.
 
 In 1.4, a SIP spiral is treated the same way as a call forward. This
 works much better than what is currently in trunk and 1.6.X. The code
 in trunk and 1.6.X did not create a new call to the recipient of the spiral,
 instead trying to continue the same call. In addition to just being plain
 wrong, this also had the side effect of only being able to spiral calls
 to other SIP channels.
 
 With this in place, as long as call forwards are honored, SIP spirals
 will work properly. This means that it will work for outbound calls
 made  by the Queue, Dial, and Page applications. For originated calls and
 spool calls, however, the spiral will not work properly until a generic
 call forward mechanism is introduced into Asterisk.
 
 (relates to issue ASTERISK-12832)
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=193961
By: Digium Subversion (svnbot) 2009-05-12 15:51:28

Repository: asterisk
Revision: 193962

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r193962 | mmichelson | 2009-05-12 15:51:28 -0500 (Tue, 12 May 2009) | 24 lines

Merged revisions 193954 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r193954 | mmichelson | 2009-05-12 15:28:13 -0500 (Tue, 12 May 2009) | 18 lines
 
 Update spiral support in trunk and 1.6.X to match what is in 1.4.
 
 In 1.4, a SIP spiral is treated the same way as a call forward. This
 works much better than what is currently in trunk and 1.6.X. The code
 in trunk and 1.6.X did not create a new call to the recipient of the spiral,
 instead trying to continue the same call. In addition to just being plain
 wrong, this also had the side effect of only being able to spiral calls
 to other SIP channels.
 
 With this in place, as long as call forwards are honored, SIP spirals
 will work properly. This means that it will work for outbound calls
 made  by the Queue, Dial, and Page applications. For originated calls and
 spool calls, however, the spiral will not work properly until a generic
 call forward mechanism is introduced into Asterisk.
 
 (relates to issue ASTERISK-12832)
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=193962
By: Digium Subversion (svnbot) 2009-06-02 16:17:50

Repository: asterisk
Revision: 198856

U   trunk/include/asterisk/channel.h
U   trunk/main/channel.c
U   trunk/main/features.c

------------------------------------------------------------------------
r198856 | dvossel | 2009-06-02 16:17:50 -0500 (Tue, 02 Jun 2009) | 10 lines

Generic call forward api, ast_call_forward()

The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string.  After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one.  I have included this api call in both channel.c's ast_request_and_dial() and feature.c's feature_request_and_dial().  App_dial and app_queue already contain call forward logic specific for their application and options.

(closes issue ASTERISK-12832)
Reported by: festr

Review: https://reviewboard.asterisk.org/r/271/


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

http://svn.digium.com/view/asterisk?view=rev&revision=198856
By: Digium Subversion (svnbot) 2009-06-03 10:24:51

Repository: asterisk
Revision: 198886

_U  branches/1.6.2/
U   branches/1.6.2/include/asterisk/channel.h
U   branches/1.6.2/main/channel.c
U   branches/1.6.2/main/features.c

------------------------------------------------------------------------
r198886 | dvossel | 2009-06-03 10:24:50 -0500 (Wed, 03 Jun 2009) | 16 lines

Merged revisions 198856 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r198856 | dvossel | 2009-06-02 16:17:49 -0500 (Tue, 02 Jun 2009) | 10 lines
 
 Generic call forward api, ast_call_forward()
 
 The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string.  After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one.  I have included this api call in both channel.c's ast_request_and_dial() and feature.c's feature_request_and_dial().  App_dial and app_queue already contain call forward logic specific for their application and options.
 
 (closes issue ASTERISK-12832)
 Reported by: festr
 
 Review: https://reviewboard.asterisk.org/r/271/
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=198886
By: Digium Subversion (svnbot) 2009-06-03 10:26:16

Repository: asterisk
Revision: 198887

_U  branches/1.6.1/
U   branches/1.6.1/include/asterisk/channel.h
U   branches/1.6.1/main/channel.c
U   branches/1.6.1/main/features.c

------------------------------------------------------------------------
r198887 | dvossel | 2009-06-03 10:26:16 -0500 (Wed, 03 Jun 2009) | 16 lines

Merged revisions 198856 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r198856 | dvossel | 2009-06-02 16:17:49 -0500 (Tue, 02 Jun 2009) | 10 lines
 
 Generic call forward api, ast_call_forward()
 
 The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string.  After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one.  I have included this api call in both channel.c's ast_request_and_dial() and feature.c's feature_request_and_dial().  App_dial and app_queue already contain call forward logic specific for their application and options.
 
 (closes issue ASTERISK-12832)
 Reported by: festr
 
 Review: https://reviewboard.asterisk.org/r/271/
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=198887
By: Digium Subversion (svnbot) 2009-06-03 10:27:31

Repository: asterisk
Revision: 198889

_U  branches/1.6.0/
U   branches/1.6.0/include/asterisk/channel.h
U   branches/1.6.0/main/channel.c
U   branches/1.6.0/main/features.c

------------------------------------------------------------------------
r198889 | dvossel | 2009-06-03 10:27:30 -0500 (Wed, 03 Jun 2009) | 16 lines

Merged revisions 198856 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r198856 | dvossel | 2009-06-02 16:17:49 -0500 (Tue, 02 Jun 2009) | 10 lines
 
 Generic call forward api, ast_call_forward()
 
 The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string.  After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one.  I have included this api call in both channel.c's ast_request_and_dial() and feature.c's feature_request_and_dial().  App_dial and app_queue already contain call forward logic specific for their application and options.
 
 (closes issue ASTERISK-12832)
 Reported by: festr
 
 Review: https://reviewboard.asterisk.org/r/271/
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=198889
By: Digium Subversion (svnbot) 2009-06-03 10:49:47

Repository: asterisk
Revision: 198891

U   branches/1.4/include/asterisk/channel.h
U   branches/1.4/main/channel.c
U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r198891 | dvossel | 2009-06-03 10:49:46 -0500 (Wed, 03 Jun 2009) | 10 lines

Generic call forward api, ast_call_forward()

The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string.  After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one.  I have included this api call in both channel.c's ast_request_and_dial() and res_feature.c's feature_request_and_dial().  App_dial and app_queue already contain call forward logic specific for their application and options.

(closes issue ASTERISK-12832)
Reported by: festr

Review: https://reviewboard.asterisk.org/r/271/


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

http://svn.digium.com/view/asterisk?view=rev&revision=198891
By: Digium Subversion (svnbot) 2009-06-03 10:51:11

Repository: asterisk
Revision: 198892

_U  trunk/

------------------------------------------------------------------------
r198892 | dvossel | 2009-06-03 10:51:11 -0500 (Wed, 03 Jun 2009) | 15 lines

Blocked revisions 198891 via svnmerge

........
 r198891 | dvossel | 2009-06-03 10:49:46 -0500 (Wed, 03 Jun 2009) | 10 lines
 
 Generic call forward api, ast_call_forward()
 
 The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string.  After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one.  I have included this api call in both channel.c's ast_request_and_dial() and res_feature.c's feature_request_and_dial().  App_dial and app_queue already contain call forward logic specific for their application and options.
 
 (closes issue ASTERISK-12832)
 Reported by: festr
 
 Review: https://reviewboard.asterisk.org/r/271/
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=198892