Subject: [MMUSIC] New draft: multiple times problem description: draft-garcia-mmusic-multiple-ptimes-problem-00.txt

From: Miguel Garcia <[email-masked]>
Date: Tue, 29 May 2007 13:41:06 +0300

Hi:

We have just submitted a new short draft that describes the problem with 
the lack of multiple packetization times in SDP.

The draft should be soon available in the traditional repositories. 
Until that time, you can fetch a copy from:

http://people.nokia.net/~miguel/drafts/draft-garcia-mmusic-multiple-ptimes-problem-00.txt
http://people.nokia.net/~miguel/drafts/draft-garcia-mmusic-multiple-ptimes-problem-00.html

We are aware that the issue has been discussed in the past, without a 
clear conclusion on whether a problem exists. We believe there is an 
interoperability problem, and thus, we are soliciting comments about it. 
At this stage, we are not discussing solutions yet, we rather agree 
first that there is a problem that needs to be solved.

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 May 2007 18:35:19 -0700

Would a solution that meets REQ-10 and REQ-20 from
draft-ietf-mmusic-sdp-capability-negotiation-reqts also resolve the ptime
problem?

   REQ-10: It MUST be possible to indicate and negotiate alternative 
   media formats on a per media stream basis. 

      For example, many implementations support multiple codecs, but 
      only one at a time.  Changes between codecs cannot be done on-
      the-fly, e.g. when receiving a simple RTP payload type change. 

   REQ-20: It MUST be possible to indicate and negotiate alternative 
   attribute values ("a=") on a per media stream basis.  

      For example, T.38 [T38] defines new attributes that may need to 
      be conveyed as part of a capability. Also, alternative SRTP 
      keying mechanisms (e.g. [SDES] and [KMGMT]) may use SDP 
      attributes to negotiate SRTP keying material. 

I noticed your document didn't reference
draft-ietf-mmusic-sdp-capability-negotiation-reqts, but I think there is an
overlap of a requirement you have and the solution proposed in
draft-ietf-mmusic-sdp-capability-negotiation-05.txt.

-d

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: Tuesday, May 29, 2007 3:41 AM
> To: mmusic
> Cc: Willekens, Marc
> Subject: [MMUSIC] New draft: multiple times problem 
> description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt
> 
> Hi:
>

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 30 May 2007 09:21:17 +0300

Hi Dan:

Thanks for the reaction. Some inline discussion.

>    media formats on a per media stream basis. 

No, this isn't the problem we are trying to tackle, because this 
requirement speaks about "alternative media formats" and speaks "on a 
per media stream basis".

However, our problem is not about alternative media formats, but about 
"specific parameters" and is not "on a per media stream basis" but "on a 
per media format (or codec) basis".

>       the-fly, e.g. when receiving a simple RTP payload type change. 

Right... but this seems to be a different problem than the one we 
describe in the draft.

>    attribute values ("a=") on a per media stream basis.  

Again, the "on a per media stream basis" does not fulfill the 
requirement of the draft. It should say "on a per media type basis".

> draft-ietf-mmusic-sdp-capability-negotiation-05.txt.

At this stage, the goal of the draft is just to highlight the problem 
and serve for deriving requirements, which we are doing in this thread. 
I am not sure how to reference your requirements...

As for the solution, the solution is space is quite broad, ranging from 
any of the proprietary solutions that have been specified elsewhere to 
the SDP capability negotiation, to SDP grouping of media, or perhaps 
others.

I would prefer that we don't derive the discussion to discuss a solution 
until we agree that there is a problem to be solved.

BR,

       Miguel

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 1 Jun 2007 05:11:33 +0200

Hi,

RFC3108 defines a "vsel" attribute (and also a "onewaySel" attribute),
which allows you to to specify Packet Length and Packet Time per code. 

Now, I know RFC3108 was written for ATM, but I don't think there is
anything ATM specific with these attributes (and, if there is, at least
we should look whether we can use the attributes as base for our work).

Regards,

Christer

> Sent: 29. toukokuuta 2007 13:41
> To: mmusic
> Cc: Willekens, Marc
> We have just submitted a new short draft that describes the 
> problem with the lack of multiple packetization times in SDP.
> 
> We are aware that the issue has been discussed in the past, 
> without a clear conclusion on whether a problem exists. We 
> believe there is an interoperability problem, and thus, we 
> are soliciting comments about it. 
> At this stage, we are not discussing solutions yet, we rather 
> agree first that there is a problem that needs to be solved.
> 
> /Miguel
> --