thunderheart
New Member
- Joined
- Oct 30, 2007
- Messages
- 255
- Reaction score
- 0
Ok, so I seem to have DUNDi talking between my two boxes and an outgoing route via a DUNDi trunk landing in the appropriate context to attempt a lookup. I also think the lookup is working ok:
Side ‘A’
[Sep 9 16:05:07] DEBUG[15634] pbx_dundi.c: Registering request for '200@e164' on behalf of '00:00:00:00:00:00' crc '00000000'
[Sep 9 16:05:07] DEBUG[15634] pbx_dundi.c: Will query peer '00:1e:90:c0:ac:45' for '200@e164'
[Sep 9 16:05:07] DEBUG[21538] pbx_dundi.c: Got canonical message 13 (0), 50 bytes data
[Sep 9 16:05:07] DEBUG[21538] pbx_dundi.c: Got canonical message 66 (0), 9 bytes data (Final)
[Sep 9 16:05:07] DEBUG[21538] pbx_dundi.c: Looks like success of some sort (-1), 0 answers
[Sep 9 16:05:07] DEBUG[21538] pbx_dundi.c: Caching hint at 'hint/001E90C0AC45/2/e164/e00000000'
[Sep 9 16:05:07] DEBUG[21538] pbx_dundi.c: Caching hint at 'hint/001E90C0AC45/2/e164/r000000000000'
Side ‘B’
[Sep 9 16:05:07] DEBUG[18603] pbx_dundi.c: Got canonical message 13 (0), 334 bytes data
[Sep 9 16:05:07] DEBUG[18603] pbx_dundi.c: Wow, new key combo passed signature and decrypt!
[Sep 9 16:05:07] DEBUG[18603] pbx_dundi.c: Got canonical message 1 (0), 27 bytes data
[Sep 9 16:05:07] DEBUG[18603] pbx_dundi.c: Answering query for '200@e164'!
[Sep 9 16:05:07] DEBUG[31700] pbx_dundi.c: Whee, looking up '200@e164' for '00:19:db:61:9c:32'
[Sep 9 16:05:07] DEBUG[31700] pbx_dundi.c: Registering request for '200@e164' on behalf of '00:19:db:61:9c:32' crc '00000000'
[Sep 9 16:05:07] DEBUG[31700] pbx_dundi.c: Avoiding '00:19:db:61:9c:32' in transaction
Subsequent calls from "A" to "B" show messages relating to the number being cached so I'd say that part is working. However, the call results in congestion so there must be something wrong with the way the call gets routed to the associated IAX trunk. This doesn't surprise me as I see no association between the DUNDi trunk and the IAX trunk.
Where is that association set and how? The trunk exists on both sides and seems to be online.
Dallas
Side ‘A’
[Sep 9 16:05:07] DEBUG[15634] pbx_dundi.c: Registering request for '200@e164' on behalf of '00:00:00:00:00:00' crc '00000000'
[Sep 9 16:05:07] DEBUG[15634] pbx_dundi.c: Will query peer '00:1e:90:c0:ac:45' for '200@e164'
[Sep 9 16:05:07] DEBUG[21538] pbx_dundi.c: Got canonical message 13 (0), 50 bytes data
[Sep 9 16:05:07] DEBUG[21538] pbx_dundi.c: Got canonical message 66 (0), 9 bytes data (Final)
[Sep 9 16:05:07] DEBUG[21538] pbx_dundi.c: Looks like success of some sort (-1), 0 answers
[Sep 9 16:05:07] DEBUG[21538] pbx_dundi.c: Caching hint at 'hint/001E90C0AC45/2/e164/e00000000'
[Sep 9 16:05:07] DEBUG[21538] pbx_dundi.c: Caching hint at 'hint/001E90C0AC45/2/e164/r000000000000'
Side ‘B’
[Sep 9 16:05:07] DEBUG[18603] pbx_dundi.c: Got canonical message 13 (0), 334 bytes data
[Sep 9 16:05:07] DEBUG[18603] pbx_dundi.c: Wow, new key combo passed signature and decrypt!
[Sep 9 16:05:07] DEBUG[18603] pbx_dundi.c: Got canonical message 1 (0), 27 bytes data
[Sep 9 16:05:07] DEBUG[18603] pbx_dundi.c: Answering query for '200@e164'!
[Sep 9 16:05:07] DEBUG[31700] pbx_dundi.c: Whee, looking up '200@e164' for '00:19:db:61:9c:32'
[Sep 9 16:05:07] DEBUG[31700] pbx_dundi.c: Registering request for '200@e164' on behalf of '00:19:db:61:9c:32' crc '00000000'
[Sep 9 16:05:07] DEBUG[31700] pbx_dundi.c: Avoiding '00:19:db:61:9c:32' in transaction
Subsequent calls from "A" to "B" show messages relating to the number being cached so I'd say that part is working. However, the call results in congestion so there must be something wrong with the way the call gets routed to the associated IAX trunk. This doesn't surprise me as I see no association between the DUNDi trunk and the IAX trunk.
Where is that association set and how? The trunk exists on both sides and seems to be online.
Dallas
Phone System 