how to set g.711 only codec for ephone

Hello! I'm not sure that the question is related to CCIE Voice, but still interesting.

Actually, I need following scheme: Cisco IP Phone -> G.711u-law -> CUCME -> g.729 -> other gateways

G.711 is a must, cause of open-source voice recording software (Oreca, g.729 not supported). By default IP Phone always negotiates g.729 codec (g.711 was set as preferred). Who knows the simplest way to make it use g.711 only?

The IOS version is 12.4(24)T.

Thank you!

P.S.: I think, that it is possible to change IP Phones to SIP-mode and configure CUBE with transcoding (it is simple, i'll try it later), but it would be nice to use default SCCP.

Comments

  • You would use CUBE, as you mentioned, but you don't need to convert your phones to SIP to use CUBE - SCCP will work just fine. 



    On Oct 25, 2010, at 5:04, odin <[email protected]> wrote:

    Hello! I'm not sure that the question is related to CCIE Voice, but still interesting.

    Actually, I need following scheme: Cisco IP Phone -> G.711u-law -> CUCME -> g.729 -> other gateways

    G.711 is a must, cause of open-source voice recording software (Oreca, g.729 not supported). By default IP Phone always negotiates g.729 codec (g.711 was set as preferred). Who knows the simplest way to make it use g.711 only?

    The IOS version is 12.4(24)T.

    Thank you!

    P.S.: I think, that it is possible to change IP Phones to SIP-mode and configure CUBE with transcoding (it is simple, i'll try it later), but it would be nice to use default SCCP.




    Internetwork Expert - The Industry Leader in CCIE Preparation

    http://www.internetworkexpert.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • I thought, that transcoding for efxs should be automatic (without CUBE and transcoding configuration). But still with associated dspfarm profile or without it g.711u is only "preferred". I don't know how to change it to "required".

    CUCME administration guide says: "Transcoding is enabled only if an H.323 call with a different codec from the remote phone tries to make a call to the remote phone. If a local phone on the same Cisco Unified CME as the remote phone makes a call to remote phone, the local phone is forced to change its codec to G.729 instead of using transcoding." I think, that it is valid for SIP dial-peers also. So, it seems to be unsupported. And converting to SIP-mode will not help with classical configuration, cause efxs will still exist.

    "Unsupported" doesn't mean it is not possible. A workaround exists. I've created a dial-peer voip with more priority then ephone-dn and only g.711 allowed. This dial-peer directs SIP and RTP to another VRF via GRE-tunnel, then traffic comes back to GLOBAL and then to IP phone. I have 3 vrf's, 6 gre tunnels, translation profiles, NAT, CUBE and transcoding in my config (not optimized) currently. It works, but looks a little bit complicated. =)

    The question is: is it the only way to set fixed codec, or I've missed something?

    P.S.: if it is the only solution, I can post it here later. But still have a hope that I'm wrong somewhere.

  • Wow. That is an ULTIMATE workaround for Voice! You either must be a RS or SP CCIE, or you soon will be both of those AND a Voice CCIE! 

    Excellent solution if I do say so!

     

    Well, for all of the other codecs (G729, iLBC, even G722) you can force them to use a DSP, but only if G.711 is negotiated. However for G711 configured on the ephone (either companding type), you cannot force them. Wait, I should reverse that and say that other than the elaborate scheme you have concocted, you cannot force them.

    Below is the output when trying to force G711uLaw or aLaw (aLaw is a hidden codec but works nonetheless) to use a dspfarm-assist command:

     


    Branch2(config-ephone)#codec g729r8 dspfarm-assist

    Branch2(config-ephone)#codec ilbc dspfarm-assist

    Branch2(config-ephone)#codec G722-64K dspfarm-assist

    Branch2(config-ephone)#codec g711alaw

    Branch2(config-ephone)#codec g711alaw dspfarm-assist

                                          ^

    % Invalid input detected at '^' marker.


    Branch2(config-ephone)#codec g711ulaw dspfarm-assist

                                          ^

    % Invalid input detected at '^' marker.


    Branch2(config-ephone)#                 

  • And please, post your config! I am sure many would love to see it!

  • OK. If there is no other solution, I'll optimize it and post a link to full lab description here next week.

  • Here is a link to the post with config and lab description: http://netl0g.blogspot.com/2010/11/how-to-force-g711-for-ephone-with.html

    Specially for ine.com readers who'll found it. =) It is not yet totally optimized, but it works.

    All content is free to use, repost, etc., links and other references appreciated.

  • Petr,

    This is a brilliant solution! Well done.
    Now for the sake of the other Voice students who may not be R/S gurus like you, let us all hope for their sake that something like this is not on the lab exam :-0

    Do you mind if I link to this blog post from our blog?
    I think this is certainly something worth sharing.


    Kind Regards,

    Mark Snow, CCIE #14073
    (Voice, Security)
    Instructor
    Internetwork Expert, Inc.
    Toll Free: 877-224-8987
    Outside US: +1 775 826 4344

    - docendo discitur



    On Nov 1, 2010, at 9:24 AM, odin wrote:

    Here is a link to the post with config and lab description: http://netl0g.blogspot.com/2010/11/how-to-force-g711-for-ephone-with.html

    Specially for ine.com readers who'll found it. =) It is not yet totally optimized, but it works.

    All content is free to use, repost, etc., links and other references appreciated.




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Thank you, Mark.

    Of cause I do not mind if you link to this post. But, as I said, this solution is not yet totally optimized. Now I'm working on a small pilot, that is more complex than a lab. Some minor bugs crawled out.

    First, # character is not well parsed. Cisco router logs some errors, but works. Still our SIP-proxy ignores all messages with this character completely. OK, it's not a big deal. 1-st solution - don not use # for prefixes. 2-d solution (was tested) - set #0#xxx as a secondary number under ephone-dn configuration and use sip-profiles to translate SIP Contact field content.

    Second, this solution adds some complexity. If router is not correctly configured - it can be killed by ip input from one voice call (yes, it was tested too =)). I spent some time planning inbound and outbound dial-peers with permission term and orig set.

    Finally, yesterday I simply hairpinned calls with a dial-peer pointing to loopback (without all manipulations with vrfs and tunnels). I thought, hairpin can work only for PSTN-to-IP, but call sequence was correct (with all translations). I was out of time, not tested RTP and transcoding yet. It is possible that posted solution is more complex the it is really necessary. I'll update this post by all means if I'll get working transcoding with simple hairpin.

    So, it's up to you - post it now or wait a little. In any case, I think, this solution can be interesting as a lab in all stages.

     

  • OK, I have to admit that simple hairpin works well. Config was rather simplified. Correct voice configuration is sufficient, no R&S manipulations are necessary.

    I archived working transcoding without any vrf, tunnels and NAT. The only thing, that is really necessary, is dial-peer that force transcoding and points to routers loopback. Actually, the output from previous configuration (that was posted) shows that only SIP requests and replies was passing through tunnels, you can see that all RTP sessions use loopback address as the source and destination.

    Interesting, that "debug ccsip errors" always shows "Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL". But call is successful, transcoding works. What this log can be about?

    I'm not sure that hairpin works always. It was tested only for 12.4(24)T. So, I have not yet rejected previous configuration, it can be more reliable unsupported configuration =), cause "local GRE" was better tested. The next step is to pass SIP through NAT correctly (this will hide hairpin, I think). May be NAT-T for SBC will work? I'll check.

  • By the way, there is very useful command "credentials" under "sip-ua" configuration. It allows to register arbitrary numbers that can be hidden behind Cisco gateway. The question: is there any way to register address block, not only individual "name"?

  • Great question Petr,

    Actually, yes, you can. Even if you don't intend to use SIP CME, you can use the SIP CME server to bulk register numbers with a SIP Proxy Server. Example config below (note the "bulk" command):

    voice register global
     mode cme
     source-address 1.1.1.1 port 5060
     max-dn 1
     max-pool 1
     bulk 0207033...   


    Kind Regards,

    Mark Snow, CCIE #14073
    (Voice, Security)
    Instructor
    Internetwork Expert, Inc.
    Toll Free: 877-224-8987
    Outside US: +1 775 826 4344

    - docendo discitur


    On Nov 6, 2010, at 10:03 AM, odin wrote:

    By the way, there is very useful command "credentials" under "sip-ua" configuration. It allows to register arbitrary numbers that can be hidden behind Cisco gateway. The question: is there any way to register address block, not only individual "name"?




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Hello, Mark.

    Finally it works. At least for 12.4(22)T. But actually configuration tend to put together all hidden IOS bugs. So it is hard to find good compatible IOS.

    Post was updated. Both simple hairpin and call looped trough VRFs were described. Problem with ALG was fixed with sip-profiles.

    I think, now it is optimized enough to post a link from your blog (if your didn't change your mind yet).

    Actually, I think this configuration is not very useful for production network, but

    1) it can be useful in some fire-cases

    2) it was an interesting voice lab =)

    3) local GRE can be useful without voice

    I appreciate any comments.

  • By the way, one more question about sip-to-sip hairpin. Is it a feature or a bug?

    If it's a feature, why router logs "Failed FROM/TO Request check - IGNORE IF HAIRPIN CALL" error.

    Also confused by this link from CCO: "However, it (SIP) does not support IP-to-IP hairpinning". But it works.

    If it's a bug, it looks like very stable bug, we can rely upon. =)

  • And here is the end of story: commercial recording software with g.729 support acquired to protect production routers from this configuration. =)

    P.S.: sip-to-sip hairpin looks pretty simple and very-very stable... I'm ready to recognize it as a feature. May be undocumented.

  • Petr,

     

    Great work, and a great feature find!

    I will be happy to post it in a few days.

     

    Keep in touch!

Sign In or Register to comment.