[cisco-voip] Do CUBEs do transcoding by its own
Nick Matthews
matthnick at gmail.com
Thu Sep 30 20:34:27 EDT 2010
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100930/43b05835/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2210 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100930/43b05835/attachment.jpg>
-------------- 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/43b05835/attachment-0001.jpg>
More information about the cisco-voip
mailing list