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

Cisco VCS <-> CUCM: Decode Error

Hi,

I have configured a SIP Trunk between Cisco VCS-Control and CUCM V7.1.3 (1 Publisher, 2 Subscribers):

Zone: CUCM_Zone

H323: Off

SIP: On / 5060 / TCP

Publisher: Failed to connect on 5060

Subscriber1: Active on 5060

Subscriber2: Active on 5060

(All CUCM Nodes are on the same subnet)

Relevant Search rules and transforms have been configured on VCS, Route Pattern and SIP Trunk have been configured on CUCM Pub, pattern confirmed using Dialled Digit Analyser.

Outstanding Issues are:

  • Publisher node fails to connect on 5060
  • Seeing Decode Error's in VCS Eventlog on all CUCM Nodes "(Warning) Invalid warn-agent in Warning"
  • Can call from video endpoint to phone, answer on the phone which says connected, video endpoint says still connecting then drops after 10-20 seconds. (can also hear the phone end on the video endpoint, not the other way round)
  • Can not call from phone to video endpoint, not seeing any logs in the search history or eventlog based on this call. TCP trace on VCS shows i'm recieving a 503 service unavailable message from the CUCM PUB.

Dial Plan details:

IPT - #1XXXX

Video - 2XXXX

The video endpoints are SIP so i have had to base my search rules using %23 as opposed to # as it isn't a valid SIP character, not sure if this has any effect when presented to CUCM?

Thanks, Si

Everyone's tags (6)
2 REPLIES

Cisco VCS <-> CUCM: Decode Error

Check Device Pool in cucm and make sure your SIP trunk contains CUCM publisher in your CUCM call manager group.

and make sure CUCM service in pub is running, if not no need to use it in your rules.

the %23 is #, so thats normal.

New Member

Cisco VCS <-> CUCM: Decode Error

Gonzalo,

I managed to resolve this issue with the assistance with Cisco TAC.

The issue was that Cisco VCS does not support the handling of the # character, this needs to be encoded to hexadecimal format of %23.

The IPT phone was registered to CUCM with a #, this meant the # character was being sent to the VCS in the SIP message headers and VCS was not decoding it.

I managed to find a 'workaround' for this, by disabling both 'remote-party-ID' and 'asserted-identity' on the CUCM SIP trunk pointing at Cisco VCS.

TAC also reported that an internal bug had been reported based on this:

(SIP Stack needs to escape # in SIP URI as per RFC 3261)

Resolved in following revisions:

8.6(1.98000.47)

8.6(1.98000.110)

8.6(2.10000.30)

Thanks, Si

1599
Views
5
Helpful
2
Replies
CreatePlease to create content