One way audio

Discussion in 'UK VOIP' started by PL, Feb 28, 2006.

  1. PL

    PL Guest

    I've been with since last October and have been a very happy
    bunny ever since. However today at around 4pm, with every geographical
    call I made, I could hear them, but they couldn't hear me. Hopefully
    this is a short term issue, but can anyone give an explanation as to why
    this happens?

    Sure I've raised the issue with and their technical team is
    looking into it.

    I'm not making a fuss, but would simply like to acquire a better
    understanding of the 'way things work'. Mind you, anything too
    technical and it'll be beyond my comprehension anyway. Keep it basic
    PL, Feb 28, 2006
    1. Advertisements

  2. PL

    PL Guest

    Anybody here using with Metronet (Plusnet). Any problems
    with audio?
    PL, Mar 1, 2006
    1. Advertisements

  3. PL

    Andrew Crane Guest

    The gateway to the PSTN will be over either SS7 or Q931 (SS7 is the protocol
    that carriers talk to each other over and Q931 is usually used to interface
    to their customers). In both cases, the transmit and receive paths are on
    different physical cables. In the case of SS7, the audio bearers are more
    than likely to be on separate circuits to the signalling. So a break in the
    cable the transmit is going down will cause a 1 way audio whenever that
    particular trunk is being used to transmit. Because the signalling is
    happening on different cables, the call won't drop, just one half of the

    Andrew Crane, Mar 1, 2006
  4. PL

    PL Guest

    So what actually is a 'break in the cable'? Is this a temporary or
    permanent interuption / obstruction ' interference? Do breaks just
    happen and just happen also to go through a 'self-reparation' process?
    PL, Mar 1, 2006
  5. PL

    Andrew Crane Guest

    Normally something like this is quickly reported to, and bypassed by the
    network operator by shutting down the offending trunk for later repair.

    The reason I quoted the above scenario is that we have experienced this on
    several occasions and because it appears to be affecting only your PSTN
    calls. There might be many other reasons why this behaviour is being heard,
    this is just one.

    Andrew Crane, Mar 1, 2006
  6. PL

    Boonie... Guest

    In a normal telecom network a broken cable will NOT result in one way
    speech. The circuits will be automatically blocked. Other cables with
    parallel circuits will take the traffic. So this is not the issue here.

    Are you sure your microphone is OK?

    Boonie..., Mar 1, 2006
  7. To be perfectly frank, this is bollocks.

    Mostly due to the fact that E1 circuits are usually delievered over a 2
    copper pairs (+ring +tip -ring -tip), or coax (Rx/Tx). If the cable
    breaks, then the line protocol will fail and the device signals a LOS
    (Los Of Service (Unless of course you're cisco and you decide to send a
    Loss Of Frame instead (happened on one IOS version, 12.1 I think))).
    Even if they are not delivered in a single E1, and are multiplexed
    together onto an STM1 trunk, a break in that kind of cable means EVERY
    E1 trunked on the STM circuit goes down. So your comments regarding
    different cables and Q931 and transmission trunks, irrespective of SS7
    involvement, is just wrong.

    I can't think of a single telecoms device that would keep in service an
    interface that has a broken cable. I just wouldn't make any logical
    sense to do so... I may be wrong, but I don't even think that's

    I believe this should be an example of "go home and try it again"...

    ~ Rich
    Richard Smith, Mar 1, 2006
  8. Moo,

    The way thins work with VoIP to PSTN calls contains 2 major parts - the
    voIP bit, and the PSTN bit. I'm assuming you're asking about the VoIP
    side of "the way things work"...

    First some basic background:

    your average VoIP phone (audio) call contains 2 parts - Signalling and
    Media. It's very important to remember that these are two very
    distinct and seperate things.

    The signalling protocol used with a SIP device is, funnily enough ..
    SIP. SIP is used for signalling - i.e, telling a SIP server you want
    to make a call, hang up, etc. A SIP message contains a request or
    response line, followed by a number of headers, followed by an optional
    'body' (get back to the body in a moment).

    The Media part is used for transferring the actual audio of a phone
    call. With SIP, the media protocol used for transferin gthe audio is
    called RTP (Real Time Protocol). RTP works by splitting up a media
    stream (such as an audio stream captured from your phone handset) into
    smallish UDP packets and transmitting them, normally somewhere between
    10 and 60ms apart, depdning on your configuration, type of codec in
    use, etc.

    RTP streams are set up by using a protocol called SDP that is carried
    within a SIP message's body. SDP basically says what codecs are
    supported (i.e, what formats the audio can be sent in) by the device,
    and various parameters for those codecs (such as packet timings), audio
    direction, etc etc. It also contains the IP address and port to send
    RTP to.

    As mentioned before, Media and Signalling are 2 different things. We
    use seperate servers to handle the signalling and the media, as it is a
    lot easier to scale this way.

    Ok. So, when a device is not behind NAT, things are fairly simple.
    When you dial a number, your MTA/SIP Phone sends a SIP message of type
    INVITE to This message contains the number you want
    to dial, and among other things an SDP message within the body of the
    SIP message that has the IP address that the MTA would like the RTP
    stream to be sent to.

    So devices have to work out what IP address to send within the SDP
    message that contains that IP address. For devices not behind NAT,
    this is normally worked out by using the same IP address as the device
    itself has. I'll get onto NAT issues in a minute.

    [i'll skip 18x early media at this point, as it's not really that
    relivant for this].

    When the call is finally connected, sends back a "200
    OK" SIP response to the INVITE the device initially sent. Within that
    SIP message there is an SDP answer for the body of the message, that
    contains the IP address of where your MTA/SIP Phone should send the RTP
    stream to.

    Now, up to this point there is relativly few thigs that can go wrong
    when the MTA has a real IP address. Granted, i've seen some really
    messed up implementations that are incapable of even basic codec
    negotiation, and a supprising number of devices get very confused with
    packet sizes that are not multiples of 10ms with codecs that allow it
    .... but almost all stacks work correctly at this point when the MTA is
    not behind NAT.

    Next we bring NAT into the equation. first, a little bit of background
    on types of NAT. One of the reasons for inventing NAT was because there
    is a limited number of IP addresses on the internet, and they are
    fairly scarce resources. As more and more people needed more than one
    IP address, a solution to allow lots of devices share one IP address.
    That's why you have "internal IP addresses" (like 192.168.x.x,
    10.x.x.x), and "external ip addresses". Your router converts the
    internal addressses into a single external IP address. There are 4
    common ways of doing this: Symmetric NAT, Full cone NAT, Restricted
    Cone NAT, and Port Restricted Cone NAT. There is a fairly good doc on
    NAT at <>. The
    most common type of NAT with residential devices is port restricted,
    which is described in the aforementioned doc as:

    "An external host can send a packet, with source IP address X and
    source port P, to the internal host only if the internal host had
    previously sent a packet to IP address X and port P."

    So going back a little bit, before you place a phone call (or receive
    one), your device needs to work out what it's IP address AND port
    number will be to the media server so that it can tell the media server
    where to send the RTP stream in the INVITE message. There are
    essentially two problems here:

    SIP (Signalling)

    For your outgoing calls, the SIP server (signalling) needs to know
    where to send the responses to the INVITE message. RFC3261 (the SIP
    standard document) specifies that responses to SIP requests (such as an
    INVITE sent by your MTA) are sent back to the same IP address the
    request came from (so no problems here), but to the port number that is
    specified within the top Via header. If you've ever seen a SIP
    request, there will be at least one "Via" header that looks something
    like this:

    Via: SIP/2.0/UDP;branch=xxxxx

    SIP messages are with almost all MTA and resedential SIP devices sent
    over UDP. UDP is a protocol that does not establish a "connection"
    before you send traffic between hosts over the internet, and there is
    no garuntee that the packet will ever get there... because of this, you
    can't just send some data to the remote end like you do with TCP (the
    other common protocol used on the internet), but instead need to
    specify the destination IP and port number of each and every message
    you send.

    Each message sent over UDP contains a number of parameters, including
    the Source IP address, Source Port number, Destination IP Address, and
    Destination port number. So when your MTA (assuming it has an internal
    IP address of is behind NAT (and your external ip
    address is and you place a phone call to someone, the
    UDP packet leaving your SIP device contains the following (plus a lot
    lot more, ignored for the sake of this explanation):

    * Source IP Address:
    * Source Port: 5060
    * Destination IP Address:
    * Destination Port: 5060
    * Contents:
    INVITE sip::5060 SIP/2.0
    Via: SIP/2.0/UDP;branch=xxxx

    This arrives at your broadband router, which will create a NAT mapping
    to say =, where xxx is an
    availabe port number - lets say 15678. this means that any traffic
    sent back to would be sent to your internal
    address of So, it changes the UDP message and
    sends it out to your ISP who sends the message to us. As it leaves
    your DSL router, it would look something like this:

    * Source IP Address:
    * Source Port: 15678
    * Destination IP Address:
    * Destination Port: 5060
    * Contents:
    INVITE sip::5060 SIP/2.0
    Via: SIP/2.0/UDP;branch=xxxx

    Notice that the is still in the "Via" header there.
    The problem with devices that do NAT is that they normally only work at
    the IP layer (i.e, change the UDP/TCP headers, not the actual content
    of the message [1]).

    So, gets your INVITE, and unless something else
    outside the core SIP standard is done, it would try to send responses
    back to ... which is wrong as it should instead be
    goi nto

    The smart guys at the IETF realised this, and came up with an extension
    for SIP called 'rport'. Basically, it specifies that if the Via header
    contains an 'rport' parameter, the server should send responses back to
    the same port number as well as IP address. So if your device sends
    something like:

    Via: SIP/2.0/UDP;branch=xxxx;rport

    then all will work smoothly with modern SIP devices.

    you might be wondering why the original specification didn't set this
    as the default. I won't go into the details, but if anyone is
    interested, let me know and i'll try to explain why. neeedless to say,
    there is a valid reason that the base SIP standard specifies this.

    Almost all residential SIP devices these days come with rport turned on
    by default. However, there are still a number of legacy devices that
    don't (or the software writters didn't implement it), and they will
    cause problems.

    SDP (Media)

    This is where it gets a lot more complicated, and there is only one
    [almost] perfect solution (UPnP) that is supported by relativly few NAT
    routers, and only a tiny fraction of SIP devices. In the process of
    trying to work out a solution, a number of very broken "solutions" were
    invented (STUN being the major culprit).

    The problem here lies in a chicken and egg situation. when you want to
    call someone, the initial INVITE that is sent out needs to contain the
    IP address and port number that you need want to RTP (audio) sent to.
    However, you can't work that out until you've sent some RTP, as the NAT
    device (i.e, your router) is the thing allocating the port numbers.

    As mentioned before, the SIP request when you make a phone call is sent
    to, and contains a "body" that is an SDP message,
    defining the codecs supported, and an IP Address and port number of
    where to send the RTP (audio). the phone call gets processed, and then
    a response it sent and within it an IP address and port number where
    your MTA should send audio.

    So, looking at just the body of the SIP INVITE you send when you dial a
    number, you send something like this (i've skipped all apart from the 2
    lines related to this explanation) when behind NAT:

    c=IN IP4
    m=audio 56789 RTP/AVP 0.

    This says that any audio from the person you're calling should be sent
    to, port 56789. When the phone call starts, a SIP
    response is sent from that contains something like

    c=IN IP4
    m=audio 98765 RTP/AVP 0.

    which says your MTA should send audio from your phone to,
    port 98765.

    The problem is of course similar to the SIP issue above, which is that
    the NAT breaks this, as we can't send audio to however,
    even if we send it to the same IP address as we got the INVITE from
    (which would be your external address), the port number would still be
    incorrect, as RTP works on a different port (it's randomly chosen) from
    the signalling (which is commonly port 5060, but can be anyhting).

    STUN tries to get around this by contacting an "stun server" which does
    very little other than tell your MTA what the IP address and port
    number the message was seen from is - so you can work out your external
    IP address from this.

    However, if we recall the description of the commonly used port
    restricted NAT:

    "An external host can send a packet, with source IP address X and
    source port P, to the internal host only if the internal host had
    previously sent a packet to IP address X and port P."

    .... so many implementations will use a different external port for UDP
    packets sent from a device to a different external ip address, even
    when the source port if the same. So if your device tries to use STUN
    to calculate it's external IP address and port number to use, it would
    send something like this: ->

    Your NAT device would then create a mapping for traffic from to be sent to However, if a
    UDP packet came from (one of's media servers),
    it would not match this mapping and just drop the packet ("only if the
    internal host had previously sent a packet to IP address X and port P"
    - which it had not).

    So STUN is essentially useless for many NAT users, and infact cause so
    many problems we tell users to turn it off, as it effectly makes SIP
    messages we get look like the user is not behind NAT, so we don't
    attempt to work around NAT issues. It does however work for a sizable
    percentable of users, with slightly more inteligent NAT implementations
    or routers with built in "SIP support" [ick!].

    The real solution for almost all [2] users is UPnP. UPnP (it has many
    uses, but this is one of them) works by defining a protocol that lets
    your MTA tell your NAT device to open a mapping and allocate a port
    number, so the device knows what port number and IP address to use in
    the SDP message before sending the INVITE.

    However, as mentioned, very very few SIP devices support UPnP at this
    time, and those that do are foten not implmented correctly. So until
    then (or a better solution is invented, or IPv6 is everywhere), we do
    "clever stuff (tm)" to ensure you phoen calls work every time, without
    any need to enable STUN, port forwarding, or other hacks/manual
    confiuration of port forwarding and your SIP devices that are more than
    liktly not implemented correctly, or have not been thought through
    before implemrnting them in software.

    This is of course a very simplistic introduction to some of the issues
    with VoIP behind NAT. there are many other factors and issues
    involved, but the above is some of "normal" issues and solutions

    Any questions, corrections, or comments - let me know!

    ~ Theo

    1 - Some routers try to be clever and run what is known as an
    'Application Layer Gateway' (ALG) and change the SIP messages as well,
    but normally fail miserably and make even more problems, and even for
    the ones that function correctly, they can't work for encrypted
    protocols, such as secure SIP.

    2 - At least, it is for resedential users in your average situation
    where the NAT device is on the same broadcast domain at the UPnP
    client. Larger networks that have MTA's outside the same broadcast
    domain as the NAT router are still goi nto be broken.
    zourzouvillys, Mar 1, 2006
  9. PL

    Andrew Crane Guest

    I'll bow to your superior knowledge. This is how it has been explained to me
    by upstreams when we've had the fault, and I accept it could well have been
    dumbed down for my understanding.

    Andrew Crane, Mar 2, 2006
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.