Subject: [MMUSIC] Usage of a=group:LS

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 19 Oct 2006 10:31:19 -0700

Dear MMUSIC experts,

As per RFC3388 "Grouping of Media Lines in SDP", it seems like LS
semantics can be used to signal that audio and video in a session must
not be synchronized. 

Following is an example.

       v=0
       o=Laura 289083124 289083124 IN IP4 one.example.com
       t=0 0
       c=IN IP4 129.92.64.56
       a=group:LS 1 
       a=group:LS 2
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=video 30002 RTP/AVP 31
       a=mid:2

"a=group:LS 1" indicates that audio is grouped with no other media.
"a=group:LS 2" indicates that video is grouped with no other media.

As a result of the above, one can say that the offerer of the above SDP
does not want to the receiver to synchronize audio and video streams.

RFC3388 does not seem to prevent the above mentioned interpretation.
Hence, I believe that such SDP offer should be treated as valid and
complaint with RFC3388.

I'd like know if I am incorrect in interpreting RFC3388 for the above
case? 

Thanks,
- - - - - - - - - - - - - - - - - -
Harikishan Desineni
Qualcomm Inc.,
mailto:[email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Joerg Ott <[email-masked]>
Date: Fri, 20 Oct 2006 12:31:45 +0300

> semantics can be used to signal that audio and video in a session must

I am curious how that would work.

> does not want to the receiver to synchronize audio and video streams.

This appears to be beyond borderline and is not specified anywhere.

> Hence, I believe that such SDP offer should be treated as valid and

If you take a closer look at many standards documents, I guess, you
will often find cases where more things can be expressed than are
well described and/or meaningful.  A general rule to achieve
interoperability is to stick to what _is_ described.

> I'd like know if I am incorrect in interpreting RFC3388 for the above

The definition of RFC 3388 is describing in a positive way what you
can achieve.  Everything else is undefined.  Also, the spec is phrased
in a way that allows for backwards compatibility if the extension is
not understood.  Your suggested interpretation would clearly not meet
this goal.

So, I would like to explicitly discourage any "grey area" interpretation
of the spec (which essentially equals second-guessing and will surely
be done by different people in different ways).

Regards,
Joerg