Transfer and release

What I am wanting to do is a call transfer to a new machine and have the call released… Example:

Call comes into BoxA from User1
We want to transfer User1 to BoxB and have BoxA let go of the call.

Does this make sense?

Usr1 - BoxA
BoxA moves it to Boxb
it then becomes
Usr1 - BoxB

When I do dial with blindxfer it goes to BoxB but BoxA is still holding the call.

BoxA: Dialplan
exten => s,1,Answer
exten => s,n,Wait(1)
exten => s,n,SetVar(GOTO_ON_TRANSFER=test1^s^1)
exten => s,n,Dial(SIP/111.11.11.111|60|Tt)

BoxA - features:
[featuremap]
blindxfer => #1
disconnect => *0
;automon => *1 ; One Touch Record
atxfer => *2

BoxB of course just has a typical dialplan options which play fine… it doesnt actually go to test1,s,1 on that machine… but that is fine and really nothing important as of right now.

Anyone have any experience doing this? This is SIP channels as well

ahh, I think you’d have to either use Transfer() (which may or may not work); or you can enable SIP reinvites. reinvite will still have boxa ‘holding’ the call but the voice data will go straight to boxb.

Yeah I’ve tried both of these cases:

[Call-Route1]
exten => s,1,Answer
exten => s,n,Wait(1)
exten => s,n,Set(TRANSFER_CONTEXT=test1^s^1)
exten => s,n,Dial(SIP/xx.xx.xx.xx|60|Tt)
exten => s,n,Hangup

[Call-Route2]
exten => s,1,Answer
exten => s,n,Wait(1)
exten => s,n,Transfer(SIP/xx.xx.xx.xx)
exten => s,n,Hangup

When I use Call-Route1 it does in fact go to boxB but boxA holds on to it still… when I use the second I get:
– Incoming call: Got SIP response 405 “method not allowed” back from myproviderIP"

I am not sure if it’s just my provider who doesnt allow a straight transfer. I am going to contact other providers and see what I can do. It’s frustrating because I am trying to set up a cluster of machines and need to do some routing to the different boxes for load balancing. Is there a better method for this? Or is there a solution out there for handling this?

it’s quite possible your provider may not support transfer. However i am guessing that the transfer() cmd is being formatted wrong, I don’t think you can pass SIP/ in a transfer.

Try Transfer(exten@ipaddy) or Transfer(ipaddy) or Transfer(validphonenumber) and see if any of those work

You were right. Using the TECH/IP was what caused it to error. Changing to the straight IP did the transfer. Thanks for the insight. at least now I know that transfer command does in fact work.

Thanks again for the help. I wish asterisk would release the call then life would be good hahah.

I am curious. If I do an IAX setup between the boxes and have pass to an ext on one of the boxes, if the original call box will still hold on to the call. … just thinking outloud.

If you do transfer, your box1 should release the call… doesn’t it? Use show channels or sip show channels to see if it does…

IAX has a function like sip reinvites, if you have two IAX2 call legs it will send media directly but only if it can. SIP on the other hand will often do so when it can’t which results in one-way audio or no audio.
IAX won’t help you though because you can’t reinvite SIP audio into an IAX2 call leg-

ie
provider – sip – box1 – iax2 – box2

iax reinvite will not help you at all because it cannot reinvite the provider’s audio stream between sip and iax. On the other hand-

provider – sip – box1 – sip – box2
would work with a reinvite, it would reinvite provider to box2 because both are using sip (as i said above) (presuming you have no reason such as NAT to prevent it from doing so).

also

provider – iax2 – box1 – iax2 – box2
would reinvite provider to box2 because both legs are iax2.

That’s what I assumed would happen as well. When I do the transfer it still shows the two call legs in BoxA. I set canreinvite=yes on both sip.conf files. Is there a particular command I need to call in order to have it do the invite?

Iron, thanks again for shedding some light on this. After going round and round on the phone with my provider, they are in fact stopping the call from transferring to the additional IP.

Moving forward with just having a hunt group.

Thanks again.

what a shame :frowning:

You may be able to get the transfer to work by DID, that is transfer it to a valid number… shrug

good luck

I think transfer may work like dial if it’s rejected… that may be what’s happening?

Yeah its returning not allowed.
What happened was yesterday when I thought the transfer worked… I thought I had changed the dialplan to use the transfer , it still used the Dial. After switching it last night and double checking, it was returned “Method not allowed” . I spoke with our SIP carrier and they said it was not permissible by them.

I wanted more control over the routing so that I could set up a decent load balancing scenario while also being able to move calls to our Voxeo system for Voice Rec. After evaluating it, going with a Hunt Group from the carrier seemed logical as the overall number of concurrent calls that we would transfer to our PBX or the Voxeo system would be minimal, so holding on the call should not be that taxing on the over all system.