Subject: [AVT] Parameters lost for media type MPA in new RFC4856 ?

From: "Coinchon, Mathias" <[email-masked]>
Date: Mon, 2 Apr 2007 08:33:03 +0200

Dear RFC editors,

I have one question regarding the new RFC4855 and RFC4856 that obsolete
RFC3555:

- Where are parameters for MPA (mpeg audio) specified ? They were in RFC3555
(4.1.17) but not anymore in RFC4856.

As I have understood from RFC4855/4856, parameters should now be specified
in payload format RFCs.
However looking in RFC2250 for MPEG payload format (video and audio) I don't
see a specification of these parameters.
Looking on IANA pages, media type MPA still point on RFC3555.

Could you please tell me where to point now for MPEG audio parameters ?

Will there be modifications of RFC2250 for MPEG payload format specifying
parameters ? (and modification of RFC3550/3551 to point to RFC3855/56
instead of RFC3555 ?)

This is an important issue as we rely and point to RFCs for the signalling
of parameters (using SDP) for a standard on Audio contribution over IP (EBU
group N/ACIP).

Thank you

Regards,

Mathias Coinchon
Senior Engineer
Technical Department

European Broadcasting Union
L'Ancienne-Route 17A
1218 Grand-Saconnex
Switzerland

Tel +41 22 717 27 16
Fax +41 22 747 47 16

-----------------------------------------
**************************************************
This email and any files transmitted with it 
are confidential and intended solely for the 
use of the individual or entity to whom they
are addressed. 
If you have received this email in error, 
please notify the system manager.
This footnote also confirms that this email 
message has been swept by the mailgateway
**************************************************

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Stephen Casner <[email-masked]>
Date: Mon, 2 Apr 2007 12:21:30 -0700 (PDT)

> Could you please tell me where to point now for MPEG audio parameters ?

Section 1.1, IANA Considerations, in RFC4856 says:

    Some media type registrations contained in RFC 3555 are omitted
    from this document; the existing registrations for those types
    continue to be valid until updated by other RFCs.

That is why on the IANA pages, media type MPA still lists RFC3555 as
the reference.

> parameters ? (and modification of RFC3550/3551 to point to RFC3855/56

There was some work done on updating RFC2250 by one of the authors,
but that has not come to fruition.  In any case, I would expect any
changes to be backwards compatible with the parameter specifications
in RFC3555.

                                                         -- Steve

---

From: "Bhattacharya, Abhijit \(Abhijit\)" <[email-masked]>
Date: Tue, 3 Apr 2007 13:11:54 +0530

Hi,

I have a confusion regarding RTP header. Let us suppose the following
considerations

Version = 2
Padding = 0
Extension = 0
CC = 0
PT = 0
Seq. No. = 0A9E

Now what should be the packet look like 

0000 80 00 0A 9E ....
0010 ................

  OR 

0000 02 00 9E 0A ....
0010 ................

I am confused regarding this. 

Thanks and regards,
Abhijit

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 03 Apr 2007 10:50:20 +0200

> Now what should be the packet look like 

It is network byte order, which means the most significant bits and 
bytes first.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Bhattacharya, Abhijit \(Abhijit\)" <[email-masked]>
Date: Tue, 3 Apr 2007 14:26:50 +0530

Hi Magnus,

Thanks for the information. Actually, the rtp_hdt_t structure in RFC
3550 resulted in the confusion. Here version field is the 1st element in
the structure. So it becomes the LSB. Anyways, now its clear to me.

Thanks and regards,
Abhijit 

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 2:20 PM
To: Bhattacharya, Abhijit (Abhijit)
Cc: [email-masked]
Subject: Re: [AVT] Confusion regarding RTP

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 03 Apr 2007 11:04:14 +0200

> the structure. So it becomes the LSB. Anyways, now its clear to me.

Your comment make me think you are misunderstanding how bit fields in C 
are defined? If one looks at the rtp_hdt_t:

    typedef struct {
        unsigned int version:2;   /* protocol version */
        unsigned int p:1;         /* padding flag */
        unsigned int x:1;         /* header extension flag */
        unsigned int cc:4;        /* CSRC count */
        unsigned int m:1;         /* marker bit */
        unsigned int pt:7;        /* payload type */
        unsigned int seq:16;      /* sequence number */
        u_int32 ts;               /* timestamp */
        u_int32 ssrc;             /* synchronization source */
        u_int32 csrc[1];          /* optional CSRC list */
    } rtp_hdr_t;

I can't understand why you think version is the LSB. Starting in the 
most significant 2 bits in the first byte write version. The next bit is 
p, then x, then 4 bits of CC in MSB to LSB. In the next byte there is 
first the marker bit (bit 9) and then 7 PT bits. Then you have the more 
significant first byte of the sequence number, followed by the less 
significant byte.

Cheers

Magnus Westerlund

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 3 Apr 2007 11:10:02 +0100

It seems you've forgotten that C (and C++) reserves the right to pack these 
up how it feels.  Try:

    #include <stdio.h>

    typedef unsigned int u_int32;

    typedef struct {

    typedef union {
        rtp_hdr_t rtp;
        unsigned int uint;
    } thingy;

    int main()
    {
        thingy my_thing;

        my_thing.uint = 0;
        my_thing.rtp.version = 3;
        printf( "Version: %x\n", my_thing.uint );

        my_thing.uint = 0;
        my_thing.rtp.seq = 0xffff;
        printf( "Seq: %x\n", my_thing.uint );

        return 0;
    }

I get:

Version: 3
seq: ffff0000

on both Visual Studio x86 and Cygwin GCC (x86).

Hence this is not likely to be portable.

HTH,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx/
http://www.codalogic.com/lmx/
=============================================

----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Bhattacharya, Abhijit (Abhijit)" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 03, 2007 10:04 AM
Subject: Re: [AVT] Confusion regarding RTP

> I can't understand why you think version is the LSB. Starting in the most 
> significant 2 bits in the first byte write version. The next bit is p, 
> then x, then 4 bits of CC in MSB to LSB. In the next byte there is first 
> the marker bit (bit 9) and then 7 PT bits. Then you have the more

---

From: Nikola Sprljan <[email-masked]>
Date: Tue, 03 Apr 2007 11:25:23 +0100

> significant first byte of the sequence number, followed by the less

It think the problem that Abhijit is encountering is a common one with C
bit-fields - the order of bits will depend on endianess of processor
this is compiled on. Since x86 processors use the little-endian format,
you'll have to manually reverse the order of fields for each byte in the
structure. You'll also have to do conversions from/to network byte order
(which is big-endian) by using ntohl and htonl (and other) functions.

Also, for data to be aligned properly, for some versions of the MS
compiler you have to specify correct packing when in a default Debug mode:
#pragma pack(1)
, otherwise casting pointers to/from structures including rtp_hdr_t
struct would not work.

Kind regards,

Nikola Sprljan

-- 
*Dr. Nikola Sprljan*
/Research Engineer/
*MITSUBISHI ELECTRIC INFORMATION TECHNOLOGY CENTRE EUROPE B.V*
*VISUAL INFORMATION LABORATORY*
20, Frederick Sanger Road
The Surrey Research Park
Guildford, Surrey GU2 7YD
/UK Registered Branch BR 003158/
*DDI Telephone: +44 1483 885538*
Tel: +44 1483 885800   Fax: +44 1483 579107

CONFIDENTIALITY NOTICE:
This message contains information which is confidential and/or privileged
and is intended for the named addressee(s) only. If you are not the
intended recipient, you must not copy, distribute, disclose, otherwise
use the information or take any action in reliance on it. If you have
received this message in error, please notify sender immediately and
destroy any copies whether in physical or electronic record.

---

From: Nikola Sprljan <[email-masked]>
Date: Tue, 03 Apr 2007 11:36:35 +0100

Please disregard the confidentiality notice in my previous mail, it was
inserted by mistake.

Nikola

---

From: Colin Perkins <[email-masked]>
Date: Tue, 3 Apr 2007 11:44:47 +0100

Note the comment at the start of appendix A of RFC 3550:

    The following definitions are used for all examples; for clarity and
    brevity, the structure definitions are only valid for 32-bit big-
    endian (most significant octet first) architectures.  Bit fields are
    assumed to be packed tightly in big-endian bit order, with no
    additional padding.  Modifications would be required to construct a
    portable implementation.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Bhattacharya, Abhijit \(Abhijit\)" <[email-masked]>
Date: Tue, 3 Apr 2007 16:22:13 +0530

Hi all,

Thanks for your inputs. Actually I just now attempted in both Solaris
and Linux the same code as the following 

#include<stdio.h>
#include<math.h>
#include <stdlib.h>
#include <string.h>
#include <netinet/in.h>
typedef struct headers {
       unsigned int version:2;   /* protocol version */
       unsigned int p:1;         /* padding flag */
       unsigned int x:1;         /* header extension flag */
       unsigned int cc:4;        /* CSRC count */
        }HDR;
   typedef struct {
       HDR       u;
       unsigned int ts;               /* timestamp */
       unsigned int ssrc;             /* synchronization source */
       unsigned int csrc[1];          /* optional CSRC list */
   } rtp_hdr_t;

main()
{
        char a[1];
        rtp_hdr_t rtp_hdr;
        rtp_hdr.u.version = 1;
        rtp_hdr.u.p = 0;
        rtp_hdr.u.x = 0;
        rtp_hdr.u.cc = 0;
        memcpy((void *)a, (void *)(&rtp_hdr.u), 1);
        printf("\n THE value is %x !! \n", a[0]);
}

In Linux the answer is :-

THE value is 1

And in Solaris the answer is :-

THE value is 40 !!

Initially I was using Linux and since htons does not work within "a
byte", I was confused. So the 1st element is considered MSB in Solaris
and LSB in Linux.

Thanks and regards,
Abhijit

-----Original Message-----
From: Nikola Sprljan [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 3:55 PM
To: Magnus Westerlund
Cc: Bhattacharya, Abhijit (Abhijit); [email-masked]
Subject: Re: [AVT] Confusion regarding RTP

Magnus Westerlund wrote:
>> 3550 resulted in the confusion. Here version field is the 1st element

>> in the structure. So it becomes the LSB. Anyways, now its clear to
me.
>>
> 
> Your comment make me think you are misunderstanding how bit fields in 
> C are defined? If one looks at the rtp_hdt_t:
> 
>    typedef struct {
> most significant 2 bits in the first byte write version. The next bit 
> is p, then x, then 4 bits of CC in MSB to LSB. In the next byte there 
> is first the marker bit (bit 9) and then 7 PT bits. Then you have the 
> more significant first byte of the sequence number, followed by the 
> less significant byte.

Also, for data to be aligned properly, for some versions of the MS
compiler you have to specify correct packing when in a default Debug
mode:
#pragma pack(1)
, otherwise casting pointers to/from structures including rtp_hdr_t
struct would not work.

Kind regards,

Nikola Sprljan

--
*Dr. Nikola Sprljan*
/Research Engineer/
*MITSUBISHI ELECTRIC INFORMATION TECHNOLOGY CENTRE EUROPE B.V* *VISUAL
INFORMATION LABORATORY* 20, Frederick Sanger Road The Surrey Research
Park Guildford, Surrey GU2 7YD /UK Registered Branch BR 003158/ *DDI
Telephone: +44 1483 885538*
Tel: +44 1483 885800   Fax: +44 1483 579107

CONFIDENTIALITY NOTICE:
This message contains information which is confidential and/or
privileged and is intended for the named addressee(s) only. If you are
not the intended recipient, you must not copy, distribute, disclose,
otherwise use the information or take any action in reliance on it. If
you have received this message in error, please notify sender
immediately and destroy any copies whether in physical or electronic
record.

---

From: Nikola Sprljan <[email-masked]>
Date: Tue, 03 Apr 2007 12:14:24 +0100

> and Linux the same code as the following 
...
> byte", I was confused. So the 1st element is considered MSB in Solaris

My guess is that you are running Solaris on a SPARC architecure
(big-endian), while your Linux is on a x86 based machine
(little-endian). Remember, it's the processor that counts here, not the
OS. Also, some new SPARCs have switchable endianness.

And I forgot to mention: my initial assumption was that you were
compiling this on a x86 or some other little-endian processor, due to
observations you made in your second e-mail.

Cheers,

Nikola

---

From: "Bhattacharya, Abhijit \(Abhijit\)" <[email-masked]>
Date: Tue, 3 Apr 2007 16:53:13 +0530

Hi Nikola,

"My guess is that you are running Solaris on a SPARC architecure
(big-endian), while your Linux is on a x86 based machine
(little-endian). Remember, it's the processor that counts here, not the
OS. Also, some new SPARCs have switchable endianness."

Yes your guess is absolutely right.

Thanks and regards,
Abhijit

-----Original Message-----
From: Nikola Sprljan [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 4:44 PM
To: Bhattacharya, Abhijit (Abhijit)
Cc: [email-masked]
Subject: Re: [AVT] Confusion regarding RTP

...

Cheers,

Nikola

> It think the problem that Abhijit is encountering is a common one with

> C bit-fields - the order of bits will depend on endianess of processor

> this is compiled on. Since x86 processors use the little-endian 
> format, you'll have to manually reverse the order of fields for each 
> byte in the structure. You'll also have to do conversions from/to 
> network byte order (which is big-endian) by using ntohl and htonl (and
other) functions.

---

From: "Bhattacharya, Abhijit \(Abhijit\)" <[email-masked]>
Date: Tue, 3 Apr 2007 20:41:31 +0530

Hi all,

Sorry troubling you all again. 

Suppose I wish to send EVRC rate 1/2 packets (ptime 120, maxptime 120,
hence no variation in rates and no interleaving) what will be the value
of "Mode (mmm)" field in RTP payload header. Will it be 4 (since all
packets are 1/2) or 0 ?

I feel that since Rate 1 packets are not being transmitted so the
fraction of Rate 1 packets being Rate 2 does not arise. So this field
can be ignored. Is my thinking right?

Thanks and regards,
Abhijit

-----Original Message-----
From: Nikola Sprljan [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 4:44 PM
To: Bhattacharya, Abhijit (Abhijit)
Cc: [email-masked]
Subject: Re: [AVT] Confusion regarding RTP

...

Cheers,

Nikola

other) functions.

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 3 Apr 2007 11:13:55 -0700

"Compact bundle format" is probably the correct payload format for what
you are trying to do. The corresponding MIME type is EVRC1. See section
4, RFC 4788 for more details.

-Hari

> From: Bhattacharya, Abhijit (Abhijit) [mailto:abhattacharya@alcatel-
> lucent.com]
> Sent: Tuesday, April 03, 2007 8:12 AM
> To: Nikola Sprljan
> Cc: [email-masked]
> Subject: RE: [AVT] Confusion regarding RTP
> 
> Hi all,
> 
*VISUAL