IAX Blind Transfer issue. Yikes!

sigmaz

Member
Joined
Dec 17, 2010
Messages
100
Reaction score
1
Ok here is todays situation.

I have 2 servers running linked via hamachi.
Everyone is talking..but there are a few bugs I dont understand.

server1: Inbound trunk rings custom ring group 778 which includes all of the local extensions and a custom extension that passes to IAX2/Server2/777 (ring all group)

I'm local to server2 and get the call ringing on my phone..
I receive all the call info including callerID.

I can answer the call and blind transfer it to any of my local extensions however when I try to do a blind transfer back to an extension on server1 where the call originated from the call gets dropped.

I havent been able to test an attended transfer yet but thats not what I'm trying to do.

Any ideas?

Thanks
-jon
 
So, what does the routing from Server2 back to Server1 look like? Can you dial extension to extension from Server2 to Server1? You need to be able to do this first.
 
Yes.. the extensions on server1 and server2 can dial any extension on either server.

extensions on server1 are in the 3xxx range and server2 are 2xxx

The dial patterns are matched and sent down the appropriate IAX2 trunk.
 
Trunk config between these two servers
The host names are the servers as designated in my first post.

trunk name:voip2

host=server1_IP
context=from-internal
secret=123456
trunk=yes
type=friend
username=voip1

Register:voip1:123456@server2_IP
___________________________________


trunk name:voip1

host=server2_IP
context=from-internal
secret=123456
trunk=yes
type=friend
username=voip2

Register:voip2:123456@server2_IP
 
That should work. Can you look at the logs for each server and see what is going on at the time of the transfer?

Edit: You're not transferring back to the ring group 778, are you?
 
Umm, no when I do the transfer I'm punching in to the actual extension I'd like to send it to.

I'll have to RDP into a 7 box and then hit my ESXi Server to get the logs on that side.. I'll see if I can get one of my goons to test it with me later today..
Thanks!
 
I found a while back that when I was trying to make a call loop back going from an extension on server A via a trunk to server B then back on a trunk to server A again and trying to call an extension back in server A - that this did not work. I guessed at the time that asterisk maybe didn't allow it for some reason.
 
So do you think then that it's programmatically refusing the transfer?
 
I'm not sure but it just sounds similar to the problem I had. Are you able to test with the call routing set so that an extension-->extension call would need to route between the servers and back again? I see you have the trunks set so that calls coming in on them land in the from-internal context, so that is not the problem.
 
Im not exactly sure what you're asking me to do?

call a virtual extension locally that routes to a virtual on another box that routes to an actual extension locally?
 
I wonder if this is similar to what we call split-horizon in routing. A route to a destination can't point back in to itself. So if an incoming packet is trying to find the "best" route to a destination, you don't send it back the way it came.

This is just out of the box thinking. Asterisk on Server1 tracks a call and sends it out to server 2. Server2 blind transfers it back to Server1 but server1 is still tracking the original call with an ID number. It sees "a call ID" coming in that should be going out.
 
If you mean to say that split horizon routing at the IP level is a factor here; no, it should not be.

If you mean that there may be something akin to split horizon within Asterisk's call routing functionality(very different from IP routing), I suppose that's possible, though I am unaware of any such functionality.
 
Im not exactly sure what you're asking me to do?

call a virtual extension locally that routes to a virtual on another box that routes to an actual extension locally?

I think what blanchae and astrosmurfer were discussing sounds like an explaination.

You could confirm/eliminate this by doing something like the following:

Say you have two boxes PBX1 and PBX2. PBX1 has a trunk configured to a provider A dialled with outgoing route 9|. and PBX2 also has a trunk with a provider similarly reached via outgoing route 9|.

Say extensions on PBX 1 are numbered 1xx and extensions on PBX2 are numbered 2xx.

You then set up outgoing routes on each PBX to route calls between them so that, say, to dial an extension on B from A you would have 122|. And to dial an extension on PBX 1 from an extension on PBX2 you would dial 221|. So dialling 122200 from a phone on PBX1 should ring extension 200 on PBX2. And dialling 221100 from a phone on PBX2 should ring extension 100 on PBX1.

You can then prove that extensions on PBX 1 can dial out on a trunk from PBX2 by calling 1229[some phone number].

However what I found was the dialling 122221100 from an extension on PBX1 did not work. You might expect ringing this from an extension on PBX1 to call extension 100 back on PBX1. I can;t recall what Asterisk version I was testing when I tried this, so it may have changed in a later version.
 
I think what blanchae and astrosmurfer were discussing sounds like an explaination.

You could confirm/eliminate this by doing something like the following:

Say you have two boxes PBX1 and PBX2. PBX1 has a trunk configured to a provider A dialled with outgoing route 9|. and PBX2 also has a trunk with a provider similarly reached via outgoing route 9|.

Say extensions on PBX 1 are numbered 1xx and extensions on PBX2 are numbered 2xx.

You then set up outgoing routes on each PBX to route calls between them so that, say, to dial an extension on B from A you would have 122|. And to dial an extension on PBX 1 from an extension on PBX2 you would dial 221|. So dialling 122200 from a phone on PBX1 should ring extension 200 on PBX2. And dialling 221100 from a phone on PBX2 should ring extension 100 on PBX1.

You can then prove that extensions on PBX 1 can dial out on a trunk from PBX2 by calling 1229[some phone number].

However what I found was the dialling 122221100 from an extension on PBX1 did not work. You might expect ringing this from an extension on PBX1 to call extension 100 back on PBX1. I can;t recall what Asterisk version I was testing when I tried this, so it may have changed in a later version.
:confused5::confused5:

lol.. just kidding.

I've got ya.. I'll do some testing and get back to you guys.

I just returned from vacation and the workload has go to level out before I can side step.

Thanks for the suggestions.
 
I'm going to thank you guys for helping me out.. I'll revisit this issue f it doesn't clear up after I hammer dundi in place.

I'm hoping that the distributed device states will aid is call routing.

Or I may find myelf in a bigger mess with 4 * servers doing nothing.


wish me luck
 

Members online

Forum statistics

Threads
26,687
Messages
174,411
Members
20,257
Latest member
Dempan
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Back
Top