From alam_fresher@yahoo.co.in Sun Jul 5 21:38:05 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8132428C195 for ; Sun, 5 Jul 2009 21:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.81 X-Spam-Level: X-Spam-Status: No, score=0.81 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_05=-1.11, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtxxGmSolf+f for ; Sun, 5 Jul 2009 21:38:04 -0700 (PDT) Received: from web94305.mail.in2.yahoo.com (web94305.mail.in2.yahoo.com [203.104.16.215]) by core3.amsl.com (Postfix) with SMTP id C809A28C18C for ; Sun, 5 Jul 2009 21:38:03 -0700 (PDT) Received: (qmail 27305 invoked by uid 60001); 6 Jul 2009 04:38:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1246855094; bh=a6cY7EhfUrghIgtKXmqHEY+tyItqpB7qiiPh3bMegGw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=WqdVnlwD8Qqzlt8cJjvu9QpkYmi/E6xZ2ZmSkYlWV/kBwUFimVGWhWS2AiPMGVEcfGQnLFm+/rZFpwgOkKVy2abJDgVJduAIUDtoaeyJm6VN7qTnseEdGVw2EVFsVt2p4tPYx5JQfVgoS34d8UL1ldblf7apakjBIrqgZQG6jyA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=6LpRCF6AJMqfHsQ3ir9vqk6BQJBwUHwta4wyuXG5lPZvyYIFDbw09if/V0aFajaUjG8+V/U6ohhXQFmyKEVLNCnUSwUNBVz8ylzY64SQKXONmJ6Kx5jXEzWHCbu75XUwsNEEgqVlMLBhRwFfFR20VQrknGnVyojM8T5KFyPu5w0=; Message-ID: <152701.26791.qm@web94305.mail.in2.yahoo.com> X-YMail-OSG: nQK4B0YVM1lbYfxc8WjhKS.vB4LgKHahb_6glNDKTzOCJ8Ku9CFSy0AGcfNJTvf0L1_NV8WdyxDFcQ19aUAauDpHit6sbRPUcXLaQSoIQfOlPYaWs0PZgKg3_s1j5MtRN.LHjZGEOm4TBr1O8EuNzIpUi6evrDi_WOsqosuvfl1UtBgEWwjvXirjRb47HkQHkFL8Y6VK772RgGwDGyZitX13sGmlZykfuXXJJg-- Received: from [59.162.59.194] by web94305.mail.in2.yahoo.com via HTTP; Mon, 06 Jul 2009 10:08:14 IST X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Mon, 6 Jul 2009 10:08:14 +0530 (IST) From: Mohammad Alam To: mmusic@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1904747781-1246855094=:26791" Subject: [MMUSIC] Non - Aggregation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 04:38:05 -0000 --0-1904747781-1246855094=:26791 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi I am implementing RTSP server in my application. I want to support non -=A0= aggregation=A0in=A0my server. There is non-aggregation example in sec 14.1o= f RFC 2326. I want to=A0implement the same. (eg. for 2 media. there=A0shoul= d be 2 SETUP, 2 PLAY=A0and 2=A0TEARDOWN with different session IDs) 1) I want to know what are the changes to be made in sdp.2) How can I have = different session IDs for different media.=A0 alam=0A=0A=0A See the Web's breaking stories, chosen by people lik= e you. Check out Yahoo! Buzz. http://in.buzz.yahoo.com/ --0-1904747781-1246855094=:26791 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =

I am implementing RT= SP server in my application. I want to support non -

aggregation in my server. There is non-aggregation example in sec 14.1

o= f RFC 2326. I want to implement the same. (eg. for 2 media. there = ;

should be 2 SETUP, 2 PLAY and 2= TEARDOWN with different session IDs)

1) I want to know wha= t are the changes to be made in sdp.

2= ) How can I have different session IDs for different media.

alam

=0A

See the Web's breaking = stories, chosen by people like you. Check out Yahoo! B= uzz. --0-1904747781-1246855094=:26791-- From jaehwan@vidiator.com Sun Jul 5 22:04:16 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DE028C1A7 for ; Sun, 5 Jul 2009 22:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QequTobu5HAM for ; Sun, 5 Jul 2009 22:04:15 -0700 (PDT) Received: from kor1corpmail01.mediator.com (vkimail.vidiator.com [211.189.53.2]) by core3.amsl.com (Postfix) with ESMTP id BB9E528C1C2 for ; Sun, 5 Jul 2009 22:04:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9FDF7.38D0F475" Date: Mon, 6 Jul 2009 14:04:20 +0900 Message-ID: In-Reply-To: <152701.26791.qm@web94305.mail.in2.yahoo.com> References: <152701.26791.qm@web94305.mail.in2.yahoo.com> From: "Jaehwan Kim" To: "Mohammad Alam" , Subject: Re: [MMUSIC] Non - Aggregation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 05:04:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FDF7.38D0F475 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9FDF7.38D0F475" ------_=_NextPart_002_01C9FDF7.38D0F475 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alam, 1/ no change in the sdp. 2/ The decision is made by player. If player uses the same session id in the second SETUP), server will think of it as aggregated control. Therefore, player should not send session id even in the second SETUP. =20 In fact, 2326 has some ambiguity for this, therefore, you can read also 2326bis draft. =20 Regards, Jaehwan =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Mohammad Alam Sent: Monday, July 06, 2009 1:38 PM To: mmusic@ietf.org Subject: [MMUSIC] Non - Aggregation =20 Hi =20 I am implementing RTSP server in my application. I want to support non - aggregation in my server. There is non-aggregation example in sec 14.1 of RFC 2326. I want to implement the same. (eg. for 2 media. there=20 should be 2 SETUP, 2 PLAY and 2 TEARDOWN with different session IDs) =20 1) I want to know what are the changes to be made in sdp. 2) How can I have different session IDs for different media.=20 =20 alam =20 ________________________________ See the Web's breaking stories, chosen by people like you. Check out=20 Yahoo! Buzz . ------_=_NextPart_002_01C9FDF7.38D0F475 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alam,

1/ no change in the sdp.

2/ The decision is made by player. If player uses the = same session id in the second SETUP), server will think of it as aggregated = control. Therefore, player should not send session id even in the second = SETUP.

In fact, 2326 has some ambiguity for this, therefore, you = can read also 2326bis draft.

Regards,

Jaehwan

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Mohammad Alam
Sent: Monday, July 06, 2009 1:38 PM
To: mmusic@ietf.org
Subject: [MMUSIC] Non - Aggregation

I am implementing RTSP server in my application. I want to support non = -

aggregation in my server. There is non-aggregation example in sec = 14.1

of RFC 2326. I want to implement the same. (eg. for 2 media. = there

should be 2 SETUP, 2 PLAY and 2 TEARDOWN with different session = IDs)

1) I want to know what are the changes to be made in sdp.

2) How can I have different session IDs for different = media.

alam

See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz.

------_=_NextPart_002_01C9FDF7.38D0F475-- ------_=_NextPart_001_01C9FDF7.38D0F475 Content-Type: text/plain; name="non-aggregate control example.txt" Content-Transfer-Encoding: base64 Content-Description: non-aggregate control example.txt Content-Disposition: attachment; filename="non-aggregate control example.txt" REVTQ1JJQkUgcnRzcDovLzE5Mi4xNi4xMTEuMzMvYWFhLmszZyBSVFNQLzEuMA0KQ1NlcTogMQ0K QWNjZXB0OiBhcHBsaWNhdGlvbi9zZHAgDQpBY2NlcHQtTGFuZ3VhZ2U6IGVuLVVTIA0KVXNlci1B Z2VudDogVklESTgwMA0KDQpSVFNQLzEuMCAyMDAgT0sNCkNTZXE6IDENCkxhc3QtTW9kaWZpZWQ6 IFR1ZSwgMDQgTWFyIDIwMDMgMDc6MjI6MDUgR01UIA0KQ2FjaGUtQ29udHJvbDogbXVzdC1yZXZh bGlkYXRlIA0KRGF0ZTogRnJpLCA5IE1heSAyMDAzIDA1OjU3OjAxIEdNVCANCkV4cGlyZXM6IEZy aSwgMjMgSnVuIDIwMDMgMDU6NTc6MDEgDQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3NkcA0K Q29udGVudC1CYXNlOiBydHNwOi8vMTkyLjE2LjExMS4zMy9WSURJL2FhYS5rM2cNCkNvbnRlbnQt TGFuZ3VhZ2U6IGVuLVVTIA0KQ29udGVudC1MZW5ndGg6IDczMiANClNlcnZlcjogVklESV9WT0Qv MS4wDQoNCnY9MCANCm89LSAyNjk5NDcwNDg5IDEwNTEyNDU2MzkgSU4gSVA0IDE5Mi4xNi4xMTEu MzMgDQpzPVZJREkvMQ0KdT13d3cubXl0ZWxlY29tLmNvLmtyDQplPXNlcnZpY2VAbXl0ZWxlY29t LmNvLmtyIA0KYz1JTiBJUDQgMC4wLjAuMCANCnQ9MCAwIA0KYT1jb250cm9sOiBydHNwOi8vMTky LjE2LjExMS4zMy9WSURJL2FhYS5rM2cNCmE9cmFuZ2U6bnB0PTAuMDAwMDAwLTQ2LjQwMDAwMCAg ICAgDQptPWF1ZGlvIDAgUlRQL0FWUCAxMTAgICAgIA0KYj1BUzoxNyAgICAgDQphPXJhbmdlOm5w dD0wLjAwMDAwMC00Ni4yNTQwMDAgICAgIA0KYT1ydHBtYXA6MTEwIE1QNEEtTEFUTS8yMjA1MC8x ICAgICANCmE9Y29udHJvbDp0cmFja0lEPTMxICAgICANCmE9Zm10cDoxMTAgcHJvZmlsZS1sZXZl bC1pZD0xNTtvYmplY3Q9MjtjcHJlc2VudD0wO2NvbmZpZz00MzAwMjcxMDNGQzANCm09dmlkZW8g MCBSVFAvQVZQIDk3ICAgICANCmI9QVM6MzINCmE9cmFuZ2U6bnB0PTAuMDAwMDAwLTQ2LjQwMDAw MCANCmE9WC1EaXNhbGxvd3JhbmRvbWFjY2Vzcw0KYT1ydHBtYXA6OTcgTVA0Vi1FUy81IA0KYT1j b250cm9sOnRyYWNrSUQ9MjEgDQphPWZtdHA6OTcgcHJvZmlsZS1sZXZlbC1pZD04O2NvbmZpZz0w MDAwMDFCMDA4MDAwMDAxQjI1MzQ1NTI0RjRENDUyMDU0NDU0Mw0KNDg0RTRGNEM0RjQ3NTkyMDUy MjY0NDIwNDM0NTRFNTQ0NTUyMjA0RDU1NEM1NDQ5NEQ0NTQ0NDk0MTIwNEM0MQ0KNDIyRTAwMDAw MUI1MDkwMDAwMDEwMDAwMDAwMTIwMDA4NDQwMDE3MzA1ODQxMjE0NDMNCg0KU0VUVVAgcnRzcDov LzE5Mi4xNi4xMTEuMzMvYWFhLmszZy90cmFja0lEPTIxIFJUU1AvMS4wDQpDU2VxOiAyIFRyYW5z cG9ydDogUlRQL0FWUDt1bmljYXN0O2NsaWVudF9wb3J0PTEzMTAwLTEzMTAxIA0KQmxvY2tzaXpl OiAxNDYwDQpVc2VyLUFnZW50OiBWSURJODAwLzEuMCANCg0KUlRTUC8xLjAgMjAwIE9LDQpDU2Vx OiAyIA0KTGFzdC1Nb2RpZmllZDogVHVlLCAwNCBNYXIgMjAwMyAwNzoyMjowNSBHTVQgDQpDYWNo ZS1Db250cm9sOiBtdXN0LXJldmFsaWRhdGUgDQpEYXRlOiBGcmksIDIzIE1heSAyMDAzIDA1OjU3 OjAzIEdNVCANCkV4cGlyZXM6IEZyaSwgMjMgSnVuIDIwMDMgMDU6NTc6MDMgR01UIA0KU2Vzc2lv bjogMjU0NTgyMjAxMSANClRyYW5zcG9ydDogUlRQL0FWUDt1bmljYXN0O2NsaWVudF9wb3J0PTEz MTAwLTEzMTAxO3NlcnZlcl9wb3J0PTEyMDAwLTEyMDAxO3NvdXJjZT0xOTIuMTYuMTExLjMzO2Rl c3RpbmF0aW9uPTEwLjYwLjI1My4zMTtzc3JjPTc5MGEwODJjIFNlcnZlcjogVklESV9WT0QvMS4w IA0KDQpTRVRVUCBydHNwOi8vMTkyLjE2LjExMS4zMy9WSURJL2FhYS5rM2cvdHJhY2tJRD0zMSBS VFNQLzEuMA0KQ1NlcTogMw0KVHJhbnNwb3J0OiBSVFAvQVZQO3VuaWNhc3Q7Y2xpZW50X3BvcnQ9 MTMxMDItMTMxMDMNCkJsb2Nrc2l6ZTogMTQ2MA0KVXNlci1BZ2VudDogVklESTgwMC8xLjAgDQoN ClJUU1AvMS4wIDIwMCBPSw0KQ1NlcTogMyAgICAgICAgDQpMYXN0LU1vZGlmaWVkOiBUdWUsIDA0 IE1hciAyMDAzIDA3OjIyOjA1IEdNVCANCkNhY2hlLUNvbnRyb2w6IG11c3QtcmV2YWxpZGF0ZSAN CkRhdGU6IEZyaSwgMjMgTWF5IDIwMDMgMDU6NTc6MDQgR01UIA0KRXhwaXJlczogRnJpLCAyMyBK dW4gMjAwMyAwNTo1NzowNCBHTVQgDQpTZXNzaW9uOiAyMDYwNzQzNDE1IA0KVHJhbnNwb3J0OiBS VFAvQVZQO3VuaWNhc3Q7Y2xpZW50X3BvcnQ9MTMxMDItMTMxMDM7c2VydmVyX3BvcnQ9MTIwMDIt MTIwMDM7c291cmNlPTE5Mi4xNi4xMTEuMzM7ZGVzdGluYXRpb249MTAuNjAuMjUzLjMxO3NzcmM9 YWU5ZjM3NGQgDQoNClBMQVkgcnRzcDovLzE5Mi4xNi4xMTEuMzMvVklESS9hYWEuazNnIFJUU1Av MS4wDQpDU2VxOiA0IA0KU2Vzc2lvbjogMjU0NTgyMjA2Mg0KVXNlci1BZ2VudDogVklESTgwMC8x LjAgDQoNClJUU1AvMS4wIDIwMCBPSw0KQ1NlcTogNA0KTGFzdC1Nb2RpZmllZDogVHVlLCAwNCBN YXIgMjAwMyAwNzoyMjowNSBHTVQgDQpDYWNoZS1Db250cm9sOiBtdXN0LXJldmFsaWRhdGUgDQpE YXRlOiBGcmksIDIzIE1heSAyMDAzIDA1OjU3OjA1IEdNVCANCkV4cGlyZXM6IEZyaSwgMjMgSnVu IDIwMDMgMDU6NTc6MDUgR01UIA0KU2Vzc2lvbjogMjU0NTgyMjA2Mg0KU2VydmVyOiBWSURJX1ZP RC8xLjANClJhbmdlOiBucHQ9MC4wMDAwLQ0KUlRQLUluZm86ICB1cmw9cnRzcDovLzE5Mi4xNi4x MTEuMzMvVklESS9hYWEuazNnL3RyYWNrSUQ9MjE7c2VxPTE7cnRwdGltZT0wDQoNClBMQVkgcnRz cDovLzE5Mi4xNi4xMTEuMzMvVklESS9hYWEuazNnIFJUU1AvMS4wDQpDU2VxOiA1IA0KU2Vzc2lv bjogMjA2MDc0MzQxNQ0KVXNlci1BZ2VudDogVklESTgwMC8xLjAgDQoNClJUU1AvMS4wIDIwMCBP Sw0KQ1NlcTogNQ0KTGFzdC1Nb2RpZmllZDogVHVlLCAwNCBNYXIgMjAwMyAwNzoyMjowNSBHTVQg DQpDYWNoZS1Db250cm9sOiBtdXN0LXJldmFsaWRhdGUgDQpEYXRlOiBGcmksIDIzIE1heSAyMDAz IDA1OjU3OjA3IEdNVCANCkV4cGlyZXM6IEZyaSwgMjMgSnVuIDIwMDMgMDU6NTc6MDcgR01UIA0K U2Vzc2lvbjogMjA2MDc0MzQxNQ0KU2VydmVyOiBWSURJX1ZPRC8xLjANClJhbmdlOiBucHQ9MC4w MDAwLQ0KUlRQLUluZm86ICAgIHVybD1ydHNwOi8vMTkyLjE2LjExMS4zMy9WSURJL2FhYS5rM2cv dHJhY2tJRD0zMTtzZXE9MTtydHB0aW1lPTANCiAgICAgDQoNClBBVVNFIHJ0c3A6Ly8gMTkyLjE2 LjExMS4zMy9WSURJL2FhYS5rM2cvdHJhY2tJRD0yMSBSVFNQLzEuMA0KQ1NlcTogNiBTZXNzaW9u OiAyNTQ1ODIyMDYyDQpVc2VyLUFnZW50OiBWSURJODAwLzEuMCANCg0KDQpSVFNQLzEuMCAyMDAg T0sNCkNTZXE6IDYNCkxhc3QtTW9kaWZpZWQ6IFR1ZSwgMDQgTWFyIDIwMDMgMDc6MjI6MDUgR01U IA0KQ2FjaGUtQ29udHJvbDogbXVzdC1yZXZhbGlkYXRlIA0KRGF0ZTogRnJpLCAyMyBNYXkgMjAw MyAwNTo1NzowOCBHTVQgDQpFeHBpcmVzOiBGcmksIDIzIEp1biAyMDAzIDA1OjU3OjA4IEdNVCAN ClNlc3Npb246IDI1NDU4MjIwNjINClJhbmdlOm5wdD0yMy43OTgtDQpTZXJ2ZXI6IFZJRElfVk9E LzEuMA0KDQoNClRFQVJET1dOIHJ0c3A6Ly8xOTIuMTYuMTExLjMzL1ZJREkvYWFhLmszZyBSVFNQ LzEuMA0KQ1NlcTogNyANClNlc3Npb246IDI1NDU4MjIwNjINClVzZXItQWdlbnQ6IFZJREk4MDAv MS4wIA0KDQpSVFNQLzEuMCAyMDAgT0sNCkNTZXE6IDcNCkxhc3QtTW9kaWZpZWQ6IFR1ZSwgMDQg TWFyIDIwMDMgMDc6MjI6MDUgR01UIA0KQ2FjaGUtQ29udHJvbDogbXVzdC1yZXZhbGlkYXRlIA0K RGF0ZTogRnJpLCAyMyBNYXkgMjAwMyAwNTo1Nzo0NCBHTVQgDQpFeHBpcmVzOiBGcmksIDIzIEp1 biAyMDAzIDA1OjU3OjQ0IEdNVCANClNlcnZlcjogVklESV9WT0QvMS4wDQoNClRFQVJET1dOIHJ0 c3A6Ly8xOTIuMTYuMTExLjMzL1ZJREkvYWFhLmszZyBSVFNQLzEuMA0KQ1NlcTogOCBTZXNzaW9u OiAyMDYwNzQzNDE1DQpVc2VyLUFnZW50OiBWSURJODAwLzEuMCANCg0KUlRTUC8xLjAgMjAwIE9L DQpDU2VxOiA4DQpMYXN0LU1vZGlmaWVkOiBUdWUsIDA0IE1hciAyMDAzIDA3OjIyOjA1IEdNVCAN CkNhY2hlLUNvbnRyb2w6IG11c3QtcmV2YWxpZGF0ZSANCkRhdGU6IEZyaSwgMjMgTWF5IDIwMDMg MDU6NTc6NDUgR01UIA0KRXhwaXJlczogRnJpLCAyMyBKdW4gMjAwMyAwNTo1Nzo0NSBHTVQgDQpT ZXJ2ZXI6IFZJRElfVk9ELzEuMA0K ------_=_NextPart_001_01C9FDF7.38D0F475-- From alam_fresher@yahoo.co.in Sun Jul 5 23:14:21 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DE53A68E8 for ; Sun, 5 Jul 2009 23:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVPHAa1OVslY for ; Sun, 5 Jul 2009 23:14:20 -0700 (PDT) Received: from web94308.mail.in2.yahoo.com (web94308.mail.in2.yahoo.com [203.104.16.218]) by core3.amsl.com (Postfix) with SMTP id 4E8123A68D0 for ; Sun, 5 Jul 2009 23:14:18 -0700 (PDT) Received: (qmail 11525 invoked by uid 60001); 6 Jul 2009 06:14:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1246860875; bh=PWzqJXe3USD9eQRvtT1dD2ll9Vqi0JLZiDBmqzinTto=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=AdDDLIsViAfoQzzukKLCFE6k5B37VkiQP/M34bGNI86bvLvzprO78IAhxVO8/r4+H+dHU1gL9cnE58lJm1Sre/2IpqcTzbw4YFf2yA9FAa3AIowB38wRuzPsp5/t+Ej/WGeeKMvHDYnwylo2p5Es7/TxUiXvhVYOoanYlwS3kmI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=SIqn7xAoywelU5kE5w0dQ+P0C3OQKUvN3dKpSmiL+aFINE+zxdHSooX4iMsdG8Ip0HGuxXMFm6I8c0mbdIT90L6e0YQXsU4ofiQTvikTQ9TMM1E66mCWu9pRTrTA3zmFDXpUHNX3biN+9aGLc2/28+xZ7OgTFJlsimI9DjjBEvs=; Message-ID: <146403.8987.qm@web94308.mail.in2.yahoo.com> X-YMail-OSG: 1XeCeT0VM1m90th5aICMpefH74qvk.CeUWKHyuPZsMtTBusa_ei7C_lvGgSX4Dqh01TJciBYnpivyvM8HOeDv6bxJJ5b4ZDQRrmC2qBOpRIh7J.CjPfyAd6WObqEL11_UNHS847t7VWvGYySCl_yWP_7aZXP5iXVcreZ8y67GccwthQ6u7OMvSKrqA-- Received: from [59.162.59.194] by web94308.mail.in2.yahoo.com via HTTP; Mon, 06 Jul 2009 11:44:34 IST X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Mon, 6 Jul 2009 11:44:34 +0530 (IST) From: Mohammad Alam To: mmusic@ietf.org, Jaehwan Kim MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-918110294-1246860874=:8987" Subject: Re: [MMUSIC] Non - Aggregation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 06:14:21 -0000 --0-918110294-1246860874=:8987 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi JaehwanCan you name me one open source/freeware RTSP client that support= s=A0non - aggregation.I think VLC and QTSS does not support non - aggregati= on. RegardsAlam --- On Mon, 6/7/09, Jaehwan Kim wrote: From: Jaehwan Kim Subject: RE: [MMUSIC] Non - Aggregation To: "Mohammad Alam" , mmusic@ietf.org Date: Monday, 6 July, 2009, 10:34 AM =20 =20 =20 Hi Alam,=20 1/ no change in the sdp.=20 2/ The decision is made by player. If player uses the same session id in the second SETUP), server will think of it as aggregated cont= rol. Therefore, player should not send session id even in the second SETUP.=20 =A0=20 In fact, 2326 has some ambiguity for this, therefore, you can read also 2326bis draft.=20 =A0=20 Regards,=20 Jaehwan=20 =A0=20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Mohammad Alam Sent: Monday, July 06, 2009 1:38 PM To: mmusic@ietf.org Subject: [MMUSIC] Non - Aggregation=20 =A0=20 =20 =20 =20 =20 =20 Hi=20 =20 =A0=20 =20 =20 I am implementing RTSP server in my application. I want to support non -=A0= =20 =20 =20 aggregation=A0in=A0my server. There is non-aggregation example in sec 14.1=20 =20 =20 of RFC 2326. I want to=A0implement the same. (eg. for 2 media. there=A0=20 =20 =20 should be 2 SETUP, 2 PLAY=A0and 2=A0TEARDOWN with different session IDs)=20 =20 =20 =A0=20 =20 =20 1) I want to know what are the changes to be made in sdp.=20 =20 =20 2) How can I have different session IDs for different media.=A0=20 =20 =20 =A0=20 =20 =20 alam=20 =20 =20 =20 =20 =20 =20 =A0=20 See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buz= z.=20 =20 =0A=0A=0A Looking for local information? Find it on Yahoo! Local http:= //in.local.yahoo.com/ --0-918110294-1246860874=:8987 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Jaehwan

Can you name me one open sourc= e/freeware RTSP client that supports

non - aggregation.

I think VLC and QTSS does not support non - aggregation.

<= br>

Regards

Alam

--- On Mon, 6/7/0= 9, Jaehwan Kim <jaehwan@vidiator.com> wrote:

From: Jaehwan Kim <jaehwan@vidiator.com>
Subjec= t: RE: [MMUSIC] Non - Aggregation
To: "Mohammad Alam" <alam_fresher@y= ahoo.co.in>, mmusic@ietf.org
Date: Monday, 6 July, 2009, 10:34 AM
=

=20 =20 =20

Hi Alam,

=20

1/ no change in the sdp.

=20

2/ The decision is made by= player. If player uses the same session id in the second SETUP), server will think of it as aggregated cont= rol. Therefore, player should not send session id even in the second SETUP.

=20

In fact, 2326 has some amb= iguity for this, therefore, you can read also 2326bis draft.

=20

Regards,

=20

Jaehwan

=20

I am implementing RTSP server in my application. I want to support non -&nbs= p;

=20

aggregation in my server. There is non-aggregation example in sec 14.1

=20

of RFC 2326. I want to implement the same. (eg. for 2 media. there =

=20

should be 2 SETUP, 2 PLAY and 2 TEARDOWN with different session IDs)

=20

1) I want to know what are the changes to be made in sdp.

=20

2) How can I have different session IDs for different media.

=20

alam

=20

See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz.

=20

=0A

Yahoo! recommends that you upgrade to the new and safer Internet Explorer 8. --0-918110294-1246860874=:8987-- From jaehwan@vidiator.com Mon Jul 6 00:30:29 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4324B3A6C9D for ; Mon, 6 Jul 2009 00:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpu+Lu4zKhHC for ; Mon, 6 Jul 2009 00:30:21 -0700 (PDT) Received: from kor1corpmail01.mediator.com (vkimail.vidiator.com [211.189.53.2]) by core3.amsl.com (Postfix) with ESMTP id DD8533A6C9A for ; Mon, 6 Jul 2009 00:30:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9FE0B.ACB51A19" Date: Mon, 6 Jul 2009 16:30:44 +0900 Message-ID: In-Reply-To: <146403.8987.qm@web94308.mail.in2.yahoo.com> References: <146403.8987.qm@web94308.mail.in2.yahoo.com> From: "Jaehwan Kim" To: "Mohammad Alam" Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Non - Aggregation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 07:30:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FE0B.ACB51A19 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9FE0B.ACB51A19" ------_=_NextPart_002_01C9FE0B.ACB51A19 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alam, Unfortunately, I have no idea, although I have implemented before. Because the majority of RTSP usage looks aggregated control and non-aggregated control seems increasing system complexity, I am also not seeing it nowadays but some Motorola phone supported it in the past.=20 In fact, understanding the meaning of 'session' was one of very difficult things in only 2326 days! =20 Regarding the usage, we thought muting audio channel and a few rich media applications: multiple video, audio and picture streaming(multiple RTSP sessions) in one TCP 'connection'.=20 =20 Can we know what kind of application you think? =20 Regards, Jaehwan p.s. the example is updated. =20 From: Mohammad Alam [mailto:alam_fresher@yahoo.co.in]=20 Sent: Monday, July 06, 2009 3:15 PM To: mmusic@ietf.org; Jaehwan Kim Subject: RE: [MMUSIC] Non - Aggregation =20 Hi Jaehwan Can you name me one open source/freeware RTSP client that supports=20 non - aggregation. I think VLC and QTSS does not support non - aggregation. =20 Regards Alam --- On Mon, 6/7/09, Jaehwan Kim wrote: From: Jaehwan Kim Subject: RE: [MMUSIC] Non - Aggregation To: "Mohammad Alam" , mmusic@ietf.org Date: Monday, 6 July, 2009, 10:34 AM Hi Alam, 1/ no change in the sdp. 2/ The decision is made by player. If player uses the same session id in the second SETUP), server will think of it as aggregated control. Therefore, player should not send session id even in the second SETUP. =20 In fact, 2326 has some ambiguity for this, therefore, you can read also 2326bis draft. =20 Regards, Jaehwan =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Mohammad Alam Sent: Monday, July 06, 2009 1:38 PM To: mmusic@ietf.org Subject: [MMUSIC] Non - Aggregation =20 Hi =20 I am implementing RTSP server in my application. I want to support non - aggregation in my server. There is non-aggregation example in sec 14.1 of RFC 2326. I want to implement the same. (eg. for 2 media. there=20 should be 2 SETUP, 2 PLAY and 2 TEARDOWN with different session IDs) =20 1) I want to know what are the changes to be made in sdp. 2) How can I have different session IDs for different media.=20 =20 alam =20 ________________________________ See the Web's breaking stories, chosen by people like you. Check out=20 Yahoo! Buzz . =20 ________________________________ Yahoo! recommends that you upgrade to the new and safer Internet Explorer 8 . ------_=_NextPart_002_01C9FE0B.ACB51A19 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alam,

Unfortunately, I have no idea, although I have = implemented before.

Because the majority of RTSP usage looks aggregated = control and non-aggregated control seems increasing system complexity, I am also not seeing it = nowadays but some Motorola phone supported it in the past.

In fact, understanding the meaning of = ‘session’ was one of very difficult things in only 2326 days!

Regarding the usage, we thought muting audio channel and = a few rich media applications: multiple video, audio and picture streaming(multiple = RTSP sessions) in one TCP ‘connection’.

Can we know what kind of application you = think?

Regards,

Jaehwan

p.s. the example is updated.

From: Mohammad Alam [mailto:alam_fresher@yahoo.co.in]
Sent: Monday, July 06, 2009 3:15 PM
To: mmusic@ietf.org; Jaehwan Kim
Subject: RE: [MMUSIC] Non - Aggregation

Hi = Jaehwan

Can you name me one open = source/freeware RTSP client that supports

non - = aggregation.

I think VLC and QTSS does not = support non - aggregation.

Regards

Alam

--- On Mon, 6/7/09, Jaehwan Kim = <jaehwan@vidiator.com> wrote:

From: Jaehwan Kim <jaehwan@vidiator.com>
Subject: RE: [MMUSIC] Non - Aggregation
To: "Mohammad Alam" <alam_fresher@yahoo.co.in>, mmusic@ietf.org
Date: Monday, 6 July, 2009, 10:34 AM

Hi Alam,

1/ no change in the sdp.

2/ The decision is made by player. If player uses the same session id in = the second SETUP), server will think of it as aggregated control. = Therefore, player should not send session id even in the second = SETUP.

In fact, 2326 has some ambiguity for this, therefore, you can read also = 2326bis draft.

Regards,

Jaehwan

From:= mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Mohammad Alam
Sent: Monday, July 06, 2009 1:38 PM
To: mmusic@ietf.org
Subject: [MMUSIC] Non - Aggregation

I am implementing RTSP = server in my application. I want to support non = -

aggregation in my server. There is non-aggregation example in sec 14.1

of RFC 2326. I want to implement the same. (eg. for 2 media. = there

should be 2 SETUP, 2 PLAY and 2 TEARDOWN with different session = IDs)

1) I want to know what = are the changes to be made in sdp.

2) How can I have = different session IDs for different media.

alam

See the Web's breaking stories, chosen by people like you. Check out Yahoo! = Buzz.

Yahoo! recommends that you upgrade to the new and safer Internet Explorer = 8.

------_=_NextPart_002_01C9FE0B.ACB51A19-- ------_=_NextPart_001_01C9FE0B.ACB51A19 Content-Type: text/plain; name="non-aggregate control example.txt" Content-Transfer-Encoding: base64 Content-Description: non-aggregate control example.txt Content-Disposition: attachment; filename="non-aggregate control example.txt" REVTQ1JJQkUgcnRzcDovLzE5Mi4xNi4xMTEuMzMvVklESS9hYWEuazNnIFJUU1AvMS4wDQpDU2Vx OiAxDQpBY2NlcHQ6IGFwcGxpY2F0aW9uL3NkcCANCkFjY2VwdC1MYW5ndWFnZTogZW4tVVMgDQpV c2VyLUFnZW50OiBWSURJODAwDQoNClJUU1AvMS4wIDIwMCBPSw0KQ1NlcTogMQ0KTGFzdC1Nb2Rp ZmllZDogVHVlLCAwNCBNYXIgMjAwMyAwNzoyMjowNSBHTVQgDQpDYWNoZS1Db250cm9sOiBtdXN0 LXJldmFsaWRhdGUgDQpEYXRlOiBGcmksIDkgTWF5IDIwMDMgMDU6NTc6MDEgR01UIA0KRXhwaXJl czogRnJpLCAyMyBKdW4gMjAwMyAwNTo1NzowMSANCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24v c2RwDQpDb250ZW50LUJhc2U6IHJ0c3A6Ly8xOTIuMTYuMTExLjMzL1ZJREkvYWFhLmszZw0KQ29u dGVudC1MYW5ndWFnZTogZW4tVVMgDQpDb250ZW50LUxlbmd0aDogNzMyIA0KU2VydmVyOiBWSURJ X1ZPRC8xLjANCg0Kdj0wIA0Kbz0tIDI2OTk0NzA0ODkgMTA1MTI0NTYzOSBJTiBJUDQgMTkyLjE2 LjExMS4zMyANCnM9VklESS8xDQp1PXd3dy5teXRlbGVjb20uY28ua3INCmU9c2VydmljZUBteXRl bGVjb20uY28ua3IgDQpjPUlOIElQNCAwLjAuMC4wIA0KdD0wIDAgDQphPWNvbnRyb2w6IHJ0c3A6 Ly8xOTIuMTYuMTExLjMzL1ZJREkvYWFhLmszZw0KYT1yYW5nZTpucHQ9MC4wMDAwMDAtNDYuNDAw MDAwICAgICANCm09YXVkaW8gMCBSVFAvQVZQIDExMCAgICAgDQpiPUFTOjE3ICAgICANCmE9cmFu Z2U6bnB0PTAuMDAwMDAwLTQ2LjI1NDAwMCAgICAgDQphPXJ0cG1hcDoxMTAgTVA0QS1MQVRNLzIy MDUwLzEgICAgIA0KYT1jb250cm9sOnRyYWNrSUQ9MzEgICAgIA0KYT1mbXRwOjExMCBwcm9maWxl LWxldmVsLWlkPTE1O29iamVjdD0yO2NwcmVzZW50PTA7Y29uZmlnPTQzMDAyNzEwM0ZDMA0KbT12 aWRlbyAwIFJUUC9BVlAgOTcgICAgIA0KYj1BUzozMg0KYT1yYW5nZTpucHQ9MC4wMDAwMDAtNDYu NDAwMDAwIA0KYT1YLURpc2FsbG93cmFuZG9tYWNjZXNzDQphPXJ0cG1hcDo5NyBNUDRWLUVTLzUg DQphPWNvbnRyb2w6dHJhY2tJRD0yMSANCmE9Zm10cDo5NyBwcm9maWxlLWxldmVsLWlkPTg7Y29u ZmlnPTAwMDAwMUIwMDgwMDAwMDFCMjUzNDU1MjRGNEQ0NTIwNTQ0NTQzDQo0ODRFNEY0QzRGNDc1 OTIwNTIyNjQ0MjA0MzQ1NEU1NDQ1NTIyMDRENTU0QzU0NDk0RDQ1NDQ0OTQxMjA0QzQxDQo0MjJF MDAwMDAxQjUwOTAwMDAwMTAwMDAwMDAxMjAwMDg0NDAwMTczMDU4NDEyMTQ0Mw0KDQpTRVRVUCBy dHNwOi8vMTkyLjE2LjExMS4zMy9WSURJL2FhYS5rM2cvdHJhY2tJRD0yMSBSVFNQLzEuMA0KQ1Nl cTogMiBUcmFuc3BvcnQ6IFJUUC9BVlA7dW5pY2FzdDtjbGllbnRfcG9ydD0xMzEwMC0xMzEwMSAN CkJsb2Nrc2l6ZTogMTQ2MA0KVXNlci1BZ2VudDogVklESTgwMC8xLjAgDQoNClJUU1AvMS4wIDIw MCBPSw0KQ1NlcTogMiANCkxhc3QtTW9kaWZpZWQ6IFR1ZSwgMDQgTWFyIDIwMDMgMDc6MjI6MDUg R01UIA0KQ2FjaGUtQ29udHJvbDogbXVzdC1yZXZhbGlkYXRlIA0KRGF0ZTogRnJpLCAyMyBNYXkg MjAwMyAwNTo1NzowMyBHTVQgDQpFeHBpcmVzOiBGcmksIDIzIEp1biAyMDAzIDA1OjU3OjAzIEdN VCANClNlc3Npb246IDI1NDU4MjIwMTEgDQpUcmFuc3BvcnQ6IFJUUC9BVlA7dW5pY2FzdDtjbGll bnRfcG9ydD0xMzEwMC0xMzEwMTtzZXJ2ZXJfcG9ydD0xMjAwMC0xMjAwMTtzb3VyY2U9MTkyLjE2 LjExMS4zMztkZXN0aW5hdGlvbj0xMC42MC4yNTMuMzE7c3NyYz03OTBhMDgyYyBTZXJ2ZXI6IFZJ RElfVk9ELzEuMCANCg0KU0VUVVAgcnRzcDovLzE5Mi4xNi4xMTEuMzMvVklESS9hYWEuazNnL3Ry YWNrSUQ9MzEgUlRTUC8xLjANCkNTZXE6IDMNClRyYW5zcG9ydDogUlRQL0FWUDt1bmljYXN0O2Ns aWVudF9wb3J0PTEzMTAyLTEzMTAzDQpCbG9ja3NpemU6IDE0NjANClVzZXItQWdlbnQ6IFZJREk4 MDAvMS4wIA0KDQpSVFNQLzEuMCAyMDAgT0sNCkNTZXE6IDMgICAgICAgIA0KTGFzdC1Nb2RpZmll ZDogVHVlLCAwNCBNYXIgMjAwMyAwNzoyMjowNSBHTVQgDQpDYWNoZS1Db250cm9sOiBtdXN0LXJl dmFsaWRhdGUgDQpEYXRlOiBGcmksIDIzIE1heSAyMDAzIDA1OjU3OjA0IEdNVCANCkV4cGlyZXM6 IEZyaSwgMjMgSnVuIDIwMDMgMDU6NTc6MDQgR01UIA0KU2Vzc2lvbjogMjA2MDc0MzQxNSANClRy YW5zcG9ydDogUlRQL0FWUDt1bmljYXN0O2NsaWVudF9wb3J0PTEzMTAyLTEzMTAzO3NlcnZlcl9w b3J0PTEyMDAyLTEyMDAzO3NvdXJjZT0xOTIuMTYuMTExLjMzO2Rlc3RpbmF0aW9uPTEwLjYwLjI1 My4zMTtzc3JjPWFlOWYzNzRkIA0KDQpQTEFZIHJ0c3A6Ly8xOTIuMTYuMTExLjMzL1ZJREkvYWFh LmszZyBSVFNQLzEuMA0KQ1NlcTogNCANClNlc3Npb246IDI1NDU4MjIwNjINClVzZXItQWdlbnQ6 IFZJREk4MDAvMS4wIA0KDQpSVFNQLzEuMCAyMDAgT0sNCkNTZXE6IDQNCkxhc3QtTW9kaWZpZWQ6 IFR1ZSwgMDQgTWFyIDIwMDMgMDc6MjI6MDUgR01UIA0KQ2FjaGUtQ29udHJvbDogbXVzdC1yZXZh bGlkYXRlIA0KRGF0ZTogRnJpLCAyMyBNYXkgMjAwMyAwNTo1NzowNSBHTVQgDQpFeHBpcmVzOiBG cmksIDIzIEp1biAyMDAzIDA1OjU3OjA1IEdNVCANClNlc3Npb246IDI1NDU4MjIwNjINClNlcnZl cjogVklESV9WT0QvMS4wDQpSYW5nZTogbnB0PTAuMDAwMC0NClJUUC1JbmZvOiAgdXJsPXJ0c3A6 Ly8xOTIuMTYuMTExLjMzL1ZJREkvYWFhLmszZy90cmFja0lEPTIxO3NlcT0xO3J0cHRpbWU9MA0K DQpQTEFZIHJ0c3A6Ly8xOTIuMTYuMTExLjMzL1ZJREkvYWFhLmszZyBSVFNQLzEuMA0KQ1NlcTog NSANClNlc3Npb246IDIwNjA3NDM0MTUNClVzZXItQWdlbnQ6IFZJREk4MDAvMS4wIA0KDQpSVFNQ LzEuMCAyMDAgT0sNCkNTZXE6IDUNCkxhc3QtTW9kaWZpZWQ6IFR1ZSwgMDQgTWFyIDIwMDMgMDc6 MjI6MDUgR01UIA0KQ2FjaGUtQ29udHJvbDogbXVzdC1yZXZhbGlkYXRlIA0KRGF0ZTogRnJpLCAy MyBNYXkgMjAwMyAwNTo1NzowNyBHTVQgDQpFeHBpcmVzOiBGcmksIDIzIEp1biAyMDAzIDA1OjU3 OjA3IEdNVCANClNlc3Npb246IDIwNjA3NDM0MTUNClNlcnZlcjogVklESV9WT0QvMS4wDQpSYW5n ZTogbnB0PTAuMDAwMC0NClJUUC1JbmZvOiAgICB1cmw9cnRzcDovLzE5Mi4xNi4xMTEuMzMvVklE SS9hYWEuazNnL3RyYWNrSUQ9MzE7c2VxPTE7cnRwdGltZT0wDQogICAgIA0KDQpQQVVTRSBydHNw Oi8vIDE5Mi4xNi4xMTEuMzMvVklESS9hYWEuazNnL3RyYWNrSUQ9MjEgUlRTUC8xLjANCkNTZXE6 IDYgDQpTZXNzaW9uOiAyNTQ1ODIyMDYyDQpVc2VyLUFnZW50OiBWSURJODAwLzEuMCANCg0KDQpS VFNQLzEuMCAyMDAgT0sNCkNTZXE6IDYNCkxhc3QtTW9kaWZpZWQ6IFR1ZSwgMDQgTWFyIDIwMDMg MDc6MjI6MDUgR01UIA0KQ2FjaGUtQ29udHJvbDogbXVzdC1yZXZhbGlkYXRlIA0KRGF0ZTogRnJp LCAyMyBNYXkgMjAwMyAwNTo1NzowOCBHTVQgDQpFeHBpcmVzOiBGcmksIDIzIEp1biAyMDAzIDA1 OjU3OjA4IEdNVCANClNlc3Npb246IDI1NDU4MjIwNjINClJhbmdlOm5wdD0yMy43OTgtDQpTZXJ2 ZXI6IFZJRElfVk9ELzEuMA0KDQoNClRFQVJET1dOIHJ0c3A6Ly8xOTIuMTYuMTExLjMzL1ZJREkv YWFhLmszZyBSVFNQLzEuMA0KQ1NlcTogNyANClNlc3Npb246IDI1NDU4MjIwNjINClVzZXItQWdl bnQ6IFZJREk4MDAvMS4wIA0KDQpSVFNQLzEuMCAyMDAgT0sNCkNTZXE6IDcNCkxhc3QtTW9kaWZp ZWQ6IFR1ZSwgMDQgTWFyIDIwMDMgMDc6MjI6MDUgR01UIA0KQ2FjaGUtQ29udHJvbDogbXVzdC1y ZXZhbGlkYXRlIA0KRGF0ZTogRnJpLCAyMyBNYXkgMjAwMyAwNTo1Nzo0NCBHTVQgDQpFeHBpcmVz OiBGcmksIDIzIEp1biAyMDAzIDA1OjU3OjQ0IEdNVCANClNlcnZlcjogVklESV9WT0QvMS4wDQoN ClRFQVJET1dOIHJ0c3A6Ly8xOTIuMTYuMTExLjMzL1ZJREkvYWFhLmszZyBSVFNQLzEuMA0KQ1Nl cTogOCBTZXNzaW9uOiAyMDYwNzQzNDE1DQpVc2VyLUFnZW50OiBWSURJODAwLzEuMCANCg0KUlRT UC8xLjAgMjAwIE9LDQpDU2VxOiA4DQpMYXN0LU1vZGlmaWVkOiBUdWUsIDA0IE1hciAyMDAzIDA3 OjIyOjA1IEdNVCANCkNhY2hlLUNvbnRyb2w6IG11c3QtcmV2YWxpZGF0ZSANCkRhdGU6IEZyaSwg MjMgTWF5IDIwMDMgMDU6NTc6NDUgR01UIA0KRXhwaXJlczogRnJpLCAyMyBKdW4gMjAwMyAwNTo1 Nzo0NSBHTVQgDQpTZXJ2ZXI6IFZJRElfVk9ELzEuMA0K ------_=_NextPart_001_01C9FE0B.ACB51A19-- From Simo.Veikkolainen@nokia.com Mon Jul 6 00:32:49 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377F53A6CC4 for ; Mon, 6 Jul 2009 00:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XUzNsegGg6p for ; Mon, 6 Jul 2009 00:32:48 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id DCD6D3A6CB8 for ; Mon, 6 Jul 2009 00:32:47 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n667WsYj009191; Mon, 6 Jul 2009 02:33:11 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 10:32:18 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 10:32:13 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 6 Jul 2009 09:32:12 +0200 From: To: , Date: Mon, 6 Jul 2009 09:32:11 +0200 Thread-Topic: [MMUSIC] FW: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt Thread-Index: AcnvvNGDfqgSPD1LTIy0U6kWSQ3DnwALblwgAT0mzbACSyj8EA== Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D0021057BC@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0021057BC@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jul 2009 07:32:13.0219 (UTC) FILETIME=[E1256730:01C9FE0B] X-Nokia-AV: Clean Subject: Re: [MMUSIC] FW: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 07:32:49 -0000 =20 >-----Original Message----- >From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 >Sent: 24 June, 2009 18:21 >To: Veikkolainen Simo (Nokia-D/Helsinki); mmusic@ietf.org >Subject: RE: [MMUSIC] FW: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt > >Simo, > >I think the Security Considerations section should remind=20 >people that it is not possible to secure the media (SRTP is=20 >not available). I can add a comment to that effect in the next version. Thanks Simo > >John=20 > >> -----Original Message----- >> From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 >> Simo.Veikkolainen@nokia.com >> Sent: 18 June 2009 09:00 >> To: mmusic@ietf.org >> Subject: [MMUSIC] FW: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt >>=20 >> We submitted a new version of draft-ietf-mmusic-sdp-cs which=20 >adds some=20 >> text to address John's comments on how to behave when no correlation=20 >> information is received in the CS call setup, and on security=20 >> considerations. >>=20 >> Further comments are very welcome! >>=20 >> Regards, >> Simo >>=20 >> >-----Original Message----- >> >From: i-d-announce-bounces@ietf.org >> >[mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext=20 >> >Internet-Drafts@ietf.org >> >Sent: 18 June, 2009 05:30 >> >To: i-d-announce@ietf.org >> >Cc: mmusic@ietf.org >> >Subject: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt >> > >> >A New Internet-Draft is available from the on-line Internet-Drafts=20 >> >directories. >> >This draft is a work item of the Multiparty Multimedia Session=20 >> >Control Working Group of the IETF. >> > >> > Title : Session Description Protocol (SDP)=20 >> >Extension For Setting Up Audio Media Streams Over Circuit-Switched=20 >> >Bearers In The Public Switched Telephone Network (PSTN) >> > Author(s) : M. Garcia-Martin, S. Veikkolainen >> > Filename : draft-ietf-mmusic-sdp-cs-01.txt >> > Pages : 25 >> > Date : 2009-6-17 >> >=09 >> >This memo describes use cases, requirements, and protocol extensions >> > for using the Session Description Protocol (SDP) >> Offer/Answer model >> > for establishing audio media stream over circuit-switched >> bearers in >> > the Public Switched Telephone Network (PSTN). >> > >> >A URL for this Internet-Draft is: >> >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-01.txt >> > >> >Internet-Drafts are also available by anonymous FTP at: >> >ftp://ftp.ietf.org/internet-drafts/ >> > >> >Below is the data which will enable a MIME compliant mail reader=20 >> >implementation to automatically retrieve the ASCII version of the=20 >> >Internet-Draft. >> > >>=20 >= From Sebastian.Kiesel@nw.neclab.eu Mon Jul 6 02:36:16 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFAE3A6AC0 for ; Mon, 6 Jul 2009 02:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPHz78sLCOYC for ; Mon, 6 Jul 2009 02:36:15 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 7FD9C3A6BE0 for ; Mon, 6 Jul 2009 02:36:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A138F2C020493 for ; Mon, 6 Jul 2009 11:35:35 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWzh48tdVmFy for ; Mon, 6 Jul 2009 11:35:35 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 834A02C0004E5 for ; Mon, 6 Jul 2009 11:35:30 +0200 (CEST) Received: from foo.nw.neclab.eu ([10.1.6.240]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 11:35:30 +0200 Received: by foo.nw.neclab.eu (sSMTP sendmail emulation); Mon, 06 Jul 2009 11:35:28 +0200 Date: Mon, 6 Jul 2009 11:35:28 +0200 From: Sebastian Kiesel To: mmusic@ietf.org Message-ID: <20090706093528.GB23176@foo.nw.neclab.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 06 Jul 2009 09:35:30.0530 (UTC) FILETIME=[1A497C20:01C9FE1D] Subject: [MMUSIC] fwd: New Version Notification for draft-kiesel-mmusic-firewall-sip-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 09:36:16 -0000 Dear MMUSIC WG members, (announcement sent to NSIS and MMUSIC lists) The IETF has worked on several architectures and protocols for dynamic control of firewalls, namely MIDCOM and NSIS. This draft examines how they work together with SIP, especially if something goes wrong. The conclusion is basically that the normal SIP mechanisms are not sufficient to handle all error conditions in a reasonable way, and therefore a new SIP precondition should be standardized. Feedback and discussion are welcome. Thanks, Sebastian ----- Forwarded message from IETF I-D Submission Tool ----- From: IETF I-D Submission Tool To: sebastian.kiesel@nw.neclab.eu Subject: New Version Notification for draft-kiesel-mmusic-firewall-sip-00 Date: Mon, 6 Jul 2009 01:26:17 -0700 (PDT) A new version of I-D, draft-kiesel-mmusic-firewall-sip-00.txt has been successfuly submitted by Sebastian Kiesel and posted to the IETF repository. Filename: draft-kiesel-mmusic-firewall-sip Revision: 00 Title: Interaction of dynamic firewall control protocols and SIP Creation_date: 2009-07-06 WG ID: Independent Submission Number_of_pages: 21 Abstract: SIP-based multimedia applications dynamically negotiate parameters for the related media streams, such as UDP port numbers. Therefore, firewalls that want to inspect these streams have to interact with the session signaling. Several architectures and protocols have been developed for the dynamic control of firewalls on the media path, e. g., MIDCOM, SIMCO, and the NSIS NAT/FW NSLP. This document investigates problems with the interaction of standard SIP (as of RFC 3261) and these firewall control protocols, especially with respect to error handling. It will be pointed out how existing SIP extensions can be used for improving the interaction, and which additional mechanisms need to be specified. While the actual specification of such additional mechanisms is out of the scope of this document, it solicits feedback and discussion. The IETF Secretariat. ----- End forwarded message ----- -- Sebastian Kiesel mailto:sebastian.kiesel@nw.neclab.eu Network Research Division tel:+49-6221-4342-232 fax:+49-6221-4342-155 NEC Laboratories Europe Kurfuerstenanlage 36, 69115 Heidelberg, Germany -- NEC Europe Limited Registered in England 2832014 Registered Office NEC House, 1 Victoria Road, London W3 6BL From mohamed.boucadair@orange-ftgroup.com Mon Jul 6 04:45:48 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7DA28C272; Mon, 6 Jul 2009 04:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT7P2w8RymYy; Mon, 6 Jul 2009 04:45:47 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id E83F43A6A1C; Mon, 6 Jul 2009 04:45:46 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 13:44:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9FE2F.0E1FF4E3" Date: Mon, 6 Jul 2009 13:44:00 +0200 Message-ID: <08BA2C59E081884DB2AAE4A0BE9D6DC1368EAB@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-boucadair-mmusic-ccap-00.txt Thread-Index: Acn+Ht6b7BCUGPf8Sx21Vd9MnFbb/wAD2+LA From: To: , X-OriginalArrivalTime: 06 Jul 2009 11:44:01.0680 (UTC) FILETIME=[0E7D9900:01C9FE2F] Subject: [MMUSIC] TR: I-D Action:draft-boucadair-mmusic-ccap-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 11:45:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FE2F.0E1FF4E3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Dear all, This draft has been submitted.=20 Comments and suggestions are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org Envoy=E9 : lundi 6 juillet 2009 11:45 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-mmusic-ccap-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Session Description Protocol (SDP) Connectivity = Capability (CCAP) Attribute Author(s) : M. Boucadair, H. Kaplan Filename : draft-boucadair-mmusic-ccap-00.txt Pages : 14 Date : 2009-07-06 This memo proposes a mechanism which allows to carry multiple IP = addresses, of different address families (e.g., IPv4, IPv6), in the same = SDP offer/answer. The proposed attribute solves the backward = compatibility problem which plagued ANAT, due to its syntax. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-mmusic-ccap-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. ------_=_NextPart_001_01C9FE2F.0E1FF4E3 Content-Type: application/octet-stream; name="draft-boucadair-mmusic-ccap-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-boucadair-mmusic-ccap-00.URL Content-Disposition: attachment; filename="draft-boucadair-mmusic-ccap-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItbW11c2ljLWNjYXAtMDAudHh0DQo= ------_=_NextPart_001_01C9FE2F.0E1FF4E3-- From abegen@cisco.com Mon Jul 6 06:54:56 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277913A6C57 for ; Mon, 6 Jul 2009 06:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVbv1XXplPmC for ; Mon, 6 Jul 2009 06:54:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3886D28C266 for ; Mon, 6 Jul 2009 06:54:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,356,1243814400"; d="scan'208";a="338376546" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 06 Jul 2009 13:53:06 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n66Dr6s7011298; Mon, 6 Jul 2009 06:53:06 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n66Dr6Vp005802; Mon, 6 Jul 2009 13:53:06 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 06:53:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jul 2009 06:51:36 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5409A72B69@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC request for draft-ietf-mmusic-rfc4756bis-02 Thread-Index: Acn+QOFcRbxYQnz3RVqRXKqoL4ZpUw== From: "Ali C. Begen (abegen)" To: , "Joerg Ott" , "Jean-Francois Mule" X-OriginalArrivalTime: 06 Jul 2009 13:53:06.0374 (UTC) FILETIME=[16B01E60:01C9FE41] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=379; t=1246888386; x=1247752386; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20WGLC=20request=20for=20draft-ietf-mmusic-rfc475 6bis-02 |Sender:=20; bh=UWpRaEfnL2mRRRlwbBYE1Yf7qH6dz2xTXEnrwS9ngbA=; b=FEjkoqfPkRZIVB4Vddkib4t5sXKMN7Q3JjY0pVXt5b7U2CesBBQolQopYP YYmBph5H07gZkKwaLqCS+cJaQV3z3W1EDMxMwef5EZcvsiLO31KwbiwfPRuO eZYsnZ4n4d; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [MMUSIC] WGLC request for draft-ietf-mmusic-rfc4756bis-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 13:54:56 -0000 Hello, I would like to request WGLC for the following draft: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-02.txt This draft is dependant on the source-specific media attributes in SDP, = which recently became an RFC (5576) and the current version addressed = all the outstanding issues. This draft is needed by the FECframe WG. Thanks. -acbegen From jf.mule@cablelabs.com Mon Jul 6 07:46:08 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2DB28C276 for ; Mon, 6 Jul 2009 07:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ad1Ll7eXq58x for ; Mon, 6 Jul 2009 07:46:07 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 550753A6B80 for ; Mon, 6 Jul 2009 07:46:07 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n66Edpa6011595; Mon, 6 Jul 2009 08:39:51 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 6 Jul 2009 08:39:50 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jul 2009 08:38:08 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601EED999@srvxchg3.cablelabs.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409A72B69@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC request for draft-ietf-mmusic-rfc4756bis-02 Thread-Index: Acn+QOFcRbxYQnz3RVqRXKqoL4ZpUwABfiBA References: <04CAD96D4C5A3D48B1919248A8FE0D5409A72B69@xmb-sjc-215.amer.cisco.com> From: "Jean-Francois Mule" To: "Ali C. Begen (abegen)" , , "Joerg Ott" X-Approved: ondar Subject: Re: [MMUSIC] WGLC request for draft-ietf-mmusic-rfc4756bis-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 14:46:08 -0000 Ali, Ok, noted, will send a separate WGLC announcement.=20 We have at least 3 drafts that need to go through WGLC but given the FECframe dependency, we'll expedite this one. Can you ping one or two folks involved in fecframe that would be willing to formally review the doc during WGLC? Jean-Francois =20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Monday, July 06, 2009 7:52 AM > To: mmusic@ietf.org; Joerg Ott; Jean-Francois Mule > Subject: WGLC request for draft-ietf-mmusic-rfc4756bis-02 >=20 > Hello, >=20 > I would like to request WGLC for the following draft: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis- > 02.txt >=20 > This draft is dependant on the source-specific media attributes in > SDP, which recently became an RFC (5576) and the current version > addressed all the outstanding issues. This draft is needed by the > FECframe WG. >=20 > Thanks. > -acbegen From HKaplan@acmepacket.com Mon Jul 6 22:07:52 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651283A6DF4; Mon, 6 Jul 2009 22:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1JX9gbFFEt9; Mon, 6 Jul 2009 22:07:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E493D3A6A57; Mon, 6 Jul 2009 22:07:49 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 7 Jul 2009 01:06:24 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 7 Jul 2009 01:06:22 -0400 From: Hadriel Kaplan To: "mmusic@ietf.org" Date: Tue, 7 Jul 2009 01:06:16 -0400 Thread-Topic: A replacement for ANAT Thread-Index: Acn+Ht6b7BCUGPf8Sx21Vd9MnFbb/wAD2+LAACQixBA= Message-ID: References: <08BA2C59E081884DB2AAE4A0BE9D6DC1368EAB@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <08BA2C59E081884DB2AAE4A0BE9D6DC1368EAB@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipping@ietf.org" , "dispatch@ietf.org" Subject: [MMUSIC] A replacement for ANAT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 05:07:52 -0000 BTW, this draft was submitted in response to the discussion around the need= for an ANAT-type model that was backwards-compatible, and for a v4/v6 stac= k option-tag indicator, which was a topic of discussion on SIPPING back in = February and March. That thread started with: http://www.ietf.org/mail-archive/web/sipping/current/msg16718.html -hadriel p.s. sorry about the cross-posting, but SIPPING is effectively closed (righ= t?) so it's hard to know where to post such notices which are tightly relat= ed to SIP. > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of mohamed.boucadair@orange-ftgroup.com > Sent: Monday, July 06, 2009 7:44 AM >=20 > Dear all, >=20 > This draft has been submitted. >=20 > Comments and suggestions are more than welcome. >=20 >=20 > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > De la part de Internet-Drafts@ietf.org > Envoy=E9 : lundi 6 juillet 2009 11:45 > =C0 : i-d-announce@ietf.org > Objet : I-D Action:draft-boucadair-mmusic-ccap-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : Session Description Protocol (SDP) Connectivity > Capability (CCAP) Attribute > Author(s) : M. Boucadair, H. Kaplan > Filename : draft-boucadair-mmusic-ccap-00.txt > Pages : 14 > Date : 2009-07-06 >=20 > This memo proposes a mechanism which allows to carry multiple IP > addresses, of different address families (e.g., IPv4, IPv6), in the same > SDP offer/answer. The proposed attribute solves the backward > compatibility problem which plagued ANAT, due to its syntax. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-boucadair-mmusic-ccap-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From Simo.Veikkolainen@nokia.com Tue Jul 7 04:23:07 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CB43A6E59 for ; Tue, 7 Jul 2009 04:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+S0cfCdptnG for ; Tue, 7 Jul 2009 04:23:06 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C547C3A6899 for ; Tue, 7 Jul 2009 04:23:05 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n67BMUeD019700; Tue, 7 Jul 2009 14:22:48 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 14:22:50 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 14:22:45 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 7 Jul 2009 13:22:44 +0200 From: To: , Date: Tue, 7 Jul 2009 13:22:44 +0200 Thread-Topic: A replacement for ANAT Thread-Index: Acn+Ht6b7BCUGPf8Sx21Vd9MnFbb/wAD2+LAACQixBAADQRQgA== Message-ID: References: <08BA2C59E081884DB2AAE4A0BE9D6DC1368EAB@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jul 2009 11:22:45.0811 (UTC) FILETIME=[406D3030:01C9FEF5] X-Nokia-AV: Clean Subject: Re: [MMUSIC] A replacement for ANAT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 11:23:07 -0000 [Dropping dispatch and sipping.] >-----Original Message----- >From: sipping-bounces@ietf.org=20 >[mailto:sipping-bounces@ietf.org] On Behalf Of ext Hadriel Kaplan >Sent: 07 July, 2009 08:06 >To: mmusic@ietf.org >Cc: sipping@ietf.org; dispatch@ietf.org >Subject: [Sipping] A replacement for ANAT > > >BTW, this draft was submitted in response to the discussion=20 >around the need for an ANAT-type model that was=20 >backwards-compatible, and for a v4/v6 stack option-tag=20 >indicator, which was a topic of discussion on SIPPING back in=20 >February and March. That thread started with: >http://www.ietf.org/mail-archive/web/sipping/current/msg16718.html Sorry for missing the discussion on SIPPING. Have you taken a look at http:= //tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-00, which also defin= es a ccap attribute? The draft has exprired, but we are planning to submit = an updated version soon (with minimal changes). Regards, Simo > >-hadriel >p.s. sorry about the cross-posting, but SIPPING is effectively=20 >closed (right?) so it's hard to know where to post such=20 >notices which are tightly related to SIP. > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 >> Behalf Of mohamed.boucadair@orange-ftgroup.com >> Sent: Monday, July 06, 2009 7:44 AM >>=20 >> Dear all, >>=20 >> This draft has been submitted. >>=20 >> Comments and suggestions are more than welcome. >>=20 >>=20 >> Cheers, >> Med >>=20 >>=20 >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org=20 >> [mailto:i-d-announce-bounces@ietf.org] >> De la part de Internet-Drafts@ietf.org Envoy=E9 : lundi 6 juillet 2009=20 >> 11:45 =C0 : i-d-announce@ietf.org Objet : I-D=20 >> Action:draft-boucadair-mmusic-ccap-00.txt >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >>=20 >> Title : Session Description Protocol (SDP)=20 >Connectivity >> Capability (CCAP) Attribute >> Author(s) : M. Boucadair, H. Kaplan >> Filename : draft-boucadair-mmusic-ccap-00.txt >> Pages : 14 >> Date : 2009-07-06 >>=20 >> This memo proposes a mechanism which allows to carry multiple IP=20 >> addresses, of different address families (e.g., IPv4, IPv6), in the=20 >> same SDP offer/answer. The proposed attribute solves the backward=20 >> compatibility problem which plagued ANAT, due to its syntax. >>=20 >> A URL for this Internet-Draft is: >>=20 >http://www.ietf.org/internet-drafts/draft-boucadair-mmusic-ccap-00.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft. >_______________________________________________ >Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sip@ietf.org for new developments of core SIP >= From mohamed.boucadair@orange-ftgroup.com Tue Jul 7 05:51:35 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE553A6E5C for ; Tue, 7 Jul 2009 05:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeM8RjzL5E9c for ; Tue, 7 Jul 2009 05:51:34 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 52E1F3A6E5A for ; Tue, 7 Jul 2009 05:51:34 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 14:50:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jul 2009 14:50:40 +0200 Message-ID: <08BA2C59E081884DB2AAE4A0BE9D6DC1369319@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] A replacement for ANAT Thread-Index: Acn+Ht6b7BCUGPf8Sx21Vd9MnFbb/wAD2+LAACQixBAADQRQgAADU37A References: <08BA2C59E081884DB2AAE4A0BE9D6DC1368EAB@ftrdmel0.rd.francetelecom.fr>

From: To: , , X-OriginalArrivalTime: 07 Jul 2009 12:50:42.0113 (UTC) FILETIME=[8958FB10:01C9FF01] Subject: Re: [MMUSIC] A replacement for ANAT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 12:51:35 -0000 =20 Dear Simo, Thank you for this information. I'm not aware about this draft. We need to check together if we have the same definition and usage of = the ccap attribute. Cheers, Med -----Message d'origine----- De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la part = de Simo.Veikkolainen@nokia.com Envoy=E9 : mardi 7 juillet 2009 13:23 =C0 : HKaplan@acmepacket.com; mmusic@ietf.org Objet : Re: [MMUSIC] A replacement for ANAT [Dropping dispatch and sipping.] >-----Original Message----- >From: sipping-bounces@ietf.org >[mailto:sipping-bounces@ietf.org] On Behalf Of ext Hadriel Kaplan >Sent: 07 July, 2009 08:06 >To: mmusic@ietf.org >Cc: sipping@ietf.org; dispatch@ietf.org >Subject: [Sipping] A replacement for ANAT > > >BTW, this draft was submitted in response to the discussion around the=20 >need for an ANAT-type model that was backwards-compatible, and for a=20 >v4/v6 stack option-tag indicator, which was a topic of discussion on=20 >SIPPING back in February and March. That thread started with: >http://www.ietf.org/mail-archive/web/sipping/current/msg16718.html Sorry for missing the discussion on SIPPING. Have you taken a look at = http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-00, which = also defines a ccap attribute? The draft has exprired, but we are = planning to submit an updated version soon (with minimal changes). Regards, Simo > >-hadriel >p.s. sorry about the cross-posting, but SIPPING is effectively closed=20 >(right?) so it's hard to know where to post such notices which are=20 >tightly related to SIP. > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 >> Behalf Of mohamed.boucadair@orange-ftgroup.com >> Sent: Monday, July 06, 2009 7:44 AM >>=20 >> Dear all, >>=20 >> This draft has been submitted. >>=20 >> Comments and suggestions are more than welcome. >>=20 >>=20 >> Cheers, >> Med >>=20 >>=20 >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] >> De la part de Internet-Drafts@ietf.org Envoy=E9 : lundi 6 juillet = 2009 >> 11:45 =C0 : i-d-announce@ietf.org Objet : I-D=20 >> Action:draft-boucadair-mmusic-ccap-00.txt >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >>=20 >> Title : Session Description Protocol (SDP)=20 >Connectivity >> Capability (CCAP) Attribute >> Author(s) : M. Boucadair, H. Kaplan >> Filename : draft-boucadair-mmusic-ccap-00.txt >> Pages : 14 >> Date : 2009-07-06 >>=20 >> This memo proposes a mechanism which allows to carry multiple IP=20 >> addresses, of different address families (e.g., IPv4, IPv6), in the=20 >> same SDP offer/answer. The proposed attribute solves the backward=20 >> compatibility problem which plagued ANAT, due to its syntax. >>=20 >> A URL for this Internet-Draft is: >>=20 >http://www.ietf.org/internet-drafts/draft-boucadair-mmusic-ccap-00.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft. >_______________________________________________ >Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP Use=20 >sip-implementors@cs.columbia.edu for questions on current sip Use=20 >sip@ietf.org for new developments of core SIP > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From rfc-editor@rfc-editor.org Tue Jul 7 16:09:16 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122513A6E59; Tue, 7 Jul 2009 16:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.799 X-Spam-Level: X-Spam-Status: No, score=-16.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTNv31eIBNxg; Tue, 7 Jul 2009 16:09:15 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 1D8863A6A99; Tue, 7 Jul 2009 16:09:15 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 69B7C2E750D; Tue, 7 Jul 2009 16:06:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090707230606.69B7C2E750D@bosco.isi.edu> Date: Tue, 7 Jul 2009 16:06:06 -0700 (PDT) Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 5583 on Signaling Media Decoding Dependency in the Session Description Protocol (SDP) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 23:09:16 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5583 Title: Signaling Media Decoding Dependency in the Session Description Protocol (SDP) Author: T. Schierl, S. Wenger Status: Standards Track Date: July 2009 Mailbox: ts@thomas-schierl.de, stewe@stewe.org Pages: 18 Characters: 40214 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-decoding-dependency-08.txt URL: http://www.rfc-editor.org/rfc/rfc5583.txt This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process. A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). [STANDARDS TRACK] This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From HKaplan@acmepacket.com Tue Jul 7 20:00:32 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93093A6A48 for ; Tue, 7 Jul 2009 20:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSiXHp6GAm94 for ; Tue, 7 Jul 2009 20:00:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C16B23A6955 for ; Tue, 7 Jul 2009 20:00:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 7 Jul 2009 23:00:57 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 7 Jul 2009 23:00:57 -0400 From: Hadriel Kaplan To: "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Date: Tue, 7 Jul 2009 23:00:57 -0400 Thread-Topic: A replacement for ANAT Thread-Index: Acn+Ht6b7BCUGPf8Sx21Vd9MnFbb/wAD2+LAACQixBAADQRQgAAgkgEA Message-ID: References: <08BA2C59E081884DB2AAE4A0BE9D6DC1368EAB@ftrdmel0.rd.francetelecom.fr>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] A replacement for ANAT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 03:00:32 -0000 > -----Original Message----- > From: Simo.Veikkolainen@nokia.com [mailto:Simo.Veikkolainen@nokia.com] > Sent: Tuesday, July 07, 2009 7:23 AM >=20 > Sorry for missing the discussion on SIPPING. Have you taken a look at > http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-00, which als= o > defines a ccap attribute? The draft has exprired, but we are planning to > submit an updated version soon (with minimal changes). Heh, that's funny - nope hadn't seen that draft before. =20 The concepts are obviously similar, though different in the following ways: 1) The boucadair draft does not to tie the ccap concept to sdp-cap-neg in a= ny way. Specifically, we did not want to make implementers have to support= sdp-cap-neg just to offer alternate addresses for v4/v6. Sdp-cap-neg is a= fairly complex mechanism for people who don't need it. 2) We assumed in the boucadair draft that a host could not necessarily use = the same UDP/TCP/etc. port numbers for the alternate address, since they're= different number spaces, so we include the port number in the ccap attribu= te. 3) Since we include the port number in the ccap in the boucadair draft, and= the port number is specific to the media line, we do not allow the ccap at= the session level - only the media level. 4) The boucadair draft is for the alternate address/port connection concept= only, and not for any other capabilities. This was done on purpose, becau= se the only goal was to have a workable replacement model for ANAT for v4/v= 6, so we wanted any claims of compliance to the draft to be for the specifi= c support of ccap. -hadriel From Simo.Veikkolainen@nokia.com Wed Jul 8 02:43:34 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921C23A6E87 for ; Wed, 8 Jul 2009 02:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTRGXyyirsWy for ; Wed, 8 Jul 2009 02:43:33 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B6B9E3A6A05 for ; Wed, 8 Jul 2009 02:43:33 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n689hOiY028756; Wed, 8 Jul 2009 04:43:28 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 12:43:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 12:43:15 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 8 Jul 2009 11:43:14 +0200 From: To: , Date: Wed, 8 Jul 2009 11:43:13 +0200 Thread-Topic: A replacement for ANAT Thread-Index: Acn+Ht6b7BCUGPf8Sx21Vd9MnFbb/wAD2+LAACQixBAADQRQgAAgkgEAAA5LAuA= Message-ID: References: <08BA2C59E081884DB2AAE4A0BE9D6DC1368EAB@ftrdmel0.rd.francetelecom.fr>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jul 2009 09:43:15.0624 (UTC) FILETIME=[8454B280:01C9FFB0] X-Nokia-AV: Clean Subject: Re: [MMUSIC] A replacement for ANAT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 09:43:34 -0000 =20 >-----Original Message----- >From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 >Sent: 08 July, 2009 06:01 >To: Veikkolainen Simo (Nokia-D/Helsinki); mmusic@ietf.org >Cc: mohamed.boucadair@orange-ftgroup.com >Subject: RE: A replacement for ANAT > > > >> -----Original Message----- >> From: Simo.Veikkolainen@nokia.com=20 >[mailto:Simo.Veikkolainen@nokia.com] >> Sent: Tuesday, July 07, 2009 7:23 AM >>=20 >> Sorry for missing the discussion on SIPPING. Have you taken=20 >a look at=20 >>=20 >http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-00, which=20 >> also defines a ccap attribute? The draft has exprired, but we are=20 >> planning to submit an updated version soon (with minimal changes). > >Heh, that's funny - nope hadn't seen that draft before. =20 > >The concepts are obviously similar, though different in the=20 >following ways: >1) The boucadair draft does not to tie the ccap concept to=20 >sdp-cap-neg in any way. Specifically, we did not want to make=20 >implementers have to support sdp-cap-neg just to offer=20 >alternate addresses for v4/v6. Sdp-cap-neg is a fairly=20 >complex mechanism for people who don't need it. > >2) We assumed in the boucadair draft that a host could not=20 >necessarily use the same UDP/TCP/etc. port numbers for the=20 >alternate address, since they're different number spaces, so=20 >we include the port number in the ccap attribute. > >3) Since we include the port number in the ccap in the=20 >boucadair draft, and the port number is specific to the media=20 >line, we do not allow the ccap at the session level - only the=20 >media level. > >4) The boucadair draft is for the alternate address/port=20 >connection concept only, and not for any other capabilities. =20 >This was done on purpose, because the only goal was to have a=20 >workable replacement model for ANAT for v4/v6, so we wanted=20 >any claims of compliance to the draft to be for the specific=20 >support of ccap. The ccap attribute as defined in the boucadair draft seems to borrow its sy= ntax from sdp cap-neg, but is otherwise totally independent; but I guess th= is was your intention. Actually, you probably could remove any references t= o sdp-cap-neg without losing any of the functionality you have described.=20 You could use the definitions in draft-garcia-mmusic-sdp-misc-cap for the a= ddress capability part, but you would still need the port number indicated = as a capability. This is not defined currently in any of the related drafts= (sdp-cap-neg, sdp-media-capabilities, sdp-misc-cap).=20 Simo >-hadriel >= From jf.mule@cablelabs.com Wed Jul 8 07:00:49 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EE3E3A6B69 for ; Wed, 8 Jul 2009 07:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.258 X-Spam-Level: X-Spam-Status: No, score=-0.258 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfejRE0MfnT2 for ; Wed, 8 Jul 2009 07:00:48 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id B07033A6B65 for ; Wed, 8 Jul 2009 07:00:48 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n68DxXHZ007451 for ; Wed, 8 Jul 2009 07:59:33 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 8 Jul 2009 07:59:33 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jul 2009 07:59:16 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601EEDAA0@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MMUSIC agenda for IETF#75 - call for additional agenda items Thread-Index: Acn/1Eg5Gzg8eotZSeKgf/0moAV17g== From: "Jean-Francois Mule" To: X-Approved: ondar Subject: [MMUSIC] MMUSIC agenda for IETF#75 - call for additional agenda items X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:00:49 -0000 Hi, We have received a couple of requests for agenda time during the MMUSIC WG meeting at IETF#75. Let Joerg and I know if you need time and how much. We will post our agenda on Friday 7/10. Thank you, Jean-Francois THURSDAY, July 30, 2009 0900-1130 Morning Session I Congresshall B INT l2vpn Layer 2 Virtual Private Networks WG Cabaret INT savi Source Address Validation Improvements WG Room 300 OPS capwap Control And Provisioning of Wireless Access Points WG Room 307 RAI mediactrl Media Server Control WG Congresshall C RAI mmusic Multiparty Multimedia Session Control WG Congresshall A RTG sidr Secure Inter-Domain Routing WG Large Stage SEC keyprov Provisioning of Symmetric Keys WG Small Stage TSV nfsv4 Network File System Version 4 WG From jaehwan@vidiator.com Thu Jul 9 02:34:47 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3447E3A6A5E; Thu, 9 Jul 2009 02:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNZZTbtp8Z84; Thu, 9 Jul 2009 02:34:46 -0700 (PDT) Received: from kor1corpmail01.mediator.com (vkimail.vidiator.com [211.189.53.2]) by core3.amsl.com (Postfix) with ESMTP id 53BC73A67B3; Thu, 9 Jul 2009 02:34:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 18:35:10 +0900 Message-ID: In-Reply-To: <20090619133001.9387C3A69C5@core3.amsl.com> References: <20090619133001.9387C3A69C5@core3.amsl.com> From: "Jaehwan Kim" To: , Cc: i-d-announce@ietf.org Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 09:34:47 -0000 Hi, It seems that the biggest change is 'DVD Player remote control' because I always introduced people RTSP as a TV remote control protocol. And I would like to share some my comments, originally written for my better understanding, if you don't mind. >(Page18) When the server is notifying the client about the end of the media delivery requested using PLAY, it sends a PLAY_NOTIFY request to the client.=20 [jh]The right intention looks "When the server wants to notify the client about the end of the media delivery, it can send a PLAY_NOTIFY..." >(Page18) The PLAY_NOTIFY request includes information about the last RTP sequence numbers for each stream, and thus enables correct handling of the buffer drainage at the end. [jh] How about this? "The PLAY_NOTIFY request includes the last RTP sequence number for each stream to help the player to empty the buffer smoothly." >(Page19) For video is possible to manipulate the number of frames that is displayed per second, but... [jh] This part could be enhanced like below. Correct me if I am wrong. Some 'this' are ambiguous to me. "For video, it is possible to manipulate the framerate on the fly, although the randering capabilities are often limited to certain frame rates. And the allowed contents bitrate also limits the modification of the framerate. Therefore, basically fast forward feature could be implemented in this regards in which some subset of the frames from the original content could be picked up. However, the result of this way would be different from the video encoding methods. Due to the media characteristics, possible scale ratios is commonly limited. To signal right scale ratio information, RTSP has a way of indicating the supported Scale ratios for the content. To support aggregated or dynamic content, where the scale may change during the session and this change is dependent on the location within the content, a mechanism for updating the media properties and the currently used scale factor exists." >(Page20) Speed affects how much of=20 [jh] I think this parts overally should be re-reviewed. Or I would revisit here again later. >(Page25) transport. A message is either a Request or a Response. Message Body: The information transferred as the payload of a message. A message body consists of meta-information in the (snip) [jh] the expression, "either a request or a response" should be in the message body. It helps RTSP implementers to consider message body even in the request which is not common in basic operation. Therefore, rather the original sentence in draft20 looks better. And I think "The information transferred as the payload of a request or response." could be rephrased to "The contents of the message without the message header in either RTSP request or response message." >(Page141) The server SHALL respond if the session is in playing state with the Range header filled in with the current playback point and with the corresponding RTP-Info values. [jh] Original one looks more clear. It would be enhanced like below, though. "The server SHALL respond if the session is in playing state. Then, that response MUST have RTP-Info value which is corresponding to the given Range value." >(Page250)=20 S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 CSeq: 45 Notify-Reason: end-of-stream Request-Status: cseq=3D4 status=3D200 reason=3D"OK" Range: npt=3D-15 RTP-Info:url=3D"rtsp://example.com/fizzle/audiotrack" ssrc=3D0D12F123:seq=3D49;rtptime=3D39200 Session: abcdefgh C->S: RTSP/2.0 200 OK CSeq: 854 User-Agent: PhonyClient/1.2 [jh] CSeq looks mismatched.=20 Regards, Jaehwan Vidiator -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, June 19, 2009 10:30 PM To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt 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 : Real Time Streaming Protocol 2.0 (RTSP) Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-mmusic-rfc2326bis-21.txt Pages : 283 Date : 2009-06-19 This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-21.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From thomas.stach@siemens-enterprise.com Thu Jul 9 07:59:31 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9193A6B76 for ; Thu, 9 Jul 2009 07:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.694 X-Spam-Level: X-Spam-Status: No, score=-3.694 tagged_above=-999 required=5 tests=[AWL=1.735, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5jYC7opi8sB for ; Thu, 9 Jul 2009 07:59:31 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id B335D3A6C9D for ; Thu, 9 Jul 2009 07:59:30 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id n69F05LL012637; Thu, 9 Jul 2009 17:00:05 +0200 Received: from nets139a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id n69Exrrc015741; Thu, 9 Jul 2009 16:59:53 +0200 Received: from atnets1aka.ww300.siemens.net ([158.226.238.99]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 16:59:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 16:59:51 +0200 Message-ID: <65A25F4A9EA17343A44B0456FBE6217DB135BA@nets11ca> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] A replacement for ANAT Thread-Index: Acn+Ht6b7BCUGPf8Sx21Vd9MnFbb/wAD2+LAACQixBAADQRQgAAgkgEAAA5LAuAAPWKu0A== References: <08BA2C59E081884DB2AAE4A0BE9D6DC1368EAB@ftrdmel0.rd.francetelecom.fr>

From: "Stach, Thomas" To: , , X-OriginalArrivalTime: 09 Jul 2009 14:59:52.0531 (UTC) FILETIME=[E9C86A30:01CA00A5] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::090709170005-1EC41BA0-19C9DEA4/0-0/0-15 X-purgate-size: 3903/999999 Subject: Re: [MMUSIC] A replacement for ANAT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:59:32 -0000 Hi Hadriel and Simo, this proposal resembles almost exactly what was proposed as ice-micro-lite in early 2007. ice-micro-lite was proposed as further reduced ice-lite procedures, i.e. ice-lite without the need to respond to STUN connectivity checks. The main differences in this new draft is that the syntax mimics SDP-cap-neg instead of ICE. The discussion back in 2007 ended with a proposal by Jonathan R. which seemed to satisfy all needs. --> http://www.ietf.org/mail-archive/web/mmusic/current/msg05648.html I wonder if such an approach, i.e. ice-lite on both sides, would work for your scenarios as well. Regards Thomas =20 > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 > Simo.Veikkolainen@nokia.com > Sent: Wednesday, July 08, 2009 11:43 AM > To: HKaplan@acmepacket.com; mmusic@ietf.org > Subject: Re: [MMUSIC] A replacement for ANAT >=20 >=20 > =20 >=20 > >-----Original Message----- > >From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > >Sent: 08 July, 2009 06:01 > >To: Veikkolainen Simo (Nokia-D/Helsinki); mmusic@ietf.org > >Cc: mohamed.boucadair@orange-ftgroup.com > >Subject: RE: A replacement for ANAT > > > > > > > >> -----Original Message----- > >> From: Simo.Veikkolainen@nokia.com=20 > >[mailto:Simo.Veikkolainen@nokia.com] > >> Sent: Tuesday, July 07, 2009 7:23 AM > >>=20 > >> Sorry for missing the discussion on SIPPING. Have you taken=20 > >a look at=20 > >>=20 > >http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-0 > 0, which=20 > >> also defines a ccap attribute? The draft has exprired, but we are=20 > >> planning to submit an updated version soon (with minimal changes). > > > >Heh, that's funny - nope hadn't seen that draft before. =20 > > > >The concepts are obviously similar, though different in the=20 > >following ways: > >1) The boucadair draft does not to tie the ccap concept to=20 > >sdp-cap-neg in any way. Specifically, we did not want to make=20 > >implementers have to support sdp-cap-neg just to offer=20 > >alternate addresses for v4/v6. Sdp-cap-neg is a fairly=20 > >complex mechanism for people who don't need it. > > > >2) We assumed in the boucadair draft that a host could not=20 > >necessarily use the same UDP/TCP/etc. port numbers for the=20 > >alternate address, since they're different number spaces, so=20 > >we include the port number in the ccap attribute. > > > >3) Since we include the port number in the ccap in the=20 > >boucadair draft, and the port number is specific to the media=20 > >line, we do not allow the ccap at the session level - only the=20 > >media level. > > > >4) The boucadair draft is for the alternate address/port=20 > >connection concept only, and not for any other capabilities. =20 > >This was done on purpose, because the only goal was to have a=20 > >workable replacement model for ANAT for v4/v6, so we wanted=20 > >any claims of compliance to the draft to be for the specific=20 > >support of ccap. >=20 > The ccap attribute as defined in the boucadair draft seems to=20 > borrow its syntax from sdp cap-neg, but is otherwise totally=20 > independent; but I guess this was your intention. Actually,=20 > you probably could remove any references to sdp-cap-neg=20 > without losing any of the functionality you have described.=20 >=20 > You could use the definitions in=20 > draft-garcia-mmusic-sdp-misc-cap for the address capability=20 > part, but you would still need the port number indicated as a=20 > capability. This is not defined currently in any of the=20 > related drafts (sdp-cap-neg, sdp-media-capabilities, sdp-misc-cap).=20 >=20 > Simo >=20 > >-hadriel > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 From HKaplan@acmepacket.com Thu Jul 9 09:45:54 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016183A6D00 for ; Thu, 9 Jul 2009 09:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpGm1gW27a8x for ; Thu, 9 Jul 2009 09:45:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E93543A6B57 for ; Thu, 9 Jul 2009 09:45:52 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 9 Jul 2009 12:46:18 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 9 Jul 2009 12:46:18 -0400 From: Hadriel Kaplan To: "Stach, Thomas" , "Simo.Veikkolainen@nokia.com" , "mmusic@ietf.org" Date: Thu, 9 Jul 2009 12:46:17 -0400 Thread-Topic: [MMUSIC] A replacement for ANAT Thread-Index: Acn+Ht6b7BCUGPf8Sx21Vd9MnFbb/wAD2+LAACQixBAADQRQgAAgkgEAAA5LAuAAPWKu0AACu9zw Message-ID: References: <08BA2C59E081884DB2AAE4A0BE9D6DC1368EAB@ftrdmel0.rd.francetelecom.fr>

<65A25F4A9EA17343A44B0456FBE6217DB135BA@nets11ca> In-Reply-To: <65A25F4A9EA17343A44B0456FBE6217DB135BA@nets11ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] A replacement for ANAT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:45:54 -0000 Hi Thomas,=20 I don't remember a micro-lite, but we did consider an ICE-Lite model instea= d of a new attribute. The problem is, and correct me if I'm wrong, but in = the current ICE draft-19 an ICE-lite implementation MUST be able to respond= to connectivity checks. That was a basic requirement from that email you = cited as well. The basic rationale for that is to enable NAT traversal. But we have no such need in the boucadair-draft, or for ANAT replacement in= general. All we need is for an alternate address to be signaled in a back= wards-compatible fashion in the offer, and one of them to be picked/used in= the answer. In particular, I fully expect there to be ccap-offering devic= es which cannot respond to connectivity checks. So re-using the ice-lite c= oncept is inappropriate I think. It isn't ICE really. For example, suppose a device which could not respond to connectivity check= s sent an ice-lite offer, and the answerer was capable of ICE-full. The an= swerer would do connectivity checks, and they would fail. =20 So instead, the proposal in the boucadair-draft is to signal this using a c= cap attribute, which is an alternative to ICE. The offerer can offer both = ccap and ICE (or even Ice-Lite); an Ice-only answerer would ignore the ccap= ; a ccap-only device would ignore the ICE attributes and do ccap; and an an= swerer which can do both can choose whether to use ICE or ccap, but it can'= t use both. There are some other differences as well, but not as big probably. -hadriel > -----Original Message----- > From: Stach, Thomas [mailto:thomas.stach@siemens-enterprise.com] > Sent: Thursday, July 09, 2009 11:00 AM >=20 > Hi Hadriel and Simo, >=20 > this proposal resembles almost exactly what was proposed as > ice-micro-lite in early 2007. > ice-micro-lite was proposed as further reduced ice-lite procedures, i.e. > ice-lite without the need to respond to STUN connectivity checks. > The main differences in this new draft is that the syntax mimics > SDP-cap-neg instead of ICE. >=20 > The discussion back in 2007 ended with a proposal by Jonathan R. which > seemed to satisfy all needs. > --> http://www.ietf.org/mail-archive/web/mmusic/current/msg05648.html >=20 > I wonder if such an approach, i.e. ice-lite on both sides, would work > for your scenarios as well. >=20 From Simo.Veikkolainen@nokia.com Fri Jul 10 05:21:28 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631B328C2AF for ; Fri, 10 Jul 2009 05:21:28 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6UOmofPsTDv for ; Fri, 10 Jul 2009 05:21:27 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 38D6228C15B for ; Fri, 10 Jul 2009 05:21:27 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6ACKepR027616 for ; Fri, 10 Jul 2009 15:20:47 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 15:18:55 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 15:18:50 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 10 Jul 2009 14:18:50 +0200 From: To: Date: Fri, 10 Jul 2009 14:18:48 +0200 Thread-Topic: I-D Action:draft-garcia-mmusic-sdp-misc-cap-01.txt Thread-Index: AcoAJCn2IhJpcsfOTSO2NwzZjeT0wwBM/5/g Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_B23B311878A0B4438F5F09F47E01AAE03A72D50386NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2009 12:18:50.0573 (UTC) FILETIME=[95385FD0:01CA0158] X-Nokia-AV: Clean Subject: [MMUSIC] FW: I-D Action:draft-garcia-mmusic-sdp-misc-cap-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 12:21:28 -0000 --_003_B23B311878A0B4438F5F09F47E01AAE03A72D50386NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have submitted a new version of the misc-cap draft. Changes are only in = the dates to keep the draft alive as we could not recollect any open techni= cal items. In case we have forgotten to address your comments or concerns, = please let us know. Simo=20 >-----Original Message----- >From: i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext=20 >Internet-Drafts@ietf.org >Sent: 09 July, 2009 02:30 >To: i-d-announce@ietf.org >Subject: I-D Action:draft-garcia-mmusic-sdp-misc-cap-01.txt=20 > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > > Title : Miscellaneous Capabilities=20 >Negotiation in the Session Description Protocol (SDP) > Author(s) : M. Garcia, et al. > Filename : draft-garcia-mmusic-sdp-misc-cap-01.txt > Pages : 15 > Date : 2009-07-08 > >SDP has been extended with a capability negotiation mechanism=20 >framework that allows the endpoints to negotiate transport=20 >protocols and attributes. This framework has been extended=20 >with a Media capabilities negotiation mechanism that allows=20 >endpoints to negotiate additional media-related capabilities. =20 >This negotiation is embedded into the widely-used SDP=20 >offer/answer procedures. > >This memo extends the SDP capability negotiation framework to=20 >allow endpoints to negotiate a number of miscellaneous SDP=20 >capabilities. >In particular, this memo provides a mechanism to negotiate=20 >media titles ("i=3D" line for each media), connection data ("c=3D"=20 >line), and media bandwidth ("b=3D" line). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-garcia-mmusic-sdp-mis >c-cap-01.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail=20 >reader implementation to automatically retrieve the ASCII=20 >version of the Internet-Draft. >= --_003_B23B311878A0B4438F5F09F47E01AAE03A72D50386NOKEUMSG01mgd_ Content-Type: message/external-body; name="draft-garcia-mmusic-sdp-misc-cap-01.url" Content-Description: draft-garcia-mmusic-sdp-misc-cap-01.url Content-Disposition: attachment; filename="draft-garcia-mmusic-sdp-misc-cap-01.url"; size=100; creation-date="Thu, 09 Jul 2009 01:31:05 GMT"; modification-date="Thu, 09 Jul 2009 01:31:05 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1nYXJjaWEtbW11c2ljLXNkcC1taXNjLWNhcC0wMS50eHQNCg== --_003_B23B311878A0B4438F5F09F47E01AAE03A72D50386NOKEUMSG01mgd_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=258; creation-date="Thu, 09 Jul 2009 01:31:05 GMT"; modification-date="Thu, 09 Jul 2009 01:31:05 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K --_003_B23B311878A0B4438F5F09F47E01AAE03A72D50386NOKEUMSG01mgd_-- From root@core3.amsl.com Fri Jul 10 10:00:01 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2603728C0FF; Fri, 10 Jul 2009 10:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090710170001.2603728C0FF@core3.amsl.com> Date: Fri, 10 Jul 2009 10:00:01 -0700 (PDT) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-sdp-media-capabilities-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 17:00:01 -0000 --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 : SDP media capabilities Negotiation Author(s) : R. Gilman, et al. Filename : draft-ietf-mmusic-sdp-media-capabilities-08.txt Pages : 47 Date : 2009-07-10 Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This extension is designed to map easily to existing and future SDP media attributes, but not encodings or formatting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mmusic-sdp-media-capabilities-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-10095627.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 13 03:00:04 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 919213A6C01; Mon, 13 Jul 2009 03:00:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713100004.919213A6C01@core3.amsl.com> Date: Mon, 13 Jul 2009 03:00:04 -0700 (PDT) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc3388bis-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 10:00:04 -0000 --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 : The SDP (Session Description Protocol) Grouping Framework Author(s) : G. Camarillo Filename : draft-ietf-mmusic-rfc3388bis-03.txt Pages : 20 Date : 2009-07-13 In this specification, we define a framework to group "m" lines in SDP (Session Description Protocol) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc3388bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mmusic-rfc3388bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13025742.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 13 07:00:01 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6883E3A6D7E; Mon, 13 Jul 2009 07:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713140001.6883E3A6D7E@core3.amsl.com> Date: Mon, 13 Jul 2009 07:00:01 -0700 (PDT) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rtsp-nat-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 14:00:01 -0000 --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 : A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) Author(s) : J. Goldberg, et al. Filename : draft-ietf-mmusic-rtsp-nat-08.txt Pages : 28 Date : 2009-07-13 This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mmusic-rtsp-nat-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13064742.I-D@ietf.org> --NextPart-- From magnus.westerlund@ericsson.com Mon Jul 13 08:57:25 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D1B3A6DB2 for ; Mon, 13 Jul 2009 08:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.01 X-Spam-Level: X-Spam-Status: No, score=-6.01 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2US5wR3SK22G for ; Mon, 13 Jul 2009 08:57:23 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4DCC028C479 for ; Mon, 13 Jul 2009 08:57:23 -0700 (PDT) X-AuditID: c1b4fb3e-b7be7ae000001a87-64-4a5b59806000 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 28.34.06791.0895B5A4; Mon, 13 Jul 2009 17:57:52 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 17:57:51 +0200 Received: from [153.88.50.16] ([153.88.50.16]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 17:57:51 +0200 Message-ID: <4A5B597E.2080700@ericsson.com> Date: Mon, 13 Jul 2009 17:57:50 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jaehwan Kim References: <20090619133001.9387C3A69C5@core3.amsl.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Jul 2009 15:57:51.0545 (UTC) FILETIME=[AD16D290:01CA03D2] X-Brightmail-Tracker: AAAAAA== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 15:57:25 -0000 Hi, Thanks for your comments. See inline for each individual item. The changes made will be able in the 22 version. Jaehwan Kim skrev: > Hi, > > It seems that the biggest change is 'DVD Player remote control' because > I always introduced people RTSP as a TV remote control protocol. > > And I would like to share some my comments, originally written for my > better understanding, if you don't mind. > >> (Page18) When the server is notifying the client about the end of the > media delivery requested using PLAY, it sends a PLAY_NOTIFY request to > the client. > [jh]The right intention looks "When the server wants to notify the > client about the end of the media delivery, it can send a > PLAY_NOTIFY..." Yes, I changed this to: When the server want to notify the client about the completion of the media delivery, it sends a PLAY_NOTIFY request to the client. > >> (Page18) The PLAY_NOTIFY request includes information about the last > RTP sequence numbers for each stream, and thus enables correct handling > of the buffer drainage at the end. > [jh] How about this? "The PLAY_NOTIFY request includes the last RTP > sequence number for each stream to help the player to empty the buffer > smoothly." Yes, reworded it somewhat: The PLAY_NOTIFY request includes information about the stream end, including the last RTP sequence number for each stream, thus enabling the client to empty the buffer smoothly. > >> (Page19) For video is possible to manipulate the number of frames that > is displayed per second, but... > [jh] This part could be enhanced like below. Correct me if I am wrong. > Some 'this' are ambiguous to me. > > "For video, it is possible to manipulate the framerate on the fly, > although the randering capabilities are often limited to certain frame > rates. And the allowed contents bitrate also limits the modification of > the framerate. Therefore, basically fast forward feature could be > implemented in this regards in which some subset of the frames from the > original content could be picked up. However, the result of this way > would be different from the video encoding methods. > > Due to the media characteristics, possible scale ratios is commonly > limited. To signal right scale ratio information, RTSP has a way of > indicating the supported Scale ratios for the content. To support > aggregated or dynamic content, where the scale may change during the > session and this change is dependent on the location within the content, > a mechanism for updating the media properties and the currently used > scale factor exists." > I want to keep this reasonably non-specific when it comes to the codec. Is this better? For video is possible to manipulate the frame rate, although the rendering capabilities are often limited to certain frame rates. Also the allowed bit-rates in decoding, the structured used in the encoding and its dependency between frames and other capabilities of the rendering device limits the possible manipulations. Due to the media restrictions, the possible scale values are commonly restricted to a limited set of possible scale ratios. To enable the clients to select from the possible scale values, RTSP can signal the supported Scale ratios for the content. To support aggregated or dynamic content, where this may change during the ongoing session and dependent on the location within the content, a mechanism for updating the media properties and the current used scale factor exist. >> (Page20) Speed affects how much of > [jh] I think this parts overally should be re-reviewed. Or I would > revisit here again later. > Well, it is a lot of new text. When it comes to this I do need feedback what is problematic with the text. Writing about speed and scale is problematic. >> (Page25) > transport. A message is either a Request or a Response. > > Message Body: The information transferred as the payload of a > message. A message body consists of meta-information in the > (snip) > [jh] the expression, "either a request or a response" should be in the > message body. It helps RTSP implementers to consider message body even > in the request which is not common in basic operation. Therefore, rather > the original sentence in draft20 looks better. And I think "The > information transferred as the payload of a request or response." could > be rephrased to "The contents of the message without the message header > in either RTSP request or response message." I have clarified that this is either a request or a response. But your suggested phrasing is a the invert that isn't fully true as there can be other parts in a message. I try to write what it is. > >> (Page141) The server SHALL > respond if the session is in playing state with the Range header > filled in with the current playback point and with the corresponding > RTP-Info values. > [jh] Original one looks more clear. It would be enhanced like below, > though. > "The server SHALL respond if the session is in playing state. Then, that > response MUST have RTP-Info value which is corresponding to the given > Range value." Okay, is this clearer? The RTP-Info header and the Range header MAY be included in a GET_PARAMETER request from client to server without any values to request the current playback point and corresponding.RTP synchronization information. When the RTP-Info header is included in a Request also the Range header MUST be included (Note, Range header only MAY be used). The server respons SHALL include both the Range header and the RTP-Info header. If the session is in playing state, then the value of the Range header SHALL be filled in with the current playback point and with the corresponding RTP-Info values. If the server is another state, no values are included in the RTP-Info header. > >> (Page250) > S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 > CSeq: 45 > Notify-Reason: end-of-stream > Request-Status: cseq=4 status=200 reason="OK" > Range: npt=-15 > RTP-Info:url="rtsp://example.com/fizzle/audiotrack" > ssrc=0D12F123:seq=49;rtptime=39200 > Session: abcdefgh > > C->S: RTSP/2.0 200 OK > CSeq: 854 > User-Agent: PhonyClient/1.2 > [jh] CSeq looks mismatched. > Fixed. Thanks for the comments Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F�r�gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From root@core3.amsl.com Mon Jul 13 09:45:02 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1FF803A6E6D; Mon, 13 Jul 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713164502.1FF803A6E6D@core3.amsl.com> Date: Mon, 13 Jul 2009 09:45:02 -0700 (PDT) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-22.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 16:45:02 -0000 --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 : Real Time Streaming Protocol 2.0 (RTSP) Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-mmusic-rfc2326bis-22.txt Pages : 282 Date : 2009-07-13 This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-22.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mmusic-rfc2326bis-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13093826.I-D@ietf.org> --NextPart-- From jaehwan@vidiator.com Mon Jul 13 19:08:08 2009 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91413A6CA2 for ; Mon, 13 Jul 2009 19:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYiyZh+swUw9 for ; Mon, 13 Jul 2009 19:08:07 -0700 (PDT) Received: from kor1corpmail01.mediator.com (vkimail.vidiator.com [211.189.53.2]) by core3.amsl.com (Postfix) with ESMTP id 2260D3A67A8 for ; Mon, 13 Jul 2009 19:08:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2009 11:08:30 +0900 Message-ID: In-Reply-To: <4A5B597E.2080700@ericsson.com> References: <20090619133001.9387C3A69C5@core3.amsl.com> <4A5B597E.2080700@ericsson.com> From: "Jaehwan Kim" To: "Magnus Westerlund" Cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: ,