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

[Nick Matthews]

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)
>
>  [image: ccie_voice_large.gif]
>
>
>
> *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
>
>
>
> [image: untitled]
>
>   RAYA Building El Motamiez District, 6th of October, Egypt
>
>
>
>   Mob: +2019-0016211
>
>   Phone: +202 3827 6000 Ext.2475
>
>   Website: www.rayacorp.com
>
>   E-mail: ahmed_elnagar at rayacorp.com
>
>   CCIE#24697 (Voice)
>
>  [image: ccie_voice_large.gif]
>
>
>
>
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100930/ee708ab7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 1801 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100930/ee708ab7/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 2210 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100930/ee708ab7/attachment-0001.jpg>