GetServerInfo from CallManager 5

Hi,
I'm trying to use the GetServerInfo method implemented in the RisPort service.
When calling this method I always get the following error:
2007-07-17 12:31:52,301 INFO [http-8443-Processor18] security.RequestRateControl - http://schemas.cisco.com/ast/soap/action/#PerfmonPort#GetServerInfo
2007-07-17 12:31:53,533 INFO [http-8443-Processor18] risport.RisBindingImpl - https://xx.xx.xx.xx:8443/realtimeservice/services/RisPort
2007-07-17 12:31:53,548 ERROR [http-8443-Processor18] risport.CiscoSoapClientTestTrustManager - Exception in loadKeyStore() java.io.IOException: Keystore was tampered with, or password was incorrect
I know my username/password are correct because other RisPort functions like SelectCmDevice works fine.
Does anyone know how to solve this?

I have been able to successfully call GetServerInfo using Eclipse's auto generated Web Services Client (It uses Apache Axis to read a WSDL and generate all the code to call a web service). Took me 10 mins to be up and running. I am thinking to post a blog on it. There is a way to trust the SSL certificate without importing it.
What tool are you using to generate WS client?

Similar Messages

TCL script from CallManager

Hello. Does anybody know about the ability of CallManager to run applications on gateway? (for example, tcl scripts).
Thank You for any advice

Hi marchine,
I've ccm doing H.323 with Gateway. I want to run default AA script on Gateway.
1) Will the default AA script which comes for CME work with CCM also?
2) How would Gateway know about the extension numbers. Will it simply forward the digits to CCM based on VOIP dial-peer?
Thanks,
inner_silence

Extract Call Detail Record from CME

Hi,
How can I extract the CDR from a CME, if i don't have a CVM. I wanna use it with a mySQL Database.
Thank you.

Thanks for the plug, David.
I'm the author of qqCDR. It is capable of pulling from CallManager, but not CME (unless there is a SQL interface that I don't know of - somebody emailed me asking just this question, I'm looking into a way to possibly code a solution around CME once I get a little more info. The last I knew, CME could only spit out CDR to syslog, for later parsing. Has this changed?

Callmanager 8.0.2(C)

i'm trying to upgrade from callmanager System version: 7.1.2.20000-2 to 8.0.2.40000-1. is direct mode supported?
Thanks

It shows as supported:
Table 4 Supported Cisco Unified Communications Manager Upgrades for Release 8.0(x)
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr.html#wp184796
HTH
java
If this helps, please rate
www.cisco.com/go/pdihelpdesk

Calls forwarded from sip device

I am setting up a callmanager with an h323 gateway.
for incoming and outgoing calls , the customer wants the calls passed to the H323 gateway and then passed to another gateway within the Lan, which has a SIP trunk to the outside world.
Is it just a simple case of having a H323 dial peer on each gateway to pass calls to and from callmanager?

Yes, you need to have the ff dial-peers
On h323 gateway
1. inbound h323 dial-peer from cucm to h323 gateway
2. outbound h323 dial-peer to cucm from h323 gateway
3. Outbound sip-dial-peer from h323 gateway to the sip gateway
4. inbound sip dial-peer from sip gateway to h323 gateway
On SIP gateway
5. inbound sip dial-peer for calls from h323 gateway to sip gateway
6. outbound sip dial-peer to h323 gateway
7. outbound dial-peer for PSTN calls to ITSP
8. You may also have inbound dial-peer from ITSP for inbound PSTN calls

SIP Calls Drop. Receive Bye From Cube 15min,30min, 45min

Hello,
Running into an odd issue. I've seen several others having this problem with calls dropping after 15min duration. But this is a bit different. Sometimes long duration calls drop at 15min. Some at 30min, others at 45min. And sometimes not at all. Call flow is such.
8831-sip--CUCM--sip--Cube--ITSP
I'm convinced this is likely a problem with the refresh timer. But I can't explain why it wouldn't just fail only at 15min. It's also interesting to note I've only seen this on the 8831. I tried getting the issue with debugs from the cube but of course it didn't happen once I turned on ccsip message.
From the callmanager traces I see the bye arrive from cube with Reason Q.850 cause=102.
The CUCM version is 9.1.2 and cube is 15.2(4)M1. I did see some odd defect in 15.1 related to this where the refresh on the cube would send out 3 invites to the ITSP on an update. I guess it would have only 33% chance of getting it right. Any help someone could provide I'd appreciate it.

Thanks for the replies.
So was able to capture it while had debugs running. This time it disconnected after an hour. Same cause=102.
Now here is where it gets interesting in the debugs. I see an invite is sent 3 seconds from callmanager. I assume this is a refresher with the same call-id. Cube receives it and sends out to ITSP. With a new call-id. We then receive a bye from ITSP cause=86. Which then of course is sent to callmanager. Here are the relevent sections of debugs.
Received from cucm to cube:
820421: May 6 09:00:42.976: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:43           2365082: Received:
2014-05-06 09:00:43           2365083: INVITE sip:[email protected]:5060;transport=tcp SIP/2.0
2014-05-06 09:00:43           2365084: Via: SIP/2.0/TCP 10.38.246.136:5060;branch=z9hG4bK28bab16dbd5664
2014-05-06 09:00:43           2365085: From: "Marcos Vazquez" <sip:[email protected]>;tag=3831180~dfbf10b3-6c69-4443-852f-cbf609935a6f-35009402
2014-05-06 09:00:43           2365086: To: <sip:[email protected]>;tag=5EBA2282-19C8
2014-05-06 09:00:43           2365087: Date: Tue, 06 May 2014 15:00:42 GMT
2014-05-06 09:00:43           2365088: Call-ID: [email protected]
2014-05-06 09:00:43           2365089: Supported: 100rel,timer,resource-priority,replaces
2014-05-06 09:00:43           2365090: Min-SE: 1800
2014-05-06 09:00:43           2365091: User-Agent: Cisco-CUCM9.1
2014-05-06 09:00:43           2365092: Allow: INVITE, OPTIONS, I
2014-05-06 09:00:43           2365093: NFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
2014-05-06 09:00:43           2365094: CSeq: 106 INVITE
2014-05-06 09:00:43           2365095: Max-Forwards: 70
2014-05-06 09:00:43           2365096: Expires: 300
2014-05-06 09:00:43           2365097: Allow-Events: presence, kpml
2014-05-06 09:00:43           2365098: Supported: X-cisco-srtp-fallback
2014-05-06 09:00:43           2365099: Supported: Geolocation
2014-05-06 09:00:43           2365100: P-Asserted-Identity: "Marcos Vazquez" <sip:[email protected]>
2014-05-06 09:00:43           2365101: Remote-Party-ID: "Marcos Vazquez" <sip:[email protected]>;party=calling;screen=yes;privacy=off
2014-05-06 09:00:43           2365102: Contact: <sip:[email protected]:5060;transport=tcp>
2014-05-06 09:00:43           2365103: Content-Type: application/sdp
2014-05-06 09:00:43           2365104: Content-Length: 371
2014-05-06 09:00:43           2365105:
2014-05-06 09:00:43           2365106: v=0
2014-05-06 09:00:43           2365107: o=CiscoSystemsCCM-
2014-05-06 09:00:43           2365108: SIP 3831180 1 IN IP4 10.38.246.136
2014-05-06 09:00:43           2365109: s=SIP Call
2014-05-06 09:00:43           2365110: c=IN IP4 10.96.5.28
2014-05-06 09:00:43           2365111: b=TIAS:64000
2014-05-06 09:00:43           2365112: b=AS:64
2014-05-06 09:00:43           2365113: t=0 0
2014-05-06 09:00:43           2365114: m=audio 31146 RTP/AVP 18 0 116 101
2014-05-06 09:00:43           2365115: a=rtpmap:0 PCMU/8000
2014-05-06 09:00:43           2365116: a=ptime:20
2014-05-06 09:00:43           2365117: a=rtpmap:116 iLBC/8000
2014-05-06 09:00:43           2365118: a=ptime:20
2014-05-06 09:00:43           2365119: a=maxptime:60
2014-05-06 09:00:43           2365120: a=fmtp:116 mode=20
2014-05-06 09:00:43           2365121: a=rtpmap:18 G729/8000
2014-05-06 09:00:43           2365122: a=ptime:20
2014-05-06 09:00:43           2365123: a=fmtp:18 annexb=no
2014-05-06 09:00:43           2365124: a=rtpmap:101 telephone-event/8000
2014-05-06 09:00:43           2365125: a=fmtp:101 0-15
2014-05-06 09:00:43           2365126: 5820422: May 6 09:00:42.978: //3024943/CC044C80000B/SIP/Msg/ccsipDisplayMsg:
Sent to ITSP:
Sent: Which looks like 3 are sent.
2014-05-06 09:00:43           2365128: INVITE sip:12.194.190.26:5060;transport=udp SIP/2.0
2014-05-06 09:00:43           2365129: Via: SIP/2.0/UDP 12.17.223.243:5060;branch=z9hG4bK2D699C1126
2014-05-06 09:00:43           2365130: P-Asserted-Identity: "Marcos Vazquez" <sip:[email protected]>
2014-05-06 09:00:43           2365131: From: "Marcos Vazquez" <sip:[email protected]>;tag=5EBA1628-22FC
2014-05-06 09:00:43           2365132: To: <sip:[email protected]>;tag=8088820710430052_c2b05.1.1.1385369448756.0_9843675_19511361
2014-05-06 09:00:43           2365133: Date: Tue, 06 May 2014 15:00:42 GMT
2014-05-06 09:00:43           2365134: Call-ID: [email protected]
2014-05-06 09:00:43           2365135: Supported: 100rel,timer,resource-priority,replaces,sdp-an
2014-05-06 09:00:43           2365136: at
2014-05-06 09:00:43           2365137: Min-SE: 1800
2014-05-06 09:00:43           2365138: Cisco-Guid: 3422833792-0000065536-0000746374-2297832970
2014-05-06 09:00:43           2365139: User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:43           2365140: Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
2014-05-06 09:00:43           2365141: CSeq: 105 INVITE
2014-05-06 09:00:43           2365142: Max-Forwards: 70
2014-05-06 09:00:43           2365143: Timestamp: 1399388442
2014-05-06 09:00:43           2365144: Contact: <sip:[email protected]:5060>
2014-05-06 09:00:43           2365145: Expires: 60
2014-05-06 09:00:43           2365146: Allow-Events: telephone-event
2014-05-06 09:00:43           2365147: Content-Type: application/sdp
2014-05-06 09:00:43           2365148: Content-Length: 334
2014-05-06 09:00:43           2365149:
2014-05-06 09:00:43           2365150: v=0
2014-05-06 09:00:43           2365151: o=CiscoSystemsSIP-GW-UserAgent 8182 4488 IN IP4 12.17.223.243
2014-05-06 09:00:43           2365152: s=SIP Call
2014-05-06 09:00:43           2365153: c=IN IP4 1
2014-05-06 09:00:43           2365154: 2.17.223.243
2014-05-06 09:00:43           2365155: t=0 0
2014-05-06 09:00:43           2365156: m=audio 18760 RTP/AVP 18 0 100 101
2014-05-06 09:00:43           2365157: c=IN IP4 12.17.223.243
2014-05-06 09:00:43           2365158: a=rtpmap:18 G729/8000
2014-05-06 09:00:43           2365159: a=fmtp:18 annexb=no
2014-05-06 09:00:43           2365160: a=rtpmap:0 PCMU/8000
2014-05-06 09:00:43           2365161: a=rtpmap:100 X-NSE/8000
2014-05-06 09:00:43           2365162: a=fmtp:100 192-194
2014-05-06 09:00:43           2365163: a=rtpmap:101 telephone-event/8000
2014-05-06 09:00:43           2365164: a=fmtp:101 0-15
2014-05-06 09:00:43           2365165: 5820423: May 6 09:00:42.978: //3024942/CC044C80000B/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:43           2365166: Sent:
2014-05-06 09:00:43           2365167: SIP/2.0 100 Trying
2014-05-06 09:00:43           2365168: Via: SIP/2.0/TCP 10.38.246.136:5060;branch=z9hG4bK28bab16dbd5664
2014-05-06 09:00:43           2365169: From: "Marcos Vazquez" <sip:[email protected]>;tag=3831180~dfbf10b3-6c69-4443-852f-cbf609935a6f-35009402
2014-05-06 09:00:43           2365170: To: <sip:[email protected]>;tag=5EBA2282-19C8
2014-05-06 09:00:43           2365171: Date: Tue, 06 May 2014 15:00:42 GMT
2014-05-06 09:00:43           2365172: Call-ID: [email protected]
2014-05-06 09:00:43           2365173: CSeq: 106 INVITE
2014-05-06 09:00:43           2365174: Allow-Events: telephone-event
2014-05-06 09:00:43           2365175: Server: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:43           2365176: Content-Length: 0
2014-05-06 09:00:43           2365177:
2014-05-06 09:00:43           2365178: 5820424: May 6 09:00:43.479: //3024943/CC044C80000B/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:43           2365179: Sent:
2014-05-06 09:00:43           2365180: INVITE sip:12.194.190.26:5060;transport=udp SIP/2.0
2014-05-06 09:00:43           2365181: Via: SIP/2.0/UDP 12.17.223.243:5060;branch=z9hG4bK2D699C1126
2014-05-06 09:00:43           2365182: P-Asserted-Identity: "Marcos Vazquez" <sip:[email protected]>
2014-05-06 09:00:43           2365183: From: "Marcos Vazquez" <sip:[email protected]>;tag=5EBA1628-22FC
2014-05-06 09:00:43           2365184: To: <sip:[email protected]>;tag=8088820710430052_c2b05.1.1.1385369448756.0_9843675_19511361
2014-05-06 09:00:43           2365185: Date: Tue, 06 May 2014 15:00:43 GMT
2014-05-06 09:00:43           2365186: Call-ID: [email protected]
2014-05-06 09:00:43           2365187: Supported: 100rel,timer,resource-priority,replaces,sdp-an
2014-05-06 09:00:43           2365188: at
2014-05-06 09:00:43           2365189: Min-SE: 1800
2014-05-06 09:00:43           2365190: Cisco-Guid: 3422833792-0000065536-0000746374-2297832970
2014-05-06 09:00:43           2365191: User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:43           2365192: Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
2014-05-06 09:00:43           2365193: CSeq: 105 INVITE
2014-05-06 09:00:43           2365194: Max-Forwards: 70
2014-05-06 09:00:43           2365195: Timestamp: 1399388443
2014-05-06 09:00:43           2365196: Contact: <sip:[email protected]:5060>
2014-05-06 09:00:43           2365197: Expires: 60
2014-05-06 09:00:43           2365198: Allow-Events: telephone-event
2014-05-06 09:00:43           2365199: Content-Type: application/sdp
2014-05-06 09:00:43           2365200: Content-Length: 334
2014-05-06 09:00:43           2365201:
2014-05-06 09:00:43           2365202: v=0
2014-05-06 09:00:43           2365203: o=CiscoSystemsSIP-GW-UserAgent 8182 4488 IN IP4 12.17.223.243
2014-05-06 09:00:43           2365204: s=SIP Call
2014-05-06 09:00:43           2365205: c=IN IP4 1
2014-05-06 09:00:44           2365206: 2.17.223.243
2014-05-06 09:00:44           2365207: t=0 0
2014-05-06 09:00:44           2365208: m=audio 18760 RTP/AVP 18 0 100 101
2014-05-06 09:00:44           2365209: c=IN IP4 12.17.223.243
2014-05-06 09:00:44           2365210: a=rtpmap:18 G729/8000
2014-05-06 09:00:44           2365211: a=fmtp:18 annexb=no
2014-05-06 09:00:44           2365212: a=rtpmap:0 PCMU/8000
2014-05-06 09:00:44           2365213: a=rtpmap:100 X-NSE/8000
2014-05-06 09:00:44           2365214: a=fmtp:100 192-194
2014-05-06 09:00:44           2365215: a=rtpmap:101 telephone-event/8000
2014-05-06 09:00:44           2365216: a=fmtp:101 0-15
2014-05-06 09:00:44           2365217: 5820425: May 6 09:00:44.479: //3024943/CC044C80000B/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:44           2365218: Sent:
2014-05-06 09:00:44           2365219: INVITE sip:12.194.190.26:5060;transport=udp SIP/2.0
2014-05-06 09:00:44           2365220: Via: SIP/2.0/UDP 12.17.223.243:5060;branch=z9hG4bK2D699C1126
2014-05-06 09:00:44           2365221: P-Asserted-Identity: "Marcos Vazquez" <sip:[email protected]>
2014-05-06 09:00:44           2365222: From: "Marcos Vazquez" <sip:[email protected]>;tag=5EBA1628-22FC
2014-05-06 09:00:44           2365223: To: <sip:[email protected]>;tag=8088820710430052_c2b05.1.1.1385369448756.0_9843675_19511361
2014-05-06 09:00:44           2365224: Date: Tue, 06 May 2014 15:00:44 GMT
2014-05-06 09:00:44           2365225: Call-ID: [email protected]
2014-05-06 09:00:44           2365226: Supported: 100rel,timer,resource-priority,replaces,sdp-an
2014-05-06 09:00:44           2365227: at
2014-05-06 09:00:44           2365228: Min-SE: 1800
2014-05-06 09:00:44           2365229: Cisco-Guid: 3422833792-0000065536-0000746374-2297832970
2014-05-06 09:00:44           2365230: User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:44           2365231: Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
2014-05-06 09:00:44           2365232: CSeq: 105 INVITE
2014-05-06 09:00:44           2365233: Max-Forwards: 70
2014-05-06 09:00:44           2365234: Timestamp: 1399388444
2014-05-06 09:00:44           2365235: Contact: <sip:[email protected]:5060>
2014-05-06 09:00:44           2365236: Expires: 60
2014-05-06 09:00:44           2365237: Allow-Events: telephone-event
2014-05-06 09:00:44           2365238: Content-Type: application/sdp
2014-05-06 09:00:44           2365239: Content-Length: 334
2014-05-06 09:00:44           2365240:
2014-05-06 09:00:44           2365241: v=0
2014-05-06 09:00:44           2365242: o=CiscoSystemsSIP-GW-UserAgent 8182 4488 IN IP4 12.17.223.243
2014-05-06 09:00:44           2365243: s=SIP Call
2014-05-06 09:00:44           2365244: c=IN IP4 1
2014-05-06 09:00:44           2365245: 2.17.223.243
2014-05-06 09:00:44           2365246: t=0 0
2014-05-06 09:00:44           2365247: m=audio 18760 RTP/AVP 18 0 100 101
2014-05-06 09:00:44           2365248: c=IN IP4 12.17.223.243
2014-05-06 09:00:44           2365249: a=rtpmap:18 G729/8000
2014-05-06 09:00:44           2365250: a=fmtp:18 annexb=no
2014-05-06 09:00:44           2365251: a=rtpmap:0 PCMU/8000
2014-05-06 09:00:44           2365252: a=rtpmap:100 X-NSE/8000
2014-05-06 09:00:44           2365253: a=fmtp:100 192-194
2014-05-06 09:00:44           2365254: a=rtpmap:101 telephone-event/8000
2014-05-06 09:00:44           2365255: a=fmtp:101 0-15
2014-05-06 09:00:45           2365256: 5820426: May 6 09:00:45.147: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:45           2365257: Received:
And then I don't see a response then send out a bye:
Sent:
2014-05-06 09:00:46           2365897: BYE sip:12.194.190.26:5060;transport=udp SIP/2.0
2014-05-06 09:00:46           2365898: Via: SIP/2.0/UDP 12.17.223.243:5060;branch=z9hG4bK2D69A54BC
2014-05-06 09:00:46           2365899: From: "Marcos Vazquez" <sip:[email protected]>;tag=5EBA1628-22FC
2014-05-06 09:00:46           2365900: To: <sip:[email protected]>;tag=8088820710430052_c2b05.1.1.1385369448756.0_9843675_19511361
2014-05-06 09:00:46           2365901: Date: Tue, 06 May 2014 15:00:44 GMT
2014-05-06 09:00:46           2365902: Call-ID: [email protected]
2014-05-06 09:00:46           2365903: User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:46           2365904: Max-Forwards: 70
2014-05-06 09:00:46           2365905: P-Asserted-Identity: "Marcos Vazquez" <sip:[email protected]>
2014-05-06 09:00:46           2365906: Timestamp: 1399388446
2014-05-06 09:00:46           2365907: CSeq: 106 BYE
2014-05-06 09:00:46           2365908: Reason: Q.850;cause=86
2014-05-06 09:00:46           2365909: P-RTP-Stat: PS=180295,OS=3604444,PR=180354,OR=3607080,PL=0,JI=0,LA=0,DU=3603
2014-05-06 09:00:46           2365910: Content-Length: 0
2014-05-06 09:00:46           2365911:
2014-05-06 09:00:46           2365912: 5820458: May 6 09:00:46.479: //3024942/CC044C80000B/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:46           2365913: Sent:
2014-05-06 09:00:46           2365914: BYE sip:[email protected]:5060;transport=tcp SIP/2.0
2014-05-06 09:00:46           2365915: Via: SIP/2.0/TCP 10.38.246.166:5060;branch=z9hG4bK2D69A6E75
2014-05-06 09:00:46           2365916: From: <sip:[email protected]>;tag=5EBA2282-19C8
2014-05-06 09:00:46           2365917: To: "Marcos Vazquez" <sip:[email protected]>;tag=3831180~dfbf10b3-6c69-4443-852f-cbf609935a6f-35009402
2014-05-06 09:00:46           2365918: Date: Tue, 06 May 2014 15:00:42 GMT
2014-05-06 09:00:46           2365919: Call-ID: [email protected]
2014-05-06 09:00:46           2365920: User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:46           2365921: Max-Forwards: 70
2014-05-06 09:00:46           2365922: Timestamp: 1399388446
2014-05-06 09:00:46           2365923: CSeq: 101 BYE
2014-05-06 09:00:46           2365924: Reason: Q.850;cause=102
2014-05-06 09:00:46           2365925: P-R
2014-05-06 09:00:46           2365926: TP-Stat: PS=180239,OS=3604780,PR=180295,OR=3604444,PL=0,JI=0,LA=0,DU=3603
2014-05-06 09:00:46           2365927: Content-Length: 0
2014-05-06 09:00:46           2365928:

Callback between HiPath 4000 and Callmanager 6.1

Hello Community,
I am currently facing the issue that the call back feature is not working from Callmanager to Siemens, only vice versa.
Callmanager <-----MGCP---->GW-<----QISG ISO---> HiPath
Have somebody of you experience in this topic and can give me a advise where I can start looking to resolve this issue?
Thank you!

Hi
I'm expect you mean the CallBack feature as in 'user is busy, press callback, get alerted when he isn't'...
There are some Service Parameters under the CallManager service, which allow you to customize how this works... documents on Cisco.com suggest the defaults should be OK.
Hipath -> CCM6, ECMA: http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/pbx/interop/notes/607736nt.pdf
Hipath -> CCM6, ISO : http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/pbx/interop/notes/603504nt.pdf
Similar docs from Avaya (http://support.avaya.com/css/P8/documents/100011769) suggest that callback might be configurable on the HiPath as part of the CoS applied to the trunk, maybe get the HiPath engineer to verify it is configured... or if you have, try switching it from ISO to ECMA and see if the functionality changes.
Have you had a look what is being logged when you attempt callback?
Aaron
Please rate helpful posts...

Problem with PRI and Nortel Integration

We have a Nortel Option 81C connected to a 3825 MGCP gateway and we had a weird problem with it. The PRI looked fine from CallManager's perspective, but the PBX was showing that the first nine channels were in a Far End Make Busy state (FE MBSY) instead of being in IDLE state like CCM thought.
I did some checking around and found a weird "fix" for the problem that involved enabling and then disabled D-channel service messages on the PBX, but I'd like to find out more about this problem. I got the fix from a guy who has a LOT of experience with Nortel and with Cisco, and he said that 99 times out of 100, an FE MBSY problem like this is going to be because of the Cisco side, not the Nortel side.
I just did a bug search through CCM 4.1(3) and IOS 12.4(8) and I didn't see anything about D-channels being incorrectly reported as unavailable on PRI.
Have any of you ever heard of something like this?
Thanks!
John

John,
Our 81Cs are long gone, but the only ISDN switchtype that worked flawlessly for us was NI. We tried DMS100, and saw your problem. Nortel sees NI as a carrier side protocol and will not allow an inbound NI call to tandem through to another NI PRI. This forced us move all PSTN PRIs to CCM gateways early in out migration, but worked out well. I believe QSIG will also work, but it was a $20k upgrade for our PBXs, so was not an option.
Dave

How to block alternate match on a voicegateway?

Hello,
i need configuration support for a voicegateway.
we have two mainnumbers, which are connected by a BRI-interface and a E1-interface.
When they call outside with accesscode = 0, they reache the phone provider and get connected,
But in my example, we have two matching destination-pattern = 0T and .T
When they forget to dial the accesscode, the BRI-Interface with destination-pattern .T is still working and the number manipulation is wrong.
We use H323 to CUCM. MGCP is currently not an option for us.
How can i prevent that on the voicegateway easily?
voice-port 0/0/0:15
description *** E1 ***
input gain 3
echo-cancel coverage 32
no comfort-noise
cptone DE
bearer-cap 3100Hz
voice-port 0/1/0
description *** BRI 1 ***
no vad
compand-type a-law
cptone DE
dial-peer voice 1 pots
description *** E1 ***
tone ringback alert-no-PI
progress_ind setup enable 3
destination-pattern 0T
direct-inward-dial
port 0/0/0:15
dial-peer voice 2 pots
description *** BRI 1 ***
destination-pattern .T
direct-inward-dial
port 0/1/0

I tried it with a prefix, but this is not helpfull. As soon as the setup from callmanager reaches the voicegateway, i only can use a matching destination pattern, what activates a translationrule. My thinking was to seperate both mainnumbers, but for incoming calls this is not a problem, only for outgoing.
Peer my understanding, the call is coming from callmanager. This is matching an incoming dialpeer, where i can use translationrules. The same behavior will apply for outgoing dialpeer to phoneprovider.
My thinking and still my hope, is to use a prefix for all incoming calls from callmanager, which matches the proper outgoing dialpeer.
In your translation-profiles you can apply your translation-rules to either calling, called, or redirect called party numbers. You can do your digit manipulation at that point to remove your prefix.
It also sounds like you're dealing with hunting issues. In addition to the preference commands, you can also use the huntstop and even permission commands to limit hunting and add hard incoming/outgoing limitations to your dial-peers.
Although I may have completely misunderstood the issue in which case please ignore.
thanks,
will

SIP 400 Bad Request

I'm getting a bad request error when attempting to an outbound SIP call on a IP2IP gateway (H323 -> SIP).
It's a slightly odd configuration as we will only be using this route for outgoing calls only. The only error message I get is:
//-1/xxxxxxxxxxxx/SIP/Error/sipsdp_add_standard_lines: media_src_address is NULL; c-line is not added
SIP Invite message:
Sent:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK11222C
From: "anonymous" <sip:[email protected]>;tag=404CF30-282
To: <sip:[email protected]>
Date: Wed, 16 May 2007 13:09:44 GMT
Call-ID: [email protected]
Supported: 100rel,timer
Min-SE: 1800
Cisco-Guid: 15103203-2971783453-520093696-2887190163
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=full
Timestamp: 1179320984
Contact: <sip:[email protected]:5060>
Call-Info: <sip:192.168.1.1:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
May 16 13:09:44.608 UTC: //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpSocketReads: Msg enqueued for SPI with IP addr: 192.168.1.2:5060
May 16 13:09:44.608 UTC: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg: context=0x00000000
May 16 13:09:44.608 UTC: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK11222C
From: "anonymous" <sip:[email protected]>;tag=404CF30-282
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 101 INVITE
User-Agent: 2N StarGate V-02.20.47
Allow: INVITE, BYE, ACK, CANCEL, OPTIONS
Content-Length: 0
Any ideas?

For what its worth, I had the same problem from Callmanager to an IOS IPIPGW. I was getting the SIP/2.0 400 Bad Request - 'Malformed/Missing Contact field' error message. Turns out I had mistyped my caller id mask and was sending characters in place of numbers. By correcting it, my problem went away.
Todd

UCCX 7 audio prompts problem - sound distorted

Hi,
We have a UCCX 7 system which holds many IVR prompts, lately we added a new audio prompt to be played if users are waiting in the queue of the IVR.
The prompt is being played normally but at some points of the prompt the sound is a little distorted, it is a music ad, and when the music gets high the sound is some how distored which is not accepted by our management.
The file specifications are like the rest of the prompts which is::
1. Bit Rate= 64kbps
2. Audio sample size= 8 bit
3. Channels = 1 (mono)
4. Audio sample rate = 8khz
5. Audio format = u-law
The codecs of the prompts is G.711.
Apreciate any assistance please, thanks a lot.

Hi
No, if you run G729 you will get poor quality music. It's just a function of the way that G729 works.
The option you mentioned makes UCCX run G729 prompts natively - if all communications to/from the UCCX server need to run G729, there's no point sending them out at g711 and having to transcode everyting. Conversely if you mainly use G711, you would have UCCX run G711 prompts so that you don't lose audio quality for no good reason.
If you need good quality, then you can do one of these two things IF your music is just played in between the prompts. If you have prompts created with background music embedded in it then you can't do this:
1) stream the music as G711 from CallManager by ensuring the MoH server is in a region that allows g711 between it and your PSTN gateways on the remote site
2) stream the music as G711 from the local gateway using multicast; there are lots of references on how to do this on this forum and on cisco.com.
If you have background music mixed in with the voice in your prompts, and you need good quality then your only real option is to stop using G729, or start again with voice-only prompts and an MoH solution as suggested above.
Regards
Aaron
Please rate helpful posts and mark answered questions that you've got a satisfactory response from to help identify useful content in the forums...
https://supportforums.cisco.com/docs/DOC-6212

VoIP Upgrade to 10.5

We are in the process of planning our upgrade from CallManager 8.5 to 10.5 and we have some questions. We will also be upgrading Unity, Presence, Attendant Console, Contact Center, and Emergency Responder. The question concerns Emergency Responder. Per docs on Cisco website, it is recommended to upgrade Emergency Responder prior to CallManager. We are taking our VoIP infrastructure to Cisco UCS and we are discussing the best way to do this. We pretty much have CallManager figured out, but with Emergency Responder we are looking to do a P-to-V of the physical MCS box to ESXi on UCS. Once we P-to-V the Emergency Responder we plan on upgrading to the latest version which should be 10.5 or 10.0 at the minimum. Is Emergency Responder 10.5 or 10.0 compatible with CallManager 8.5. I don't believe it will be, but the reason is we would like to upgrade Emergency Responder prior to upgrading CallManager. Would like to hear what other members of the forum have done when upgrading Emergency Responder.

The RNs for CER cover compatibility with CUCM, you can find them on CCO.

Can't import CTI Ports in CUE 3.1

Hi Everyone,
I have recently migrated CallManager 4.1 to CUCM 7.1. Everything is working fine but CUE is not able to integrate with CUCM 7.1
I have provided the new credentials for Admin User and JTAPI user in CUE 3.1 and also made a new application user in CUCM 7.1.
When I verify CallManager Admin User in CUE web interface it shows Admin login successful, JTAPI login successful.
But when I try to search and import CTI Ports from CallManager, it shows me the error IOException: No such attribute.
Can anyone please help me with this issue?
Thanks,
Amit.

Hi
See this compatibility chart:
http://www.cisco.com/en/US/docs/voice_ip_comm/unity_exp/compatibility/cuecomp.htm#CUCM
To run CM7.1, you need to be running 3.2.1 of CUE as a minimum.
Regards
Aaron
Please rate helpful posts...

MCS Server Sizing

Just looking for a general idea on MCS server sizing for CCM and IPCC Express. I understand actual sizing needs to be done by a partner with the Cisco tool.
My understanding from SRND is that all servers within a CCM cluster should be the same size (7835's, 7845's, etc.).
Does that mean my IPCC Express servers should be the same size/model as well?
Conceptually, would it be ok to use 7845's for my CCM cluster and 7835's for IPCC Express? (provided the sizing is independently appropriate).
Thanks.

The choice of servers for IPCC express is completely independent from Callmanager hardware. Regarding the servers in the CCM cluster being the same, its generally a good practice to keep them all the same. (Though, you definitely can have a 7835 for your Subscriber and 7845 for Publisher, no big deal).
Now for IPCC Express, the choice of server requirement is based on, many factors.
a. Just like Callmanager assigns weights to devices, IPCC Express assigns weights or points to various features such as (number of Recording sessions, number of Historical reporting sessions, ASR/TTS, total number of agents, supervisors, IVR ports etc. If your server doesnt meet the total number of points required for all the features you need, then you need to use the next higher model. So a 7825 has 900 points, 7835 has 1266 points, 7845 has i think about 3400 points. You have to use a spreadsheet available for download (called CRS configuration tool) which tells you the right hardware you need for the IPCC features that is required for your call center.
7845s are same as 7835s except that 7845s have dual processors, 2 extra hard disks, RAID 5 etc. You may need a 7845 if you need upto two HR sessions during business hours.
HTH
Sankar
PS: please remember to rate posts!

Agent logged out suddenly, reason code:50003

Hi,
We have icm 8.0(3) and cad 8.
Sometimes, an agent (each time a different one) is logged out suddenly and he get the reason code: 50003
Please find attached a logout status report that is showing the agent using extension “7459” has been logged out at 13:48:50 and reason code “50003”
I am attaching the CM-pim, opc and ctios logs as well
did anyone have been faced by a simalar issue?
Thanks in advance
Georges

Reason code 50003 says
50003 - Device Failure log out. Call Manager reported that the device is out of service.
From the below trace you can see that PIM has recieved an outofservice event from jgw and we dont have jgw logs but jgw is simply passing the events it received from callmanager.
    Line 9: 13:44:46:595 PG1B-pim1 Trace: RecvAddressOutOfService: Couldn't find client stack for device target device string 800
    Line 12: 13:44:47:939 PG1B-pim1 Trace: RecvAddressOutOfService: Couldn't find client stack for device target device string 7459
    Line 18: 13:46:12:784 PG1B-pim1 Trace: RecvAddressOutOfService: Couldn't find client stack for device target device string 800
    Line 19: 13:46:20:065 PG1B-pim1 Trace: RecvAddressOutOfService: Couldn't find client stack for device target device string 7459
    Line 43: 13:48:51:021 PG1B-pim1 Trace: RecvAddressOutOfService: Couldn't find client stack for device target device string 800
so you need to investigate why callmanager is reporting out of service event for these phones, if you are using extension mobility and when the user logs out you could see similar messages in the jgw/pim logs
From the PG side you could
-check the connectivity with callmanager,
- check the switch port setting are as per BOM (auto/auto if using gigi interfaces)
- check that the TCP chimney has been disabled on the PG
https://supportforums.cisco.com/docs/DOC-9222
- check PG eventvwr logs to see if you get any clues
If it doesnt help, collect the callmanager SDI/SDL and CTIManager SDI/SDL logs at Detailed level and open a TAC case with CUCM team to investigate why phones are reported as outof service to PG
Thanks,
Shirish

GetServerInfo from CallManager 5

Similar Messages

Maybe you are looking for