cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Bookmark
|
Subscribe
|
898
Views
0
Helpful
8
Replies

call forwarding 3905 not working

6952010460-> 5705  call forward to 6941580555  -  failure

6952010460-> 5700  call forward to 6941580555  - success

both extensions , devices have the same settings - forwarding css is correct

any idea of what is causing the failure in the 5705  ?

 

 

8 Replies 8

i am wondering if the below sdl are helpful?

 

 

 

success   Line 65229: 17598767.000 |10:27:10.882 |SdlSig   |CcSetupCompReq                         |call_active                    |RouteListCdrc(2,100,172,522898)  |RouteListControl(2,100,173,51)   |2,100,251,61628741.1290216^10.10.254.20^* |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0] CI=48444278 CI.branch=0 IEId=4 SigLen=1 SigVal=79 lPart=658a7efb-a807-5c67-9beb-52fd7f2c4206 lPatt=0.6XXXXXXXXX lModNum=tn=0npi=0ti=1nd=06941580555pi=1si0 lName=locale: 16 Name:  UnicodeName:  pi: 1 cName=locale: 16 Name:  UnicodeName:  pi: 1 cn:tn=0npi=0ti=1nd=06952010460User=Host=ims.otenet.grPort=0PassWord=Madder=Transport=4mDisplayName=RawUrl=OrigPort=0pi=1si3 cVMbox= localPatternUsage=5 connectedPatternUsage=2 lCnPart= lCnPatt= rn:tn=0npi=0ti=1nd=5700pi=1si1 lLRPart=28067779-ac3a-b62b-f204-3f6b21752450 lLRPatt=5700 lOCdpnPart=28067779-ac3a-b62b-f204-3f6b21752450 lOCdpnPatt=5700 oCdpn:tn=0npi=0ti=1nd=5700pi=0si1 oRFR =15 lBridgePartID= lCnBridgePartID= DevCEPN=d2e78c3e-5380-9639-23e4-46751e49c3f3 CnDevCEPN=885de28e-b6cb-5add-239c-f0313fb390e3 lrnCEPN=1923b9ab-e45d-04b3-9bfc-4261c03ddccf oCdpnCEPN=1923b9ab-e45d-04b3-9bfc-4261c03ddccf lHPMemCEPN= cHPMemCEPN= External Presentation Info [ pi=0si1locale: 1 Name:  UnicodeName:  pi: 0 mIsCallExternal=F ] secureStatus=(T,1) isAnnMohResourceInsertedAtParty =F media=2 M=Unknown ;rc=0 Hdrs= CanSupportSIPTandN=true TransId=0 AllowBitMask=0x7ff UserAgentOrServer=Cisco-SIPGateway/IOS-17.9.4a OrigDDName=locale: 1 Name:  UnicodeName:  pi: 0 mCallerId= mCallerName= TrustRxId=T mIsMultiForkingEnabled=Fhold =F
||

 

 

failure   Line 37696: 89262625.000 |21:23:40.973 |SdlSig-O |CcSetupReq                             |NA RemoteSignal                |RouteListControl(2,100,173,51)   |Cdcc(1,100,39,2963483)           |1,100,251,1021200.2^10.10.254.20^*       |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] CI=32845931 CI.branch=0  sBPL.plid=65 sBPL.l=1 sBPL.pl=5 sBPL.msd=0  FDataType=0 opId=0 ssType=0 SsKey=0 invokeId=0 resultExp=F bpda=F pi.piid=30 pi.l=0 pi2.piid=30 pi2.l=0 pi3.piid=30 pi3.l=0 FQCGPN=pi=0si1 preXCgpn=tn=0npi=0ti=1nd=06952010460User=Host=ims.otenet.grPort=0PassWord=Madder=Transport=4mDisplayName=RawUrl=OrigPort=0pi=0si3 cgPart= cgPat= cgpn=tn=0npi=0ti=1nd=06952010460User=Host=ims.otenet.grPort=0PassWord=Madder=Transport=4mDisplayName=RawUrl=OrigPort=0pi=1si3 cgpnVM= unXCgpn=tn=0npi=0ti=1nd=06952010460User=Host=ims.otenet.grPort=0PassWord=Madder=Transport=4mDisplayName=RawUrl=OrigPort=0pi=1si0 cName=locale: 16 Name:  UnicodeName:  pi: 1 DD=ti=1nd=06941580555pi=0si1 origDD=tn=0npi=1ti=1nd=5705User=5705Host=10.10.254.5Port=5060PassWord=Madder=Transport=4mDisplayName=RawUrl=sip:5705@10.10.254.5OrigPort=0pi=0si1 preXCdpn=tn=0npi=0ti=1nd=06941580555pi=0si0 preXTagsList=ACCESS-CODE:SUBSCRIBER preXPosMatchList=0:6941580555 cdPart=658a7efb-a807-5c67-9beb-52fd7f2c4206 cdPat=0.6XXXXXXXXX cdpn=tn=0npi=0ti=1nd=06941580555pi=0si1 cdpnVMbox= localPatternUsage=5 connectedPatternUsage=2 itrPart= itrPat= LRPart=28067779-ac3a-b62b-f204-3f6b21752450 LRPat=5705 LR=tn=0npi=0ti=1nd=5705pi=1si1 LRVM= LRName=locale: 16 Name:  UnicodeName: ΓΡΑΜ ΠΜΣ ΤΑΥΤΟΤΗΤΑ ΕΚΠΑΙΔ ΚΑΙ ΔΗΜΟΚΡ ΠΟΛΙΤΙΣΜΟΣ pi: 0 FQOCpdn=ti=1nd=+302107275705pi=0si1 fFQLRNum=ti=1nd=+302107275705pi=0si1 oPart=28067779-ac3a-b62b-f204-3f6b21752450 oPat=5705 oCpdn=tn=0npi=0ti=1nd=5705pi=0si1 oCdpnVM= oRFR=15 oName=locale: 16 Name:  UnicodeName: ΓΡΑΜ ΠΜΣ ΤΑΥΤΟΤΗΤΑ ΕΚΠΑΙΔ ΚΑΙ ΔΗΜΟΚΡ ΠΟΛΙΤΙΣΜΟΣ pi: 0 ts=ACCESS-CODE:SUBSCRIBER posMatches=0:6941580555 withTags= withValues= rdn.l=0IpAddrMode=0 ipAddrType=0 ipv4=10.10.254.20:2 ...

 

 

 

Both calls show that they are hitting the Route Pattern "cdPat=0.6XXXXXXXXX" which means that CUCM is finding the same route pattern for both, so they should be handled by CUCM the same way.

I think it might be the PSTN gateway and not CUCM. If you can provide the SDL logs for both the successful and failed calls we should be able to tell if the CUCM is generating the issue or the gateway.

Maren

good morning,

a lot of sdl files, searched all of them ,so i attached only the .txt i have created which contain the messages regarding the a , b and c numbers. 

 

 

I can see this in the logs for the failed calls. Without the logs from the voice gateway, we cannot determine the issue, as it appears to be with the gateway for this call.

 

SIP/2.0 408 Request Timeout
Via: SIP/2.0/TCP 10.10.254.6:5070;branch=z9hG4bK13db6d93db86fc0
From: "ΓΡΑΜ ΠΜΣ ΤΑΥΤΟΤΗΤΑ ΕΚΠΑΙΔ ΚΑΙ ΔΗΜΟΚΡ ΠΟΛΙΤΙ΢ <sip:5705@10.10.254.6>;tag=499615520~3c1a87fe-dee7-4800-b391-c33a4ec3a46c-61610081
To: <sip:06941580555@acheron.uoa.gr>;tag=6F39691B-1CA2
Date: Tue, 15 Oct 2024 18:18:21 GMT
Call-ID: fc989a80-1f01a92c-ffb5a5-6fe0a0a@10.10.254.6
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-17.9.4a
Reason: Q.850;cause=102
Session-ID: 00000000000000000000000000000000;remote=707997fdc4465a3a85073d8587bab82a
Content-Length: 0



Response Signature


the time stamp for the failed forwarding is 15 Oct 2024 22:16 , so disregard this message , mistakenly added by me in this file - furthermore if you see the invite, no 'diversion' header is present so i do not think it is our case at all - for the failed, i am not sure if the forwarding hit the cube, cut by the CUCM ? - it is a pity not documentation exists for the sdl logs , i am almost sure that the reason of the failure is somehow hidden in there  

Could you share the gateway logs for both failed and working scenarios?

Please include the debug outputs for ccapi inout and CCSIP messages.



Response Signature


unfortunately not - i do not have access to the customer network - and i do not think it would help us in getting them - for him problem solved - i do not write how , as it does not make any sense - in this post i am trying to find why happened in the first place - i can share sdl logs