trunk in ulaw, phone in alaw?

Discussion in 'General' started by Patrick_elx, Jan 31, 2009.

  1. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0
    Hi,

    I have a trunk with ulaw & alaw and a few cisco 7960 with alaw&ulaw

    A call come in on the trunk, asterisk decides to use alaw.
    Then my phone ring and ulaw is used for this step.

    There's not a lot of work to translate ulaw to alaw, but why this translation? When there is a choice of codec, does not asterisk try to choose the least processor intensive?

    Patrick
     
  2. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Asterisk will use the easiest way to transcode codecs, it will however accept the offered codec from the endpoint without arguing if it can , If both asterisk and cisco are setup to do both but the cisco offers g711u first it will accept it, conversely if the provider offers alaw first it will accept it also (with the proviso outlined below), and thus transcode, you are right in saying there is minimal effort to transcode a to u or vice versa, it is just a matter of pre-emphasis.

    I suggest that you turn off u or a on the cisco (depending on your locale), and possibly asterisk also unless taking anonymous calls from outside your country, if it bothers you.

    Once again depending on where you are and assuming that the trunk is from a "local" provider it is cleaner to just use the pertinent codec for where you are and let the provider transcode if necessary.

    I believe that the order of the codec is unimportant to asterisk in sip.conf or its inclusions when it is in the user(phone) context, it is however honored in the peer(trunk) context
     
  3. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0
    I have a few DIDs in Europe and a few in the US, then I'm receiving u and alaw all the time.
    Again it's not a big deal, but I would have expected asterisk not to translate anything if both ends have the same codec in their lists.

    thanks for the clarification
     

Share This Page