Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Green

LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 works

I have another thread where I talked about Location synchronization not working with CVP 8.5. That's a pain, but I can configure the location table by hand and deploy. The problem is, it does not work.

Everything is set up correctly for LBCAC.

IP phone calls a route point and runs an ICM script. 1st Send To VRU returns the NVRU label on CUCM (8222222222) and CUCM matches this in a route pattern that is associated with the SIP Trunk to the Proxy (in Phantom location) Server.

Proxy sends it to CVP and ICM resumes the script and it hits a 2nd Send To VRU which returns the CVP NVRU label (8111111111) that we want to push to the CUPERTINO gateway via the Proxy Server.

I have CUPERTINO configured in CVP as a Site ID = 408

We can see in the trace that the location information (CUPERTINO) is coming through from CUCM over SIP. But CVP 8.5 does not like it and won't match it.

Here is the trace:

616: 16.91.120.149: May 10 2012 15:21:23.680 -0700: %CVP_8_5_SIP-7-CALL:  {Thrd=DATAI.4} CALLGUID = FE733E80000100000000000586785B10 LEGID = fe733e80-fac146fa-5-86785b10 - [INBOUND]: Display Name [] Is Using Survivability [false] CallServer build CVP_8_5_1_0_0_0_312 

617: 16.91.120.149: May 10 2012 15:21:23.680 -0700: %CVP_8_5_SIP-7-CALL:  {Thrd=DATAI.4} CALLGUID = FE733E80000100000000000586785B10 LEGID = fe733e80-fac146fa-5-86785b10 - [INBOUND]: Incoming call already has a Location Call Info header. <urn:x-cisco-remotecc:callinfo>;x-cisco-loc-id=10908748-4928-9dfa-172d-cec71d1626e3;x-cisco-loc-name=CUPERTINO 

a few lines later:

351: 16.91.120.149: May 10 2012 15:21:23.680 -0700: %CVP_8_5_ICM-3-LOGMSG_ICM_SS_PROPERTY:  Unexpected format of location received [CUPERTINO].  Expecting delimeter[--].  Ignoring invalid location info. [id:2011]

This is strange - what is it expecting?

Now on the CVP 8 Call Server it is clearly matching the location and inserting the site code:

192: 16.91.120.234: May 10 2012 16:38:45.278 -0700: %CVP_8_0_SIP-7-CALL:  {Thrd=DATAI.4} CALLGUID = 391E709E1000013723708C2B105B78EA LEGID = 57e06b00-fac15857-7-86785b10 - [INBOUND]: Display Name [] Is Using Survivability [false] CallServer build CVP_8_0_1_0_0_0_1440 

193: 16.91.120.234: May 10 2012 16:38:45.278 -0700: %CVP_8_0_SIP-7-CALL:  {Thrd=DATAI.4} CALLGUID = 391E709E1000013723708C2B105B78EA LEGID = 57e06b00-fac15857-7-86785b10 - [INBOUND]: Incoming call already has a Location Call Info header. <urn:x-cisco-remotecc:callinfo>;x-cisco-loc-id=10908748-4928-9dfa-172d-cec71d1626e3;x-cisco-loc-name=CUPERTINO 

and immediately:

194: 16.91.120.234: May 10 2012 16:38:45.293 -0700: %CVP_8_0_ICM-7-CALL:  {Thrd=pool-1-thread-106-ICM-29} CALLGUID = 391E709E1000013723708C2B105B78EA, DLGID = 7 [SIP_LEG_PRERTE_CORRID] - Processing ,, [ICM_TEMPORARY_CONNECT],   dialogueId=7,   sendSeqNo=1,   label=8111111111,   correlationId=10090,   callguid=391E709E1000013723708C2B105B78EA,   rckey=360,   rcday=150244,   rcseq=2,   location=CUPERTINO,   locationpkid=10908748-4928-9dfa-172d-cec71d1626e3,   CallContext:,, LEGID = 57e06b00-fac15857-7-86785b10, DNIS = 822222222210089, ANI = 30002 

195: 16.91.120.234: May 10 2012 16:38:45.293 -0700: %CVP_8_0_ICM-7-CALL:  {Thrd=pool-1-thread-106-ICM-29} CALLGUID = 391E709E1000013723708C2B105B78EA, DLGID = 7 [SIP_LEG_PRERTE_CORRID] - Location[408] added to label[8111111111]. Label with location=8111111111408, LEGID = 57e06b00-fac15857-7-86785b10, DNIS = 822222222210089, ANI = 30002 

and off it goes. The Proxy server has a static route for 8111111111408* to the correct gateway.

Do you have this working. Is there something I am missing in 8.5?

Regards,

Geoff

Everyone's tags (3)
13 REPLIES
Green

Re: LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 wo

I did not have the 8.5 TCL and VXML files on the gateway, but had to do that to fix Whisper, but no change to the functionality (and I would not expect that, but just to be sure).

In summary, I am using:

* UCCE 8.5.3 on W2008 R2 x64

* CVP 8.5

* CUCM 8.5.1.129007

* IOS 15.1(4) M4  (c2800nm-ipvoice_ivs-mz.151-4.M4.bin)

All my ducks are in a row and I still see in the CVP Error Log

266: 16.91.120.149: May 11 2012 12:40:58.633 -0700: %CVP_8_5_ICM-3-LOGMSG_ICM_SS_PROPERTY:  Unexpected format of location received [CUPERTINO].  Expecting delimeter[--].  Ignoring invalid location info. [id:2011]

Any clues?

Regards,

Geoff

LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 works

Might have to read through your description a bit closer if not, but have you seen CSCtr51655 -  "LBCAC does not work if a location does not have an associated gateway" ? Seems fairly similar to what you're trying at first read.

Cheers,

Kris

Green

LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 works

Kris,

Thanks for taking a look. I do have an associated gateway. 

I have it working fine on CVP 8.0, and have a parallel deployment on CVP 8.5. I just fiddle the static routes in the proxy so that the VRU transfer label on the CUCM RC goes to either CVP 8 or CVP 8.5.

It's not even trying LBCAC - it doesn't seem to like what the CUCM says. And why should it argue? It's job is to match the data from CUCM with the Site table, and it won't do that.

Regards,

Geoff

Green

LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 works

I installed CVP 8.5 ES6 this morning and it fixed the problem with synchronizing Location data from the Call Manager using AXL, but did not solve the issue here, where it continues to barf on the location from CUCM with

Expecting delimeter[--].  Ignoring invalid location info

As an experiment I decided to change the locations in CUCM to have -- in front

and then synchronize from CVP and insert my Site IDs and deploy to CVP.

and these align with my CUPS static routes

This immediately worked!! CVP understood that --CUPERTINO was a valid location and inserted 480 between 8111111111 and the correlation ID and sent it to the correct gateway. This was actually in the context of an incoming call from the PSTN using agent greeting from the phone, but it's good to know that LBCAC is also applied to agent greeting - probably to whisper too, but I haven't tested that yet.

So yippee - it's working. But why do Cisco want to see locations with "--" in the name and where is this documented? Do the CUCM guys know that they will have to make location names like this to work with CVP LBCAC? Who's on first?

Regards,

Geoff

Green

LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 works

Interesting thing I noticed yesterday. In the icm.properties file on the Call Server, a file that is constructed by the Ops Console and pushed during "save and deploy", we find these settings:

# Wait for PIM to be ready delay

ICM.icmPimReadyDelay = 4

ICM.maxGatewayPorts = 700

ICM.useLocation = true

ICM.locationDelimeter = --

ICM.icmPimCheckHeartbeat = true

I tried changing the ICM.locationDelimiter to remove the --. I changed the locations on the Call Manager and changed the locations/site table to remove the -- from the location names. And I restarted the Call Server.

But this did not work.

It's clear that ICM.locationDelimeter has some function, but what is it?

Regards,

Geoff

New Member

LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 works

Geoff,

I have also seen similar behavior, and did find a video detailing how to do LBCAC for CVP 7.0.2.  It does describe the need for the delimiter, as well as specifiying the identifier in the Location name.  The options and method for doing this have changed going to CVP 8.5, but this video was the first place I found mentioning that "--" delimiter.  You can see it at

http://developer.cisco.com/web/cvp/video/-/wiki/Developer%20Video%20Tip%20Series/Call+Server, look for the video titled Configuring Location and VXML Gateway Routing for IP Callers in 7.0.2

Maybe that will help a little...

Loren

New Member

Re: LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 wo

I'm trying this out for the 1st time in CVP 9.0. It does not appear to need the location "--" prefix anymore.

I do have a question however, is this LBCAC supposed to be used in place of SigDigit or in conjuction with SigDigits.

Our dialplan is built around prefixing SigDigits to calls @ the ingress Gateways, and working good, but I was looking at using the LBCAC to handle calls orginated by CUCM into CVP from remote sites. ie: CTI Route point agent transfers.

41EF7020A, DLGID = -1 [null] - Processing ,, [MsgBus:NEW_CALL],   ssId=SYS_SIP4,   mediaType=,   location=VAL,   locationpkid=a7109c32-de4b-ba77-ce72-79e983d8baa7,   locationsiteid=555100,   srcaddr=10.2.247.30,   pstntrunkgroupid=10.2.247.30 ,   pstntrunkgroupchannelnum=2147483647,   sipheader=,   rckey=,   rcday=,   rcseq=,   uui=,   calltypeid=4,   CallContext:,     user.media.id: 313D840000010000000000341EF7020A,, LEGID = null, DNIS = -1, ANI = -1 

51106: 10.2.187.14: Sep 13 2012 09:15:13.344 -0700: %CVP_9_0_ICM-7-CALL:  {Thrd=pool-1-thread-371-ICM-9} CALLGUID = 313D840000010000000000341EF7020A - Correlation ID routed call 

51107: 10.2.187.14: Sep 13 2012 09:15:13.344 -0700: %CVP_9_0_ICM-7-CALL:  {Thrd=pool-1-thread-371-ICM-9} CALLGUID = 313D840000010000000000341EF7020A, DLGID = 3 [SIP_LEG_PRERTE_CORRID] - Publishing ,, [ICM_REQUEST_INSTRUCTION],   dialogueId=3,   sendSeqNo=1,   trunkGroupId=200,   trunkNumber=0,   serviceId=2,   uui=,   correlationId=10107,   location=VAL,   locationpkid=a7109c32-de4b-ba77-ce72-79e983d8baa7,   pstntrunkgroupid=10.2.247.30 ,   pstntrunkgroupchannelnum=2147483647,   sipheader=,, LEGID = 313d8400-5210691-ae8-1ef7020a, DNIS = 011111888810107, ANI = 20001 

51108: 10.2.187.14: Sep 13 2012 09:15:13.500 -0700: %CVP_9_0_ICM-7-CALL:  {Thrd=pool-1-thread-372-ICM-10} CALLGUID = 313D840000010000000000341EF7020A, DLGID = 3 [SIP_LEG_PRERTE_CORRID] - Processing ,, [ICM_TEMPORARY_CONNECT],   dialogueId=3,   sendSeqNo=1,   label=0111119999,   correlationId=10108,   callguid=313D840000010000000000341EF7020A,   rckey=227,   rcday=150370,   rcseq=1,   location=VAL,   locationpkid=a7109c32-de4b-ba77-ce72-79e983d8baa7,   CallContext:,     user.microapp.input_type: D,     user.microapp.locale: en-us,     user.microapp.app_media_lib: .,     user.microapp.media_server: http://cvpmedia:8070,, LEGID = 313d8400-5210691-ae8-1ef7020a, DNIS = 011111888810107, ANI = 20001 

51109: 10.2.187.14: Sep 13 2012 09:15:13.500 -0700: %CVP_9_0_ICM-7-CALL:  {Thrd=pool-1-thread-372-ICM-10} CALLGUID = 313D840000010000000000341EF7020A, DLGID = 3 [SIP_LEG_PRERTE_CORRID] - Location[555100] added to label[0111119999].

Green

LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 works

braclarke wrote:

I'm trying this out for the 1st time in CVP 9.0. It does not appear to need the location "--" prefix anymore.

I've been doing a lot with this recently and have sorted it out.

It's not CVP 9.0 that fixes this - it's the CUCM it tries to sync with. For example, CVP 8.5 will sync with CUCM 8.5 and later, so you would not put location information in that CUCM as FOO--NNN and let it pull the site code out of the Call-Info that comes across in the SIP INVITE.

But CVP 8.5 will not sync with CUCM 7.1(5) (for example) and neither will you be able to create the location table by hand (because it does not just match on the side code but matches also on the pkid). It's broken - works OK with CVP 8.0 though. Cisco dropped the ball here.

I do have a question however, is this LBCAC supposed to be used in place of SigDigit or in conjuction with SigDigits.

In place of - it replaces SigDigits and is far easier to use - and it actually allows CUCM to calculate the bandwidth being used. I've done teh SigDigits method and it's painful compared to LBCAC.

Regards,

Geoff

Green

LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 works

Sorry - in your case it would be in conjunction. It's only the calls from IP phones that would use it. You ingress gateway calls would still use SigDigits

Regards,

Geoff

New Member

Re: LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 wo

Ok thanks I got it.  I tested it and its working like I thought it would.  I still prefix the SigDigits on our Route Patterns to CUSP since once you turn it on its ON for all calls, and then look deeper into the label for the Location SiteID to route to the proper VXML gateway.

I could possibly stop prefixing on our Route Patterns, and tell CVP to put the SiteID at the beginning of the VRU label too.  I'll try that out.

Green

LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 works

I activated LBCAC at a customer last weekend and they reported a small number of failures during the week when an agent transferred to another skill group through a route point.

32031: 161.135.182.90: Sep 17 2012 09:31:17.215 -0500: %CVP_8_5_ICM-3-LOGMSG_ICM_SS_PROPERTY:  Unexpected format of location received [Hub_None].  Expecting delimeter[--].  Ignoring invalid location info. [id:2011]

and I see related trace in the CVP logs:

57120e4-68801-15b787a1 - [INBOUND]: Incoming call already has a Location Call Info header. ;x-cisco-loc-id=29c5c1c4-8871-4d1e-8394-0b9181e8c54d;x-cisco-loc-name=Hub_None 

So I first though that some of the phones at the branch had not been adjusted to have the correct location, but that is not the case.

Then the customer told me that these are occurring in a RONA (router requery) scenario.

I had deliberatley blocked the route to the gateway for in favour of to activate LBCAC unambiguously, but I just opened this up again to stop this error.

Does anyone have experience with this? Is this what should happen in a Requery?

Regards,

Geoff

LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 works

Hi Geoff,

Did you ever get round having to put -- in front of locations? I have the same issue. Locations have snyc'd fine, I have site ID's but I get the error message still.

LOGMSG_ICM_SS_PROPERTY:  Unexpected format of location received [LOC_MAN].  Expecting delimeter[--].  Ignoring invalid location info.

I have CVP 8.5 (with ES6) CUCM is 8.6.2

Thanks Chris

New Member

LBCAC with CVP 8.5 fails - exact same config with CVP 8.0 works

Its back in CVP 10.0 again.  We have CVP 10 testing with CUCM9.1.2SU1 , same old -- messages again , was working fine in CVP 9.0

2606
Views
0
Helpful
13
Replies
CreatePlease to create content