Professional Web Applications Themes
  1. #1

    Default Re: V.90: mu-law vs. a-law?

    [email]geos@epost.de[/email] (Georg Schwarz) writes:
    >
    > Does V.90 require the explicite configuration by the user of mu-law
    > or a-law, respectively? I'm ujsing an iBook's internal modem in
    > Brazil with a German version of Mac OS X. So far I only get V.34
    > connects, not V.90 (could be the line quality though).
    It's line quality.

    mu-law vs. a-law is a function of what the phone company uses on the
    digital trunks. Your modem connects to an og circuit and so
    isn't involved in this.

    If you are running the server side of a 56K connection (which is
    attached to a digital telco circuit) then it would make a difference.
    But the result of using the wrong encoding would be no connection at
    all, not a reduced-speed connection.
    > Does anybody know which would be the appropriate V.90 setup for
    > Brazil?
    Can't help here. I don't know what Brazil's telco standard is.

    -- David
    David C. Guest

  2. #2

    Default Re: V.90: mu-law vs. a-law?

    David C. <shamino@techie.com> wrote:
    > mu-law vs. a-law is a function of what the phone company uses on the
    > digital trunks. Your modem connects to an og circuit and so
    > isn't involved in this.
    I'm not so sure about that last sentence. V.90 in fact does make use of
    the fact that the subscriber is connected to a digital switch, and it
    has to make use of the digital-og conversion internals. Otherwise
    with the bandwidth of an og line we would be limited to V.34. For a
    strictly og connection with the voice quality bandwidth (spectrum)
    available, 33600 bps basically is almost the theoretical limit.
    At least Apple's V.90 modem (and I'm sure many others as well) has some
    settings of assuming either a-law or mu-law og/digital conversion
    facilities. What I'm wondering is whether this has to be set manually or
    whether it is detected automatically by the V.90 protocol.
    >
    > If you are running the server side of a 56K connection (which is
    > attached to a digital telco circuit) then it would make a difference.
    normal V.90 modems cannot even run as server side modems (if you try
    V.34 is the most you get). On the other hand, you are right, for V.90
    server side equipment it surely does make a difference.
    > But the result of using the wrong encoding would be no connection at
    > all, not a reduced-speed connection.
    I assume if I don't get a V.90 connection the modem falls back to V.34.
    This is what I get.


    --
    Georg Schwarz [url]http://home.pages.de/~schwarz/[/url]
    [email]geos@epost.de[/email] +49 177 8811442
    Georg Schwarz Guest

  3. #3

    Default Re: V.90: mu-law vs. a-law?

    Georg Schwarz writes:
    > David C. wrote:
    >>
    >> mu-law vs. a-law is a function of what the phone company uses on
    >> the digital trunks. Your modem connects to an og circuit and
    >> so isn't involved in this.
    >
    > I'm not so sure about that last sentence. V.90 in fact does make use
    > of the fact that the subscriber is connected to a digital switch,
    > and it has to make use of the digital-og conversion internals.
    Not correct.

    It assumes that the server side is digitally-connected to the public
    phone network.

    The client side is always connected to an og loop. If you have a
    digital connection in your home, then you have ISDN or a leased line,
    and your interface is nothing like a modem.

    It is true that your local line must connect directly to an
    og-digital converter, but that's because og repeaters
    introduce too much noise into the signal. It is not a function of
    the encoding algorithms.
    >> If you are running the server side of a 56K connection (which is
    >> attached to a digital telco circuit) then it would make a
    >> difference.
    >
    > normal V.90 modems cannot even run as server side modems (if you try
    > V.34 is the most you get).
    Didn't say otherwise. When you have a digital connection to the
    phone system (as in ISDN, leased lines or other digital connections)
    then you must generate the bit-stream that corresponds to the audio
    that an og client will get. In order to properly do this, you
    absolutely need to know if it's a-law or mu-law.

    This is the case for any protocol - even the old Bell-212A (300bps)
    protocol - if you have a digital link to the phone network.

    a-law and mu-law are og-digital encoding standards. Equipment
    which converts between the two must support the right standard.
    Which means modems that have digital connections to the phone network
    and the equipment that telcos use to terminate the og local loop.
    >> But the result of using the wrong encoding would be no connection
    >> at all, not a reduced-speed connection.
    >
    > I assume if I don't get a V.90 connection the modem falls back to
    > V.34. This is what I get.
    Most (if not all) modems manufactured have firmware that supports all
    prior standards (33.6, 28.8, 14.4, 9600, 2400, 1200 and 300). They
    negotiate a protocol at startup using the answer tones and the
    high-speed protocols have facilities for dynamically changing speeds
    during a session in order to accommodate line-condition changes.

    But none of the standards (not even 300bps) will work if a digitally-
    attached modem uses the wrong encoding standard.

    -- David
    David C. Guest

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139