|Summary:||ASTERISK-02807: [request] Keeping Asterisk in the Channel Path using DUNDi and notransfer=yes|
|Reporter:||Leif Madsen (lmadsen)||Labels:|
|Date Opened:||2004-11-13 18:56:44.000-0600||Date Closed:||2011-06-07 14:05:00|
|Description:||I am trying to create a gateway using DUNDi and IAX2 with the notransfer=yes option. However, it does not work as expected. Here is a quick diagram of my configuration:|
*1 <--------> *2 <------> *3
Asterisk *1 is peered with *2 and in turn peered with *3. The dundi context being advertised from *2 to *1 is different than *3. *2 re-advertises *3 extensions to *1 as reachable at *2. When a call is placed from *1, it does a DUNDiLookup(), and a call is then placed via IAX2 to *2. Once this call comes in, it also does a DUNDiLookup() on the number and sees that it is reachable at *3. I want to keep *2 in the path between *1 and *3 once the call is picked up at *3. I have tried using the notransfer=yes option in iax.conf under the [general] section. Unfortunately the call is still natively bridged.
Here is some output from my *CLI:
This is the output of *2. You can see the call being natively bridged - this is what I would like to try and avoid.
-- Accepting AUTHENTICATED call from 24.141.x.x, requested format = 4, actual format = 4
-- Executing Macro("IAX2firstname.lastname@example.org:4569/1", "dundi-lookup|1601") in new stack
-- Executing DUNDiLookup("IAX2email@example.com:4569/1", "1601|priv") in new stack
-- Executing Dial("IAX2firstname.lastname@example.org:4569/1", "IAX2/dundi:RbNNPJxZVi7oSlY+4FabdQ@142.55.x.64/1601|30|rT") in new stack
-- Called dundi:RbNNPJxZVi7oSlY+4FabdQ@142.55.x.64/1601
-- Call accepted by 142.55.x.64 (format ULAW)
-- Format for call is ULAW
-- IAX2/142.55.x.64:4569/2 is ringing
-- IAX2/142.55.x.64:4569/2 answered IAX2email@example.com:4569/1
-- Attempting native bridge of IAX2firstname.lastname@example.org:4569/1 and IAX2/142.55.x.64:4569/2
-- Hungup 'IAX2/142.55.x.64:4569/2'
Here is the view from *1:
-- Executing Macro("SIP/1000-3dc3", "dundi-lookup|1601") in new stack
-- Executing DUNDiLookup("SIP/1000-3dc3", "1601|scaet") in new stack
-- Executing Dial("SIP/1000-3dc3", "IAX2/sheridan:w1D4c+TVIj3FK0REtXTRAg@scaetb144.sheridanc.on.ca/1601|30|r") in new stack
-- Called sheridan:w1D4c+TVIj3FK0REtXTRAg@x.sheridanc.on.ca/1601
-- Call accepted by 142.55.x.30 (format ULAW)
-- Format for call is ULAW
-- IAX2/142.55.x.30:4569/4 is ringing
-- IAX2/142.55.x.30:4569/4 answered SIP/1000-3dc3
-- Hungup 'IAX2/142.55.x.30:4569/4'
So from *1 view it doesn't look as if it is being bridged, but I see that happening on *2 (the gateway). notransfer=yes has been enabled on all the Asterisk boxes.
****** ADDITIONAL INFORMATION ******
I am doing this for lab testing.
The reason for this setup is that *2 and *3 are on the same local network. Both have external IPs, but traffic going into *2 is not filtered through the packeteer. If the call is natively bridged, then the latency rises to over 3000ms (this is because the IP for *3 is restricted to very low bandwidth unless it talks to *2 - in which case it is locally 100mbit).
|Comments:||By: Brian West (bkw918) 2004-11-13 20:26:20.000-0600|
This is not something dundi would do/be used for. you would only advertise the one box and keep that as the one box that talks to dundi.. then take the call in and send it to box 3 via iax...
By: Brian West (bkw918) 2004-11-13 20:27:17.000-0600
Or better yet.. in dundi.conf on that third box... change the mapping reply to sned it to box 2 instead of 3... then anything thats advertised on box 3 will go ot box 2 instead then box 2 is responsible for sending it to box 3.
By: Leif Madsen (lmadsen) 2004-11-14 10:11:10.000-0600
What I am doing right now is accepting the call on box 2, then opening another Dial statement to call box 3. From my understanding of notransfer=yes, that should work.
I'll give your second suggestion a shot this afternoon and see if that works. I personally think this is something that DUNDi should be able to handle. I can think of several uses for this.
By: Leif Madsen (lmadsen) 2004-11-19 18:38:33.000-0600
I was able to get this working. Thankfully file explained to me what was actually going on during a native transfer. I was under the impression the call was being handed off when that was not the case.
The only bug here was behind the keyboard.
edited on: 11-19-04 18:39
By: Joshua C. Colp (jcolp) 2004-11-19 18:41:46.000-0600
Reporter indicated no problem exists in the first place. Bug closed as a result.