09-13-2008 11:27 AM
Hi
I have asked my current L3 MPLS Service Provider to pass my Nortel Passport traffic . They say same will not be possible as their MPLS network does not support cRTP packets.
I am confused. Pls clarify why such a limitation. Thanks in advance.
Solved! Go to Solution.
09-16-2008 12:15 PM
Hello Srini,
RTP Header Compression and QoS
RFC 1889 leavingcisco.com specifies the RTP, which manages the audio path transport for Voice over IP (VoIP). RTP provides such services as sequencing to identify lost packets and 32-bit values to identify and distinguish between multiple senders in a multicast stream. Importantly, it does not provide or ensure QoS.
VoIP packets are composed of one or more speech codec samples or frames encapsulated in 40 bytes of IP/UDP/RTP headers. 40 bytes is a relatively large amount of overhead for the typical 20-byte VoIP payloads, particularly over low-speed links. RFC 2508 leavingcisco.com specifies compressed RTP (cRTP), which is designed to reduce the IP/UDP/RTP headers to two bytes for most packets in the case where no UDP checksums are being sent, or four bytes with checksums. The compression algorithm defined in this document draws heavily upon the design of TCP/IP header compression as described in RFC 1144 leavingcisco.com .
RFC 2508 actually specifies two formats of cRTP:
*
Compressed RTP (CR) - Used when the IP, UDP, and RTP headers remain consistent. All three headers are compressed.
*
Compressed UDP (CU) - Used when there is a large change in the RTP timestamp or when the RTP payload type changes. The IP and UDP headers are compressed, but the RTP header is not.
see
http://www.cisco.com/en/US/tech/tk543/tk762/technologies_tech_note09186a0080108e2c.shtml#head
you understand that if IPv4+UDP+RTP headers are reduced to two bytes it is difficult for a L3 device in the middle to understand what is the frame it is receiving
Hope to help
Giuseppe
09-13-2008 11:55 AM
Srinivas,
The restriction is related to the support of cRTP over MPLS interfaces. This should be a problem on the PE to P link but not on the CE to PE link, as the latter does not require MPLS.
Regards,
09-14-2008 03:03 AM
Hi Hritter
Thanks for the reply.
The question here again is that while the Service Provider is carrying UDP voice packets between PE ( source) to PE (Destination) why is the limitation for cRTP packet specifically. I belive the PE to PE transport should be transparent to IP traffic.
Thanks for reply in advance...
Srini
09-15-2008 04:01 AM
Hello Srini,
cRTP actually compresses also the IP header and so that traffic is fine on a point-to-point L2 link not if examined by PE router in L3 MPLS VPN service.
It isn't a standard IPv4 packet because it is targeted at reducing the header overheads in small VoIP packets it isn't a payload compression.
Hope to help
Giuseppe
09-15-2008 08:32 AM
Hi Giuseppe
I understand what you said and that is more close to my understanding too that cRTP is doing something for headers and hence being non-transparent on MPLS between PE to PE.
Could you throw some statistics on the header compression OR alternatively suggest a better link for the same.
Thanks a lot in advance
Srini
09-16-2008 12:15 PM
Hello Srini,
RTP Header Compression and QoS
RFC 1889 leavingcisco.com specifies the RTP, which manages the audio path transport for Voice over IP (VoIP). RTP provides such services as sequencing to identify lost packets and 32-bit values to identify and distinguish between multiple senders in a multicast stream. Importantly, it does not provide or ensure QoS.
VoIP packets are composed of one or more speech codec samples or frames encapsulated in 40 bytes of IP/UDP/RTP headers. 40 bytes is a relatively large amount of overhead for the typical 20-byte VoIP payloads, particularly over low-speed links. RFC 2508 leavingcisco.com specifies compressed RTP (cRTP), which is designed to reduce the IP/UDP/RTP headers to two bytes for most packets in the case where no UDP checksums are being sent, or four bytes with checksums. The compression algorithm defined in this document draws heavily upon the design of TCP/IP header compression as described in RFC 1144 leavingcisco.com .
RFC 2508 actually specifies two formats of cRTP:
*
Compressed RTP (CR) - Used when the IP, UDP, and RTP headers remain consistent. All three headers are compressed.
*
Compressed UDP (CU) - Used when there is a large change in the RTP timestamp or when the RTP payload type changes. The IP and UDP headers are compressed, but the RTP header is not.
see
http://www.cisco.com/en/US/tech/tk543/tk762/technologies_tech_note09186a0080108e2c.shtml#head
you understand that if IPv4+UDP+RTP headers are reduced to two bytes it is difficult for a L3 device in the middle to understand what is the frame it is receiving
Hope to help
Giuseppe
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide