Thanks Mark for the information. That's good to know. I also found out that according to Cisco CUE best practices section in the Cisco Unified Manager SRND document, CUE version 3.0 can transcode an incoming G.729 SIP call leg. JD
CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Re: [OSL | CCIE_Voice] CUE FNA FB ProblemDate: Fri, 22 Feb 2008 06:38:14 -0500Not a limitation of UCME or IOS - it boils down to a limitation of the protocol SIP. The RFC for SIP includes no language in it about transcoding - it simply isn't supported on a SIP end-to-end call unless invoked by a proprietary method (which of course Cisco is working on that). Mark Snow CCIE #14073 (Voice, Security) CCSI #31583 Senior Technical Instructor - IPexpert, Inc. A Cisco Learning Partner - We Accept Learning Credits! Telephone: +1.810.326.1444 Fax: +1.309.413.4097 Mailto: [EMAIL PROTECTED] IPexpert - The Global Leader in Self-Study, Classroom-Based, Video On Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. On Feb 21, 2008, at 9:20 PM, Devildoc wrote: So to communicate successfully with CUE through either direct calls or forwarded calls, you'll have to use either SIP with G711 codec or H323 with either G711 or G729 codec for the inbound call leg from the WAN?Wouldn't the local transcoder transcode the call legs between the G729 SIP inbound from the WAN and the G711 SIP outbound to CUE?JD From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]: Thu, 21 Feb 2008 18:04:26 -0800Subject: Re: [OSL | CCIE_Voice] CUE FNA FB Problem I see that you are using SIP inbound using g729 and using SIP outbound using g711u. This scenario is not supported. You have to use g711 on both legs or change the ipipgw -> cme leg of the call to use h323. Vik Malhi - CCIE #13890, CCSI #31584 Sr Technical Instructor - IPexpert, Inc.A Cisco Learning Partner - We Accept Learning Credits! Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Mailto: [EMAIL PROTECTED] IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. From: Devildoc [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 4:40 PMTo: [EMAIL PROTECTED]; 'Jose Linero Welcker'; [EMAIL PROTECTED]: RE: [OSL | CCIE_Voice] CUE FNA FB Problem No, i already checked that and it was there along with transfer-pattern. Here is my telephony service configuration. telephony-serviceload 7910 P00403020214load 7960-7940 P00307020400max-ephones 5max-dn 15ip source-address 172.25.102.1 port 2000timeouts interdigit 5system message BR2-Sitesdspfarm units 1sdspfarm transcode sessions 4sdspfarm tag 1 XCODER2create cnf-files version-stamp Jan 01 2002 00:00:00voicemail 3500max-conferences 8 gain -6call-forward pattern .Ttransfer-system full-consulttransfer-pattern .TDo you have any other idea? I am stumped at this point. Is there any other debug that i can get to find out where the problems lie? Thank you for any suggestion. JD From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]: RE: [OSL | CCIE_Voice] CUE FNA FB ProblemDate: Thu, 21 Feb 2008 15:43:40 -0800 If your direct call to CUE worked from CCM then the transcoder must be working correctly and the allow-connections command must be configured correctly. I am guessing you are missing "call-forward pattern .T" inside telephony-service. Vik Malhi - CCIE #13890, CCSI #31584 Sr Technical Instructor - IPexpert, Inc.A Cisco Learning Partner - We Accept Learning Credits! Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Mailto: [EMAIL PROTECTED] IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. From: Devildoc [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 1:39 PMTo: [EMAIL PROTECTED]; 'Jose Linero Welcker'; [EMAIL PROTECTED]: RE: [OSL | CCIE_Voice] CUE FNA FB Problem Vik, Sorry to revisit this post again. I don't know if this issue has been resolved, but i ran into the same problem that Jose ran into with forwarding calls to CUE from IPIPGW. I have configured IPIPGW and tested calls to CUE before without any problem. This is the first time i ran into this problem with POD 25. I have never used POD 25 before so i don't know if it's the hardware issue with the DSP resources or my configuration. When the router booted up, i could see the MTP device on the local router registered successfully. However, after a few minutes, the MTP device unregistered abnormally. I had to go into the dspfarm profile to shut it down and bring it back up online again. After that, it seemed to stay up but the calls to CUE never worked. When i called to BR2 at 3003 from HQ 1003 and got forwarded to CUE due to noan, I just got a busy signal. However, when i called CUE pilot number directly, i got connected to CUE but DTMF didn not work. Below is the debug for the direct call to CUE along with my dialpeers configuration. Can you spot any misconfiguration? Thanks for you help. JD dial-peer voice 1200 voip description <<Outbound To IPIPGW for G729 H323 Calls>> destination-pattern [12]...$ session target ipv4:172.25.100.1 dtmf-relay h245-alphanumeric!dial-peer voice 3000 voip description <<Inbound From IPIPGW for G729 SIP Calls>> session protocol sipv2 incoming called-number 3...$ dtmf-relay rtp-nte digit-drop!dial-peer voice 3500 voip description <<Inbound and Outbound Calls for VM-AA-TM>> destination-pattern 3[567]00 session protocol sipv2 session target ipv4:10.25.202.2 incoming called-number 399[89].... dtmf-relay sip-notify codec g711ulaw no vadTelephony call-legs: 0SIP call-legs: 2H323 call-legs: 0Call agent controlled call-legs: 0SCCP call-legs: 2Multicast call-legs: 0Total call-legs: 43A1D : 4 265330ms.1 +70 pid:3000 Answer 2003 active dur 00:00:14 tx:732/14640 rx:725/13940 IP 162.25.102.1:18928 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g729r8 media inactive detected:n media contrl rcvd:n/a timestamp:n/a3A1D : 5 265340ms.1 +50 pid:3500 Originate 3500 active dur 00:00:14 tx:731/116960 rx:462/73443 IP 10.25.202.2:16908 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw media inactive detected:n media contrl rcvd:n/a timestamp:n/a0 : 7 265480ms.1 +0 pid:0 Originate connecting dur 00:00:14 tx:732/14640 rx:725/13940 IP 10.25.202.1:2000 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g729r8 media inactive detected:n media contrl rcvd:n/a timestamp:n/a0 : 9 265480ms.2 +0 pid:0 Originate connecting dur 00:00:14 tx:731/116960 rx:447/71043 IP 10.25.202.1:2000 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw media inactive detected:n media contrl rcvd:n/a timestamp:n/aTelephony call-legs: 0SIP call-legs: 2H323 call-legs: 0Call agent controlled call-legs: 0SCCP call-legs: 2Multicast call-legs: 0Total call-legs: 4 Profile ID = 1, Service = TRANSCODING, Resource ID = 1 Profile Description : Profile Admin State : UP Profile Operation State : ACTIVE Application : SCCP Status : ASSOCIATED Resource Provider : FLEX_DSPRM Status : UP Number of Resource Configured : 4 Number of Resource Available : 4 Codec Configuration Codec : g711ulaw, Maximum Packetization Period : 30 Codec : g711alaw, Maximum Packetization Period : 30 Codec : g729ar8, Maximum Packetization Period : 60 Codec : g729abr8, Maximum Packetization Period : 60 Codec : gsmfr, Maximum Packetization Period : 20 Codec : g729r8, Maximum Packetization Period : 60 Codec : g729br8, Maximum Packetization Period : 60SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED0 1 4.4.20 UP 1 USED xcode 1 2 1823 18080 1 4.4.20 UP 1 USED xcode 1 3 1823 10280 1 4.4.20 UP N/A FREE xcode 1 - - -0 1 4.4.20 UP N/A FREE xcode 1 - - -0 1 4.4.20 UP N/A FREE xcode 1 - - - Total number of DSPFARM DSP channel(s) 4 From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: Wed, 20 Feb 2008 16:02:17 -0800Subject: Re: [OSL | CCIE_Voice] CUE FNA FB Problem when you use the "service session" can you get an active call and enter the command "sh call act voice brief" and find out what codecs and what protocols are being used. We'll have a better idea of what is going on when you post the answer to this question. The service session command invokes the default session- a built-in tcl script. I've posted the description of this tcl script below: #sh call applicatio voice Script Name : session URL : builtin:app_session_script.tcl Type : Service State: Registered Life : Builtin Exec Instances: 0 Parameters registered under session namespace: name type default value description uid-len I 10 the number of digits in UID warning-time I 30 the time (in secs) within which a user is warned before the calling time expires (call terminates) pin-len I 4 the number of digits in PIN retry-count I 3 the number of attempts to reenter PIN redirect-number S the telephone number where a call is redirected to Script Code Begin:-------------------------------- TCL Script version 2.0 - 2.1 # app_session.tcl#----------------------------------# August 1999, Saravanan Shanmugham## Copyright (c) 1998, 1999, 2000, 2001, 2002, 2003 by cisco Systems, Inc.# All rights reserved.#------------------## This tcl script mimics the default SESSION app## If DID is configured, just place the call to the dnis# Otherwise, output dial-tone and collect digits from the# caller against the dial-plan.## Then place the call. If successful, connect it up, otherwise# the caller should hear a busy or congested signal. # The main routine just establishes the statemachine and then exits.# From then on the system drives the statemachine depending on the # events it recieves and calls the appropriate tcl procedure -------------------------------------------------------------------------------------------------------------- Vik Malhi - CCIE #13890, CCSI #31584 Sr Technical Instructor - IPexpert, Inc.A Cisco Learning Partner - We Accept Learning Credits! Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Mailto: [EMAIL PROTECTED] IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. From: Jose Linero Welcker [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 20, 2008 2:21 PMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]: RE: [OSL | CCIE_Voice] CUE FNA FB Problem Hi Vik: Thanks for your answer, to make the things clear, if I have different codecs one of the legs shoud be H323, wright?, however if I use G711 in both legs, then I can use sip-to-sip, wright?. The other thing is, with the configuration I sent you adding the command "service session" it works, the the dial-peer configuration is: dial-peer voice 4 voip service session session protocol sipv2 incoming called-number 3... dtmf-relay rtp-nte It is another way to fix it without changing the codecs or protocol of the legs, my question is, could we use it in the lab exam? Thanks, Jose From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: RE: [OSL | CCIE_Voice] CUE FNA FB ProblemDate: Wed, 20 Feb 2008 14:13:27 -0800 you cannot sip - sip. One leg must be H323. You must g711 on the inbound and outbound sip call legs to make this work. Vik Malhi - CCIE #13890, CCSI #31584 Sr Technical Instructor - IPexpert, Inc.A Cisco Learning Partner - We Accept Learning Credits! Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Mailto: [EMAIL PROTECTED] IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. From: Jose Linero Welcker [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 20, 2008 2:01 PMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]: RE: [OSL | CCIE_Voice] CUE FNA FB Problem Hi Vik: Yes it is just for the calls coming from the WAN, What I am seeing is the CME sends a SIP 302 message to the IPIPGW, and the IPIPGW shoud send a re-invite to the number of the CUE, however the IPIPGW sends an ACK and I heard a busy tone, attached are the configurations of the IPIPGW and the CME, could you please take a look at them. Regards, Jose From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: RE: [OSL | CCIE_Voice] CUE FNA FB ProblemDate: Wed, 20 Feb 2008 13:53:02 -0800 Does the call-forward work from the PSTN? If it is specifically the calls from over the WAN that do not fwd then I go along with DevilDoc and Jason- transcoder or incoming dial-peer not matching correctly. If it doesn't work for g711u end to end, then that potentially rules out the xcoder as being the cause. Please confirm that it is only calls from over the WAN that cannot be fwded and also post the output of debug voip dialpeer. Vik Malhi - CCIE #13890, CCSI #31584 Sr Technical Instructor - IPexpert, Inc.A Cisco Learning Partner - We Accept Learning Credits! Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Mailto: [EMAIL PROTECTED] IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf OfJose Linero WelckerSent: Wednesday, February 20, 2008 1:17 PMTo: [EMAIL PROTECTED]: [OSL | CCIE_Voice] CUE FNA FB Problem Hi all: I have this configuration: CM --- H323 Trunk --- IPIPGW --- SIP Trunk --- CME The H323 is using G711 and the the SIP Trunk is using G729, the calls between the phones in CCM and CME are working without problems, however when I am going to forward the call to CUE due CFNA or CFB I received a reorder tone and I am seeing this SIP Message: Sent: SIP/2.0 302 Moved TemporarilyVia: SIP/2.0/UDP 162.1.103.1:5060;branch=z9hG4bK92655From: 'BR1-Phone2' <sip:[EMAIL PROTECTED]>;tag=8EC914-101DTo: <sip:[EMAIL PROTECTED]>;tag=1CEC58-818Date: Wed, 20 Feb 2008 21:06:32 GMTCall-ID: [EMAIL PROTECTED]: 1203541592Server: Cisco-SIPGateway/IOS-12.xCSeq: 101 INVITEAllow-Events: telephone-eventContact: <sip:[EMAIL PROTECTED]>Diversion: <sip:[EMAIL PROTECTED]:5060>;reason=no-answerContent-Length: 0 and the IPIPGW answer is an ACK not a reinvite, in the CME I have configured this for CUE: telephony-service voicemail 3600 call-forward pattern .T web admin system name Admin password cisco dial-peer voice 6 voip destination-pattern 3600 session protocol sipv2 session target ipv4:10.1.202.2 dtmf-relay sip-notify rtp-nte codec g711ulaw no vad voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip ephone-dn 1 dual-line number 3001 call-forward busy 3600 call-forward noan 3600 timeout 10! Does anybody see this problem, I am trying to reach the voicemail, but I can't. Regards, Jose Express yourself instantly with MSN Messenger! MSN Messenger Express yourself instantly with MSN Messenger! MSN Messenger Express yourself instantly with MSN Messenger! MSN Messenger Connect and share in new ways with Windows Live. Get it now! Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. Need to know the score, the latest news, or you need your Hotmail®-get your "fix". Check it out. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging. You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
