Forcing inbound Codec to G711

Discussion in 'UK VOIP' started by =?ISO-8859-1?Q?=22Pet_=40_www=2Egymratz=2Eco=2Euk_, Dec 8, 2006.

  1. At a guess I presume inbound numbers from public PSTN routed from ones
    VOIP supplier would be routed on the most economical codec eg G712A/B

    If that's the case, then if I were to force the voip ports to a single
    codec e.g. G711MU, presumably the inbound call would be forced to
    upscale to this single codec rather than the lowest it could get away with?

    Would there be any forseeable disadvantages doing this?
    I see it as a way of getting max. call quality in inbound calls esp.
    where downstream bandwidth is not such an issue as upstream.

    Any thoughts?
    Pete
    --
    http://gymratz.co.uk - Best Gym Equipment & Bodybuilding Supplements UK.
    http://gymratz.co.uk/polar-heart-rate-monitors/ Polar HeartRate Monitors
    http://fitness-equipment-uk.com - UK's No.1 Fitness Equipment Suppliers.
    http://water-rower.co.uk - Worlds best prices on the Worlds best Rower.
     
    =?ISO-8859-1?Q?=22Pet_=40_www=2Egymratz=2Eco=2Euk_, Dec 8, 2006
    #1
    1. Advertising

  2. =?ISO-8859-1?Q?=22Pet_=40_www=2Egymratz=2Eco=2Euk_

    alexd Guest

    "Pet @ www.gymratz.co.uk ;¬)" wrote:

    > At a guess I presume inbound numbers from public PSTN routed from ones
    > VOIP supplier would be routed on the most economical codec eg G712A/B


    What do you mean by "economical"? Some codecs cost less bandwidth but more
    CPU time. Some codecs are patented [whether legally or not] and require
    licensing.

    > If that's the case, then if I were to force the voip ports to a single
    > codec e.g. G711MU, presumably the inbound call would be forced to
    > upscale to this single codec rather than the lowest it could get away
    > with?


    If it's SIP we're talking about, both ends have to agree on a codec. If they
    cannot, the call will fail.

    > Would there be any forseeable disadvantages doing this?


    Higher bandwidth use.

    > I see it as a way of getting max. call quality in inbound calls esp.
    > where downstream bandwidth is not such an issue as upstream.


    When budgeting bandwidth, it makes sense to assume that it will be
    symmetrical. When I watch the bandwidth graph on my Asterisk server [SIP,
    G711u], it's always level in both directions, ie it doesn't have peaks and
    troughs that correlate with speech and silence. This of course may depend
    on silence suppression and voice activity detection settings etc on the
    endpoints.

    --
    <http://ale.cx/> (AIM:troffasky) ()
    09:58:29 up 19 days, 13:41, 2 users, load average: 0.02, 0.06, 0.02
    This is my BOOOOOOOOOOOOOOOOOOOOOMSTICK
     
    alexd, Dec 9, 2006
    #2
    1. Advertising

  3. "Pet @ www.gymratz.co.uk ;¬)" <> wrote in message
    news:fmgeh.13632$...
    > If that's the case, then if I were to force the voip ports to a single
    > codec e.g. G711MU, presumably the inbound call would be forced to
    > upscale to this single codec rather than the lowest it could get away

    with?

    If the other end of the call (your Providers PSTN Gateway) does not support
    the codec you try to enforce, then the call will fail.

    > I see it as a way of getting max. call quality in inbound calls esp.
    > where downstream bandwidth is not such an issue as upstream.


    There is no connection between inbound calls and downstream bandwith. Both
    Inbound calls and outbound are using the same (symmetric) bandwith, if using
    the same codec.
    With good downstraem bandwith, you will experience good sound quality, but
    with a bad upstraeam bandwith the other party will experience bad quality
    (what you hear is downstream, what the other party hears is upstream - not
    related to incoming our outgoing calls ...
     
    Philippe Deleye, Dec 9, 2006
    #3
  4. =?ISO-8859-1?Q?=22Pet_=40_www=2Egymratz=2Eco=2Euk_

    Jono Guest

    alexd brought next idea :

    >
    > When budgeting bandwidth, it makes sense to assume that it will be
    > symmetrical. When I watch the bandwidth graph on my Asterisk server [SIP,
    > G711u],


    How'd you do that?
     
    Jono, Dec 10, 2006
    #4
  5. =?ISO-8859-1?Q?=22Pet_=40_www=2Egymratz=2Eco=2Euk_

    Paul Guest

    Pet @ www.gymratz.co.uk ;¬) wrote:
    > At a guess I presume inbound numbers from public PSTN routed from ones
    > VOIP supplier would be routed on the most economical codec eg G712A/B


    Not in my experience, most stick to G.711a/u. It's still only needs
    about 80kbps per call which is fine for the vast majority of Internet
    connections these days. G729 would save on bandwidth but it's CPU
    intensive, this might not matter for you but it'll make a big difference
    for a service provider. It is also not a free codec and the license
    holder must be paid for it. I dare say that most importantly, it's
    lower quality than G711 (and therefore the PSTN) so the customer would
    perceive the service provider's service as poorer quality.

    >
    > If that's the case, then if I were to force the voip ports to a single
    > codec e.g. G711MU, presumably the inbound call would be forced to
    > upscale to this single codec rather than the lowest it could get away with?


    Yes if you set your VoIP hardware to only accept g711a/u then either the
    service providers server will agree to this or the call will fail.

    >
    > Would there be any forseeable disadvantages doing this?
    > I see it as a way of getting max. call quality in inbound calls esp.
    > where downstream bandwidth is not such an issue as upstream.


    Less calls through your Internet connection. The calls require the same
    amount of bandwidth in either direction regardless of whether they are
    incoming calls or outgoing calls.

    >
    > Any thoughts?
    > Pete
     
    Paul, Dec 11, 2006
    #5
  6. =?ISO-8859-1?Q?=22Pet_=40_www=2Egymratz=2Eco=2Euk_

    ale.cx Guest

    On Dec 10, 11:59 am, Jono <> wrote:

    > How'd you do that?


    gkrellmd on the Asterisk box, gkrellm on my desktop :-D

    alexd
     
    ale.cx, Dec 11, 2006
    #6
  7. Re: Forcing inbound Codec to G711 & SIP port numbers

    Paul wrote:

    > Not in my experience, most stick to G.711a/u. It's still only needs
    > about 80kbps per call which is fine for the vast majority of Internet
    > connections these days. G729 would save on bandwidth but it's CPU
    > intensive, this might not matter for you but it'll make a big difference
    > for a service provider. It is also not a free codec and the license
    > holder must be paid for it. I dare say that most importantly, it's
    > lower quality than G711 (and therefore the PSTN) so the customer would
    > perceive the service provider's service as poorer quality.


    I was just going down the train of thought based on last weeks incoming
    calls, though, they were being routed through a sipgate number when our
    BT line was busy. Since then I have signed up to voipfone.co.uk mainly
    for incoming calls (on BT busy) but also for the CLI on outgoing calls
    should we have anyone that decides not to answer "no ID/International"
    calls from voipcheap.com

    <snip>

    > Less calls through your Internet connection. The calls require the same
    > amount of bandwidth in either direction regardless of whether they are
    > incoming calls or outgoing calls.


    I'll leave it with multiple codecs available then and see how we go.

    On a further note, if I have 2 outgoing lines via router do I need to
    specify a range of SIP ports
    e.g. 5060-5061 for line 1 and 5062 - 5063 for line 2

    At the moment all accounts are left at 5060.

    Cheers
    Pete


    --
    http://gymratz.co.uk - Best Gym Equipment & Bodybuilding Supplements UK.
    http://gymratz.co.uk/polar-heart-rate-monitors/ Polar HeartRate Monitors
    http://fitness-equipment-uk.com - UK's No.1 Fitness Equipment Suppliers.
    http://water-rower.co.uk - Worlds best prices on the Worlds best Rower.
     
    =?ISO-8859-1?Q?=22Pet_=40_www=2Egymratz=2Eco=2Euk_, Dec 11, 2006
    #7
  8. =?ISO-8859-1?Q?=22Pet_=40_www=2Egymratz=2Eco=2Euk_

    ale.cx Guest

    Re: Forcing inbound Codec to G711 & SIP port numbers

    On Dec 11, 2:12 pm, "Pet @ www.gymratz.co.uk ;¬)"
    <> wrote:

    > On a further note, if I have 2 outgoing lines via router do I need to
    > specify a range of SIP ports
    > e.g. 5060-5061 for line 1 and 5062 - 5063 for line 2


    For outgoing you don't need to forward any ports so long as your router
    does NAT and the firewall rules don't block it.

    For incoming it's slightly different. If it's one physical device [eg a
    single router, ATA or Asterisk server] with multiple accounts on, the
    device should be able to deduce from the info in the inbound call which
    account the call is for. SIP calls are a bit like email addresses, the
    bit before the '@' is the account that the call is for.

    If you've got multiple devices registering their own accounts behind a
    single public IP address, you will need to make sure the relevant ports
    are forwarded to the relevant devices for them to be able to receive
    calls.

    > At the moment all accounts are left at 5060.


    Does it work?
     
    ale.cx, Dec 12, 2006
    #8
  9. Re: Forcing inbound Codec to G711 & SIP port numbers

    ale.cx wrote:

    > For outgoing you don't need to forward any ports so long as your router
    > does NAT and the firewall rules don't block it.


    That'd be ok then.
    It's only multiple outgoing calls that concerned me.

    > For incoming it's slightly different. If it's one physical device [eg a
    > single router, ATA or Asterisk server] with multiple accounts on, the
    > device should be able to deduce from the info in the inbound call which
    > account the call is for. SIP calls are a bit like email addresses, the
    > bit before the '@' is the account that the call is for.
    >
    > If you've got multiple devices registering their own accounts behind a
    > single public IP address, you will need to make sure the relevant ports
    > are forwarded to the relevant devices for them to be able to receive
    > calls.


    >> At the moment all accounts are left at 5060.

    >
    > Does it work?


    I haven't really tried it in anger.
    Currently incoming BT calls are set to divert to 0845 number provided by
    voipfone should the bt line be busy. from there both voip ports on the
    router ring so should bt line be tied up and port 1 also tied up then
    port 2 should get the call.

    We don't generally get enough calls to try it and most of the time
    there's only 2 of us here anyway.
    :¬)

    It just seemed that when I was trying to make 2 outgoing voip calls at
    the same time I was getting a busy tone, hence the reason for the post.

    May just have been a coincidence though.

    Cheers
    Pete


    --
    http://gymratz.co.uk - Best Gym Equipment & Bodybuilding Supplements UK.
    http://gymratz.co.uk/polar-heart-rate-monitors/ Polar HeartRate Monitors
    http://fitness-equipment-uk.com - UK's No.1 Fitness Equipment Suppliers.
    http://water-rower.co.uk - Worlds best prices on the Worlds best Rower.
     
    =?ISO-8859-1?Q?=22Pet_=40_www=2Egymratz=2Eco=2Euk_, Dec 12, 2006
    #9
  10. =?ISO-8859-1?Q?=22Pet_=40_www=2Egymratz=2Eco=2Euk_

    PeterW Guest

    Paul <> wrote in
    news:457d2a89$0$624$:

    > Pet @ www.gymratz.co.uk ;¬) wrote:
    >> At a guess I presume inbound numbers from public PSTN routed from
    >> ones VOIP supplier would be routed on the most economical codec eg
    >> G712A/B

    >
    > Not in my experience, most stick to G.711a/u. It's still only needs
    > about 80kbps per call which is fine for the vast majority of Internet
    > connections these days. G729 would save on bandwidth but it's CPU
    > intensive, this might not matter for you but it'll make a big
    > difference for a service provider. It is also not a free codec and
    > the license holder must be paid for it. I dare say that most
    > importantly, it's lower quality than G711 (and therefore the PSTN) so
    > the customer would perceive the service provider's service as poorer
    > quality.
    >
    >>
    >> If that's the case, then if I were to force the voip ports to a
    >> single codec e.g. G711MU, presumably the inbound call would be forced
    >> to upscale to this single codec rather than the lowest it could get
    >> away with?

    >
    > Yes if you set your VoIP hardware to only accept g711a/u then either
    > the service providers server will agree to this or the call will fail.
    >
    >>
    >> Would there be any forseeable disadvantages doing this?
    >> I see it as a way of getting max. call quality in inbound calls esp.
    >> where downstream bandwidth is not such an issue as upstream.

    >
    > Less calls through your Internet connection. The calls require the
    > same amount of bandwidth in either direction regardless of whether
    > they are incoming calls or outgoing calls.
    >
    >>
    >> Any thoughts?
    >> Pete

    >


    Most offer G.711a (this is the European/worldwide standard). It provides
    the best 8khz sampled audio available.

    G.711u is a US standard. G.726/729 or other compression standards (GSM,
    Speex etc.) is only useful where bandwidth is a big issue.

    peter
     
    PeterW, Dec 18, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tony

    Forcing native 802.1x supplicant to re-auth??!

    Tony, Jul 2, 2004, in forum: Wireless Networking
    Replies:
    3
    Views:
    3,111
    Pavel A.
    Jul 8, 2004
  2. Blacklab

    forcing one connection

    Blacklab, Oct 6, 2005, in forum: Wireless Networking
    Replies:
    5
    Views:
    539
    Blacklab
    Oct 8, 2005
  3. fety
    Replies:
    7
    Views:
    748
    graeme@invalid
    Mar 4, 2005
  4. Greg
    Replies:
    2
    Views:
    1,906
  5. Replies:
    1
    Views:
    648
    Wolfgang S. Rupprecht
    May 23, 2006
Loading...

Share This Page