VOIP - TCP or UDP

controlcontrol Posts: 309Member
I always thought it was UDP, but my Todd Lammle states Voice traffic uses TCP? Is this an error?

Comments

  • YFZbluYFZblu Posts: 1,462Member ■■■■■■■■□□
    control wrote: »
    I always thought it was UDP, but my Todd Lammle states Voice traffic uses TCP? Is this an error?

    As far as I know, yes - VoIP uses UDP for transport. What does the book say exactly? Have you checked the Lammle website for errata?
  • controlcontrol Posts: 309Member
    YFZblu wrote: »
    As far as I know, yes - VoIP uses UDP for transport. What does the book say exactly? Have you checked the Lammle website for errata?

    Will check exactly tonight, I read it just before I went to sleep, and now at work. I thought it could be errata, but If I remember correctly it then tried to justify why it used TCP (reliable delivery etc..). WIll double check it all tonight, and see if it was an error.
  • YFZbluYFZblu Posts: 1,462Member ■■■■■■■■□□
    control wrote: »
    Will check exactly tonight, I read it just before I went to sleep, and now at work. I thought it could be errata, but If I remember correctly it then tried to justify why it used TCP (reliable delivery etc..). WIll double check it all tonight, and see if it was an error.

    Problem with that situation is once TCP tries to recover a lost packet during a VoIP call, that moment has already passed and it would ruin the flow of normal conversation.
  • veritas_libertasveritas_libertas CISSP, GIAC x5, CompTIA x5 Greenville, SC USAPosts: 5,735Member ■■■■■■■■■■
    It most definitively uses UDP. This is not to say that the VoIP application couldn't handle error correction at Layer-7, but VoIP would be UDP.
    Currently working on: Linux and Python
  • Greenmet29Greenmet29 Posts: 240Member
    I would check the errata. It's gotta be a mistake
  • fsanyeefsanyee Posts: 171Member
    I think voip use TCP to control data and UDP to voice data.
  • SharkDiverSharkDiver Posts: 844Member
    Everything I ever read said that VoIP was UDP.

    TCP wouldn't make sense. TCP will resend a packet that wasn't received. When talking about VoIP, you would not want to receive that packet later, because it would contain a part of the conversation that has already passed.
  • controlcontrol Posts: 309Member
    Everyones backing up what I always thought/read. Can't wait to get home now to check this again! icon_smile.gif
  • controlcontrol Posts: 309Member
    Right, back and have checked the book. This is what it says. It's page 78 of the CCNA Sybex book if anyone else has it.

    "So, if you're using Voip for example, you really don't want to use UDP, because if segments arrive out of order (very common in IP networks) they'll ust be passed up to the next OSI (DOD) layer in whatever order they are received, resulting in some seriously garbled data. On the other hand, TCP sequences the segments so they get put back together in exactly the right order - something UDP just can't do"

    I have checked the errata Sybex: CCNA: Cisco Certified Network Associate Study Guide: Exam 640-802, 6th Edition but it's not there. So is this a mistake?
  • boredgameladboredgamelad Posts: 365Member ■■■■□□□□□□
    A few quick Google searches for "Lammle voip tcp" turned up these threads:

    TCP or UDP for VOIP? [Archive] - Lammle Forum
    TCP is used for VoIP (CCNA Fast Pass 3rd Ed., pag. 22) [Archive] - Lammle Forum

    Seems kind of like a weird answer, but there you go.
  • sexion8sexion8 Posts: 242Member
    control wrote: »
    "So, if you're using Voip for example, you really don't want to use UDP, because if segments arrive out of order (very common in IP networks) they'll ust be passed up to the next OSI (DOD) layer in whatever order they are received, resulting in some seriously garbled data. On the other hand, TCP sequences the segments so they get put back together in exactly the right order - something UDP just can't do"

    Bottom line is, you need to answer this how Cisco wants you to answer this. The reality of it is, VoIP is a BUNCH of different protocols, SIP, SRTP, RSTP, TLS, and so forth. I perceive he was meaning something along the lines of the SIGNALING part of the protocol "Do not want to use UDP for SIP SIGNALING" which is the only place it would make sense.

    On the audio side of the equation (RTSP) it would make no sense for error correction nor going back and forth since it would add overhead without giving you any benefit. In a normal TCP connection, the purpose of even using TCP is for error correction, checksumming, sequencing. For a session to work flawlessly, there are parameters in place using TCP to correct errors. In a live conversation (RTSP) there is no mechanism for a device to go back to someone's voice and retrieve what was already said:

    VoIP Call --> hello --> Recipient --> Dead_Air
    Recipient --> TCP error --> Caller "resend what you said a second ago"

    At max in a Real Time (the RT in RTSP) it needs to be blazing fast and has no time to go back and ensure all packets arrived before proceeding. You may think that you could buffer a conversation and you can for at MAX maybe 3 seconds before you have a conversation like this:

    You (using VoIP) ---> Hello --> recipient (1 second - real time)
    Recipient --> Hi how are you --> dead air for 3 seconds --> You

    You'd get the effect of say watching CNN correspondents talk with someone abroad where they respond after some massive lag. In a VoIP conversation especially where business is concerned, this would not fly especially for say the financial arena where trades are made in second
    "Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth." - Marcus Aurelius
  • YFZbluYFZblu Posts: 1,462Member ■■■■■■■■□□
    From the link:

    LAMMLE:

    I can say this because Cisco removed it from the objectives:

    There was a time where Cisco DID have an answer of TCP for VoIP, hence the note in my book. However, that "problem" has been removed, so always think "UDP" if thinking VoIP.

    On another note. That question you are referring to is way TOO EASY for the CCNA exam. You will not find anything even remotely close to something that easy any longer. I am not sure where you are studying, but you'll be shocked beyound belief when you go take your CCNA exam and find out that is less questions now (44) and a lot more simulations (4 to 6 I think).

    So, get on the gear and configure NAT/PAT, ACL's, EIGRP, OSPF, Frame-Relay...etc, etc...you HAVE to be able to configure all the objectives to pass this test! IT IS HARD!

    Okay, good luck :)
    Cheers!
    Todd Lammle
Sign In or Register to comment.