Summary:ASTERISK-03954: [patch] Allow transfers to a different server
Reporter:jshugart (jshugart)Labels:
Date Opened:2005-04-19 15:20:45Date Closed:2008-01-15 15:37:57.000-0600
Versions:Frequency of
Environment:Attachments:( 0) chan_sip.c.20050426.diff
( 1) chan_sip.c.20050602.diff
( 2) chan_sip.c.20050606.diff
Description:I have found the it useful to be able to transfer SIP calls to different servers.  I do this by allowing the transfer number to contain an @.  So to transfer a call after answering it I would do
I have submitted signed the disclaimer and have submitted a couple of patches in the past.
Comments:By: Brian West (bkw918) 2005-04-19 15:24:24

This is so not the right way to do it.. Why are you not using the dial command to start the transfer?


By: jshugart (jshugart) 2005-04-19 17:33:36

Using dial would bridge the call, which I do not want to do.  I am using this to play a message and collect digits.  Based on the digits entered and a backend lookup, I send the call to a specified server.  I do not want to take part in the call after this point.  Can this be done using dial?

By: Kevin P. Fleming (kpfleming) 2005-04-21 22:53:16

Can't you just define a SIP peer for this target server and send the call there using normal SIP dial string syntax?

By: Olle Johansson (oej) 2005-04-22 18:44:22

Since we allow transfer to user@domain in ringing state, we should do it in up state as well, I think.

We also need to implement max_forwards the same way as in sip_sipredirect.

By: jshugart (jshugart) 2005-04-26 14:28:09

I have added the max forwards check and uploaded the new patch.

By: Kevin P. Fleming (kpfleming) 2005-04-29 10:47:32

oej: are you OK with this patch? It looks good to me, just wanted a second opinion.

By: Olle Johansson (oej) 2005-06-02 02:57:24

This is recommended for CVS.

By: Olle Johansson (oej) 2005-06-02 02:57:53

Please update patch to latest cvs :-)

By: Olle Johansson (oej) 2005-06-04 07:06:05

Ok, ready for CVS

By: Kevin P. Fleming (kpfleming) 2005-06-05 11:11:39

I don't understand what I'm supposed to do here; the new small patch from oej doesn't have any 'maxforwards' stuff in it, so are we dropping that and just allowing the target to contain an '@', or are these patches cumulative?

By: Olle Johansson (oej) 2005-06-05 16:41:22

I'll check - btw, this is not my patch.

By: Kevin P. Fleming (kpfleming) 2005-06-05 16:54:49

Sorry, I thought you had uploaded the second one... I'll send a reminder to the OP.

By: Kevin P. Fleming (kpfleming) 2005-06-05 16:55:48

There was no bugnote added when you uploaded this new, smaller, patch. Can you let us know what we should do with these two patches? Thanks.

By: jshugart (jshugart) 2005-06-06 13:20:29

Sorry.  I messed everyone up.  I uploaded one piece of the code change.  I have uploaded the new code fix against the latest chan_sip.c.  This patch is almost identical to the original patch, except the strncpy calls have been changed to ast_string_copy.

By: Kevin P. Fleming (kpfleming) 2005-06-09 18:39:26

Committed to CVS HEAD, thanks!

By: Digium Subversion (svnbot) 2008-01-15 15:37:57.000-0600

Repository: asterisk
Revision: 5894

U   trunk/channels/chan_sip.c

r5894 | kpfleming | 2008-01-15 15:37:57 -0600 (Tue, 15 Jan 2008) | 2 lines

allow transfer-to number for SIP transfers to contain an '@' (and enforce the max-forwards restriction for these transfers) (bug ASTERISK-3954)