[cisco-voip] Do CUBEs do transcoding by its own

Fri Oct 1 12:09:30 EDT 2010

I will give it another try and feedback...it is a production environment
L

 Best Regards;

  Ahmed Elnagar

  Senior Network PS Engineer

  Mob: +2019-0016211

  CCIE#24697 (Voice)

From: matthn at gmail.com [mailto:matthn at gmail.com] On Behalf Of Nick
Matthews
Sent: Friday, October 01, 2010 4:47 AM
To: Ahmed Elnagar
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Do CUBEs do transcoding by its own

I took a look at this - I think gsmefr may be a codec that is
automatically assigned to an unknown codec.  It looked like there were
some cases of codec transparent and video calls that invoked this
behavior.  If it's not causing problems I wouldn't worry about it.  If
you paste what the INVITE and SDP look like, we can take a look to see
if it's unusual in any matter.

-nick

On Thu, Sep 30, 2010 at 9:09 PM, Ahmed Elnagar <
ahmed_elnagar at rayacorp.com> wrote:

Yes that what I thought too... the call hits a dial-peer without any
configured codec class, so should be using g729 I don't know why it is
using this strange codec...plus really the call is working and I am sure
that the other system is g711ualaw only "IPCC enterprise" and the
dial-peer is configured to force it too.

Cisco SE says that this behavior is unique to ISR G2 "2900 and 3900" and
really I still don't understand that.

 Best Regards;

  Ahmed Elnagar

  Senior Network PS Engineer

  Mob: +2019-0016211

  CCIE#24697 (Voice)

From: matthn at gmail.com [mailto:matthn at gmail.com] On Behalf Of Nick
Matthews
Sent: Friday, October 01, 2010 2:34 AM
To: Ahmed Elnagar
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Do CUBEs do transcoding by its own

Highly doubtful.  I can't say with any certainty that it makes sense for
one leg to be gsmefr in a normal scenario.  Is this a codec you use in
your environment?

Without seeing the dial peers that have been hit, it's really hard to
say what's going on.

To be absolutely clear - the only way a CUBE will change the codec on
one leg of a call to another is if transcoding is configured.  The
transcoding must be configured in a CME style, or it will not happen.
CUBE does not reserve DSPs.

-nick

On Thu, Sep 30, 2010 at 7:14 PM, Ahmed Elnagar <
ahmed_elnagar at rayacorp.com> wrote:

Hello;

I have a strange behavior from a 3945 router acting as a CUBE for SIP
leg from CUCM cluster to a ITSP using H323 "pretty old way I know" the
call works normally for incoming and outgoing but I am facing a problem
in dialing my numbers from the VOIP line "that is going out and in again
on the same line"

My specific question here when I show voice call active voice I found
one leg of the call as gsmefr and the other leg is g711ulaw and I did
not configure any transcoding resources any where...I have been told by
a Cisco SE that the router may assign "some" DSPs for that
transcoding...is that possible without I configure it for the CUBE to
use??

  Best Regards;

  Ahmed Elnagar

  Senior Network PS Engineer

  RAYA Building El Motamiez District, 6th of October, Egypt 

  Mob: +2019-0016211

  Phone: +202 3827 6000 Ext.2475

  Website: www.rayacorp.com <http://www.rayacorp.com/> 

  E-mail: ahmed_elnagar at rayacorp.com

  CCIE#24697 (Voice)

Disclaimer: NOTICE The information contained in this message is
confidential and is intended for the addressee(s) only. If you have
received this message in error or there are any problems please notify
the originator immediately. The unauthorized use, disclosure, copying or
alteration of this message is strictly forbidden. Raya will not be
liable for direct, special, indirect or consequential damages arising
from alteration of the contents of this message by a third party or as a
result of any malicious code or virus being passed on. Views expressed
in this communication are not necessarily those of Raya.If you have
received this message in error, please notify the sender immediately by
email, facsimile or telephone and return and/or destroy the original
message. 

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Disclaimer: NOTICE The information contained in this message is
confidential and is intended for the addressee(s) only. If you have
received this message in error or there are any problems please notify
the originator immediately. The unauthorized use, disclosure, copying or
alteration of this message is strictly forbidden. Raya will not be
liable for direct, special, indirect or consequential damages arising
from alteration of the contents of this message by a third party or as a
result of any malicious code or virus being passed on. Views expressed
in this communication are not necessarily those of Raya.If you have
received this message in error, please notify the sender immediately by
email, facsimile or telephone and return and/or destroy the original
message. 

Disclaimer: NOTICE The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Raya will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any malicious code or virus being passed on. Views expressed in this communication are not necessarily those of Raya.If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20101001/98463ffe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1801 bytes
Desc: image001.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20101001/98463ffe/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 2210 bytes
Desc: image002.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20101001/98463ffe/attachment-0001.jpg>