VM Pro - How to detect reason for failure to transfer

[pipind]

Hello experts,

How do I get, from the Monitor tool, the reason why a transfer request via VM Pro fails? I have these logs showing one such scenario, but I cannot figure out what makes it fail when done through VM Pro. I am logging enough to reveal what needs to be done?


3120789mS VMAIL: VMMESSAGE Transfer request [3818@0722743223]
3120789mS CMExtnRx: v=RAS, p1=0
CMTransfer
Line: type=NoLine 0 Call: lid=0 id=-1 in=0
Called[3818] Type=Default (100) Reason=CMDRdirect SndComp Calling[0722743223] Type=Unknown Plan=Default
IE CMIECallingPartyName (110)(Type=CMNameDefault) name=0722743223
3120790mS CMCallEvt: 0.1248.0 82 RAS.0: Transfer CMCauseTransfer
3120790mS PRN: CDR - ResetQueueSize=500
3120791mS PRN: CDR - TCPSend maxqueuesize=500 operational=0
3120792mS CD: CALL: 21.6.1 BState=Connected Cut=3 Music=0.0 Aend="Line 21" (271.1) Bend="AutoAttendOleExt(AutoAttendOleExt)" [VoiceMail] (6.8) CalledNum=AutoAttendOleExt () CallingNum= (0722743223) Internal=0 Time=11570 AState=Connected
3120793mS CMTARGET: 21.6.1 82 H323TrunkEP: ADD TARGET (N): number=3818 type=100 depth=1 nobar=1 setorig=1 ses=0
3120794mS CMTARGET: 21.6.1 82 H323TrunkEP: SYS SC: 3818 4 18 sc=type=Dial code=38xx, num=38n callinfop->sending_complete=1 secondary_dialtone=
3120795mS CMARS: FindActiveARSByGroupID GroupID=49 - Not Found
3120795mS CMLRQ: FindActiveLRQByGroupID GroupID=49 - Not Found
3120796mS CMCallEvt: 0.1252.0 -1 BaseEP: NEW CMEndpoint fe9582c0 TOTAL NOW=5 CALL_LIST=2
3120799mS CMTARGET: DIAL LINE: 82 GROUP = 49 SUCCESS = fe9582c0
3120799mS CMTARGET: 21.6.1 82 H323TrunkEP: PrepareTransferTargets Found 1 target
3120799mS CMTARGET: 21.6.1 82 H323TrunkEP: GetNoAnswerTimer:16
3120800mS CMCallEvt: 0.1253.0 -1 BaseEP: NEW CMEndpoint fe9485f8 TOTAL NOW=6 CALL_LIST=2
3120801mS CMExtnEvt: RAS: CALL LOST (CMCauseTransfer)
3120802mS CMCallEvt: 0.1248.0 -1 RAS.0: StateChange: END=X CMCSConnected->CMCSCompleted
3120802mS CMExtnEvt: v=1008 State, new=PortRecoverDelay old=Connected,0,0,RAS
3120802mS CMExtnTx: v=RAS, p1=0
CMReleaseComp
Line: type=RAS 1 Call: lid=0 id=1008 in=0
Called[AutoAttendOleExt] Type=Voicemail (102) Reason=CMDRX_Attendant
BChan: slot=6 chan=8
Cause=126, Transfer(IPO)
3120803mS VMAIL: SESS 6b: CMD=2 Mailbox=AutoAttendOleExt Access=4 !Internal!=N Calling_party_number=0722743223 targeted_party_number= Called_party_number= Display=0722743223>AutoAttendOleExt
3120804mS VMAIL: SESS 6b: END Transmit=92 Discards=0 Recv=72 SeqErrs=0 Empty=0 Purges=5
3120805mS CMExtnEvt: RAS: CMExtnHandler::SetCurrent( id: 1248->0 )
3120806mS CMCallEvt: 0.1248.0 -1 RAS.-1: StateChange: END=X CMCSCompleted->CMCSDelete
3120806mS CMExtnEvt: v=1008 State, new=Idle old=PortRecoverDelay,0,0,RAS
3120806mS CMExtnTx: v=RAS, p1=0
CMReleaseComp
Line: type=RAS 1 Call: lid=0 id=1008 in=0
BChan: slot=6 chan=8
Cause=126, Transfer(IPO)
3120807mS CMCallEvt: 0.1253.0 82 TargetingEP: StateChange: END=B CMCSIdle->CMCSOffering
3120808mS CMCallEvt: 0.1252.0 82 H323TrunkEP: StateChange: END=T CMCSIdle->CMCSOffering
3120811mS CMLineTx: v=49
CMSetup
Line: type=IPLine 49 Call: lid=0 id=1252 in=0
Called[3818] Type=Unknown (0) Reason=CMDRdirect SndComp Calling[0722743223] Type=Unknown Plan=Unknown
BC: CMTC=UnreservedDigital CMTM=Packet CMTR= CMST=Default CMU1=H221
IE CMIESupplementaryService (3)
Network Facility Extension
sourceEntity: 0
destinationEntity: 0
Interpretation APDU
discardAnyUnrecognisedInvokePdu
CallingName.Invoke.CodePageISO8859-1
invokeId 14735
user '0722743223' presentation Allowed
IE CMIEFastStartInfoData (6)
IE CMIECallSignalChannelData (8) unknown
Display [0722743223>3818]
Cause=126, Transfer(IPO)
Timed: 09/03/10 17:43
3120816mS CMLineTx: v=49
CMFacility
Line: type=IPLine 49 Call: lid=0 id=1252 in=0
3120817mS CMLineTx: v=21
CMFacility
Line: type=IPLine 21 Call: lid=21 id=6 in=1
Cause=126, Transfer(IPO)
3120818mS CMLineTx: v=21
CMFacility
Line: type=IPLine 21 Call: lid=21 id=6 in=1
IE CMIESupplementaryService (3)
Interpretation APDU
rejectAnyUnrecognisedInvokePdu
CallTransferComplete.Invoke.CodePageISO8859-1
invokeId 14736
redirection name '' redirection number '' secondary end alerting
3120818mS CMCallEvt: 0.1248.0 -1 BaseEP: DELETE CMEndpoint fe93c79c TOTAL NOW=5 CALL_LIST=2
3120823mS CD: CALL: 21.6.1 BState=Idle Cut=1 Music=0.0 Aend="Line 21" (271.1) Bend="Line 49" [Line 49] (0.0) CalledNum=3818 () CallingNum=0722743223 (0722743223) Internal=0 Time=11601 AState=Connected
3120827mS H323Evt: v=0 stacknum=49 State, new=NullState, old=NullState id=-1
3120843mS H323Evt: v=0 stacknum=49 State, new=Initiated, old=NullState id=1252
3120845mS H323Tx: dst=192.168.36.52:1720
H323 Pcol=08(Q931) Reflen=2 ref=0004(Remote)
Message Type = Setup
3120849mS H323Tx: dst=192.168.41.45:12048
H323 Pcol=08(Q931) Reflen=2 ref=001D(Local)
Message Type = Facility
3121436mS H323Rx: src=192.168.36.52:1720
H323 Pcol=08(Q931) Reflen=2 ref=0004(Local)
Message Type = CallProceeding
3121437mS H323Evt: v=0 stacknum=49 State, new=Proceeding, old=Initiated id=1252
3121439mS CMLineRx: v=49
CMProceeding
Line: type=IPLine 49 Call: lid=0 id=1252 in=0
3121439mS CMCallEvt: 0.1253.0 82 TargetingEP: RequestEnd 0.1252.0 82 H323TrunkEP
3121440mS CMTARGET: 21.6.1 82 H323TrunkEP: CancelTimer CMTCNoAnswerTimeout
3121440mS CMCallEvt: 0.1253.0 -1 BaseEP: DELETE CMEndpoint fe9485f8 TOTAL NOW=4 CALL_LIST=2
3121441mS CMCallEvt: 0.1252.0 82 H323TrunkEP: StateChange: END=B CMCSOffering->CMCSAccept
3121444mS CD: CALL: 21.6.1 BState=Ringing Cut=3 Music=0.0 Aend="Line 21" (271.1) Bend="Line 49" [Line 49] (299.1) CalledNum=3818 () CallingNum=0722743223 (0722743223) Internal=0 Time=12222 AState=Connected
3121506mS H323Rx: src=192.168.36.52:1720
H323 Pcol=08(Q931) Reflen=2 ref=0004(Local)
Message Type = ReleaseComplete
3121507mS H323Evt: v=0 stacknum=49 State, new=NullState, old=Proceeding id=1252
3121509mS CMLineRx: v=49
CMReleaseComp
Line: type=IPLine 49 Call: lid=0 id=1252 in=0
Cause=65, Bearer capability not implemented
3121509mS CMCallEvt: 0.1252.0 82 H323TrunkEP: StateChange: END=B CMCSAccept->CMCSCompleted
3121510mS PRN: CDR - ResetQueueSize=500
3121512mS PRN: CDR - TCPSend maxqueuesize=500 operational=0
3121513mS CMLOGGING: CALL:2010/03/0917:42,00:00:12,000,0722743223,I,3818,*80,,,,0,,""n/a,0
3121514mS CD: CALL: 21.6.1 BState=Disconnecting Cut=1 Music=0.0 Aend="Line 21" (271.1) Bend="Line 49" [Line 49] (299.1) CalledNum=3818 () CallingNum=0722743223 (0722743223) Internal=0 Time=12292 AState=Connected
3121515mS CD: CALL: 21.6.1 Deleted
3121517mS CMTARGET: 21.6.1 -1 H323TrunkEP: ~CMTargetHandler
3121518mS CMLineTx: v=21
CMReleaseComp
Line: type=IPLine 21 Call: lid=21 id=6 in=1
Cause=65, Bearer capability not implemented
3121518mS CMCallEvt: 21.6.1 -1 H323TrunkEP: StateChange: END=X CMCSConnected->CMCSDelete
3121519mS CMCallEvt: 21.6.1 -1 BaseEP: DELETE CMEndpoint fe92e818 TOTAL NOW=3 CALL_LIST=1
3121520mS CMCallEvt: 0.1252.0 -1 H323TrunkEP: StateChange: END=X CMCSCompleted->CMCSDelete
3121520mS CMCallEvt: END CALL:82 (fe9a7cd4)
3121523mS CMCallEvt: 0.1252.0 -1 BaseEP: DELETE CMEndpoint fe9582c0 TOTAL NOW=2 CALL_LIST=1
3121525mS H245Tx: v=0 peb=21
MultimediaSystemControlMessage = command = endSessionCommand = disconnect
3121525mS H323Tx: dst=192.168.41.45:12048
H323 Pcol=08(Q931) Reflen=2 ref=001D(Local)
Message Type = Facility
3121526mS H323Evt: v=0 stacknum=21 State, new=ReleaseReq, old=Active id=6
3121526mS H323Tx: dst=192.168.41.45:12048
H323 Pcol=08(Q931) Reflen=2 ref=001D(Local)
Message Type = ReleaseComplete
3121527mS H323Evt: v=0 stacknum=21 State, new=NullState, old=ReleaseReq id=6
3121528mS H323Evt: RTP(END): 192.168.41.50/49154 192.168.41.45/35000 CODEC=Alaw64K(4) PKTSZ=1280 RFC2833=off AGE=12273 SENT=577 RECV=562 RTdelay=0 jitter=0 loss=0 remotejitter=0 remoteloss=0

 

[tlpeter]

This is the problem:
Cause=65, Bearer capability not implemented

What it means:
1. In most cases, the number being called is not an ISDN number but an analog destination.
2. The equipment is dialing at a faster rate than the circuitry allows, for example, dialing at 64K when only 56K is supported.


ACS IP Office or is it ACSS
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[pipind]

@tlpeter,

How can I solve the problem then?
1. The number being called is a short code. The Switch the VM Pro is connected to has an IP trunk to another switch, where the actual call needs to go out through.
2. The eqpt dialing at a faster rate..hmm... that one is a hard one, but from my desk phone, I am able to dial the short code and get the destination without a problem.

The funny thing is, via the VM Pro, dialing any extn in any of the switches (IPOs and two Definity units) works without a problem. However,

(a) dialing a sc that is supposed to go out via another switch fails
(b) if the short code is "local" to the unit (as in this very unit is the one to call out directly, not via another unit) then the call goes through. I mean if the end destination is the "next switch" then it works. If the next switch has to make an external call, it fails. But that is only subject to the call coming in via VM Pro. If I dial from a deskphone, there is no problem;-)

I believe Avaya id not to blame for such, otherwise I'd be happy to apportion the blame to them ..hahaha...
Seriously though, I need help, and there is no better place than this community.

 

[tlpeter]

Why do you transfer to a shortcode anyway ?


ACS IP Office or is it ACSS
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[djuplift]

The reason its not working is because the short code is not on the main switch..

ACA - Implement IP Office
ACS - Implement IP Office
ACSS - SMEC (IP Office)
Juniper - JNCIA-FWV
Convergence+

 

[pipind]

@tlpeter - the reason I transfer to a short code is two-fold, but it's basically the reason we invested in VM Pro for our IP 0ffice. Let me explain in black and white.
We have a big network - Kenya, Moscow, London, Cyprus, etc.
Each of these locations have either an IPO40x or Definity switch.
Each switch has extensions (obviously) and each user has a short code pointed to his/her mobile (GSM) phone.
So in Kenya, we have VM Pro configured with IPO406 and we have three IPO switches.

(a)when my boss is not in the office and he needs to talk to someone in the office without going through the receptionist, he calls into a number that goes into VM Pro, which prompts him for the extension he needs. He does this and he is able to talk to the person. At the same time, if this person were to be outside the office and all he could remember is his/her short code, then he can input the short code and this works perfectly.

(b) when the boss is not in the office and wants to speak to someone in London, then he needs to input the person's extn or short code and this is where the drama begins - it does not work!! And the logs I posted reflect that.
There is an another angle to this that surprises me though: There are some extns in the 15xx range which, funnily, do work. What amazes me is the fact that they are on the same switch (same IP Trunk), like the rest of the extns which are failing to work.

@djuplift - given the above response, what do you suppose is the reason for this problem?

It's just so confusing!

 

[djuplift]

Do your you locations use 9 to dial out or some other number?

What type of trunks are we attempting to dial out of at the remote location?

What do your short codes look like?



ACA - Implement IP Office
ACS - Implement IP Office
ACSS - SMEC (IP Office)
Juniper - JNCIA-FWV
Convergence+

 

[pipind]

@djuplift - We dial 9 only for national numbers, which go out through the analgue trunks and some GSM gateways which use IP trunks. For the purpose of my case with VM Pro, the numbers are all extensions/short codes within the setup.

 

[tlpeter]

Do perhaps use a * in shortcode ?
Remove the * and use a #
See if that works.


ACS IP Office or is it ACSS
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[IPGuru]

What version of IPO firmware

Transfering to an external call to an analog trunk may not be permited (& is usualy a bad idea)

 

[djuplift]

Wait a minute you are trying to transfer a call off switch from within a voicemail pro call flow, has this worked for you in the past with voicemail pro?

I am pretty sure you cannot do this as in it will not work, I just remembered that I have dealt with this once before and I learned that it is a blocked function and it is blocked because it's considered a security issue.

Not 100% on that but I am pretty sure I am right, once again has this worked for you in the past specifically with voicemail pro?

ACA - Implement IP Office
ACS - Implement IP Office
ACSS - SMEC (IP Office)
Juniper - JNCIA-FWV
Convergence+

 

[pipind]

@tlpeter - I don't use any * in the short codes.

@IPGuru - Firmware ver 5.0.18. The transfers are being done to short codes defined on a Definity system. These short codes work when dialed from desktop phone.

@djuplift - yes, that is what I am doing. It's working with some extns/short codes but not others. This is my first flirting with VM Pro, and actually the purpose we purchased it.

 

[TomMills]

unless im totally misreading this, wouldnt it be easier to have the users set their forwarding if they arent at their desk? will remove the need to remember codes AND extns too.

http://www.twitter.com/tem1985

ACSS-SME
Get well soon Aaron.