From mmusic-bounces@ietf.org Tue Mar 1 10:22:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05293 for ; Tue, 1 Mar 2005 10:22:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69Dk-0005sd-Ro for mmusic-web-archive@ietf.org; Tue, 01 Mar 2005 10:23:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69Ap-00068d-47; Tue, 01 Mar 2005 10:20:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69An-000673-7s for mmusic@megatron.ietf.org; Tue, 01 Mar 2005 10:20:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04928 for ; Tue, 1 Mar 2005 10:20:31 -0500 (EST) Received: from [220.117.193.39] (helo=lapis1.nextreaming.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69Bj-0005o4-OX for mmusic@ietf.org; Tue, 01 Mar 2005 10:21:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [MMUSIC] RTSP: RTP-Info syntax (2326bis09) Date: Wed, 2 Mar 2005 00:19:56 +0900 Message-ID: Thread-Topic: [MMUSIC] RTSP: RTP-Info syntax (2326bis09) thread-index: AcUeciAvaQclm/R8S2yMaOy+OazmXA== From: "Jae-Hwan Kim" To: X-Spam-Score: 0.3 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1869897077==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd This is a multi-part message in MIME format. --===============1869897077== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51E72.317755FA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C51E72.317755FA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear experts, =20 Recently, I found some weird RTP-Info strings in a commercial RTSP server. RTP-Info:url=3Drtsp://example.com/foo/audio RTP-Info: =20 According to 2326bis09 RTP-Info syntax(I am very happy with the new ABNF syntax,=20 which is much clear than before ;-> ), the above seem to be wrong and I am fine, anyway. But I could know the following cases are possible: =20 Case1) RTP-Info:url=3Drtsp://example.com/foo/audio;seq=3D45102 Case2) RTP-Info:url=3Drtsp://example.com/foo/audio;rtptime=3D12345678 =20 What does this mean? Are they meaningful? =20 Best Regards, Jae-Hwan ------------------------------------ Software Architect/Streaming Platform Nextreaming Corporation kjh1905m@nextreaming.com 5th Fl. Gangnam Metro Bldg., 1339-9,=20 Seocho-Dong, Seocho-Gu, Seoul 137-070, Korea tel: +82.2.2194.5361 mobile: +82.17.225.0619 ------------------------------------ =20 ------_=_NextPart_001_01C51E72.317755FA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = experts,

Recently, I found some = weird RTP-Info strings in a commercial RTSP = server.

RTP-Info:url=3Drtsp://exampl= e.com/foo/audio

RTP-Info:<= /font>

According to 2326bis09 = RTP-Info syntax(I am very happy with the new ABNF syntax, =

which is much clear than = before ;-> ), the above seem to be wrong and I am fine, = anyway.

But I could know the = following cases are possible:

Case1) RTP-Info:url=3Drtsp://example.com/foo/audio;s= eq=3D45102

Case2) RTP-Info:url=3Drtsp://example.com/foo/audio;r= tptime=3D12345678

What does this mean? Are = they meaningful?

Best = Regards,

Jae-Hwan

------------------------------------

Software Architect/Streaming = Platform

Nextreaming = Corporation

kjh1905m@nextreaming.com

5th Fl. Gangnam Metro Bldg., 1339-9,

Seocho-Dong, Seocho-Gu, Seoul 137-070, = Korea

tel: = +82.2.2194.5361

mobile: = +82.17.225.0619

------------------------------------

------_=_NextPart_001_01C51E72.317755FA-- --===============1869897077== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1869897077==-- From mmusic-bounces@ietf.org Tue Mar 1 10:59:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09133 for ; Tue, 1 Mar 2005 10:59:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69n3-0006nK-Ub for mmusic-web-archive@ietf.org; Tue, 01 Mar 2005 11:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69kW-000698-HU; Tue, 01 Mar 2005 10:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69kV-00068q-7v for mmusic@megatron.ietf.org; Tue, 01 Mar 2005 10:57:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09003 for ; Tue, 1 Mar 2005 10:57:25 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69lS-0006k4-Q1 for mmusic@ietf.org; Tue, 01 Mar 2005 10:58:28 -0500 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j21FvNO6027629; Tue, 1 Mar 2005 16:57:23 +0100 Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 16:58:10 +0100 Received: from [147.214.237.66] ([147.214.237.66]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 16:58:10 +0100 Message-ID: <422490E2.6060006@ericsson.com> Date: Tue, 01 Mar 2005 16:57:22 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jae-Hwan Kim Subject: Re: [MMUSIC] RTSP: RTP-Info syntax (2326bis09) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2005 15:58:10.0410 (UTC) FILETIME=[777624A0:01C51E77] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hi, I think you have stumbled on an issue in the ABNF syntax. The current syntax: RTP-Info = "RTP-Info" HCOLON rtsp-info-spec *(COMMA rtsp-info-spec) CRLF rtsp-info-spec = stream-url 1*ri-parameter Requires that in addition to the URI, that also at least one parameter is present. However the new RTP-Info text does not require either of the parameters to be present. However due to this there is the question what to do: A) Do not provide any RTP-Info for that media stream that one do not have at least one parameter to provide. B) Allow that only the URL is present but no parameters with sync information. Any opinions on which to use? Jae-Hwan Kim wrote: > > Recently, I found some weird RTP-Info strings in a commercial RTSP > server. > > RTP-Info:url=rtsp://example.com/foo/audio This is against the current syntax. It is also the most likely against the old erroneous syntax. > > RTP-Info: > This is definitely not allowed in either the new or old syntax. In this case the header shall not be present at all. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Mar 1 13:07:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23336 for ; Tue, 1 Mar 2005 13:07:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Bnj-0001ll-8K for mmusic-web-archive@ietf.org; Tue, 01 Mar 2005 13:08:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6BmI-0001b1-RV; Tue, 01 Mar 2005 13:07:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6BmH-0001aw-Im for mmusic@megatron.ietf.org; Tue, 01 Mar 2005 13:07:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23320 for ; Tue, 1 Mar 2005 13:07:22 -0500 (EST) Received: from scarface.real.com ([207.188.7.230]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6BnG-0001lG-8r for mmusic@ietf.org; Tue, 01 Mar 2005 13:08:27 -0500 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,128bits,RC4-SHA) by scarface.real.com with esmtp; Tue, 01 Mar 2005 10:06:39 -0800 id 00238B92.4224AF4C.0000492A Received: from aaron by raven.dev.prognet.com with local (Exim 4.34) id 1D6BjJ-0005dv-3h for mmusic@ietf.org; Tue, 01 Mar 2005 10:04:21 -0800 Date: Tue, 1 Mar 2005 10:04:21 -0800 From: Aaron Colwell To: mmusic@ietf.org Message-ID: <20050301180421.GA21638@real.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [MMUSIC] SDP for alternative encodings X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit I have a few questions about how to represent alternative encodings with SDP. How do the following 2 SDPs differ in meaning? m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 m=audio 49230 RTP/AVP 96 a=rtpmap:96 L8/8000 m=audio 49230 RTP/AVP 97 a=rtpmap:97 L16/8000 m=audio 49230 RTP/AVP 98 a=rtpmap:98 L16/11025/2 If I understand the SDP spec it seems to me that this indicates that payload types 96, 97, and 98 will all be transmitted to port 49230 and represent the same stream. What am I missing? The SDP Internet Draft seems to indicate that alternate streams are signalled by m= lines using the same port. The RTSP spec says that if the server doesn't care about what ports are used then it should just specify 0. The SDP draft also mandates that m= lines with the same port have "compatible media (e.g. both audio or both video)". This seems to imply that the server has to specify ports if it wants to serve an A/V stream. Is that the intention or is 0 a special case? If 0 is a special case then how are you supposed to specify alternate streams when the server doesn't care about the ports used? Aaron _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Mar 1 16:25:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12205 for ; Tue, 1 Mar 2005 16:25:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Ese-0006Mq-6T for mmusic-web-archive@ietf.org; Tue, 01 Mar 2005 16:26:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6EpB-00044j-6n; Tue, 01 Mar 2005 16:22:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Ep9-00044b-GM; Tue, 01 Mar 2005 16:22:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12077; Tue, 1 Mar 2005 16:22:32 -0500 (EST) From: Wayne.Davies@didata.com.au Received: from nwynmime2.didata.com.au ([148.182.20.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Eq8-0006Jv-FN; Tue, 01 Mar 2005 16:23:37 -0500 Received: from internet.didata.com.au (unverified [148.182.20.65]) by NWYNMIME2.didata.com.au (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Wed, 2 Mar 2005 08:22:18 +1100 To: Aaron Colwell Subject: Re: [MMUSIC] SDP for alternative encodings MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: Date: Wed, 2 Mar 2005 08:22:16 +1100 X-MIMETrack: Serialize by Router on SYDMTA/Sydney/Com Tech/AU (Release 5.0.11 |July 24, 2002) at 02/03/2005 08:20:37 AM, Serialize complete at 02/03/2005 08:20:37 AM X-Spam-Score: 0.5 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: mmusic@ietf.org, mmusic-bounces@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1604168988==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb This is a multipart message in MIME format. --===============1604168988== Content-Type: multipart/alternative; boundary="=_alternative 007564F4CA256FB7_=" This is a multipart message in MIME format. --=_alternative 007564F4CA256FB7_= Content-Type: text/plain; charset="us-ascii" Aaron, My understanding is that if these were SDP for a request then - your first example is saying I would like an audio media session and I support any one(1)of the following three codecs for it. Your second example is requesting three(3) audio media sessions, each using the codec grouped with the m= line. Regards - Wayne D. Aaron asked: ********************************************************* I have a few questions about how to represent alternative encodings with SDP. How do the following 2 SDPs differ in meaning? m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 m=audio 49230 RTP/AVP 96 a=rtpmap:96 L8/8000 m=audio 49230 RTP/AVP 97 a=rtpmap:97 L16/8000 m=audio 49230 RTP/AVP 98 a=rtpmap:98 L16/11025/2 If I understand the SDP spec it seems to me that this indicates that payload types 96, 97, and 98 will all be transmitted to port 49230 and represent the same stream. What am I missing? The SDP Internet Draft seems to indicate that alternate streams are signalled by m= lines using the same port. The RTSP spec says that if the server doesn't care about what ports are used then it should just specify 0. The SDP draft also mandates that m= lines with the same port have "compatible media (e.g. both audio or both video)". This seems to imply that the server has to specify ports if it wants to serve an A/V stream. Is that the intention or is 0 a special case? If 0 is a special case then how are you supposed to specify alternate streams when the server doesn't care about the ports used? Aaron _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ****************************************************************************** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. ****************************************************************************** --=_alternative 007564F4CA256FB7_= Content-Type: text/html; charset="us-ascii"
Aaron,
My understanding is that if these were SDP for a request then - your first example is saying I would like an audio media session and I support any one(1)of the following three codecs for it. Your second example is requesting three(3) audio media sessions, each using the codec grouped with the m= line.

Regards - Wayne D.

Aaron asked:
*********************************************************

I have a few questions about how to represent alternative encodings with SDP.

How do the following 2 SDPs differ in meaning?

m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2

m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000
m=audio 49230 RTP/AVP 97
a=rtpmap:97 L16/8000
m=audio 49230 RTP/AVP 98
a=rtpmap:98 L16/11025/2

If I understand the SDP spec it seems to me that this indicates that payload
types 96, 97, and 98 will all be transmitted to port 49230 and represent the
same stream. What am I missing?

The SDP Internet Draft seems to indicate that alternate streams are signalled
by m= lines using the same port. The RTSP spec says that if the server doesn't
care about what ports are used then it should just specify 0. The SDP draft
also mandates that m= lines with the same port have "compatible media (e.g.
both audio or both video)". This seems to imply that the server has to specify
ports if it wants to serve an A/V stream. Is that the intention or is 0 a
special case? If 0 is a special case then how are you supposed to specify
alternate streams when the server doesn't care about the ports used?

Aaron

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

******************************************************************************
- NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately.

Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.
******************************************************************************
--=_alternative 007564F4CA256FB7_=-- --===============1604168988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1604168988==-- From mmusic-bounces@ietf.org Tue Mar 1 16:34:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13091 for ; Tue, 1 Mar 2005 16:34:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6F1e-0006a3-6f for mmusic-web-archive@ietf.org; Tue, 01 Mar 2005 16:35:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6EzO-0005bS-QZ; Tue, 01 Mar 2005 16:33:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6EzM-0005bA-N8; Tue, 01 Mar 2005 16:33:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12883; Tue, 1 Mar 2005 16:33:06 -0500 (EST) From: Wayne.Davies@didata.com.au Received: from nwynmime2.didata.com.au ([148.182.20.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6F0N-0006X5-Ce; Tue, 01 Mar 2005 16:34:12 -0500 Received: from internet.didata.com.au (unverified [148.182.20.65]) by NWYNMIME2.didata.com.au (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Wed, 2 Mar 2005 08:32:56 +1100 To: Wayne.Davies@didata.com.au Subject: Re: [MMUSIC] SDP for alternative encodings MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: Date: Wed, 2 Mar 2005 08:32:54 +1100 X-MIMETrack: Serialize by Router on SYDMTA/Sydney/Com Tech/AU(Release 5.0.11 |July 24, 2002) at 02/03/2005 08:31:16 AM, Serialize complete at 02/03/2005 08:31:16 AM X-Spam-Score: 0.5 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: Aaron Colwell , mmusic@ietf.org, mmusic-bounces@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0881184416==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 This is a multipart message in MIME format. --===============0881184416== Content-Type: multipart/alternative; boundary="=_alternative 00765E60CA256FB7_=" This is a multipart message in MIME format. --=_alternative 00765E60CA256FB7_= Content-Type: text/plain; charset="us-ascii" Aaron, A colleague also pointed out in the second example (if my explanation is correct) and more than one session is accepted then there will be an issue as each of the audio sessions is specifying the same rtp port. Regards - Wayne D. ******************************************************** Aaron, My understanding is that if these were SDP for a request then - your first example is saying I would like an audio media session and I support any one(1)of the following three codecs for it. Your second example is requesting three(3) audio media sessions, each using the codec grouped with the m= line. Regards - Wayne D. Aaron asked: ********************************************************* I have a few questions about how to represent alternative encodings with SDP. How do the following 2 SDPs differ in meaning? m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 m=audio 49230 RTP/AVP 96 a=rtpmap:96 L8/8000 m=audio 49230 RTP/AVP 97 a=rtpmap:97 L16/8000 m=audio 49230 RTP/AVP 98 a=rtpmap:98 L16/11025/2 If I understand the SDP spec it seems to me that this indicates that payload types 96, 97, and 98 will all be transmitted to port 49230 and represent the same stream. What am I missing? The SDP Internet Draft seems to indicate that alternate streams are signalled by m= lines using the same port. The RTSP spec says that if the server doesn't care about what ports are used then it should just specify 0. The SDP draft also mandates that m= lines with the same port have "compatible media (e.g. both audio or both video)". This seems to imply that the server has to specify ports if it wants to serve an A/V stream. Is that the intention or is 0 a special case? If 0 is a special case then how are you supposed to specify alternate streams when the server doesn't care about the ports used? Aaron _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ****************************************************************************** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. ******************************************************************************_______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --=_alternative 00765E60CA256FB7_= Content-Type: text/html; charset="us-ascii"
Aaron,
A colleague also pointed out in the second example (if my explanation is correct) and more than one session is accepted then there will be an issue as each of the audio sessions is specifying the same rtp port.

Regards - Wayne D.
********************************************************
Aaron,
My understanding is that if these were SDP for a request then - your first example is saying I would like an audio media session and I support any one(1)of the following three codecs for it. Your second example is requesting three(3) audio media sessions, each using the codec grouped with the m= line.

Regards - Wayne D.

Aaron asked:
*********************************************************

I have a few questions about how to represent alternative encodings with SDP.

How do the following 2 SDPs differ in meaning?

m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2

m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000
m=audio 49230 RTP/AVP 97
a=rtpmap:97 L16/8000
m=audio 49230 RTP/AVP 98
a=rtpmap:98 L16/11025/2

If I understand the SDP spec it seems to me that this indicates that payload
types 96, 97, and 98 will all be transmitted to port 49230 and represent the
same stream. What am I missing?

The SDP Internet Draft seems to indicate that alternate streams are signalled
by m= lines using the same port. The RTSP spec says that if the server doesn't
care about what ports are used then it should just specify 0. The SDP draft
also mandates that m= lines with the same port have "compatible media (e.g.
both audio or both video)". This seems to imply that the server has to specify
ports if it wants to serve an A/V stream. Is that the intention or is 0 a
special case? If 0 is a special case then how are you supposed to specify
alternate streams when the server doesn't care about the ports used?

Aaron

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

******************************************************************************
- NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately.

Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.
******************************************************************************_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
--=_alternative 00765E60CA256FB7_=-- --===============0881184416== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0881184416==-- From mmusic-bounces@ietf.org Tue Mar 1 17:25:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17013 for ; Tue, 1 Mar 2005 17:25:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Fp3-0007Vh-Ic for mmusic-web-archive@ietf.org; Tue, 01 Mar 2005 17:26:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FnH-0007BS-QW; Tue, 01 Mar 2005 17:24:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FnF-0007BH-Tw; Tue, 01 Mar 2005 17:24:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16896; Tue, 1 Mar 2005 17:24:40 -0500 (EST) Received: from scarface.real.com ([207.188.7.230]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6FoG-0007V3-DB; Tue, 01 Mar 2005 17:25:46 -0500 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,128bits,RC4-SHA) by scarface.real.com with esmtp; Tue, 01 Mar 2005 14:23:57 -0800 id 00238C0D.4224EB9B.0000413E Received: from aaron by raven.dev.prognet.com with local (Exim 4.34) id 1D6FkK-0005rR-VN; Tue, 01 Mar 2005 14:21:40 -0800 Date: Tue, 1 Mar 2005 14:21:40 -0800 From: Aaron Colwell To: Wayne.Davies@didata.com.au Subject: Re: [MMUSIC] SDP for alternative encodings Message-ID: <20050301222140.GB22098@real.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Spam-Score: 0.2 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, mmusic-bounces@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit I'm not actually talking about using this sort of SDP for a request. I was thinking of it more as something that might come in an RTSP DESCRIBE response or perhaps used to describe an encoding session. I intentionally made the port numbers the same because it seems to be what the SDP Internet draft says to do for alternate streams. What I want to do is specify 3 streams that are the same content, but different encodings. I also want to be able to request all or a subset of them. In essence I have one logical stream, but 3 representations of that stream. I'm just trying to figure out the proper way to express this in SDP. I could potentially have audio and video in the same SDP so I'm just looking for the proper way to group m= lines. I looked at RFC 3388 and it doesn't quite seem to apply to what I'm talking about here. Aaron On Wed, Mar 02, 2005 at 08:32:54AM +1100, Wayne.Davies@didata.com.au wrote: > Aaron, > A colleague also pointed out in the second example (if my > explanation is correct) and more than one session is accepted then there > will be an issue as each of the audio sessions is specifying the same rtp > port. > > Regards - Wayne D. > ******************************************************** > Aaron, > My understanding is that if these were SDP for a request then - > your first example is saying I would like an audio media session and I > support any one(1)of the following three codecs for it. Your second > example is requesting three(3) audio media sessions, each using the codec > grouped with the m= line. > Regards - Wayne D. > > Aaron asked: > ********************************************************* > > I have a few questions about how to represent alternative encodings with > SDP. > > How do the following 2 SDPs differ in meaning? > > m=audio 49230 RTP/AVP 96 97 98 > a=rtpmap:96 L8/8000 > a=rtpmap:97 L16/8000 > a=rtpmap:98 L16/11025/2 > > m=audio 49230 RTP/AVP 96 > a=rtpmap:96 L8/8000 > m=audio 49230 RTP/AVP 97 > a=rtpmap:97 L16/8000 > m=audio 49230 RTP/AVP 98 > a=rtpmap:98 L16/11025/2 > > If I understand the SDP spec it seems to me that this indicates that > payload > types 96, 97, and 98 will all be transmitted to port 49230 and represent > the > same stream. What am I missing? > > The SDP Internet Draft seems to indicate that alternate streams are > signalled > by m= lines using the same port. The RTSP spec says that if the server > doesn't > care about what ports are used then it should just specify 0. The SDP > draft > also mandates that m= lines with the same port have "compatible media > (e.g. > both audio or both video)". This seems to imply that the server has to > specify > ports if it wants to serve an A/V stream. Is that the intention or is 0 a > special case? If 0 is a special case then how are you supposed to specify > alternate streams when the server doesn't care about the ports used? > > Aaron > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > ****************************************************************************** > - NOTICE FROM DIMENSION DATA AUSTRALIA > This message is confidential, and may contain proprietary or legally > privileged information. If you have received this email in error, please > notify the sender and delete it immediately. > Internet communications are not secure. You should scan this message and > any attachments for viruses. Under no circumstances do we accept liability > for any loss or damage which may result from your receipt of this message > or any attachments. > ******************************************************************************_______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Mar 2 09:36:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16175 for ; Wed, 2 Mar 2005 09:36:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Uyx-0001tw-0V for mmusic-web-archive@ietf.org; Wed, 02 Mar 2005 09:37:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Uvl-0000PD-Iw; Wed, 02 Mar 2005 09:34:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Uvj-0000On-7I for mmusic@megatron.ietf.org; Wed, 02 Mar 2005 09:34:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15913 for ; Wed, 2 Mar 2005 09:34:25 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Uws-0001qK-Dt for mmusic@ietf.org; Wed, 02 Mar 2005 09:35:40 -0500 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j22EYFfq009428; Wed, 2 Mar 2005 15:34:16 +0100 (MET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 15:35:02 +0100 Received: from [147.214.237.66] ([147.214.237.66]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 15:34:57 +0100 Message-ID: <4225CEDF.40005@ericsson.com> Date: Wed, 02 Mar 2005 15:34:07 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Colwell Subject: Re: [MMUSIC] SDP for alternative encodings References: <20050301222140.GB22098@real.com> In-Reply-To: <20050301222140.GB22098@real.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2005 14:34:57.0868 (UTC) FILETIME=[021670C0:01C51F35] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Hi Aaron, If you have three different way of encoding/packetizing the media, and any of the encoding mays be used within a RTP session, then m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 is the correct representation. The SDP tells the receiver that all three codecs may occur within the RTP session. I would also like to point out that even a SDP declaration like the following: m=audio 49230 RTP/AVP 96 a=rtpmap:96 L8/8000 Does not exclude the occurance of multiple streams from different sources (SSRCs) within the same RTP session. Therefore please be careful with usage of language. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Mar 2 11:01:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26023 for ; Wed, 2 Mar 2005 11:01:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6WJA-0003s4-Fs for mmusic-web-archive@ietf.org; Wed, 02 Mar 2005 11:02:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6WDc-00068E-Q9; Wed, 02 Mar 2005 10:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6WDb-000689-TZ for mmusic@megatron.ietf.org; Wed, 02 Mar 2005 10:56:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25468 for ; Wed, 2 Mar 2005 10:56:57 -0500 (EST) Received: from nms.above.net.tw ([202.5.224.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6WEm-0003mB-5Y for mmusic@ietf.org; Wed, 02 Mar 2005 10:58:13 -0500 Received: from mail.above.net.tw (localhost [127.0.0.1]) by nms.above.net.tw (Postfix) with ESMTP id B30F3210F2 for ; Wed, 2 Mar 2005 23:56:55 +0800 (CST) From: "kkuei" To: mmusic@ietf.org Date: Wed, 2 Mar 2005 23:56:55 +0800 Message-Id: <20050302155554.M20339@above.net.tw> X-Mailer: Open WebMail 2.41 20040926 X-OriginatingIP: 24.7.112.25 (kkuei) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [MMUSIC] RFC3264: answer indicate a diff PT number X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hello all, I'm a little bit confusing in rfc3264 (offer/answer model with SDP) when answer indicate a diff payload type number case. Is there anybody can help me?? in 5.1, it says: For sendrecv RTP streams, the payload type numbers indicate the value of the payload type field the offerer expects to receive, and would prefer to send. However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. in 6.1, it says: In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer. Even if the same payload type number is used, the answer MUST contain rtpmap attributes to define the payload type mappings for dynamic payload types, and SHOULD contain mappings for static payload types. The media formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the offerer SHOULD use the format with the highest preference from the answer. My question is, the payload type number in answer may be different than in offer. Here is the case: 1. Offer PCM-WB: 98 ISAC: 101 iLBC: 102 2. Answer iLBC: 98 This means both parties agreed to use iLBC. My questionis , what payload type number should be use in constructing RTP pkts. In sec5.1, (in my understanding) it says offerer MUST respect the answer. It MUST put "98" in payload type number in RTP. But what about in the answerer?? should it respect the offer? which payload type number (102 or 98) it should put in RTP?? -- Kevin Kuei _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Mar 2 11:49:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01023 for ; Wed, 2 Mar 2005 11:49:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6X3g-00050o-Ad for mmusic-web-archive@ietf.org; Wed, 02 Mar 2005 11:50:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Wz7-0006Ln-88; Wed, 02 Mar 2005 11:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Wz3-0006LT-Qk for mmusic@megatron.ietf.org; Wed, 02 Mar 2005 11:46:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00656 for ; Wed, 2 Mar 2005 11:45:57 -0500 (EST) Received: from serpico.real.com ([207.188.23.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6X0C-0004u2-Pb for mmusic@ietf.org; Wed, 02 Mar 2005 11:47:14 -0500 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,128bits,RC4-SHA) by serpico.real.com with esmtp; Wed, 02 Mar 2005 08:45:13 -0800 id 00023E6B.4225EDB7.0000521D Received: from aaron by raven.dev.prognet.com with local (Exim 4.34) id 1D6Ww3-0006NX-6W; Wed, 02 Mar 2005 08:42:55 -0800 Date: Wed, 2 Mar 2005 08:42:55 -0800 From: Aaron Colwell To: Magnus Westerlund Subject: Re: [MMUSIC] SDP for alternative encodings Message-ID: <20050302164255.GA24449@real.com> References: <20050301222140.GB22098@real.com> <4225CEDF.40005@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <4225CEDF.40005@ericsson.com> User-Agent: Mutt/1.5.6+20040722i X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit On Wed, Mar 02, 2005 at 03:34:07PM +0100, Magnus Westerlund wrote: > Hi Aaron, > > If you have three different way of encoding/packetizing the media, and > any of the encoding mays be used within a RTP session, then > > m=audio 49230 RTP/AVP 96 97 98 > a=rtpmap:96 L8/8000 > a=rtpmap:97 L16/8000 > a=rtpmap:98 L16/11025/2 > > is the correct representation. The SDP tells the receiver that all three > codecs may occur within the RTP session. Does their usage have to be mutually exclusive or can they all be used at the same time? > > I would also like to point out that even a SDP declaration like the > following: > > m=audio 49230 RTP/AVP 96 > a=rtpmap:96 L8/8000 > > Does not exclude the occurance of multiple streams from different > sources (SSRCs) within the same RTP session. Therefore please be careful > with usage of language. So does this basically mean that there isn't a lot of difference between the 2 forms that I outlined? Are you saying that they basically mean the same thing? It seems at a minimum the multiple m= line version allows a client to select which encodings it wants to receive since there is only one a=control line for each m= section. I feel like I'm still confused on this. Do m= lines with the same port indicate alternates of the same stream or SSRC multiplexed streams? Aaron > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Mar 2 12:20:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06037 for ; Wed, 2 Mar 2005 12:20:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6XXH-0005yb-5e for mmusic-web-archive@ietf.org; Wed, 02 Mar 2005 12:21:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6XTa-00043T-Dw; Wed, 02 Mar 2005 12:17:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6XTK-0003y9-1D for mmusic@megatron.ietf.org; Wed, 02 Mar 2005 12:17:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05320 for ; Wed, 2 Mar 2005 12:17:15 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6XUV-0005nv-E8 for mmusic@ietf.org; Wed, 02 Mar 2005 12:18:32 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2005 10:33:00 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,130,1107734400"; d="scan'208"; a="230761300:sNHT20642880" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j22HGuuE026265; Wed, 2 Mar 2005 09:17:02 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-154.cisco.com [10.86.240.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APM81988; Wed, 2 Mar 2005 12:16:57 -0500 (EST) Message-ID: <4225F508.30203@cisco.com> Date: Wed, 02 Mar 2005 12:16:56 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kkuei Subject: Re: [MMUSIC] RFC3264: answer indicate a diff PT number References: <20050302155554.M20339@above.net.tw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit This was just discussed on the sip-implementors list. The answer to your question at the end is "102". Paul kkuei wrote: > Hello all, > > I'm a little bit confusing in rfc3264 (offer/answer model with SDP) when > answer indicate a diff payload type number case. Is there anybody can help > me?? > > > in 5.1, it says: > For sendrecv RTP > streams, the payload type numbers indicate the value of the payload > type field the offerer expects to receive, and would prefer to send. > However, for sendonly and sendrecv streams, the answer might indicate > different payload type numbers for the same codecs, in which case, > the offerer MUST send with the payload type numbers from the answer. > > in 6.1, it says: > In the case of RTP, if a particular codec was referenced with a > specific payload type number in the offer, that same payload type > number SHOULD be used for that codec in the answer. Even if the same > payload type number is used, the answer MUST contain rtpmap > attributes to define the payload type mappings for dynamic payload > types, and SHOULD contain mappings for static payload types. The > media formats in the "m=" line MUST be listed in order of preference, > with the first format listed being preferred. In this case, > preferred means that the offerer SHOULD use the format with the > highest preference from the answer. > > My question is, the payload type number in answer may be different than in > offer. Here is the case: > > 1. Offer > PCM-WB: 98 > ISAC: 101 > iLBC: 102 > > 2. Answer > iLBC: 98 > > This means both parties agreed to use iLBC. > My questionis , what payload type number should be use in constructing RTP > pkts. > > In sec5.1, (in my understanding) it says offerer MUST respect the answer. It > MUST put "98" in > payload type number in RTP. > > But what about in the answerer?? should it respect the offer? which payload > type > number (102 or 98) it should put in RTP?? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Mar 2 14:37:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17600 for ; Wed, 2 Mar 2005 14:37:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ZgL-0000Xl-T1 for mmusic-web-archive@ietf.org; Wed, 02 Mar 2005 14:38:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Zer-0002vK-1r; Wed, 02 Mar 2005 14:37:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Zeo-0002up-8L for mmusic@megatron.ietf.org; Wed, 02 Mar 2005 14:37:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17573 for ; Wed, 2 Mar 2005 14:37:16 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Zg0-0000XR-So for mmusic@ietf.org; Wed, 02 Mar 2005 14:38:34 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2005 14:37:08 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [10.82.240.170] (rtp-vpn2-170.cisco.com [10.82.240.170]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j22Jb41j001611; Wed, 2 Mar 2005 14:37:05 -0500 (EST) Message-ID: <422615E0.6060106@cisco.com> Date: Wed, 02 Mar 2005 14:37:04 -0500 From: Flemming Andreasen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joerg Ott Subject: Re: [MMUSIC] MMUSIC at 62nd IETF References: <421DE298.3090506@tzi.uni-bremen.de> In-Reply-To: <421DE298.3090506@tzi.uni-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , David R Oran , mmusic@ietf.org, Dan Wing , Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Hi Joerg and Colin We have updated the connectivity preconditions and security preconditions drafts as follows. Security preconditions changes: - Addressed the points required by the RFC 3312 update (per Gonzalo's comment). - Added example using "kmgmt" extensions in Section 4.2. - Trimmed author list - A few minor nits Connectivity preconditions changes: - Addressed the points required by the RFC 3312 update (per Gonzalo's comment) - Renamed attribute from "con" to "cntv" (to make accidental misuse between this one and the connection attribute "conn" less likely ) - Updated and simplified definitions of "send" and "receive" direction attributes. - Added considerations for handling multiple addresses per media stream. - Noted that current base line recommendation of supporting RTP no-op is only useful for RTP-based media streams. - Added considerations for how to determine connectivity when using RTP no-op, ICE, and TCP At this point, I don't think there is anything in the security preconditiosn draft that warrants discussion, but it would be probably be worthwhile going through the updates to the connectivity preconditions draft. -- Flemming Joerg Ott wrote: > Folks, > > MMUSIC is scheduled to meet once at the next IETF: > > ---------------------------------------------------------- > THURSDAY, March 10, 2005 > 1530-1630 Afternoon Sessions II > TSV mmusic Multiparty Multimedia Session Control WG > > 1645-1745 Afternoon Sessions III > TSV mmusic Multiparty Multimedia Session Control WG > ---------------------------------------------------------- > > We have already collected several agenda requests. > > If you have an active Internet Draft in the scope of the > MMUSIC charter with issues warranting face-to-face discussion, > please drop an email to Colin and myself so that we can > finalize the agenda soon. > > In your request, please note the I-D you are referring to > and list the most important aspects to be discussed during > the meeting. > > And, of course, remember the "Note well" statement. > > Thanks, > Joerg > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Mar 3 04:17:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25954 for ; Thu, 3 Mar 2005 04:17:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6mTw-0002bf-13 for mmusic-web-archive@ietf.org; Thu, 03 Mar 2005 04:18:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6mS9-0001MS-SZ; Thu, 03 Mar 2005 04:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6mS6-0001LI-LU for mmusic@megatron.ietf.org; Thu, 03 Mar 2005 04:17:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25759 for ; Thu, 3 Mar 2005 04:17:00 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6mTR-0002aT-28 for mmusic@ietf.org; Thu, 03 Mar 2005 04:18:25 -0500 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j239GUgG016344; Thu, 3 Mar 2005 10:16:44 +0100 (MET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 10:17:30 +0100 Received: from [147.214.237.66] ([147.214.237.66]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 10:17:29 +0100 Message-ID: <4226D5F8.40009@ericsson.com> Date: Thu, 03 Mar 2005 10:16:40 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Colwell Subject: Re: [MMUSIC] SDP for alternative encodings References: <20050301222140.GB22098@real.com> <4225CEDF.40005@ericsson.com> <20050302164255.GA24449@real.com> In-Reply-To: <20050302164255.GA24449@real.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2005 09:17:29.0957 (UTC) FILETIME=[D30FA150:01C51FD1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Aaron Colwell wrote: > On Wed, Mar 02, 2005 at 03:34:07PM +0100, Magnus Westerlund wrote: > >>Hi Aaron, >> >>If you have three different way of encoding/packetizing the media, and >>any of the encoding mays be used within a RTP session, then >> >>m=audio 49230 RTP/AVP 96 97 98 >>a=rtpmap:96 L8/8000 >>a=rtpmap:97 L16/8000 >>a=rtpmap:98 L16/11025/2 >> >>is the correct representation. The SDP tells the receiver that all three >>codecs may occur within the RTP session. > > > Does their usage have to be mutually exclusive or can they all be used at the > same time? > They can all occur at the same time. > >>I would also like to point out that even a SDP declaration like the >>following: >> >>m=audio 49230 RTP/AVP 96 >>a=rtpmap:96 L8/8000 >> >>Does not exclude the occurance of multiple streams from different >>sources (SSRCs) within the same RTP session. Therefore please be careful >>with usage of language. > > > So does this basically mean that there isn't a lot of difference between the > 2 forms that I outlined? Are you saying that they basically mean the same > thing? It seems at a minimum the multiple m= line version allows a client to > select which encodings it wants to receive since there is only one a=control > line for each m= section. There is a big difference. One "m=" lines means that there is one session with three different encodings that may occur in it. Multiple "m=" lines means that there are three RTP sessions. It does not naturally have a meaning of being alternative. There has been a lot of discussion on if there is even allowed to have multiple "m=" lines with the same port without any grouping mechanism. To my recollection the debate ended saying, not allowed, and you must use a grouping mechanism to express what type of session grouping that do occur. As multiple "m=" lines has the original interpretation of being different media streams and that you need to receive all, the interpretation I would do if this was an RTSP controlled session, would be that all media streams needs to be set up. There exist no mechanism in SDP that allows you to express alternatives in regards to bit-rate. The basic case is that one expresses what may occur in a media stream. The bit-rate values is upper limit, it may go below that. Thus if one needs different payload types to be able to support the desired range of modification, they are all need to be expressed in the SDP on the same "m=" line. If you look at 3GPP TS 26.234, section 5.3.3.3 and 5.3.3.4 you find the alternative mechanism. That is intended to give an RTSP client the possibility to provide multiple "a=control" lines to allow setup time selection of bandwidth. > > I feel like I'm still confused on this. > > Do m= lines with the same port indicate alternates of the same stream or SSRC > multiplexed streams? No, neither of these interpretations are correct. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Mar 3 08:17:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21566 for ; Thu, 3 Mar 2005 08:17:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qEM-000073-8X for mmusic-web-archive@ietf.org; Thu, 03 Mar 2005 08:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qB4-0001gF-Hf; Thu, 03 Mar 2005 08:15:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6WKg-0006s7-Ln for mmusic@megatron.ietf.org; Wed, 02 Mar 2005 11:04:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26533 for ; Wed, 2 Mar 2005 11:04:15 -0500 (EST) Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6WLn-0003vb-DZ for mmusic@ietf.org; Wed, 02 Mar 2005 11:05:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RFC3264: answer indicate a diff PT number Date: Wed, 2 Mar 2005 16:03:49 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A054E12E@veg-brk-svr-pri.vegastream> Thread-Topic: [MMUSIC] RFC3264: answer indicate a diff PT number Thread-Index: AcUfQNBZyfGpP9M+TbO4aqGvvzdtkQAAWZsg From: "Attila Sipos" To: "kkuei" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 03 Mar 2005 08:15:41 -0500 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Hi Kevin, Fortunately, this has just been discussed in the SIP-implementors list. Go to: http://lists.cs.columbia.edu/pipermail/sip-implementors/2005-March/thread= .html And look at the e-mails with the title "Negotiation of dynamic payloads using SDP". Regards, Attila Attila Sipos http://www.vegastream.com > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org]On Behalf Of kkuei > Sent: 02 March 2005 15:57 > To: mmusic@ietf.org > Subject: [MMUSIC] RFC3264: answer indicate a diff PT number >=20 >=20 > Hello all, >=20 > I'm a little bit confusing in rfc3264 (offer/answer model=20 > with SDP) when=20 > answer indicate a diff payload type number case. Is there=20 > anybody can help=20 > me??=20 >=20 >=20 > in 5.1, it says:=20 > For sendrecv RTP=20 > streams, the payload type numbers indicate the value of the payload=20 > type field the offerer expects to receive, and would prefer=20 > to send.=20 > However, for sendonly and sendrecv streams, the answer=20 > might indicate=20 > different payload type numbers for the same codecs, in which case,=20 > the offerer MUST send with the payload type numbers from=20 > the answer.=20 >=20 > in 6.1, it says:=20 > In the case of RTP, if a particular codec was referenced with a=20 > specific payload type number in the offer, that same payload type=20 > number SHOULD be used for that codec in the answer. Even=20 > if the same=20 > payload type number is used, the answer MUST contain rtpmap=20 > attributes to define the payload type mappings for dynamic payload=20 > types, and SHOULD contain mappings for static payload types. The=20 > media formats in the "m=3D" line MUST be listed in order of=20 > preference,=20 > with the first format listed being preferred. In this case,=20 > preferred means that the offerer SHOULD use the format with the=20 > highest preference from the answer.=20 >=20 > My question is, the payload type number in answer may be=20 > different than in=20 > offer. Here is the case:=20 >=20 > 1. Offer=20 > PCM-WB: 98=20 > ISAC: 101=20 > iLBC: 102=20 >=20 > 2. Answer=20 > iLBC: 98=20 >=20 > This means both parties agreed to use iLBC.=20 > My questionis , what payload type number should be use in=20 > constructing RTP=20 > pkts.=20 >=20 > In sec5.1, (in my understanding) it says offerer MUST respect=20 > the answer. It=20 > MUST put "98" in=20 > payload type number in RTP.=20 >=20 > But what about in the answerer?? should it respect the offer?=20 > which payload=20 > type=20 > number (102 or 98) it should put in RTP??=20 >=20 >=20 >=20 > -- > Kevin Kuei >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Mar 4 04:57:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22060 for ; Fri, 4 Mar 2005 04:57:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D79Zx-0005bt-Ql for mmusic-web-archive@ietf.org; Fri, 04 Mar 2005 04:58:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D79V2-0002Qr-Cx; Fri, 04 Mar 2005 04:53:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D79V1-0002Qf-10 for mmusic@megatron.ietf.org; Fri, 04 Mar 2005 04:53:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21587 for ; Fri, 4 Mar 2005 04:53:31 -0500 (EST) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D79WW-0005W9-Pf for mmusic@ietf.org; Fri, 04 Mar 2005 04:55:10 -0500 Received: from tzi.uni-bremen.de (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j249r86d021992; Fri, 4 Mar 2005 10:53:12 +0100 (MET) Message-ID: <42283004.9080008@tzi.uni-bremen.de> Date: Fri, 04 Mar 2005 10:53:08 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Draft MMUSIC Agenda X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Folks, the tentative MMUSIC agenda is as follows (note that ICE was added just recently and may not yet show up on the to be published agenda at the IETF web site) Joerg DRAFT AGENDA Monday, 10th March 2005 at 15:30-17:45 ====================================== Introduction and Status Update (Chairs) 15 draft-ietf-mmusic-conn-precon-01.txt draft-ietf-mmusic-sdp-media-label-01.txt draft-ietf-mmusic-offer-answer-examples-05.txt draft-ietf-mmusic-img-req-07.txt draft-ietf-mmusic-img-framework-08.txt draft-ietf-mmusic-img-kmgmt-ext-13.txt draft-ietf-mmusic-sdescriptions-09.txt draft-ietf-mmusic-sdp-comedia-10.txt draft-ietf-mmusic-comedia-tls-02.txt draft-ietf-mmusic-sdp-srcfilter-06.txt draft-ietf-mmusic-sdp-new-24.txt SDP Format for BFCP (Camarillo) 5 draft-ietf-mmusic-sdp-bfcp-00.txt SDP Content Label (Hautakorpi) 10 draft-hautakorpi-mmusic-sdp-media-content-00.txt ICE (Rosenberg) 30 draft-ietf-mmusic-ice-04.txt SDPng (Kutscher) 10 draft-ietf-mmusic-sdpng-08.txt Stream Tracking for Resource Management in the Network (Wolf) 10 draft-guenkova-mmusic-sdp-ng-streamtrack-00.txt Harmonization between SDPng and MPEG-21 (Wolf) 10 draft-guenkova-mmusic-mpeg21-sdpng-00 RTSP (Westerlund) 30 draft-ietf-mmusic-rfc2326bis-09.txt Application Sharing draft-schulzrinne-mmusic-sharing-00.txt (Schulzrinne)10 draft-lennox-avt-app-sharing-00.txt draft-stirbu-mmusic-scal-sharing-00 (Stirbu) 10 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Mar 4 05:44:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27254 for ; Fri, 4 Mar 2005 05:44:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7AK5-0006j9-Ex for mmusic-web-archive@ietf.org; Fri, 04 Mar 2005 05:46:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7AHa-00046i-2w; Fri, 04 Mar 2005 05:43:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7AHF-00043W-DW for mmusic@megatron.ietf.org; Fri, 04 Mar 2005 05:43:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27182 for ; Fri, 4 Mar 2005 05:43:22 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7AIl-0006ha-Dc for mmusic@ietf.org; Fri, 04 Mar 2005 05:45:01 -0500 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j24AgogM015904; Fri, 4 Mar 2005 11:43:21 +0100 (MET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 11:43:59 +0100 Received: from [147.214.237.66] ([147.214.237.66]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 11:43:57 +0100 Message-ID: <42283BBA.3000307@ericsson.com> Date: Fri, 04 Mar 2005 11:43:06 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joerg Ott Subject: Re: [MMUSIC] Draft MMUSIC Agenda References: <42283004.9080008@tzi.uni-bremen.de> In-Reply-To: <42283004.9080008@tzi.uni-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2005 10:43:57.0017 (UTC) FILETIME=[1133EC90:01C520A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Joerg Ott wrote: > > DRAFT AGENDA > > Monday, 10th March 2005 at 15:30-17:45 > ====================================== According to the Agenda on the IETF homepage, MMUSIC is currently scheduled for Thursday at 15.30 - 17.45, do you have any other information? cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Mar 4 06:13:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29810 for ; Fri, 4 Mar 2005 06:13:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Am1-0007Jr-Uf for mmusic-web-archive@ietf.org; Fri, 04 Mar 2005 06:15:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Ak8-0000IN-Rz; Fri, 04 Mar 2005 06:13:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Ak7-0000Hm-AL for mmusic@megatron.ietf.org; Fri, 04 Mar 2005 06:13:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29801 for ; Fri, 4 Mar 2005 06:13:12 -0500 (EST) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7AlZ-0007Iv-RC for mmusic@ietf.org; Fri, 04 Mar 2005 06:14:51 -0500 Received: from rubin.informatik.uni-bremen.de (rubin.informatik.uni-bremen.de [134.102.224.59]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j24BCopv006514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Mar 2005 12:12:52 +0100 (MET) Received: (from jo@localhost) by rubin.informatik.uni-bremen.de (8.12.8/8.12.8/Submit) id j24BCniV015941; Fri, 4 Mar 2005 12:12:49 +0100 From: Joerg Ott Message-Id: <200503041112.j24BCniV015941@rubin.informatik.uni-bremen.de> Subject: Re: [MMUSIC] Draft MMUSIC Agenda To: magnus.westerlund@ericsson.com (Magnus Westerlund) Date: Fri, 4 Mar 2005 12:12:49 +0100 (MET) In-Reply-To: <42283BBA.3000307@ericsson.com> from "Magnus Westerlund" at Mar 04, 2005 11:43:06 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Joerg Ott , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Oops, that was copy & paste. It is Thursday! Thanks for pointing this out. Joerg > > Joerg Ott wrote: > > > > DRAFT AGENDA > > > > Monday, 10th March 2005 at 15:30-17:45 > > ====================================== > > According to the Agenda on the IETF homepage, MMUSIC is currently > scheduled for Thursday at 15.30 - 17.45, do you have any other information? > > cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Mar 7 14:14:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22648 for ; Mon, 7 Mar 2005 14:14:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Nj7-0003wG-DS for mmusic-web-archive@ietf.org; Mon, 07 Mar 2005 14:17:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Nfo-0003FP-Mo; Mon, 07 Mar 2005 14:13:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Nfn-0003FK-8t for mmusic@megatron.ietf.org; Mon, 07 Mar 2005 14:13:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22549 for ; Mon, 7 Mar 2005 14:13:45 -0500 (EST) Received: from lmfilto02.st1.spray.net ([212.78.202.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Ni0-0003uo-So for mmusic@ietf.org; Mon, 07 Mar 2005 14:16:06 -0500 Received: from localhost (localhost [127.0.0.1]) by lmfilto02.st1.spray.net (Postfix) with ESMTP id 292B81078D3 for ; Mon, 7 Mar 2005 19:13:35 +0000 (GMT) Received: from cmcodec02.st1.spray.net ([212.78.202.183]) by localhost (lmfilto02.st1.spray.net [212.78.202.32]) (amavisd-new, port 10024) with ESMTP id 10168-02 for ; Mon, 7 Mar 2005 19:13:34 +0000 (GMT) Received: from cmcodec02.st1.spray.net (localhost [127.0.0.1]) by cmcodec02.st1.spray.net (Postfix) with SMTP id D371582D00 for ; Mon, 7 Mar 2005 19:13:34 +0000 (GMT) Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=caramail.com; h=from:subject; b=WiAXw+g96XwQXfBYC6kiP8meiYGIA/y4oBRAyu0sDI1PkfLiYtmHPBRPm3rUR9dieFoObmWS8xf63y5WD76xJlhesSkam+5o+RGEMyktX95lsfJdTYxSK4j0unhnIs7wzh5MoEI4lvZGJprsXqgNCnNaIDqhPSmmgEx+Elu0f68=; From: "khaled" To: mmusic@ietf.org Message-ID: <1110222814031709@lycos-europe.com> X-Mailer: LycosMail X-Originating-IP: [134.157.116.130] Mime-Version: 1.0 Date: Mon, 07 Mar 2005 19:13:34 GMT Content-Type: multipart/mixed; boundary="=_NextPart_Lycos_0317091110222814_ID" X-Virus-Scanned: by amavisd-new at spray.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [MMUSIC] streaming proxy : live splitting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Lycos_0317091110222814_ID Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Hello, for my studies, I've to program a streaming proxy to use with RealPlayer = by students at the university. The students will connect to the proxy, which will connect to the server. When several students connect for the same stream on the same server (for= online tv, or radio for example), live streamind exactly, the proxy must= create only one connection to the server, and then distribute the strams= to the students (live splitting). But students would also to view videos or audios whose are not live, so t= hey will not start viewing at the same time and each student may interact= with the stream. In this case, connections will be created to the server= s for each student (the proxy may also use a cache system). So how I can do to know if a student or more are viewing a live video/aud= io, and so create only one connection to the server? Can I know it from the RTSP requests or something else? How is it possible? Thanks. C est le moment de dynamiser votre bo=EEte mail en d=E9couvrant les offre= s CaraMail Max et Pro - http://www.caramail.com --=_NextPart_Lycos_0317091110222814_ID Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --=_NextPart_Lycos_0317091110222814_ID-- From mmusic-bounces@ietf.org Tue Mar 8 15:25:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14140 for ; Tue, 8 Mar 2005 15:25:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lJd-0007oG-2e for mmusic-web-archive@ietf.org; Tue, 08 Mar 2005 15:28:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lEB-0005FH-Rm; Tue, 08 Mar 2005 15:22:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lEA-0005FC-LJ for mmusic@megatron.ietf.org; Tue, 08 Mar 2005 15:22:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13893 for ; Tue, 8 Mar 2005 15:22:48 -0500 (EST) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lGb-0007k8-R0 for mmusic@ietf.org; Tue, 08 Mar 2005 15:25:23 -0500 Received: from tzi.uni-bremen.de (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j28KMK6p021916; Tue, 8 Mar 2005 21:22:27 +0100 (MET) Message-ID: <422E097D.3010807@tzi.uni-bremen.de> Date: Tue, 08 Mar 2005 21:22:21 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Colin Perkins Subject: [MMUSIC] Slides for the MMUSIC meeting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Folks, attached is the updated MMUSIC agenda. Note that the application sharing stuff has moved to the 2nd slot of the AVT WG for discussion. All presenters are kindly requested to send their slides to both chairs until Thursday 3pm (i.e. 30 minutes before our meeting). Thanks, Colin and Joerg ------------------------------------------------------------------------ Multiparty Multimedia Session Control (MMUSIC) Working Group CHAIRS: Joerg Ott Colin Perkins DRAFT AGENDA Monday, 10th March 2005 at 15:30-17:45 ====================================== Introduction and Status Update (Chairs, 10) draft-ietf-mmusic-conn-precon-01.txt draft-ietf-mmusic-sdp-media-label-01.txt draft-ietf-mmusic-offer-answer-examples-05.txt draft-ietf-mmusic-img-req-07.txt draft-ietf-mmusic-img-framework-08.txt draft-ietf-mmusic-img-kmgmt-ext-13.txt draft-ietf-mmusic-sdescriptions-09.txt draft-ietf-mmusic-sdp-comedia-10.txt draft-ietf-mmusic-comedia-tls-02.txt draft-ietf-mmusic-sdp-srcfilter-06.txt draft-ietf-mmusic-sdp-new-24.txt SDP Format for BFCP (Camarillo, 5) draft-ietf-mmusic-sdp-bfcp-00.txt SDP Content Label (Hautakorpi, 10) draft-hautakorpi-mmusic-sdp-media-content-00.txt SDP Connectivity Preconditions (Andreasen, 10) draft-andreasen-mmusic-connectivityprecondition-02.txt ICE (Rosenberg, 30) draft-ietf-mmusic-ice-04.txt SDPng (Kutscher, 10) draft-ietf-mmusic-sdpng-08.txt Stream Tracking for Resource Management in the Network (Wolf, 10) draft-guenkova-mmusic-sdp-ng-streamtrack-00.txt Harmonization between SDPng and MPEG-21 (Wolf, 10) draft-guenkova-mmusic-mpeg21-sdpng-00 RTSP (Westerlund, 20) draft-ietf-mmusic-rfc2326bis-09.txt Internet Media Guides (Nomura, 10) - + - _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Mar 8 15:44:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17721 for ; Tue, 8 Mar 2005 15:44:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lbO-0000JJ-OQ for mmusic-web-archive@ietf.org; Tue, 08 Mar 2005 15:46:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lUp-0001dl-4W; Tue, 08 Mar 2005 15:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lUn-0001d3-Px for mmusic@megatron.ietf.org; Tue, 08 Mar 2005 15:40:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17332; Tue, 8 Mar 2005 15:39:59 -0500 (EST) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lXF-0000CN-P7; Tue, 08 Mar 2005 15:42:34 -0500 Received: from tzi.uni-bremen.de (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j28KdXvC028169; Tue, 8 Mar 2005 21:39:43 +0100 (MET) Message-ID: <422E0D86.3090105@tzi.uni-bremen.de> Date: Tue, 08 Mar 2005 21:39:34 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org, agenda@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MMUSIC Agenda Update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Sorry, of course, it is Thursday... --------------------------------------------------------------------- Multiparty Multimedia Session Control (MMUSIC) Working Group CHAIRS: Joerg Ott Colin Perkins AGENDA Thursday, 10th March 2005 at 15:30-17:45 ======================================== Introduction and Status Update (Chairs, 10) draft-ietf-mmusic-conn-precon-01.txt draft-ietf-mmusic-sdp-media-label-01.txt draft-ietf-mmusic-offer-answer-examples-05.txt draft-ietf-mmusic-img-req-07.txt draft-ietf-mmusic-img-framework-08.txt draft-ietf-mmusic-img-kmgmt-ext-13.txt draft-ietf-mmusic-sdescriptions-09.txt draft-ietf-mmusic-sdp-comedia-10.txt draft-ietf-mmusic-comedia-tls-02.txt draft-ietf-mmusic-sdp-srcfilter-06.txt draft-ietf-mmusic-sdp-new-24.txt SDP Format for BFCP (Camarillo, 5) draft-ietf-mmusic-sdp-bfcp-00.txt SDP Content Label (Hautakorpi, 10) draft-hautakorpi-mmusic-sdp-media-content-00.txt SDP Connectivity Preconditions (Andreasen, 10) draft-andreasen-mmusic-connectivityprecondition-02.txt ICE (Rosenberg, 30) draft-ietf-mmusic-ice-04.txt SDPng (Kutscher, 10) draft-ietf-mmusic-sdpng-08.txt Stream Tracking for Resource Management in the Network (Wolf, 10) draft-guenkova-mmusic-sdp-ng-streamtrack-00.txt Harmonization between SDPng and MPEG-21 (Wolf, 10) draft-guenkova-mmusic-mpeg21-sdpng-00 RTSP (Westerlund, 20) draft-ietf-mmusic-rfc2326bis-09.txt Internet Media Guides (Nomura, 10) - + - _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Mar 10 14:22:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21060 for ; Thu, 10 Mar 2005 14:22:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9TI5-0000yd-MF for mmusic-web-archive@ietf.org; Thu, 10 Mar 2005 14:25:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TEJ-00037Q-TV; Thu, 10 Mar 2005 14:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TEI-00037G-Gm for mmusic@megatron.ietf.org; Thu, 10 Mar 2005 14:21:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20996 for ; Thu, 10 Mar 2005 14:21:52 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9TH6-0000xQ-Hw for mmusic@ietf.org; Thu, 10 Mar 2005 14:24:52 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j2AJLnO6029407 for ; Thu, 10 Mar 2005 20:21:49 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 20:21:49 +0100 Received: from [147.214.97.151] (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id F5NGM0VL; Thu, 10 Mar 2005 20:21:49 +0100 Message-ID: <42307C84.1010401@ericsson.com> Date: Thu, 10 Mar 2005 17:57:40 +0100 X-Sybari-Trust: ac86eb69 b10726bd 811900c8 00000139 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2005 19:21:49.0276 (UTC) FILETIME=[6830E1C0:01C525A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Hi, It has come to my knowledge that the current specification of usage of Allow header may be to free to be useful. Currently OPTIONS method text says: Regardless of scope of the request, the Public header MUST always be included in the OPTIONS response listing the methods that are supported by the responding RTSP agent. In addition, if the scope of the request is limited to a media resource, the Allow header MAY be included in the response to enumerate the set of methods that are allowed for that resource. Thus a client indicating a specific media resource can not be guaranteed to get an correct indication if the media resource specific support is limited compared to the general capabilities. Therefore I would propose to change this to: Regardless of scope of the request, the Public header MUST always be included in the OPTIONS response listing the methods that are supported by the responding RTSP agent. In addition, if the scope of the request is limited to a media resource, the Allow header MUST be included in the response to enumerate the set of methods that are allowed for that resource unless the set of methods completely matches the set in the Public header. So what do you say about such a change? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Mar 10 14:39:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23266 for ; Thu, 10 Mar 2005 14:39:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9TYD-000228-SH for mmusic-web-archive@ietf.org; Thu, 10 Mar 2005 14:42:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TRK-0005gA-3N; Thu, 10 Mar 2005 14:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TRF-0005e7-MW; Thu, 10 Mar 2005 14:35:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22581; Thu, 10 Mar 2005 14:35:15 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9TU6-0001dJ-Ez; Thu, 10 Mar 2005 14:38:14 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1D9TRD-0003Gw-Ro; Thu, 10 Mar 2005 14:35:15 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 10 Mar 2005 14:35:15 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: mmusic chair , Internet Architecture Board , mmusic mailing list , mmusic chair , RFC Editor Subject: [MMUSIC] Protocol Action: 'Connection-Oriented Media Transport in the Session Description Protocol (SDP)' to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 The IESG has approved the following document: - 'Connection-Oriented Media Transport in the Session Description Protocol (SDP) ' as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. Technical Summary Traditionally, the Session Description Protocol (SDP) is used to set up connectionless media that runs over UDP or DCCP. When bidirectional media is set up with SDP, it is in fact established as a pair of unidirectional sockets. This specification describes how to express media transport over connection-oriented protocols in SDP. It defines the SDP TCP protocol identifier, the SDP setup attribute, which describes the connection setup procedure, and the SDP connection attribute, which handles connection reestablishment. Working Group Summary The MMUSIC WG supported the advancement of this specification, though for some time its applicability was in question. There are known implementations of this mechanism in the field. Protocol Quality This specification was reviewed for the IESG by Jon Peterson. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Mar 10 16:11:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07359 for ; Thu, 10 Mar 2005 16:11:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9UzY-00080e-7P for mmusic-web-archive@ietf.org; Thu, 10 Mar 2005 16:14:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Uvi-0002GT-Tz; Thu, 10 Mar 2005 16:10:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Tlt-0005j7-6E for mmusic@megatron.ietf.org; Thu, 10 Mar 2005 14:56:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27432 for ; Thu, 10 Mar 2005 14:56:34 -0500 (EST) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Toj-0003Wy-4e for mmusic@ietf.org; Thu, 10 Mar 2005 14:59:34 -0500 Received: from srsdmail01.PVNS.COM (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j2AJuPfp029221 for ; Thu, 10 Mar 2005 13:56:25 -0600 (CST) X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses Date: Thu, 10 Mar 2005 11:56:24 -0800 Message-ID: <758B5A159B385447B4F950DE72D7D7AD678D64@srsdmail01.PVNS.COM> Thread-Topic: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses Thread-Index: AcUlqnfSK7q++juqQuqh7wtJyV+tSQAAHB6w From: "Thomas Zeng" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 10 Mar 2005 16:10:49 -0500 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Hi Magnus: Our implementation only includes "Allow" header for any resource specific URL in the OPTIONS response. I like your proposal to mandate "Public" header in such cases, even though it means our implementation has to change.=20 It will make the standard less ambiguous. Thanks, -thomas =20 ---------- Forwarded message ---------- From: Magnus Westerlund Date: Thu, 10 Mar 2005 17:57:40 +0100 Subject: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses To: "mmusic (E-mail)" Hi, It has come to my knowledge that the current specification of usage of Allow header may be to free to be useful. Currently OPTIONS method text says: Regardless of scope of the request, the Public header MUST always be included in the OPTIONS response listing the methods that are supported by the responding RTSP agent. In addition, if the scope of the request is limited to a media resource, the Allow header MAY be included in the response to enumerate the set of methods that are allowed for that resource. Thus a client indicating a specific media resource can not be guaranteed to get an correct indication if the media resource specific support is limited compared to the general capabilities. Therefore I would propose to change this to: Regardless of scope of the request, the Public header MUST always be included in the OPTIONS response listing the methods that are supported by the responding RTSP agent. In addition, if the scope of the request is limited to a media resource, the Allow header MUST be included in the response to enumerate the set of methods that are allowed for that resource unless the set of methods completely matches the set in the Public header. So what do you say about such a change? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Mar 10 16:37:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09721 for ; Thu, 10 Mar 2005 16:37:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9VOh-0000p3-Hd for mmusic-web-archive@ietf.org; Thu, 10 Mar 2005 16:40:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VHs-0008Vw-CK; Thu, 10 Mar 2005 16:33:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VHq-0008Vr-Vd for mmusic@megatron.ietf.org; Thu, 10 Mar 2005 16:33:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09145 for ; Thu, 10 Mar 2005 16:33:40 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9VKj-0000eG-3w for mmusic@ietf.org; Thu, 10 Mar 2005 16:36:41 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j2ALXffm013925 for ; Thu, 10 Mar 2005 22:33:41 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 22:33:39 +0100 Received: from [147.214.97.151] (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id F5NC3FY6; Thu, 10 Mar 2005 22:33:39 +0100 Message-ID: <4230BD30.2050608@ericsson.com> Date: Thu, 10 Mar 2005 22:33:36 +0100 X-Sybari-Trust: 7b0ce4a3 b10726bd 811900c8 00000139 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng Subject: Re: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses References: <758B5A159B385447B4F950DE72D7D7AD678D64@srsdmail01.PVNS.COM> In-Reply-To: <758B5A159B385447B4F950DE72D7D7AD678D64@srsdmail01.PVNS.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2005 21:33:39.0375 (UTC) FILETIME=[D2FA33F0:01C525B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Hi Thomas, My proposed change was not around Public header, which already has been mandated for a while. The change is to ensure that clients can rely on receiving a Allow header if there is a difference with Public header for the specified resource. Cheers Magnus Thomas Zeng wrote: > Hi Magnus: > > Our implementation only includes "Allow" header for any resource > specific URL in the OPTIONS response. > > I like your proposal to mandate "Public" header in such cases, even > though it means our implementation has to change. > > It will make the standard less ambiguous. > > Thanks, > -thomas > > > ---------- Forwarded message ---------- > From: Magnus Westerlund > Date: Thu, 10 Mar 2005 17:57:40 +0100 > Subject: [MMUSIC] RTSP: Requirement on using Allow in media resource > specific OPTIONS responses > To: "mmusic (E-mail)" > > > Hi, > > It has come to my knowledge that the current specification of usage of > Allow header may be to free to be useful. > > Currently OPTIONS method text says: > > Regardless of scope of the request, the Public header MUST always be > included in the OPTIONS response listing the methods that are > supported by the responding RTSP agent. In addition, if the scope of > the request is limited to a media resource, the Allow header MAY be > included in the response to enumerate the set of methods that are > allowed for that resource. > > Thus a client indicating a specific media resource can not be guaranteed > to get an correct indication if the media resource specific support is > limited compared to the general capabilities. Therefore I would propose > to change this to: > > Regardless of scope of the request, the Public header MUST always be > included in the OPTIONS response listing the methods that are > supported by the responding RTSP agent. In addition, if the scope of > the request is limited to a media resource, the Allow header MUST be > included in the response to enumerate the set of methods that are > allowed for that resource unless the set of methods completely > matches the set in the Public header. > > So what do you say about such a change? > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Mar 10 16:43:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10467 for ; Thu, 10 Mar 2005 16:43:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9VUh-000196-Gz for mmusic-web-archive@ietf.org; Thu, 10 Mar 2005 16:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VPg-0001wg-4L; Thu, 10 Mar 2005 16:41:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VPc-0001vt-90 for mmusic@megatron.ietf.org; Thu, 10 Mar 2005 16:41:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10227 for ; Thu, 10 Mar 2005 16:41:41 -0500 (EST) Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9VST-00010J-M9 for mmusic@ietf.org; Thu, 10 Mar 2005 16:44:43 -0500 Received: from srsdmail01.PVNS.COM (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j2ALfVfa015569; Thu, 10 Mar 2005 15:41:31 -0600 (CST) X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses Date: Thu, 10 Mar 2005 13:41:31 -0800 Message-ID: <758B5A159B385447B4F950DE72D7D7AD678D67@srsdmail01.PVNS.COM> Thread-Topic: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses Thread-Index: AcUluNUYt3xMTMtMSbm1BZud+U4XlwAAPy/g From: "Thomas Zeng" To: "Magnus Westerlund" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Ok, we mis-interpreted the standards before. Thanks for pointing it out. -thomas =20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Thursday, March 10, 2005 1:34 PM To: Thomas Zeng Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses Hi Thomas, My proposed change was not around Public header, which already has been mandated for a while. The change is to ensure that clients can rely on receiving a Allow header if there is a difference with Public header for the specified resource. Cheers Magnus Thomas Zeng wrote: > Hi Magnus: >=20 > Our implementation only includes "Allow" header for any resource=20 > specific URL in the OPTIONS response. >=20 > I like your proposal to mandate "Public" header in such cases, even=20 > though it means our implementation has to change. >=20 > It will make the standard less ambiguous. >=20 > Thanks, > -thomas > =20 >=20 > ---------- Forwarded message ---------- > From: Magnus Westerlund > Date: Thu, 10 Mar 2005 17:57:40 +0100 > Subject: [MMUSIC] RTSP: Requirement on using Allow in media resource=20 > specific OPTIONS responses > To: "mmusic (E-mail)" >=20 >=20 > Hi, >=20 > It has come to my knowledge that the current specification of usage of > Allow header may be to free to be useful. >=20 > Currently OPTIONS method text says: >=20 > Regardless of scope of the request, the Public header MUST always be > included in the OPTIONS response listing the methods that are > supported by the responding RTSP agent. In addition, if the scope of > the request is limited to a media resource, the Allow header MAY be > included in the response to enumerate the set of methods that are > allowed for that resource. >=20 > Thus a client indicating a specific media resource can not be=20 > guaranteed to get an correct indication if the media resource specific > support is limited compared to the general capabilities. Therefore I=20 > would propose to change this to: >=20 > Regardless of scope of the request, the Public header MUST always be > included in the OPTIONS response listing the methods that are > supported by the responding RTSP agent. In addition, if the scope of > the request is limited to a media resource, the Allow header MUST be > included in the response to enumerate the set of methods that are > allowed for that resource unless the set of methods completely > matches the set in the Public header. >=20 > So what do you say about such a change? >=20 > Cheers >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 --=20 Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Mar 10 16:46:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10716 for ; Thu, 10 Mar 2005 16:46:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9VWz-0001ID-L3 for mmusic-web-archive@ietf.org; Thu, 10 Mar 2005 16:49:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VPs-0001xy-LO; Thu, 10 Mar 2005 16:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VPq-0001xo-Js for mmusic@megatron.ietf.org; Thu, 10 Mar 2005 16:41:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10237 for ; Thu, 10 Mar 2005 16:41:56 -0500 (EST) Received: from smtp105.mail.sc5.yahoo.com ([66.163.169.225]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D9VSi-00010q-1n for mmusic@ietf.org; Thu, 10 Mar 2005 16:44:57 -0500 Received: from unknown (HELO ?127.0.0.1?) (arvy?n@130.129.131.8 with plain) by smtp105.mail.sc5.yahoo.com with SMTP; 10 Mar 2005 21:41:55 -0000 Message-ID: <4230BF32.3030808@yahoo.com> Date: Thu, 10 Mar 2005 15:42:10 -0600 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses References: <42307C84.1010401@ericsson.com> In-Reply-To: <42307C84.1010401@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit I think this is a good change to ensure that the OPTIONS response is clear. Aravind Magnus Westerlund wrote: > Hi, > > It has come to my knowledge that the current specification of usage of > Allow header may be to free to be useful. > > Currently OPTIONS method text says: > > Regardless of scope of the request, the Public header MUST always be > included in the OPTIONS response listing the methods that are > supported by the responding RTSP agent. In addition, if the scope of > the request is limited to a media resource, the Allow header MAY be > included in the response to enumerate the set of methods that are > allowed for that resource. > > Thus a client indicating a specific media resource can not be > guaranteed to get an correct indication if the media resource specific > support is limited compared to the general capabilities. Therefore I > would propose to change this to: > > Regardless of scope of the request, the Public header MUST always be > included in the OPTIONS response listing the methods that are > supported by the responding RTSP agent. In addition, if the scope of > the request is limited to a media resource, the Allow header MUST be > included in the response to enumerate the set of methods that are > allowed for that resource unless the set of methods completely > matches the set in the Public header. > > So what do you say about such a change? > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Mar 10 19:33:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25608 for ; Thu, 10 Mar 2005 19:33:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Y8x-0000iE-5V for mmusic-web-archive@ietf.org; Thu, 10 Mar 2005 19:36:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Y5j-0002GQ-TH; Thu, 10 Mar 2005 19:33:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Y5i-0002GL-UI for mmusic@megatron.ietf.org; Thu, 10 Mar 2005 19:33:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25586 for ; Thu, 10 Mar 2005 19:33:18 -0500 (EST) Received: from [220.117.193.39] (helo=lapis1.nextreaming.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Y8a-0000d3-SN for mmusic@ietf.org; Thu, 10 Mar 2005 19:36:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses Date: Fri, 11 Mar 2005 09:33:08 +0900 Message-ID: Thread-Topic: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses thread-index: AcUlprYIvBQbj7CBQZCI52RVkcb9MQAKFrVg From: "Jae-Hwan Kim" To: "Magnus Westerlund" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Hi Magnus, Your revised text sounds good. BTW, I could know the 'allow' header is applicable only for OPTIONS from the table 9 of rfc2326bis-09. In rfc2326, this field can be used for all methods. Is there any reason for this limitation? I think 'allow' would be beneficial if I use it in DESCRIBE or SETUP for the first place, because some players doesn't send OPTIONS at first. Best Regards, Jae-Hwan > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: Friday, March 11, 2005 1:58 AM > To: mmusic (E-mail) > Subject: [MMUSIC] RTSP: Requirement on using Allow in media resource specific > OPTIONS responses >=20 > Hi, >=20 > It has come to my knowledge that the current specification of usage of > Allow header may be to free to be useful. >=20 > Currently OPTIONS method text says: >=20 > Regardless of scope of the request, the Public header MUST always be > included in the OPTIONS response listing the methods that are > supported by the responding RTSP agent. In addition, if the scope of > the request is limited to a media resource, the Allow header MAY be > included in the response to enumerate the set of methods that are > allowed for that resource. >=20 > Thus a client indicating a specific media resource can not be guaranteed > to get an correct indication if the media resource specific support is > limited compared to the general capabilities. Therefore I would propose > to change this to: >=20 > Regardless of scope of the request, the Public header MUST always be > included in the OPTIONS response listing the methods that are > supported by the responding RTSP agent. In addition, if the scope of > the request is limited to a media resource, the Allow header MUST be > included in the response to enumerate the set of methods that are > allowed for that resource unless the set of methods completely > matches the set in the Public header. >=20 > So what do you say about such a change? >=20 > Cheers >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Mar 13 05:31:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26297 for ; Sun, 13 Mar 2005 05:31:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAQRN-0002Rt-HW for mmusic-web-archive@ietf.org; Sun, 13 Mar 2005 05:35:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAQLi-0000CD-8s; Sun, 13 Mar 2005 05:29:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAQLc-0000C4-GP for mmusic@megatron.ietf.org; Sun, 13 Mar 2005 05:29:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26245 for ; Sun, 13 Mar 2005 05:29:21 -0500 (EST) Received: from relay1.mail.vrmd.de ([81.28.232.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAQOy-0002Mq-Rk for mmusic@ietf.org; Sun, 13 Mar 2005 05:32:54 -0500 Received: from [81.173.160.199] (helo=[81.173.160.199]) by vm8.bln2.vrmd.de with asmtp (Exim 4.41) id 1DAQLP-0006Zf-TH for mmusic@ietf.org; Sun, 13 Mar 2005 11:29:12 +0100 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <418FCF24.9070006@sightspeed.com> References: <418FCF24.9070006@sightspeed.com> Message-Id: <3648a5241dd730d389c297223052d1a8@let.de> From: Marc Manthey Date: Sun, 13 Mar 2005 11:29:10 +0100 To: IETF MMUSIC WG X-Mailer: Apple Mail (2.619.2) X-Relay-User: marc@let.de X-Spam-Score: 0.2 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [MMUSIC] The qvix-1.0.1.tar.gz X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0494389398==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 --===============0494389398== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-15--741434467; protocol="application/pkcs7-signature" --Apple-Mail-15--741434467 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit dear wg, recently i found out that there was a project called "qVIX / CU30" ....member Aron Rosenberg '02 decided that porting the Windows implementation of CU30 to GNU/Linux would be worthwhile, as GNU/Linux had very few video conferencing applications at the time and Linux users tend to be earlier adopters of new software than Windows users. http://www.cs.cornell.edu/boom/2001sp/rosenberg/ qVIX couldn't have been written without the work done by the GNU Project. While qVIX does use lots of tools developed by GNU, it relies heavily on the Linux kernel for several of its interfaces. at the end there is an note Remember to keep in mind that this method is patented. The two US patents that cover this are 5,973,626 and 5,740,278. http://164.195.100.11/netacgi/nph-Parser? Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/ srchnum.htm&r=1&f=G&l=50&s1=\'5,740,278\'.WKU.&OS=PN/5,740,278&RS=PN/ 5,740,278 http://164.195.100.11/netacgi/nph-Parser? Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/ srchnum.htm&r=1&f=G&l=50&s1=\'5,973,626\'.WKU.&OS=PN/5,973,626&RS=PN/ 5,973,626 itsnt this controverse ? or i am just to stupid to find the source code? http://download.sourceforge.net/cu30/qvix-1.0.1.tar.gz any help greatly apreciated regards marc from old germany -- "If the doors of perception were cleansed, everything would appear to man as it is, infinite." www.let.de www.applehelpers.com --Apple-Mail-15--741434467 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIID0jCCA84w ggM3oAMCAQICDwCZ9gAAAALW8UGBzBqXYTANBgkqhkiG9w0BAQQFADCBvDELMAkGA1UEBhMCREUx EDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoTMVRDIFRydXN0Q2Vu dGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNVBAsTGVRDIFRydXN0 Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRpZmljYXRlQHRydXN0Y2VudGVy LmRlMB4XDTA1MDIwNDE2NDg0N1oXDTA2MDIwNDE2NDg0N1owQDELMAkGA1UEBhMCREUxFTATBgNV BAMTDE1hcmMgTWFudGhleTEaMBgGCSqGSIb3DQEJARYLbWFyY0BsZXQuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDS9nE3SQ9KDSo3u8+OOuslCEV/AyW5owmQTC7Z5h4hKjK6Stq0 KbPBnJqd7ngfnaO5RsFO2B95uu+muV4cr3GmMJrtQtoC3wYjs24o22Sz/ebz9AKMH/R8rjuok0uN npe96vujCgmPITtacdUdW5Y/XMRXhnxV4hvDs9kDou7HyRwflafVlVPGSNSPDYmxf8ADfB82UnWy pBAKxmqwQmGfCRJvQu1GacXN38etT3jz/8+Y+BnkFbfoiORcwTJYNE+1uV9eg9MkLi0G9mo3mCYb LRQtCq2zvr/XlVpzrF8zmKPj5Dx+DurTisl9eBhSEymFk8MlOiLdN16zv5QL5/NJAgMBAAGjgcgw gcUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwMwYJYIZIAYb4QgEIBCYWJGh0dHA6Ly93 d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZIAYb4 QgEDBFAWTmh0dHBzOi8vd3d3LnRydXN0Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2stcmV2LmNnaS85 OUY2MDAwMDAwMDJENkYxNDE4MUNDMUE5NzYxPzANBgkqhkiG9w0BAQQFAAOBgQBd2aCE057B+UQ5 6w1kXmST7/VlBchj44yiFB0JRnhIPiWOE+W/EqxyRpMscqHNnY9xORu4ide95s+SCuNmIsy0TQnM N4GXEiUJfEqoiy+1Tf8XTmX22ShYQ0ra2kF4ISfbb6A+QjcxSm5Vu9VtIr9n9Uexj8EfpSgfUuWX o2Y/gjGCBCMwggQfAgEBMIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4G A1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERh dGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcG CSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTAJ BgUrDgMCGgUAoIICJzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NTAzMTMxMDI5MTFaMCMGCSqGSIb3DQEJBDEWBBQt/m/IeaZiiRn5+TR5BAOwpdqG7TCB4QYJKwYB BAGCNxAEMYHTMIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMH SGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0 d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3 DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTCB4wYLKoZI hvcNAQkQAgsxgdOggdAwgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQH EwdIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBO ZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZI hvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIPAJn2AAAAAtbxQYHMGpdhMA0GCSqG SIb3DQEBAQUABIIBAAs524l9fu3IbjScOTnSbdV3WDwIvHLNwddTHitU+833ylRoOsbNguBoc/n0 bnPp/wL2ohIqD49fK7JU4+kX9V3fRbVvtNpCD8yeG+pmSFItoXu1AsnXx1UlJETBmkl3mMG5oVEz st57HuP4HWJ1vXkwRlvMTDQQ4G+zylhVgjGR3xEKKJq3ldvGsdM3/fMUFtf48RjtFenVqRfjkGEL Osi/a4X2Skor0RqJLUTLlESVCZ4Q4Ij99VOdhUv9IK91S6APuBS3HTZo5YUpTvON4FsErrGPTApN QtS8TuJyOD+cMCbvX43XLbGgxUCsFReEGglNzk/basyTN0Hckc3e9kQAAAAAAAA= --Apple-Mail-15--741434467-- --===============0494389398== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0494389398==-- From mmusic-bounces@ietf.org Wed Mar 16 15:48:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07172 for ; Wed, 16 Mar 2005 15:48:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBfVt-00058b-8C for mmusic-web-archive@ietf.org; Wed, 16 Mar 2005 15:53:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfOS-0006F9-10; Wed, 16 Mar 2005 15:45:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfOO-0006EH-OS; Wed, 16 Mar 2005 15:45:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06544; Wed, 16 Mar 2005 15:45:22 -0500 (EST) Message-Id: <200503162045.PAA06544@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 16 Mar 2005 15:45:22 -0500 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-14.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) Author(s) : J. Arkko, et al. Filename : draft-ietf-mmusic-kmgmt-ext-14.txt Pages : 28 Date : 2005-3-16 This document defines general extensions for SDP and RTSP to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol. General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the MIKEY key management protocol is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-kmgmt-ext-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-16161016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-kmgmt-ext-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-16161016.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Wed Mar 16 16:57:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01217 for ; Wed, 16 Mar 2005 16:57:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBgaQ-0006DO-7m for mmusic-web-archive@ietf.org; Wed, 16 Mar 2005 17:01:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfhw-0005fM-Co; Wed, 16 Mar 2005 16:05:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfhu-0005eu-2W; Wed, 16 Mar 2005 16:05:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12964; Wed, 16 Mar 2005 16:05:31 -0500 (EST) Received: from cyber.robotics.net ([209.150.98.82] helo=barney.robotics.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBflz-0007cl-7e; Wed, 16 Mar 2005 16:09:48 -0500 Received: from barney.robotics.net (barney.robotics.net [209.150.98.82]) by barney.robotics.net (8.12.10/8.12.10) with ESMTP id j2GL5Trg013353; Wed, 16 Mar 2005 16:05:29 -0500 Date: Wed, 16 Mar 2005 16:05:29 -0500 (EST) From: Nathan Allen Stratton To: Internet-Drafts@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-14.txt In-Reply-To: <200503162045.PAA06544@ietf.org> Message-ID: References: <200503162045.PAA06544@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mmusic@ietf.org, i-d-announce@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Wed, 16 Mar 2005 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : Key Management Extensions for Session Description > Protocol (SDP) and Real Time Streaming Protocol (RTSP) > Author(s) : J. Arkko, et al. > Filename : draft-ietf-mmusic-kmgmt-ext-14.txt > Pages : 28 > Date : 2005-3-16 I know there are a lot of key management drafts and ideas going around, but I don't think kmgmt is from Mars. : ) Internet Engineering Task Force J. Arkko MMUSIC Working Group E. Carrara INTERNET-DRAFT F. Lindholm Expires: September 2005 M. Naslund K. Norrman Ericsson Mars 2005 ><> Nathan Stratton BroadVoice, Inc. nathan at robotics.net Talk IS Cheap http://www.robotics.net http://www.broadvoice.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Mar 17 03:01:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19674 for ; Thu, 17 Mar 2005 03:01:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBq0Q-00019i-Nh for mmusic-web-archive@ietf.org; Thu, 17 Mar 2005 03:05:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBpsj-0001uz-9I; Thu, 17 Mar 2005 02:57:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBpsg-0001uj-Ou for mmusic@megatron.ietf.org; Thu, 17 Mar 2005 02:57:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19162 for ; Thu, 17 Mar 2005 02:57:20 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBpwX-00011C-9o for mmusic@ietf.org; Thu, 17 Mar 2005 03:01:42 -0500 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j2H7uwh9011756; Thu, 17 Mar 2005 08:56:58 +0100 (MET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Mar 2005 08:56:54 +0100 Received: from [147.214.97.152] ([147.214.97.152]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Mar 2005 08:56:54 +0100 Message-ID: <42393845.6020203@ericsson.com> Date: Thu, 17 Mar 2005 08:56:53 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jae-Hwan Kim Subject: Re: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2005 07:56:54.0283 (UTC) FILETIME=[E28ED5B0:01C52AC6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi, Jae-Hwan Kim wrote: > BTW, I could know the 'allow' header is applicable only for OPTIONS from > the table 9 of rfc2326bis-09. In rfc2326, this field can be used for all > methods. Is there any reason for this limitation? I think 'allow' would > be beneficial if I use it in DESCRIBE or SETUP for the first place, > because some players doesn't send OPTIONS at first. > There is to my knowledge no reason to the restriction. Instead of having the too open statement that is present in RFC 2326, I simple documented where there was explicit that Allow was needed. That was only 405 and OPTIONS response. However I do see that there could be reasons why one could include Allow in DESCRIBE and SETUP responses. However I would like to have some discussion on the requirements level for including this header. Should it only be optional requiring that any client really desiring this information uses OPTIONS? Or do you like to promote it to a higher level? Also can it be expected that the Allow header is different for an aggregated session than for the individual media streams? In that case we must consider what the implications are on usage in SETUP responses. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Mar 17 10:16:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09877 for ; Thu, 17 Mar 2005 10:16:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBwnx-000471-WB for mmusic-web-archive@ietf.org; Thu, 17 Mar 2005 10:20:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBwgr-0005Ht-NT; Thu, 17 Mar 2005 10:13:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBwgp-0005Hb-9D; Thu, 17 Mar 2005 10:13:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09382; Thu, 17 Mar 2005 10:13:32 -0500 (EST) Received: from relay1.mail.vrmd.de ([81.28.232.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBwl0-0003xn-Q7; Thu, 17 Mar 2005 10:17:59 -0500 Received: from [213.196.200.129] (helo=[213.196.200.129]) by vm8.bln2.vrmd.de with asmtp (Exim 4.41) id 1DBwgJ-000789-PR; Thu, 17 Mar 2005 16:13:04 +0100 Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: <6c09feaab7f325675695534de225ac1b@let.de> To: avt mailing list , IETF MMUSIC WG From: Marc Manthey Date: Thu, 17 Mar 2005 16:13:09 +0100 X-Mailer: Apple Mail (2.619.2) X-Relay-User: marc@let.de X-Spam-Score: 0.3 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [MMUSIC] The qvix-1.0.1.tar.gz X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1385869170==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f --===============1385869170== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--378795355; protocol="application/pkcs7-signature" --Apple-Mail-2--378795355 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit hello all, sorry for this second mail , but i got no response on my first post. Recently i found out that there was a project called "qVIX / CU30" ....member Aron Rosenberg '02 decided that porting the Windows implementation of CU30 to GNU/Linux would be worthwhile, as GNU/Linux had very few video conferencing applications at the time and Linux users tend to be earlier adopters of new software than Windows users. http://www.cs.cornell.edu/boom/2001sp/rosenberg/ qVIX couldn't have been written without the work done by the GNU Project. While qVIX does use lots of tools developed by GNU, it relies heavily on the Linux kernel for several of its interfaces. at the end there is an note Remember to keep in mind that this method is patented. The two US patents that cover this are 5,973,626 and 5,740,278. http://164.195.100.11/netacgi/nph-Parser? Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/ srchnum.htm&r=1&f=G&l=50&s1=\'5,740,278\'.WKU.&OS=PN/5,740,278&RS=PN/ 5,740,278 http://164.195.100.11/netacgi/nph-Parser? Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/ srchnum.htm&r=1&f=G&l=50&s1=\'5,973,626\'.WKU.&OS=PN/5,973,626&RS=PN/ 5,973,626 itsnt this controverse ? or i am just to stupid to find the source code? http://download.sourceforge.net/cu30/qvix-1.0.1.tar.gz any help greatly apreciated regards marc from old germany P.S. cu seeme was invented from Tim dorcey 1992 right? -- "If the doors of perception were cleansed, everything would appear to man as it is, infinite." www.let.de www.applehelpers.com --Apple-Mail-2--378795355 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIID0jCCA84w ggM3oAMCAQICDwCZ9gAAAALW8UGBzBqXYTANBgkqhkiG9w0BAQQFADCBvDELMAkGA1UEBhMCREUx EDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoTMVRDIFRydXN0Q2Vu dGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNVBAsTGVRDIFRydXN0 Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRpZmljYXRlQHRydXN0Y2VudGVy LmRlMB4XDTA1MDIwNDE2NDg0N1oXDTA2MDIwNDE2NDg0N1owQDELMAkGA1UEBhMCREUxFTATBgNV BAMTDE1hcmMgTWFudGhleTEaMBgGCSqGSIb3DQEJARYLbWFyY0BsZXQuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDS9nE3SQ9KDSo3u8+OOuslCEV/AyW5owmQTC7Z5h4hKjK6Stq0 KbPBnJqd7ngfnaO5RsFO2B95uu+muV4cr3GmMJrtQtoC3wYjs24o22Sz/ebz9AKMH/R8rjuok0uN npe96vujCgmPITtacdUdW5Y/XMRXhnxV4hvDs9kDou7HyRwflafVlVPGSNSPDYmxf8ADfB82UnWy pBAKxmqwQmGfCRJvQu1GacXN38etT3jz/8+Y+BnkFbfoiORcwTJYNE+1uV9eg9MkLi0G9mo3mCYb LRQtCq2zvr/XlVpzrF8zmKPj5Dx+DurTisl9eBhSEymFk8MlOiLdN16zv5QL5/NJAgMBAAGjgcgw gcUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwMwYJYIZIAYb4QgEIBCYWJGh0dHA6Ly93 d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZIAYb4 QgEDBFAWTmh0dHBzOi8vd3d3LnRydXN0Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2stcmV2LmNnaS85 OUY2MDAwMDAwMDJENkYxNDE4MUNDMUE5NzYxPzANBgkqhkiG9w0BAQQFAAOBgQBd2aCE057B+UQ5 6w1kXmST7/VlBchj44yiFB0JRnhIPiWOE+W/EqxyRpMscqHNnY9xORu4ide95s+SCuNmIsy0TQnM N4GXEiUJfEqoiy+1Tf8XTmX22ShYQ0ra2kF4ISfbb6A+QjcxSm5Vu9VtIr9n9Uexj8EfpSgfUuWX o2Y/gjGCBCMwggQfAgEBMIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4G A1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERh dGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcG CSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTAJ BgUrDgMCGgUAoIICJzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NTAzMTcxNTEzMTBaMCMGCSqGSIb3DQEJBDEWBBS4sALBeyp7/AQnpimlTapocybsXDCB4QYJKwYB BAGCNxAEMYHTMIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMH SGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0 d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3 DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTCB4wYLKoZI hvcNAQkQAgsxgdOggdAwgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQH EwdIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBO ZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZI hvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIPAJn2AAAAAtbxQYHMGpdhMA0GCSqG SIb3DQEBAQUABIIBALmmVtSCORewKkmpULVd/6eye3XeI1vJgnypf4rEjItvE5juyImXaukY1gh/ IRqBZeFVhQ7AwGQ4CuBr0B21U7RNAXHLAOt5v431TLLlY8xxsnfVroVHZ2Z1TSLWg+iAbiqoGT8d UZasCs8v7SCsJw5N9yfUzt04UIwB/BgSSq4L27MQtIgrqKMmL2rSPjLtehTiK/RsRVp3OKLeEGHw yntSlaK5SXLzf6gf1pdGKbnCL867HiF3XNWlTf2WmeyoknrgtqYZVrIJ7ZQkzNU7uCRdTDCQi4Dd XkKttaJEJxTHtzSwf/Q02t1jEoPx5HJOChZRHsx5W6kGli0FTa6QXdwAAAAAAAA= --Apple-Mail-2--378795355-- --===============1385869170== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1385869170==-- From mmusic-bounces@ietf.org Thu Mar 17 11:21:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19547 for ; Thu, 17 Mar 2005 11:21:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxog-0006Xr-5E for mmusic-web-archive@ietf.org; Thu, 17 Mar 2005 11:25:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBxhS-0003Gr-3k; Thu, 17 Mar 2005 11:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBxhQ-0003Gj-4b for mmusic@megatron.ietf.org; Thu, 17 Mar 2005 11:18:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19167 for ; Thu, 17 Mar 2005 11:18:13 -0500 (EST) Received: from relay1.mail.vrmd.de ([81.28.232.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxlf-0006S1-Ol for mmusic@ietf.org; Thu, 17 Mar 2005 11:22:41 -0500 Received: from [213.196.200.129] (helo=[213.196.200.129]) by vm8.bln2.vrmd.de with asmtp (Exim 4.41) id 1DBxhF-0007cZ-DI for mmusic@ietf.org; Thu, 17 Mar 2005 17:18:05 +0100 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <8920f7584bacbef755e8c72c77785a87@csperkins.org> References: <6c09feaab7f325675695534de225ac1b@let.de> <8920f7584bacbef755e8c72c77785a87@csperkins.org> Message-Id: <482fc19cdced5111abda0c5b287ba64b@let.de> From: Marc Manthey Subject: Re: [MMUSIC] The qvix-1.0.1.tar.gz Date: Thu, 17 Mar 2005 17:18:11 +0100 To: IETF MMUSIC WG X-Mailer: Apple Mail (2.619.2) X-Relay-User: marc@let.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1582791940==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 --===============1582791940== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--374893555; protocol="application/pkcs7-signature" --Apple-Mail-3--374893555 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 17. Mar 2005, at 17:03 Uhr, Colin Perkins wrote: > On 17 Mar 2005, at 15:13, Marc Manthey wrote: >> sorry for this second mail , but i got no response on my first >> post. > > What is the relation of your question to the work of the IETF AVT or > MMUSIC working groups? I don't see anything relating to our work here, > which would seem to be the reason why you got no response. > > Colin hello colin Aron Rosenberg is member of the WG right? The programm i am talking about is an videoconferencing application based on rtsp, right ?, Developed by the community and several WGs . The source code is developed from several Opensource sources and made for GPL. In germany we call this thievery. regards marc -- "I could give you reasons to kill a 100 people a day, but we are grown-up, so let's have the lawyers do it for us." www.let.de www.applehelpers.com aim://macfreak2004 macfreak@jabber.org --Apple-Mail-3--374893555 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIID0jCCA84w ggM3oAMCAQICDwCZ9gAAAALW8UGBzBqXYTANBgkqhkiG9w0BAQQFADCBvDELMAkGA1UEBhMCREUx EDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoTMVRDIFRydXN0Q2Vu dGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNVBAsTGVRDIFRydXN0 Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRpZmljYXRlQHRydXN0Y2VudGVy LmRlMB4XDTA1MDIwNDE2NDg0N1oXDTA2MDIwNDE2NDg0N1owQDELMAkGA1UEBhMCREUxFTATBgNV BAMTDE1hcmMgTWFudGhleTEaMBgGCSqGSIb3DQEJARYLbWFyY0BsZXQuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDS9nE3SQ9KDSo3u8+OOuslCEV/AyW5owmQTC7Z5h4hKjK6Stq0 KbPBnJqd7ngfnaO5RsFO2B95uu+muV4cr3GmMJrtQtoC3wYjs24o22Sz/ebz9AKMH/R8rjuok0uN npe96vujCgmPITtacdUdW5Y/XMRXhnxV4hvDs9kDou7HyRwflafVlVPGSNSPDYmxf8ADfB82UnWy pBAKxmqwQmGfCRJvQu1GacXN38etT3jz/8+Y+BnkFbfoiORcwTJYNE+1uV9eg9MkLi0G9mo3mCYb LRQtCq2zvr/XlVpzrF8zmKPj5Dx+DurTisl9eBhSEymFk8MlOiLdN16zv5QL5/NJAgMBAAGjgcgw gcUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwMwYJYIZIAYb4QgEIBCYWJGh0dHA6Ly93 d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZIAYb4 QgEDBFAWTmh0dHBzOi8vd3d3LnRydXN0Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2stcmV2LmNnaS85 OUY2MDAwMDAwMDJENkYxNDE4MUNDMUE5NzYxPzANBgkqhkiG9w0BAQQFAAOBgQBd2aCE057B+UQ5 6w1kXmST7/VlBchj44yiFB0JRnhIPiWOE+W/EqxyRpMscqHNnY9xORu4ide95s+SCuNmIsy0TQnM N4GXEiUJfEqoiy+1Tf8XTmX22ShYQ0ra2kF4ISfbb6A+QjcxSm5Vu9VtIr9n9Uexj8EfpSgfUuWX o2Y/gjGCBCMwggQfAgEBMIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4G A1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERh dGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcG CSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTAJ BgUrDgMCGgUAoIICJzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NTAzMTcxNjE4MTJaMCMGCSqGSIb3DQEJBDEWBBRfvmjWX7I8c/JW+nVBjj0vpgICbTCB4QYJKwYB BAGCNxAEMYHTMIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMH SGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0 d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3 DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTCB4wYLKoZI hvcNAQkQAgsxgdOggdAwgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQH EwdIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBO ZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZI hvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIPAJn2AAAAAtbxQYHMGpdhMA0GCSqG SIb3DQEBAQUABIIBAAStn+dZpwZB6p3pRhg/VRfVdIK5u3Ew/rBSsE/DF0YzoK8KAAO7YEqANC0J Nxv+AG5F08kKF2hTGsi+bk6GE1RnSJbeLeYmu5JP7BLcn6ifgohxPHtLUQQ4ebr5KTaGMx2FqcHK WYK7dYWi93eTXhDrDx96+u7MMrDXX+og/L+UOBWRbCtmDjhvmRX5Xy6nhauJPBVqO3E/ODwAhjuN NPpx66b/yA3BajQHdnxIRgV0ra21ofqP2jEB2HQpM0Tw+vqnG3PgdI7pWlR5e0CktCtFw1dIT0ec qhtsPUBaUNIHmfcmea+C0Ds2C+zxV9BO2FOYynNmaKI9upnk2H2SCPcAAAAAAAA= --Apple-Mail-3--374893555-- --===============1582791940== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1582791940==-- From mmusic-bounces@ietf.org Thu Mar 17 12:46:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28896 for ; Thu, 17 Mar 2005 12:46:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBz9U-0000f7-DO for mmusic-web-archive@ietf.org; Thu, 17 Mar 2005 12:51:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBz1t-00054o-76; Thu, 17 Mar 2005 12:43:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBz1r-00054g-NC for mmusic@megatron.ietf.org; Thu, 17 Mar 2005 12:43:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28686 for ; Thu, 17 Mar 2005 12:43:22 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBz66-0000Zo-9e for mmusic@ietf.org; Thu, 17 Mar 2005 12:47:51 -0500 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:54782) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1DBz1W-0004Tm-9F; Thu, 17 Mar 2005 17:43:06 +0000 In-Reply-To: <482fc19cdced5111abda0c5b287ba64b@let.de> References: <6c09feaab7f325675695534de225ac1b@let.de> <8920f7584bacbef755e8c72c77785a87@csperkins.org> <482fc19cdced5111abda0c5b287ba64b@let.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8f534427173755c3a1fc3b0a18282de6@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] The qvix-1.0.1.tar.gz Date: Thu, 17 Mar 2005 17:43:01 +0000 To: Marc Manthey X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit On 17 Mar 2005, at 16:18, Marc Manthey wrote: > On 17. Mar 2005, at 17:03 Uhr, Colin Perkins wrote: >> On 17 Mar 2005, at 15:13, Marc Manthey wrote: >>> sorry for this second mail , but i got no response on my first >>> post. >> >> What is the relation of your question to the work of the IETF AVT or >> MMUSIC working groups? I don't see anything relating to our work >> here, which would seem to be the reason why you got no response. > > Aron Rosenberg is member of the WG right? The IETF has no formal membership, and anyone is welcome to participate in the working group provided they abide by IETF IPR disclosure rules (defined in RFC 3978 and RFC 3979). > The programm i am talking about is an videoconferencing application > based on rtsp, right ?, > Developed by the community and several WGs . IETF working groups develop technical standards, not applications. > The source code is developed from several Opensource sources > and made for GPL. In germany we call this thievery. I'm not familiar with the source code of this particular application, so I can't comment on that allegation. Do you have an issue with the standards that the IETF has developed? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Mar 21 16:19:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27774 for ; Mon, 21 Mar 2005 16:19:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDUOD-0002yi-Gv for mmusic-web-archive@ietf.org; Mon, 21 Mar 2005 16:24:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDUIa-0008Lc-JK; Mon, 21 Mar 2005 16:18:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDUIY-0008If-O9 for mmusic@megatron.ietf.org; Mon, 21 Mar 2005 16:18:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27732 for ; Mon, 21 Mar 2005 16:18:52 -0500 (EST) Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=mail.tvol.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDUNh-0002vA-49 for mmusic@ietf.org; Mon, 21 Mar 2005 16:24:13 -0500 Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1HX6R0LP; Mon, 21 Mar 2005 16:18:53 -0500 To: mmusic@ietf.org Subject: Re: [MMUSIC] Maximum non-scaled image size In-reply-to: <41D053B4.8030103@ericsson.com> References: <41C6AA71.80304@vs.informatik.uni-ulm.de> <41C6DEA2.6050201@cs.columbia.edu> <41C71F30.1080302@vs.informatik.uni-ulm.de> <41C9D6DE.9090306@ericsson.com> <41CF7154.5050600@cs.columbia.edu> <41D053B4.8030103@ericsson.com> From: Randell Jesup