cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
225
Views
10
Helpful
4
Replies
Beginner

CVP 404 Failure to CUCM using CCB

CVP 11.6 with ES7,8

ICM 11.6(2)

Ingress CUBEs:

Cisco IOS XE Software, Version 03.13.05.S - Extended Support Release
Cisco IOS Software, ISR Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.4(3)S5, RELEASE SOFTWARE (fc1)

VXML Gateways (NOT VVB):

Cisco IOS Software, C3900e Software (C3900e-UNIVERSALK9-M), Version 15.7(3)M4a, RELEASE SOFTWARE (fc1)

 

1) I'm not using the SIP profile probe on the ingress cube, using application service parameters:

application
service survivability bootflash:/survivability.tcl
paramspace english index 0
paramspace english location flash
paramspace callfeature med-inact-det disable
param ccb id:10.2.99.12;loc:EDC;trunks:10
!

 

2) Survivability is applied to ingress test DID dial-peer

dial-peer voice 39130 voip
description Incoming ATT test CCB DID WWT
translation-profile incoming ATT-INB2
service survivability
session protocol sipv2
session server-group 2
incoming called-number 310<maskednumberforclientprivacy>
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/3
voice-class sip bind media source-interface GigabitEthernet0/0/3
no voice-class sip midcall-signaling passthru media-change
dtmf-relay rtp-nte sip-notify
!

3) Everything works as expected up till my transfer to the agent.

   a) Ingress sees probe returns for loc,ip,trunks; 

   b) I can schedule the call back fine,

   c) Callback re-connect leg goes out of the same ingress CUBE, confirmed via IOS show call active voice compact; 

   d) Call queues fine back into CallbackQueue.

 

4) As soon as I try and connect to my agent, I get a 404 rejected and my ReQuery in ICM immediately tries again to same agent and Finesse throws a Call Overlap error.  If I'm not using CCB feature (stay in CallbackEntry) everything works fine.

 

5) Here's my SIP INVITE on the Rejection, appreciate any input on what the heck I've missed here having done this many times in the past!  Any thoughts I should be looking at the CUCM side or the CUBE side?   I do see the Call-Info: <sip:10.2.99.12:5060>;purpose=x-cisco-origIP being set only on these CCB calls, the the CVP trunk to CUCM has the ReRoute option set per the Config guide...but if I run a call straight in I don't see any Call-Info it in the SIP header.

 

Via: SIP/2.0/TCP 10.2.99.35:5060;branch=z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199
Max-Forwards: 66
To: <sip:02597@10.2.99.55;transport=tcp>
From: "WESTBY WILLIAM--CVP_11_6_1_0_0_0_329" <sip:6612003807@10.2.99.35:5060>;tag=ds4e8caf83
Call-ID: 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35
CSeq: 1 INVITE
Content-Length: 285
Contact: <sip:6612003807@10.2.99.35:5060;transport=tcp>
Expires: 16
User-Agent: CVP 11.6 (1) ES-8 Build-82
Call-Info: <sip:10.2.99.12:5060>;purpose=x-cisco-origIP
Date: Mon, 29 Jul 2019 17:15:25 GMT
Min-SE: 1800
Cisco-Guid: 1235878445-2975535593-2716854319-0193825104
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
X-Cisco-CCBProbe: id:10.2.99.12;loc:EDC;trunks:10
P-Asserted-Identity: "WESTBY WILLIAM" <sip:6612003807@10.2.99.12>
Content-Disposition: session;handling=required
Cisco-Gucid: 49AA022DB15B11E9A1EFE82F0B8D8950
Remote-Party-ID: "WESTBY WILLIAM--CVP_11_6_1_0_0_0_329" <sip:6612003807@10.2.99.12>;party=calling;screen=yes;privacy=off
Supported: timer
Supported: resource-priority
Supported: replaces
Supported: sdp-anat
Content-Type: application/sdp
App-Info: <10.2.99.35:7000:7443>

v=0
o=Cisco-CVP-B2BUA 289844526 289844527 IN IP4 10.2.99.35
s=SIP Call
c=IN IP4 10.2.99.12
t=0 0
m=audio 18772 RTP/AVP 18 0 101
c=IN IP4 10.2.99.12
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

17436291: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection: NB-Conn_60709: Enter doWrite()
17436292: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Timers-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.Timers: SCHEDULE_QUEUE table: Client INVITE variable: m_T1 input: IN_T1 time: 500
17436293: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Wire-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Wire: [Selected Keys = 1, Total Keys = 124]
17436294: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection: Composed Message:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.2.99.35:5060;branch=z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199
From: "WESTBY WILLIAM--CVP_11_6_1_0_0_0_329" <sip:6612003807@10.2.99.35:5060>;tag=ds4e8caf83
To: <sip:02597@10.2.99.55;transport=tcp>
Date: Mon, 29 Jul 2019 17:29:13 GMT
Call-ID: 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35
CSeq: 1 INVITE
Allow-Events: presence
Content-Length: 0


17436295: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_TransactionManagement-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement: processMessage(): ----- BEGINING PROCESSING NEW MESSAGE ------
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.2.99.35:5060;branch=z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199
To: <sip:02597@10.2.99.55;transport=tcp>
From: "WESTBY WILLIAM--CVP_11_6_1_0_0_0_329" <sip:6612003807@10.2.99.35:5060>;tag=ds4e8caf83
Call-ID: 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35
CSeq: 1 INVITE
Content-Length: 0
Date: Mon, 29 Jul 2019 17:29:13 GMT
Allow-Events: presence


17436296: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_TransactionManagement-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement: processMessage(): Incoming message binding info: TCP local[[ port = 0 (10.2.99.35)]] remote[[ port = 5060 (10.2.99.55) ]], Connection ID = null, network = DEFAULT, TSIP = false
17436297: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_TransactionManagement-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement: processMessage(): Incoming message:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.2.99.35:5060;branch=z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199
To: <sip:02597@10.2.99.55;transport=tcp>
From: "WESTBY WILLIAM--CVP_11_6_1_0_0_0_329" <sip:6612003807@10.2.99.35:5060>;tag=ds4e8caf83
Call-ID: 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35
CSeq: 1 INVITE
Content-Length: 0
Date: Mon, 29 Jul 2019 17:29:13 GMT
Allow-Events: presence


17436298: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_TransactionManagement-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement: processMessage(DsSipMessage)
17436299: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_TransactionManagement-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement: processMessage(): Got a response from transport layer.
17436300: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Response-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement.Response: processResponse(): begin
17436301: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Response-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement.Response: processResponse(7): client transaction found; calling onResponse and returning, retrievedTransaction = com.dynamicsoft.DsLibs.DsSipLlApi.DsSipClientTransactionIImpl@25075936
17436302: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_SwitchState-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.SwitchState: STATECHANGE 10:29:13:296 Client INVITE DS_CALLING DS_CT_IN_PROVISIONAL DS_PROCEEDING
17436303: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_UserCB-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.UserCB: CB_PROVISIONAL_RESPONSE:
17436304: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_UserCB-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.UserCB: 02597,10.2.99.55,,6612003807,10.2.99.35,5060,ds4e8caf83,49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35,1,10.2.99.35,5060,z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199,
17436305: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_UserCB-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.UserCB: CB_PROVISIONAL_RESPONSE:
17436306: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_UserCB-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.UserCB: SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.2.99.35:5060;branch=z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199
To: <sip:02597@10.2.99.55;transport=tcp>
From: "WESTBY WILLIAM--CVP_11_6_1_0_0_0_329" <sip:6612003807@10.2.99.35:5060>;tag=ds4e8caf83
Call-ID: 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35
CSeq: 1 INVITE
Content-Length: 0
Date: Mon, 29 Jul 2019 17:29:13 GMT
Allow-Events: presence


50700240: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %CVP_11_6_SIP-7-CALL: {Thrd=DIALOG_CALLBACK.15} CALLGUID = 49AA022DB15B11E9A1EFE82F0B8D8950 LEGID = 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225 - [OUTBOUND]: Invitation proceeding 100
17436307: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Wire-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Wire: [Selected Keys = 1, Total Keys = 124]
17436308: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection: Composed Message:
SIP/2.0 404 Not Found
Via: SIP/2.0/TCP 10.2.99.35:5060;branch=z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199
From: "WESTBY WILLIAM--CVP_11_6_1_0_0_0_329" <sip:6612003807@10.2.99.35:5060>;tag=ds4e8caf83
To: <sip:02597@10.2.99.55;transport=tcp>;tag=321682018~232b64f8-17ba-4a08-9863-5d6f5dfc410e-81075282
Date: Mon, 29 Jul 2019 17:29:13 GMT
Call-ID: 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35
CSeq: 1 INVITE
Allow-Events: presence
Reason: Q.850;cause=1
Server: Cisco-CUCM11.0
Session-ID: 00000000000000000000000000000000;remote=b1df261480e8a7b2896a1ab321682018
Content-Length: 0


17436309: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_TransactionManagement-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement: processMessage(): ----- BEGINING PROCESSING NEW MESSAGE ------
SIP/2.0 404 Not Found
Via: SIP/2.0/TCP 10.2.99.35:5060;branch=z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199
To: <sip:02597@10.2.99.55;transport=tcp>;tag=321682018~232b64f8-17ba-4a08-9863-5d6f5dfc410e-81075282
From: "WESTBY WILLIAM--CVP_11_6_1_0_0_0_329" <sip:6612003807@10.2.99.35:5060>;tag=ds4e8caf83
Call-ID: 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35
CSeq: 1 INVITE
Content-Length: 0
Date: Mon, 29 Jul 2019 17:29:13 GMT
Allow-Events: presence
Reason: Q.850;cause=1
Server: Cisco-CUCM11.0
Session-ID: 00000000000000000000000000000000;remote=b1df261480e8a7b2896a1ab321682018


17436310: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_TransactionManagement-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement: processMessage(): Incoming message binding info: TCP local[[ port = 0 (10.2.99.35)]] remote[[ port = 5060 (10.2.99.55) ]], Connection ID = null, network = DEFAULT, TSIP = false
17436311: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_TransactionManagement-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement: processMessage(): Incoming message:
SIP/2.0 404 Not Found
Via: SIP/2.0/TCP 10.2.99.35:5060;branch=z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199
To: <sip:02597@10.2.99.55;transport=tcp>;tag=321682018~232b64f8-17ba-4a08-9863-5d6f5dfc410e-81075282
From: "WESTBY WILLIAM--CVP_11_6_1_0_0_0_329" <sip:6612003807@10.2.99.35:5060>;tag=ds4e8caf83
Call-ID: 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35
CSeq: 1 INVITE
Content-Length: 0
Date: Mon, 29 Jul 2019 17:29:13 GMT
Allow-Events: presence
Reason: Q.850;cause=1
Server: Cisco-CUCM11.0
Session-ID: 00000000000000000000000000000000;remote=b1df261480e8a7b2896a1ab321682018


17436312: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_TransactionManagement-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement: processMessage(DsSipMessage)
17436313: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_TransactionManagement-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement: processMessage(): Got a response from transport layer.
17436314: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Response-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement.Response: processResponse(): begin
17436315: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Response-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.TransactionManagement.Response: processResponse(3): client transaction found; calling onResponse and returning, retrievedTransaction = com.dynamicsoft.DsLibs.DsSipLlApi.DsSipClientTransactionIImpl@25075936
17436316: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_SwitchState-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.SwitchState: STATECHANGE 10:29:13:296 Client INVITE DS_PROCEEDING DS_CT_IN_3TO6XX DS_COMPLETED
17436317: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_SwitchState-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.SwitchState: STATECHANGE 10:29:13:296 Client INVITE DS_COMPLETED DS_CT_IN_TIMEOUT DS_TERMINATED
17436318: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_UserCB-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.UserCB: CB_FINAL_RESPONSE:
17436319: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_UserCB-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.UserCB: 02597,10.2.99.55,,6612003807,10.2.99.35,5060,ds4e8caf83,49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35,1,10.2.99.35,5060,z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199,
17436320: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_UserCB-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.UserCB: CB_FINAL_RESPONSE:
17436321: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_UserCB-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.UserCB: SIP/2.0 404 Not Found
Via: SIP/2.0/TCP 10.2.99.35:5060;branch=z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199
To: <sip:02597@10.2.99.55;transport=tcp>;tag=321682018~232b64f8-17ba-4a08-9863-5d6f5dfc410e-81075282
From: "WESTBY WILLIAM--CVP_11_6_1_0_0_0_329" <sip:6612003807@10.2.99.35:5060>;tag=ds4e8caf83
Call-ID: 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35
CSeq: 1 INVITE
Content-Length: 0
Date: Mon, 29 Jul 2019 17:29:13 GMT
Allow-Events: presence
Reason: Q.850;cause=1
Server: Cisco-CUCM11.0
Session-ID: 00000000000000000000000000000000;remote=b1df261480e8a7b2896a1ab321682018


17436322: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_SwitchState-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.SwitchState: STATECHANGE 10:29:13:296 Client INVITE DS_TERMINATED DS_CT_IN_ACK DS_TERMINATED
17436323: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_SwitchState-6-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.LlSM.client.SwitchState: switchState(): Next State is DS_UNDEFINED
17436324: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection: writing message to queue: callid: 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35, cseq: ACK 1
17436325: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection: Sending Message binding info (NB): TCP local[[ port = 0 (10.2.99.35)]] remote[[ port = 5060 (10.2.99.55) ]], Connection ID = null, network = DEFAULT, TSIP = false
17436326: 10.2.99.35: Jul 29 2019 10:29:13.296 -0700: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection: Sending Message (NB): ACK sip:02597@10.2.99.55;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.2.99.35:5060;branch=z9hG4bKxFnqyP5bL+KLn0DFNIdezw~~7050199
Max-Forwards: 70
To: <sip:02597@10.2.99.55;transport=tcp>;tag=321682018~232b64f8-17ba-4a08-9863-5d6f5dfc410e-81075282
From: "WESTBY WILLIAM--CVP_11_6_1_0_0_0_329" <sip:6612003807@10.2.99.35:5060>;tag=ds4e8caf83
Call-ID: 49AA022DB15B11E9A1EFE82F0B8D8950-156442135329612225@10.2.99.35
CSeq: 1 ACK
Content-Length: 0

 

Thanks, Bill Westby

1 ACCEPTED SOLUTION

Accepted Solutions
Beginner

Re: CVP 404 Failure to CUCM using CCB

Thanks Gerry, I finally figured it out!

 

It turned out to be the CUBE SIP trunk in CUCM didn't have access to the Agents partition and CVP re-routes the call via that SIP trunk on CCB calls and issues a 404 - not found error, really should be a different error IMO like "no access" or something, but oh well :) 

 

At least with CCB, when you do the re-connect to the client and then send the call to an agent, CVP adds a Call-Info tag to the SIP header:  Call-Info: <sip:10.2.99.12:5060>;purpose=x-cisco-origIP    where 10.2.99.12 is my inbound CUBE.  

 

The CVP SIP Trunk in CUCM uses a CVP SIP Profile that says "Reroute incoming request to new trunk based on: Call-Info Header with purpose=x-cisco-origIP,  this is done per the CVP Config Guide and is correct and best practice.   Not ever fully understanding what this does I finally read the on-line help for this option: 

Call-Info Header with purpose=x-cisco-origIP: If the SIP trunk uses a Customer Voice Portal (CVP) or a Back-to-Back User Agent (B2BUA), choose this option. When the incoming request is received, Cisco Unified Communications Manager parses the Call-Info header, looks for the parameter, purpose=x-cisco-origIP, and uses the IP address or domain name and the signaling port number that is specified in the header to reroute the call to the SIP trunk that uses the IP address and port. If the parameter does not exist in the header or no SIP trunk is identified, the call occurs on the SIP trunk on which the call arrived.

 

So since this Call-Info tag is in my SIP header after my CCB re-connect, CUCM re-routes the call via trunk associated with the IP address in the Call-Info tag 10.2.99.12 which is my CUBE’s IP address not CVP.  My CUBE SIP Trunk in CUCM was using a CSS for Internal Calls Only (client configured it this way, don't know why) and it didn’t include the Agent partition.  I simply added the Agent partition to the Internal CSS and everything started working. 

 

I've always just assumed that I need the inbound CVP trunk to CUCM to have access to the Agent partition, but really I need all SIP trunks, that may need to provide signaling connect with an agent, to have access to the Agent partition.   

 

In fact, it seems CVP also adds this call-info tag during some agent transfers, I haven't taken the time to figure out exactly which types, but my client was also experiencing this Call Overlap issue for sites not using CCB nor Survivability when calls were being transferred by another agent, so it was a win-win to finally understand this for myself and resolve their routing issues.

 

Thanks!  Bill.

 

4 REPLIES 4
Contributor

Re: CVP 404 Failure to CUCM using CCB

Hi Bill,

 

Could you try using Wireshark on the CVP Server instead and use "sip" filter and attached the results for a working and not working call?

 

Then save export the capture with just the SIP trace and attach to the post?

It might make it easier to spot whats is different and what the issue might be.

 

Regards,

Gerry

Beginner

Re: CVP 404 Failure to CUCM using CCB

Thanks Gerry, I finally figured it out!

 

It turned out to be the CUBE SIP trunk in CUCM didn't have access to the Agents partition and CVP re-routes the call via that SIP trunk on CCB calls and issues a 404 - not found error, really should be a different error IMO like "no access" or something, but oh well :) 

 

At least with CCB, when you do the re-connect to the client and then send the call to an agent, CVP adds a Call-Info tag to the SIP header:  Call-Info: <sip:10.2.99.12:5060>;purpose=x-cisco-origIP    where 10.2.99.12 is my inbound CUBE.  

 

The CVP SIP Trunk in CUCM uses a CVP SIP Profile that says "Reroute incoming request to new trunk based on: Call-Info Header with purpose=x-cisco-origIP,  this is done per the CVP Config Guide and is correct and best practice.   Not ever fully understanding what this does I finally read the on-line help for this option: 

Call-Info Header with purpose=x-cisco-origIP: If the SIP trunk uses a Customer Voice Portal (CVP) or a Back-to-Back User Agent (B2BUA), choose this option. When the incoming request is received, Cisco Unified Communications Manager parses the Call-Info header, looks for the parameter, purpose=x-cisco-origIP, and uses the IP address or domain name and the signaling port number that is specified in the header to reroute the call to the SIP trunk that uses the IP address and port. If the parameter does not exist in the header or no SIP trunk is identified, the call occurs on the SIP trunk on which the call arrived.

 

So since this Call-Info tag is in my SIP header after my CCB re-connect, CUCM re-routes the call via trunk associated with the IP address in the Call-Info tag 10.2.99.12 which is my CUBE’s IP address not CVP.  My CUBE SIP Trunk in CUCM was using a CSS for Internal Calls Only (client configured it this way, don't know why) and it didn’t include the Agent partition.  I simply added the Agent partition to the Internal CSS and everything started working. 

 

I've always just assumed that I need the inbound CVP trunk to CUCM to have access to the Agent partition, but really I need all SIP trunks, that may need to provide signaling connect with an agent, to have access to the Agent partition.   

 

In fact, it seems CVP also adds this call-info tag during some agent transfers, I haven't taken the time to figure out exactly which types, but my client was also experiencing this Call Overlap issue for sites not using CCB nor Survivability when calls were being transferred by another agent, so it was a win-win to finally understand this for myself and resolve their routing issues.

 

Thanks!  Bill.

 

Highlighted
Contributor

Re: CVP 404 Failure to CUCM using CCB

thanks for letting us know Bill.

Nicely explained and good to know.

 

Gerry

Cisco Employee

Re: CVP 404 Failure to CUCM using CCB

Hi Bill,

 

404 not found is returned by CUCM to CVP.

You might need to look into the CUCM Configuration and CUCM logs to see why it sent 404 Not found.

1) Check the CSS/Partition between Trunk and the IPPhone.

2) Try using the Dialed Number Analyzer tool in CUCM to see if the call is getting routed to Phone from that Trunk

 

Regards,

Senthil Kumar

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards