Subject: [MMUSIC] SDP grouping in a new offer

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 5 Jul 2012 11:47:07 +0000

Experts,

RFC3264 states that:

   If an SDP is offered, which is different from the previous SDP, the
   new SDP MUST have a matching media stream for each media stream in
   the previous SDP.  In other words, if the previous SDP had N "m="
   lines, the new SDP MUST have at least N "m=" lines.  The i-th media
   stream in the previous SDP, counting from the top, matches the i-th
   media stream in the new SDP, counting from the top.  This matching is
   necessary in order for the answerer to determine which stream in the
   new SDP corresponds to a stream in the previous SDP.  Because of
   these requirements, the number of "m=" lines in a stream never
   decreases, but either stays the same or increases.  Deleted media
   streams from a previous SDP MUST NOT be removed in a new SDP;
   however, attributes for these streams need not be present.

>From section 9.1 of RFC5888, it seems the same is applicable with SDP grouping, but is not explicit. Should there be matching m-lines in the new offer even with SDP grouping? Does SDP grouping change anything w.r.t to the above statements in RFC3264?

thanks,
Muthu

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Jul 2012 18:15:01 +0200

Hi,

In my opinion the grouping framework does not change the at-least-N-m=-lines rule.

...which is probably why 5888 doesn't mention it.

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Muthu Arul Mozhi Perumal (mperumal) [[email-masked]]
Sent: Thursday, July 05, 2012 2:47 PM
To: mmusic
Cc: Raghavendra S (raghs); Toleti Danayya Naidu (naidud); Dinesh V (dinv)
Subject: [MMUSIC] SDP grouping in a new offer

Experts,

RFC3264 states that:

thanks,
Muthu

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 5 Jul 2012 17:21:17 +0000

Thanks, Christer. It does make sense, but is not clear from RFC5888. What would be best way to fix it? File an errata on RFC5888?

Muthu

|-----Original Message-----
|From: Christer Holmberg [mailto:[email-masked]]
|Sent: Thursday, July 05, 2012 9:45 PM
|To: Muthu Arul Mozhi Perumal (mperumal); mmusic
|Cc: Raghavendra S (raghs); Toleti Danayya Naidu (naidud); Dinesh V (dinv)
|Subject: RE: SDP grouping in a new offer
|
|Hi,
|
|In my opinion the grouping framework does not change the at-least-N-m=-lines rule.
|
|...which is probably why 5888 doesn't mention it.
|
|Regards,
|
|Christer
|
|________________________________
|From: [email-masked] [[email-masked]] On Behalf Of Muthu Arul Mozhi Perumal
|(mperumal) [[email-masked]]
|Sent: Thursday, July 05, 2012 2:47 PM
|To: mmusic
|Cc: Raghavendra S (raghs); Toleti Danayya Naidu (naidud); Dinesh V (dinv)
|Subject: [MMUSIC] SDP grouping in a new offer
|
|Experts,
|
|RFC3264 states that:
|
|   If an SDP is offered, which is different from the previous SDP, the
|   new SDP MUST have a matching media stream for each media stream in
|   the previous SDP.  In other words, if the previous SDP had N "m="
|   lines, the new SDP MUST have at least N "m=" lines.  The i-th media
|   stream in the previous SDP, counting from the top, matches the i-th
|   media stream in the new SDP, counting from the top.  This matching is
|   necessary in order for the answerer to determine which stream in the
|   new SDP corresponds to a stream in the previous SDP.  Because of
|   these requirements, the number of "m=" lines in a stream never
|   decreases, but either stays the same or increases.  Deleted media
|   streams from a previous SDP MUST NOT be removed in a new SDP;
|   however, attributes for these streams need not be present.
|
|From section 9.1 of RFC5888, it seems the same is applicable with SDP grouping, but is not explicit.
|Should there be matching m-lines in the new offer even with SDP grouping? Does SDP grouping change
|anything w.r.t to the above statements in RFC3264?
|
|thanks,
|Muthu

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Jul 2012 19:48:30 +0200

Hi,

>Thanks, Christer. It does make sense, but is not clear from RFC5888. What would be best way to fix it? File >an errata on RFC5888?

I am not sure anything needs to be fixed. Unless explicitly stated, 3264 applies.

Regards,

Christer