Not 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]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ccie_voice@onlinestudylist.com
Date: Thu, 21 Feb 2008 18:04:26 -0800
Subject: 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 PM
To: [EMAIL PROTECTED]; 'Jose Linero Welcker'; ccie_voice@onlinestudylist.com
Subject: 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-service
load 7910 P00403020214
load 7960-7940 P00307020400
max-ephones 5
max-dn 15
ip source-address 172.25.102.1 port 2000
timeouts interdigit 5
system message BR2-Site
sdspfarm units 1
sdspfarm transcode sessions 4
sdspfarm tag 1 XCODER2
create cnf-files version-stamp Jan 01 2002 00:00:00
voicemail 3500
max-conferences 8 gain -6
call-forward pattern .T
transfer-system full-consult
transfer-pattern .T

Do 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]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ccie_voice@onlinestudylist.com
Subject: RE: [OSL | CCIE_Voice] CUE FNA FB Problem
Date: 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 PM
To: [EMAIL PROTECTED]; 'Jose Linero Welcker'; ccie_voice@onlinestudylist.com
Subject: 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 vad

Telephony call-legs: 0
SIP call-legs: 2
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 2
Multicast call-legs: 0
Total call-legs: 4
3A1D : 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/a
3A1D : 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/a
0    : 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/a
0    : 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/a
Telephony call-legs: 0
SIP call-legs: 2
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 2
Multicast call-legs: 0
Total 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 : 60

SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED 0 1 4.4.20 UP 1 USED xcode 1 2 1823 1808 0 1 4.4.20 UP 1 USED xcode 1 3 1823 1028 0 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]
To: [EMAIL PROTECTED]; ccie_voice@onlinestudylist.com
Date: Wed, 20 Feb 2008 16:02:17 -0800
Subject: 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 PM
To: [EMAIL PROTECTED]; ccie_voice@onlinestudylist.com
Subject: 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]
To: [EMAIL PROTECTED]; ccie_voice@onlinestudylist.com
Subject: RE: [OSL | CCIE_Voice] CUE FNA FB Problem
Date: 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 PM
To: [EMAIL PROTECTED]; ccie_voice@onlinestudylist.com
Subject: 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]
To: [EMAIL PROTECTED]; ccie_voice@onlinestudylist.com
Subject: RE: [OSL | CCIE_Voice] CUE FNA FB Problem
Date: 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 Welcker
Sent: Wednesday, February 20, 2008 1:17 PM
To: ccie_voice@onlinestudylist.com
Subject: [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 Temporarily
Via: SIP/2.0/UDP  162.1.103.1:5060;branch=z9hG4bK92655
From: 'BR1-Phone2' <sip:[EMAIL PROTECTED]>;tag=8EC914-101D
To: <sip:[EMAIL PROTECTED]>;tag=1CEC58-818
Date: Wed, 20 Feb 2008 21:06:32 GMT
Call-ID: [EMAIL PROTECTED]
Timestamp: 1203541592
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow-Events: telephone-event
Contact: <sip:[EMAIL PROTECTED]>
Diversion: <sip:[EMAIL PROTECTED]:5060>;reason=no-answer
Content-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.

Reply via email to