Hi guys,   We have a client who had an 8.6 cluster with an EMCC connection to another 8.6 cluster.   We have upgraded the client to 10.5, changed hostnames, cluster ID and re-signed certificates. As part of this, we re-performed the export of certificates for EMCC on both clusters, the consolidation and import.   We re-added the remote cluster on 10.5 and everything looks fine. We see "Remote Activated: True", the IP addresses of the pub and sub on the 8.6 cluster.   When the 8.6 side tries to add us as a new cluster, they get a message which says "Remote Cluster Update Failed: Lost Communication to default and backup server".   The only thing different is on 10.5, we are using FQDN and this is what is set in default and backup server in EMCC feature configuration. We have checked routing and DNS resolution and all seems to be correct.   Thanks Sean ... View more

Hi all,   I am having a problem restricting outgoing CLID on calls made via a SIP trunk from CUCM to a PRI gateway.   We were previously on CUCM v7 and have now upgraded to 10.5 and as part of this, have converted all our H323 gateways to SIP. We have one branch office which wants to restrict the CLID on all outgoing calls, and previously this was just set to restrict on the H323 gateway config within Call Manager and seemed to work correctly - with the SIP trunk, I cannot get this to work.   I have tried to restrict it on the trunk config, using a calling party transform mask, and also by adding "clid restrict" to the incoming VOIP dial-peer from CUCM and the outgoing POTS dial-peer to the PSTN.   The SIP leg of the call seems to come in with anonymous in the invite, but has the PAI and Remote party, so I'm wondering if this is potentially causing the issue. In this case I am calling a UK mobile (0044XXX) - the number ending in 80 is the calling number:   *Jan 19 15:02:38.274: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: INVITE sip:0044XXXXXX7143@10.19.11.253:5060 SIP/2.0 Via: SIP/2.0/TCP 10.19.99.241:5060;branch=z9hG4bK161553e57dee3 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=2871972~cc22c68e-4888-4e0d-972e-1fcb1cce5a16-79960756 To: <sip:0044XXXXXX7143@10.19.11.253> Date: Mon, 19 Jan 2015 15:06:19 GMT Call-ID: b79cad00-4bd11d6b-14447-f163130a@10.19.99.241 Supported: timer,resource-priority,replaces Min-SE: 1800 User-Agent: Cisco-CUCM10.5 Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY CSeq: 101 INVITE Expires: 180 Allow-Events: presence, kpml Supported: X-cisco-srtp-fallback,X-cisco-original-called Call-Info: <sip:10.19.99.241:5060>;method="NOTIFY;Event=telephone-event;Duration=500" Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP Cisco-Guid: 3080498432-0000065536-0000000839-4049801994 Session-Expires: 1800 P-Asserted-Identity: <sip:+4122XXXXX80@10.19.99.241> Privacy: id Remote-Party-ID: <sip:+4122XXXXX80@10.19.99.241>;party=calling;screen=yes;privacy=full Contact: <sip:10.19.99.241:5060;transport=tcp> Max-Forwards: 69 Content-Type: application/sdp Content-Length: 358 v=0 o=CiscoSystemsCCM-SIP 2871972 1 IN IP4 10.19.99.241 s=SIP Call c=IN IP4 10.19.20.6 b=TIAS:64000 b=AS:64 t=0 0 m=audio 22084 RTP/AVP 0 8 116 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:116 iLBC/8000 a=maxptime:20 a=fmtp:116 mode=20 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 *Jan 19 15:02:38.282: //-1/B79CAD000000/CCAPI/cc_api_display_ie_subfields: cc_api_call_setup_ind_common: cisco-username=+4122XXXXX80 ----- ccCallInfo IE subfields ----- cisco-ani=sip:anonymous@anonymous.invalid cisco-anitype=0 cisco-aniplan=0 cisco-anipi=1 cisco-anisi=1 dest=sip:0044XXXXXX7143@10.19.11.253:5060 cisco-desttype=0 cisco-destplan=0 cisco-rdie=FFFFFFFF cisco-rdn= cisco-rdntype=0 cisco-rdnplan=0 cisco-rdnpi=-1 cisco-rdnsi=-1 cisco-redirectreason=-1 fwd_final_type =0 final_redirectNumber = hunt_group_timeout =0 *Jan 19 15:02:38.286: //-1/B79CAD000000/CCAPI/cc_api_call_setup_ind_common:    Interface=0x8A55A8E0, Call Info(    Calling Number=sip:anonymous@anonymous.invalid,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Restricted),    Called Number=sip:0044XXXXXX7143@10.19.11.253:5060(TON=Unknown, NPI=Unknown),    Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,    Incoming Dial-peer=4000, Progress Indication=NULL(0), Calling IE Present=TRUE,    Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=38491 *Jan 19 15:02:38.286: //-1/B79CAD000000/CCAPI/ccCheckClipClir:    In: Calling Number=sip:anonymous@anonymous.invalid(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Restricted) *Jan 19 15:02:38.286: //-1/B79CAD000000/CCAPI/ccCheckClipClir:    Out: Calling Number=sip:anonymous@anonymous.invalid(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Restricted) *Jan 19 15:02:38.286: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:   This part appears to be okay, and the caller ID is not shown. It then matches the outgoing POTS dial-peer and still appears to be restricted:   *Jan 19 15:02:38.290: //38491/B79CAD000000/CCAPI/ccCallSetupRequest: Destination=, Calling IE Present=TRUE, Mode=0, Outgoing Dial-peer=2001, Params=0x8BE5E150, Progress Indication=NULL(0) *Jan 19 15:02:38.290: //38491/B79CAD000000/CCAPI/ccCheckClipClir: In: Calling Number=sip:anonymous@anonymous.invalid(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Restricted) *Jan 19 15:02:38.290: //38491/B79CAD000000/CCAPI/ccCheckClipClir: Out: Calling Number=sip:anonymous@anonymous.invalid(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Restricted)   But then just underneath this:   *Jan 19 15:02:38.290: //38491/B79CAD000000/CCAPI/ccCallSetupRequest: Calling Number=sip:anonymous@anonymous.invalid(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Restricted), Called Number=0044XXXXXX7143(TON=Unknown, NPI=Unknown), Redirect Number=, Display Info= Account Number=+4122XXXXX80, Final Destination Flag=TRUE, Guid=B79CAD00-0001-0000-0000-0347F163130A, Outgoing Dial-peer=2001 *Jan 19 15:02:38.290: //38491/B79CAD000000/CCAPI/cc_api_display_ie_subfields: ccCallSetupRequest: cisco-username=+4122XXXXX80   I'm not sure where the "Account Number" is coming from and then sends the call to the PSTN via the BRI, with the calling number populated:   *Jan 19 15:02:38.294: :FEATURE_VSA attributes are: feature_name:0,feature_time:2272865472,feature_id:6711 *Jan 19 15:02:38.294: //38492/B79CAD000000/CCAPI/ccIFCallSetupRequestPrivate: SPI Call Setup Request Is Success; Interface Type=6, FlowMode=1 *Jan 19 15:02:38.294: //38492/B79CAD000000/CCAPI/ccCallSetContext: Context=0x8BE5E100 *Jan 19 15:02:38.294: //38491/B79CAD000000/CCAPI/ccSaveDialpeerTag: Outgoing Dial-peer=2001 *Jan 19 15:02:38.294: ISDN BR2 Q931: Applying typeplan for sw-type 0x1 is 0x0 0x0, Calling num +4122XXXXX80 *Jan 19 15:02:38.298: ISDN BR2 Q931: Sending SETUP callref = 0x004F callID = 0x8A88 switch = basic-net3 interface = User *Jan 19 15:02:38.298: ISDN BR2 Q931: TX -> SETUP pd = 8 callref = 0x4F Bearer Capability i = 0x9090A3 Standard = CCITT Transfer Capability = 3.1kHz Audio Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0x82 Preferred, B2 Calling Party Number i = 0x00A1, '+4122XXXXX80' Plan:Unknown, Type:Unknown Called Party Number i = 0x80, '0044XXXXXX7143' Plan:Unknown, Type:Unknown   We have another site in Poland where the "clid restrict" on the outgoing POTS dial-peer appears to work correctly. Is there a possibility that this is a carrier issue, or is there anything else I can change?   Thanks Sean ... View more

Hi all,   We are having trouble with SIP inspect on our ASA when using NAT.   The call flow is   IP Phone -> CUCM -> CUBE -> ASA -> ITSP   In the majority of cases, this is working correctly, but in some cases (maybe 1 call in 50, but frequency varies), the call is failing with a "Your call cannot be completed as dialled". I have ran CCSIP debugs on the CUBE and can see the provider is sending a "404 Route Not found". I raised a case with them, and they have told me, that in the case of a good call, the TO and REQUEST header are the correct address for the ITSP, but in a failed call, the REQUEST address is showing the address of the external interface of the firewall (instead of our NATed endpoint address).   In the case of a good call:   192.168.46.18 is our internal CUBE address and 88.215.63.169 is the ITSP signalling address. The NAT works correctly and our source address reaches the ITSP as X.X.99.51.   In the case of a failed call:   The firewall seems to build a new dynamic translation (our normal PAT for internet traffic) and does not re-write the REQUEST header correctly, and instead, sends it with an address of our external interface X.X.99.50, instead of the ITSP address.   From the ITSP point of view, they see the invite as:     From this, I can see that the SIP invite is being sent with the correct TO, FROM & VIA address, but for some reason, the Request-Line is being sent incorrectly, and the ITSP is sending me back a 404 message.   I can't explain why this is happening and why it is only happening intermittently. The firewall is running the latest version 9.3.1.   Thanks Sean ... View more