[Home]

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-0600Date Closed:2011-06-07 14:05:00
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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("IAX2/sheridan@24.141.x.x:4569/1", "dundi-lookup|1601") in new stack
   -- Executing DUNDiLookup("IAX2/sheridan@24.141.x.x:4569/1", "1601|priv") in new stack
   -- Executing Dial("IAX2/sheridan@24.141.x.x: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 IAX2/sheridan@24.141.234.145:4569/1
   -- Attempting native bridge of IAX2/sheridan@24.141.x.x: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...

bkw
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.

bkw
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.