Arun,
I forwarded your mail to a friend of mine, sumanth. Below is what
he(Sumanth) had to say.
Hey,
As per RFC, you need to have the following format for RTCP XR:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | *PT=XR=207* | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PT=207 (XR) indicates that the RTCP packet contains XR report.
RTCP Packets have the following header structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | *PT=RR=201* | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | *PT=SR=200* | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| SC | *PT=SDES=202* | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | *PT=BYE=203* | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Hence, I feel, RTCP XR report has to be sent as a separate packet with
PT=207. Though there is mention of Stacking RTCP XR report with existing
RTCP Packets, there is no clarity on achieving this.
Stacking the XR report with RTCP RR / RTCP SR report might help. Refer to
the attached file for more details on how a stacked RTCP report would look
like.
XR in turn has the following Blocks:
Loss RLE Report Block - Run length encoding of reports concerning the
losses and receipts of RTP packets.
Duplicate RLE Report Block - Run length encoding of reports concerning
duplicates of received RTP packets
Packet Receipt Times Report Block - A list of reception timestamps of
RTP packets
Receiver Reference Time Report Block - Receiver-end wallclock
timestamps. Together with the DLRR Report Block mentioned next, these
allow non-senders to calculate round-trip times.
DLRR Report Block - The delay since the last Receiver Reference Time
Report Block was received. An RTP data sender that
receives a Receiver Reference Time Report Block can respond with
a DLRR Report Block, in much the same way as, in the mechanism
already defined for RTCP [9, Section 6.3.1], an RTP data
receiver that receives a sender's NTP timestamp can respond by filling
in
the DLSR field of an RTCP reception report block.
Statistics Summary Report Block - Statistics on RTP packet sequence
numbers, losses, duplicates, jitter, and TTL or
Hop Limit values
VoIP Metrics Report Block - Metrics for monitoring Voice over IP (VoIP) calls.
2008/5/22 arun <[EMAIL PROTECTED]>:
> hi all
> I have problems with RTCP XR.
> How should the packet be sent in network..Is it with the SR and RR or is it
> sent as a seperate packet.
>
> The problem i have is, after concatenating the RTCP XR packet with SR, RTCP
> XR is being recognised as a Profile Specific Extension but SR is recognise
> properly.
> can anyone help.
> Thnks
> ---
> Regards
> Arun S
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely for the use of the addressee(s). If you are not the intended
> recipient, please notify the sender by e-mail and delete the original
> message.Global Edge Software Ltd has taken every reasonable precaution to
> minimize this risk, but is not liable for any damage you may sustain as a
> result of any virus in this e-mail. You should carry out your own virus
> checks before opening the e-mail or attachment. Global Edge Software Ltd
> reserves the right to monitor and review the content of all messages sent to
> or from this e-mail address
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
--
Regards
Harsha
User Datagram Protocol, Src Port: 53009 (53009), Dst Port: 50047 (50047)
Source port: 53009 (53009)
Destination port: 50047 (50047)
Length: 52
Checksum: 0x428e [correct]
[Good Checksum: True]
[Bad Checksum: False]
Real-time Transport Control Protocol (Sender Report)
[Stream setup by SDP (frame 2)]
[Setup frame: 2]
[Setup Method: SDP]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 0000 = Reception report count: 0
Packet type: Sender Report (200)
Length: 6 (28 bytes)
Sender SSRC: 0x0000358b (13707)
Timestamp, MSW: 10 (0x0000000a)
Timestamp, LSW: 3014530169 (0xb3ae1479)
[MSW and LSW as NTP timestamp: Feb 7, 2036 06:28:26.7019 UTC]
RTP timestamp: 3166505852
Sender's packet count: 251
Sender's octet count: 20080
Real-time Transport Control Protocol (Source description)
[Stream setup by SDP (frame 2)]
[Setup frame: 2]
[Setup Method: SDP]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 0001 = Source count: 1
Packet type: Source description (202)
Length: 3 (16 bytes)
Chunk 1, SSRC/CSRC 0x358B
Identifier: 0x0000358b (13707)
SDES items
Type: CNAME (user and domain) (1)
Length: 4
Text: MG9K
Type: END (0)
[RTCP frame length check: OK - 44 bytes]_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
