Hi All, Found an unusual issue which I am hoping someone can point me in the right direction We are running CUCM 10.5(2) ---> SIP Trunk --> CUBE ---> ITSP Internal SCCP phone A calls  Internal SCCP phone B (which has SNR. The SNR mobile destination has been incorrectly entered on purpose) Internal SCCP phone A hears ring back, Internal SCCP phone B rings, and the call the SNR fails ( unknown to SCCP phone A) Internal Jabber phone C calls Internal SCCP Phone B  (which has SNR.  The SNR mobile destination has been incorrectly entered on purpose) Internal Jabber phone C hears ring back and then hears "We advise that the number you have dialed is currently switched off or is unavailable, please try again later", Internal SCCP Phone B continues to ring. I disable SNR on SCCP phone B and try calling from Inter Jabber phone C again, call just rings as normal. So it would seem the message being instigated by the failed call via SNR Why do I hear the message on the failed SNR call, when calling from a SIP phone? I debug ccsip messages on the CUBE call for failed SNR call: INVITE comes in from CUCM SIP/2.0 100 Trying sent back to CUCM INVITE goes out to ITSP Receive SIP/2.0 100 Trying from ITSP Receive SIP/2.0 183 Session Description from ITSP SIP/2.0 183 Session Description send to CUCM ### At this point I hear the message on the Internal Jabber phone C ### CANCEL received from CUCM (I end the call from Jabber phone C) Last 2 messages from the debug below: Sep 15 13:13:59.039: //19953829/6FE864800001/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 10.20.20.20:5060;branch=z9hG4bK15360e623ca3ea From: "Test 1" <sip:02XXXXXXXX@10.20.20.20>;tag=4893343~511c1f8c-03d8-4f7b-8410-0f199e8a9429-39046522 To: <sip:0412345678@10.10.10.10>;tag=432A154C-5E0 Date: Thu, 15 Sep 2016 03:13:58 GMT Call-ID: 6fe86480-7da111f6-a79fc-b09180a@10.20.20.20 CSeq: 101 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: kpml, telephone-event Contact: <sip:0412345678@10.10.10.10:5060> Supported: sdp-anat Server: Cisco-SIPGateway/IOS-15.4.3.M3 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 364 v=0 o=CiscoSystemsSIP-GW-UserAgent 1634 8073 IN IP4 10.10.10.10 s=SIP Call c=IN IP4 10.10.10.10 t=0 0 m=audio 18976 RTP/AVP 8 101 c=IN IP4 10.10.10.10 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 m=video 0 RTP/AVP 126 c=IN IP4 10.10.10.10 m=application 0 RTP/AVP 125 c=IN IP4 10.10.10.10 a=rtpmap:125 H224/4800 Sep 15 13:14:09.983: //19953829/6FE864800001/SIP/Msg/ccsipDisplayMsg: Received: CANCEL sip:0412345678@10.10.10.10.10:5060 SIP/2.0 Via: SIP/2.0/UDP 10.20.20.20:5060;branch=z9hG4bK15360e623ca3ea From: "Test 1" <sip:02XXXXXXXX@10.20.20.20>;tag=4893343~511c1f8c-03d8-4f7b-8410-0f199e8a9429-39046522 To: <sip:0412345678@10.10.10.10> Date: Thu, 15 Sep 2016 03:13:58 GMT Call-ID: 6fe86480-7da111f6-a79fc-b09180a@10.20.20.20 User-Agent: Cisco-CUCM10.5 CSeq: 101 CANCEL Max-Forwards: 70 Content-Length: 0 Anyway assistance in understanding and resolving the issue would be appreciated. Thanks Kent ... View more

Hi All,   I have an issue with calls over my SIP trunk where the rtp media flow between endpoints stops in both direction after exactly 5 minutes. The SIP session stays ups.  Call length can be extended by performing some sort of mid-call signalling (hold, then un-hold) during the call.   The environment looks like this:   Mobile Phone --> VTSP --> SIP --> CUBE/ZBFW --> SIP -->CUCM --> Cisco IP Phone   The issue can be resolved by disabling the ZBFW.    Here is a snippet of my CUBE/ZBFW config:   boot system flash:c2900-universalk9-mz.SPA.154-3.M3.bin   ip inspect log drop-pkt ! parameter-map type inspect global  log dropped-packets enable  max-incomplete low 18000  max-incomplete high 20000     voice service voip  ip address trusted list   ipv4 {publisher-IP}   ipv4 {Subscriber 1 IP}   ipv4 {Subscriber 2 IP}   ipv4 {VTSP SIP Proxy IP}  address-hiding  mode border-element license capacity 50  allow-connections sip to sip  modem passthrough protocol codec g711alaw  sip         session refresh   midcall-signaling passthru !          voice class codec 1  codec preference 1 g711alaw  codec preference 2 g711ulaw !          !          voice class sip-profiles 100  request INVITE sip-header Remote-Party-ID remove   request INVITE sip-header Remote-Party-ID remove    class-map type inspect match-any SIP-TRAFFIC   description --All SIP Traffic--  match protocol sip class-map type inspect match-all ICMP_Allow_CMAP   description --Allow ICMP Traffic--  match access-group name ICMP_Allow_ACL ! policy-map type inspect VOICE-TRAFFIC  class type inspect SIP-TRAFFIC   inspect   class type inspect ICMP_Allow_CMAP   inspect   class class-default   drop ! zone security INSIDE zone security OUTSIDE zone-pair security CUBE_TO_OUTSIDE_ZP source self destination OUTSIDE  service-policy type inspect VOICE-TRAFFIC zone-pair security OUTSIDE_TO_CUBE_ZP source OUTSIDE destination self  service-policy type inspect VOICE-TRAFFIC i nterface GigabitEthernet0/0  description --Connection to Us/Inside--  ip address xx.xx.xx.xx 255.255.255.0  zone-member security INSIDE  duplex auto  speed auto ! interface GigabitEthernet0/1  description --Connection to VTSP/Outside--  ip address xx.xx.xx.xx 255.255.255.248  zone-member security OUTSIDE  duplex auto  speed auto   dial-peer voice 100 voip  description --Voip in from Us/Inside--  huntstop  session protocol sipv2  incoming called-number .T  voice-class codec 1    voice-class sip profiles 100  dtmf-relay sip-kpml rtp-nte  no vad   dial-peer voice 200 voip  description --Voip in from VTSP--  huntstop  session protocol sipv2  incoming called-number 02XXXXXX..  voice-class codec 1    voice-class sip profiles 100  voice-class sip options-keepalive retry 3  dtmf-relay rtp-nte  fax-relay ecm disable  fax rate disable  no vad ! dial-peer voice 201 voip  description --Voip out to CUCM 1--  preference 1  destination-pattern 02XXXXXX..  session protocol sipv2  session target ipv4:{Subscriber 1 IP}  voice-class codec 1    voice-class sip early-offer forced  voice-class sip options-keepalive retry 3  dtmf-relay sip-kpml  fax-relay ecm disable  fax rate disable  no vad ! dial-peer voice 202 voip  description --Voip out to CUCM 2--  preference 2  destination-pattern 02XXXXXX..  session protocol sipv2  session target ipv4:{Subscriber 2 IP}  voice-class codec 1    voice-class sip early-offer forced  voice-class sip options-keepalive retry 3  dtmf-relay sip-kpml  fax-relay ecm disable  fax rate disable  no vad   At the 5 minute mark of a call, there is no indication in the logs of the CUBE that any UDP packets or SIP sessions are being dropped. There are also no SIP BYE or RE-INVITE messages in the "debug ccsip messages" output.   My work around at the moment is to remove the SIP inspection and implement only UDP inspection between source/destination IP addresses. It would much prefer to have SIP inspection only.   Am I missing something in my ZBFW configuration to allow SIP calls last longer than 5 minutes? Perhaps SIP inspection is reacting to something within the SIP messages being sent/received?   Thanks   Kent       ... View more

Hi All,   Since my failed CUCM upgrade to 10.5(2) yesterday, our CUCM 9.1(2)su2 system has sporadically alerted the following every few hours:   SeverityMatch : Critical MatchedEvent : Jan 25 00:00:00 {publisher node name} kern 2 kernel: dbcfs: compressor thread unable to open file /var/log/active/cm/trace/cti/sdl/SDL001_200.index AppID : Cisco Syslog Agent ClusterID :  NodeID : {publisher node name} TimeStamp : Sun Jan 25 00:00:01 EST 2015   Any insight would be much appreciated. Thanks   Kent ... View more

  Hi All,   I am hoping someone could answer this one for me quickly.   I have a scenario during an refresh upgrade to CUCM 10.5(2) where it fails in the install logs with "component_install:807, failed to refresh_upgrade Infrastructure_post components | <LVL::Critical>". The fix to this may be that I need to uninstall the AUNP dialplan before upgrading. See ( https://supportforums.cisco.com/printpdf/12334191)   What is the effects on route patterns etc when removing the AUNP dial plan? Will the configuration be maintained and become operable once I upgrade and re-install the AUNP?   Thanks in advance Kent     ... View more

  Hi All,   Here is my issue:   VGW1 --> SIP or H323 --> CUCM --> SIP --> CUBE--> SIP --> ITSP   An outside caller calls into our CUCM via VGW1 to reach User 1 (registered to CUCM on extension 1111) User 1 has mobility configured to call their mobile number, so a simultaneous call is established to the ITSP via the CUBE.  After the first initial SIP INVITE is received by the CUBE and sent to the ITSP, a second SIP INVITE is received from CUCM and sent to the ITSP This SIP INVITE (RE-INVITE?) has no SDP information, so the ITSP sends back a 200 OK message with SDP information The codecs sent back from the carrier are not supported on the CUBE, hence the CUBE drops the call   CUCM Mobility functionality sees the "drop" as User 1 hanging up on their mobile, therefore CUCM plays Music On Hold, waiting for User 1 to RESUME the call on the Cisco IP Phone.   Normal calls direct from Cisco IP Phones through the CUBE work fine. Initiating calls from internal Cisco IP Phones to Cisco IP Phones, the mobility functionality through the CUBE works fine The issue is only apparent when a call comes in from the outside via the VGW.   Initially I thought this was a H323 Gateway to SIP Early Offer interoperatibility issue. So I changed the Voice Gateway protocol to use SIP and I continue to get the same issue.   I do not want to use an MTP for every call and I only wish to use our preferred codecs (G711ulaw or G711alaw) I assume the best solution would be for CUCM to send SDP information in the second INVITE? How can I achieve this?   VGW and CUBE IOS version is: 152-4.M5 CUCM Version is 9.1.212900-11   SIP Profiles: Trunk Configuration {Checked} Early Offer support for voice and video calls (insert MTP if needed) {Checked} Send send-receive SDP in mid-call INVITE   All Trunks have access to Media resources such as hardware and software MTPs.    Any assistance would be much appreciated.       ... View more