Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations John Tel on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Problem transferring to another VDN

Status
Not open for further replies.

auskar85

Technical User
Dec 5, 2012
135
LT
We have such situation:
Agent is answering incoming call from outside line to vdn. When agent tries to transfer call to another vdn (presses transfer button and vdn number), he hears ringback. Once another agent picks up a call, both sides cannot hear each other. By pressing tranfer button one more time, call transfers successfully.

Here is trace:

LIST TRACE

time data

11:19:57 TRACE STARTED 12/11/2014 CM Release String cold-03.0.124.0-21172
11:21:02 active station 424 cid 0x12c6
11:21:08 conf/tran hold station 424 cid 0x12c6
11:21:08 active announcement 7979 cid 0x12c6
11:21:08 G711MU ss:eek:ff ps:20
rgn:1 [192.168.28.20]:3118
rgn:1 [192.168.1.233]:2064
11:21:11 0 0 ENTERING TRACE cid 4808
11:21:11 11 1 vdn e7931 bsr appl 0 strategy 1st-found override n
11:21:11 11 1 goto step 10 if time-of-day is all 1900 to all 1100
11:21:11 11 1 time-of-day(5,11:21)+VDNTZO(00:00)+DSR(00:00)=5,11:21
11:21:11 11 2 goto step 10 if time-of-day is fri 1900 to mon 1100
11:21:11 11 2 time-of-day(5,11:21)+VDNTZO(00:00)+DSR(00:00)=5,11:21
11:21:11 11 3 goto step 14 if ani in table 1
11:21:11 11 3 ani = [7666]



list trace station 424 Page 2

LIST TRACE

time data
11:21:11 11 4 goto step 14 if holiday in table 1
11:21:11 11 5 queue-to
11:21:11 11 5 queuing to skill 11 pri m
11:21:11 11 5 Local Agent Preference=n
11:21:11 11 5 Agent Login ID: 7806 Logged in at station: 406
11:21:11 11 5 LEAVING VECTOR PROCESSING cid 4808
11:21:11 dial 7931
11:21:11 ring vector 11 cid 0x12c8
11:21:11 G711MU ss:eek:ff ps:20
rgn:1 [192.168.1.106]:2746
rgn:1 [192.168.1.233]:2058
11:21:14 active station 406 cid 0x12c8
11:21:14 G711MU ss:eek:ff ps:20
rgn:1 [192.168.28.20]:3118
rgn:1 [192.168.1.106]:2746
11:21:14 G711MU ss:eek:ff ps:20

press CANCEL to quit -- press NEXT PAGE to continue



list trace station 424 Page 3

LIST TRACE

time data
rgn:1 [192.168.1.106]:2746
rgn:1 [192.168.28.20]:3118
11:21:25 transfer station 424 cid 0x12c8
11:21:25 G711MU ss:eek:ff ps:20
rgn:1 [192.168.1.106]:2746
rgn:1 [192.168.1.233]:2054
VOIP data from: [192.168.1.233]:2054
11:21:36 Jitter:0 0 0 0 0 0 0 0 0 0: Buff:12 WC:1 Avg:0
11:21:36 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:0 Avg:0
11:21:43 idle station 406 cid 0x12c8


What can cause a problem? All phones are in the same network region. I don't think this is a network issue too. Direct IP-IP is enabled.
CM 6.3 version. I tried upgrading phone (1608-I) firmware to required version with no success.
 
I didn't try that. But i tried to call to agent and extension from another extension (instead from outside trunk group to VDN), and then transfer to another VDN with same result. I think i should try to forward to another extension as you suggested.
 
I think you might be missing a route somewhere in there. Direct IP is enabled, and as far as your trace goes, its all in the 192.168.1 subnet with the exception of one call leg in 192.168.28. I`m thinking perhaps all your phones know how to reach the media gateways, and the gateways know how to reach all the phones, but perhaps that particular call scenario is finding a gap in your network configuration.

I`ve had that once before and had to prove it by disabling direct IP audio system-wide as a test.
 
In 192.168.1.X network there is media gateway and server, and also some phones. Other phones are in other subnets. If these phones can reach media server, they should be able to reach phones in same 192.16.1.X subnet.
 
I agree that they should. That's why I was suggesting you test and prove that theory.

If the phones in 192.168.1.0/24 only ever talk to each other, or a gateway in that same subnet, you can't really test out that the default gateway for those phones is necessarily working.

Maybe its over a site-to-site VPN that isn't voip aware and dropping packets?

Direct calls between extensions with direct audio on/off should be enough to confirm or eliminate that particular possibility though.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top