From mmusic-bounces@ietf.org Mon Apr 4 04:31:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05478 for ; Mon, 4 Apr 2005 04:31:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIN7w-0000XX-67 for mmusic-web-archive@ietf.org; Mon, 04 Apr 2005 04:40:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIMwg-0001q6-V5; Mon, 04 Apr 2005 04:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIMwf-0001px-8G for mmusic@megatron.ietf.org; Mon, 04 Apr 2005 04:28:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05284 for ; Mon, 4 Apr 2005 04:28:27 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIN4Y-0000QX-3i for mmusic@ietf.org; Mon, 04 Apr 2005 04:36:39 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j348NilL023245; Mon, 4 Apr 2005 10:27:24 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 10:27:18 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 10:27:18 +0200 Received: from [131.160.37.196] (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AEBA218A90; Mon, 4 Apr 2005 11:27:17 +0300 (EEST) Message-ID: <4250FA65.8080709@ericsson.com> Date: Mon, 04 Apr 2005 11:27:17 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic , fandreas@cisco.com, Dave Oran , dwing@cisco.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2005 08:27:18.0247 (UTC) FILETIME=[1D292770:01C538F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Connection and connectivity preconditions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Folks, in the last IETF we discussed how to proceed with the following both drafts: draft-andreasen-mmusic-connectivityprecondition-02.txt draft-ietf-mmusic-connection-precon-01.txt The former defines connectivity (e.g., RTP No-Op or ICE-based) preconditions and the latter defines connection-oriented (e.g., TCP or SCTP-based) preconditions. The question is what to do to handle scenarios using connection-oriented protocols. The choices are: 1) Merge both documents so that only one precondition type is defined which, for connection-oriented protocols, is met when the connection establishment procedure finishes (e.g., a successful TCP 3-way handshake). 2) Leave the second draft as it is and define in the first draft further conditions that should be met for connection-oriented protocols. For example, the connection establishment procedure needs to be successfull *and* you have to run some type of connectivity check on top of it to ensure that you are talking to the correct remote endpoint. In principle, Flemming and I thought that option 1) was the way to go, but in the meeting some folks talked about option 2). Given that, at present, nobody is implementing something like option 2) (if somebody is doing it please speak up), my proposal would be to go for option 1). Comments? Thanks, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 6 05:27:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18961 for ; Wed, 6 Apr 2005 05:27:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ6x9-0006PE-2e for mmusic-web-archive@ietf.org; Wed, 06 Apr 2005 05:36:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ6oW-0005GL-G7; Wed, 06 Apr 2005 05:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ6nT-0004y1-8i for mmusic@megatron.ietf.org; Wed, 06 Apr 2005 05:26:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18837 for ; Wed, 6 Apr 2005 05:25:59 -0400 (EDT) Received: from relay1.mail.vrmd.de ([81.28.232.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ6vl-0006Nr-G7 for mmusic@ietf.org; Wed, 06 Apr 2005 05:34:38 -0400 Received: from [213.168.105.148] (helo=[213.168.105.148]) by vm8.bln2.vrmd.de with asmtp (Exim 4.41) id 1DJ6nC-0007iG-QI for mmusic@ietf.org; Wed, 06 Apr 2005 11:25:47 +0200 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Message-Id: From: Marc Manthey Date: Wed, 6 Apr 2005 11:25:43 +0200 To: mmusic (E-mail) X-Mailer: Apple Mail (2.619.2) X-Relay-User: marc@let.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Subject: [MMUSIC] question regarding an older implementaion X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1151456030==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad --===============1151456030== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-87--819126016; protocol="application/pkcs7-signature" --Apple-Mail-87--819126016 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit hello wg, During my research i found this OLD code based on RTP protocol. /* * rtp.h * * Constants and structures based on the 12/15/92 draft of the RTP protocol * Internet Draft. This information is still subject to change. * */ Is it possible to implement up todate information into the protocol specification from the early days? and what defines the following lines ? and who is Bolter CPV and CCITT ? #define RTPCONT_CELLB 25 /* Sun CellB */ #define RTPCONT_JPEG 26 /* JPEG */ #define RTPCONT_CUSEEME 27 /* Cornell CU-SeeMe */ #define RTPCONT_NV 28 /* Xerox PARC nv */ #define RTPCONT_PICWIN 29 /* BBN Picture Window */ #define RTPCONT_CPV 30 /* Bolter CPV */ #define RTPCONT_H261 31 /* CCITT H.261 */ and is it a codec or protocol specification ? thank you in advance have a good day marc manthey #ifndef _rtp_h #define _rtp_h #define RTP_VERSION 1 /* Offset from UNIX's epoch to the NTP epoch in seconds (NTP's JAN_1970) */ #ifndef RTP_EPOCH_OFFSET #define RTP_EPOCH_OFFSET 2208988800UL #endif typedef unsigned long uint32; typedef unsigned short uint16; typedef unsigned char uint8; /* Basic RTP header */ struct rtphdr { #ifndef LITTLE_BITFIELDS uint8 rh_vers:2; /* version */ uint8 rh_chanid:6; /* channel id */ uint8 rh_opts:1; /* options present */ uint8 rh_sync:1; /* end of synchronization unit */ uint8 rh_content:6; /* content id */ #else uint8 rh_chanid:6; /* channel id */ uint8 rh_vers:2; /* version */ uint8 rh_content:6; /* content id */ uint8 rh_sync:1; /* end of synchronization unit */ uint8 rh_opts:1; /* options present */ #endif uint16 rh_seq; /* sequence number */ uint32 rh_ts; /* time stamp (middle of NTP timestamp) */ }; /* Basic RTP option header */ struct rtpopthdr { #ifndef LITTLE_BITFIELDS uint8 roh_fin:1; /* final option flag */ uint8 roh_type:7; /* option type */ #else uint8 roh_type:7; /* option type */ uint8 roh_fin:1; /* final option flag */ #endif uint8 roh_optlen; /* option len */ }; /* Normal RTP options */ #define RTPOPT_CSRC 0 /* Content source */ #define RTPOPT_SSRC 1 /* Synchronization source */ #define RTPOPT_BOP 2 /* Beginning of playout unit */ /* RTP synchronization source (SSRC) option header */ struct rtpssrchdr { #ifndef LITTLE_BITFIELDS uint8 rsh_fin:1; /* final option flag */ uint8 rsh_type:7; /* option type */ #else uint8 rsh_type:7; /* option type */ uint8 rsh_fin:1; /* final option flag */ #endif uint8 rsh_optlen; /* option len (== 2) */ uint16 rsh_id; /* source identifier */ uint32 rsh_addr; /* IP address of host */ }; /* RTP BOP option header */ struct rtpbophdr { #ifndef LITTLE_BITFIELDS uint8 rbh_fin:1; /* final option flag */ uint8 rbh_type:7; /* option type */ #else uint8 rbh_type:7; /* option type */ uint8 rbh_fin:1; /* final option flag */ #endif uint8 rbh_optlen; /* option len (== 1) */ uint16 rbh_seq; /* sequence number of BOP */ }; /* RTCP forward direction options */ #define RTPOPT_FMT 32 /* Format description */ #define RTPOPT_SDESC 33 /* Source description */ #define RTPOPT_BYE 35 /* Conference exit notification */ /* RTCP CDESC option header */ struct rtcpfmthdr { #ifndef LITTLE_BITFIELDS uint8 rtfh_fin:1; /* final option flag */ uint8 rtfh_type:7; /* option type */ #else uint8 rtfh_type:7; /* option type */ uint8 rtfh_fin:1; /* final option flag */ #endif uint8 rtfh_optlen; /* option len */ #ifndef LITTLE_BITFIELDS uint8 rtfh_x1:2; /* reserved (must be 0) */ uint8 rtfh_fmt:6; /* format id */ #else uint8 rtfh_fmt:6; /* format id */ uint8 rtfh_x1:2; /* reserved (must be 0) */ #endif uint8 rtfh_cqual; /* clock quality */ }; /* RTCP SDESC option header */ struct rtcpsdeschdr { #ifndef LITTLE_BITFIELDS uint8 rtsh_fin:1; /* final option flag */ uint8 rtsh_type:7; /* option type */ #else uint8 rtsh_type:7; /* option type */ uint8 rtsh_fin:1; /* final option flag */ #endif uint8 rtsh_optlen; /* option len */ uint16 rtsh_id; /* content source id */ uint32 rtsh_addr; /* IP address of host */ }; /* RTCP BYE option header */ struct rtcpbyehdr { #ifndef LITTLE_BITFIELDS uint8 rtbh_fin:1; /* final option flag */ uint8 rtbh_type:7; /* option type */ #else uint8 rtbh_type:7; /* option type */ uint8 rtbh_fin:1; /* final option flag */ #endif uint8 rtbh_optlen; /* option len */ uint16 rtbh_id; /* content source id */ }; /* RTP standard content encodings for audio */ #define RTPCONT_PCMU 0 /* 8kHz PCM mu-law mono */ #define RTPCONT_1016 1 /* 8kHz CELP (Fed Std 1016) mono */ #define RTPCONT_G721 2 /* 8kHz G.721 ADPCM mono */ #define RTPCONT_GSM 3 /* 8kHz GSM mono */ #define RTPCONT_G723 4 /* 8kHz G.723 ADPCM mono */ #define RTPCONT_DVI 5 /* 8kHz Intel DVI ADPCM mono */ #define RTPCONT_L16_16 6 /* 16kHz 16-bit linear mono */ #define RTPCONT_L16_44_2 7 /* 44.1kHz 16-bit linear stereo */ /* RTP standard content encodings for video */ #define RTPCONT_CELLB 25 /* Sun CellB */ #define RTPCONT_JPEG 26 /* JPEG */ #define RTPCONT_CUSEEME 27 /* Cornell CU-SeeMe */ #define RTPCONT_NV 28 /* Xerox PARC nv */ #define RTPCONT_PICWIN 29 /* BBN Picture Window */ #define RTPCONT_CPV 30 /* Bolter CPV */ #define RTPCONT_H261 31 /* CCITT H.261 */ #endif /*_rtp_h*/ -- "In a world without walls or fences, who needs Windows and Gates?" Marc Manthey D - 50672 Cologne Hildeboldplatz 1a Germany office: 0049.221.355.80.32 mobile: 0049.177.341.54.81 www.let.de www.cuseeme.de www.applehelpers.com aim://macfreak2004 macfreak@jabber.org --Apple-Mail-87--819126016 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIID0jCCA84w ggM3oAMCAQICDwCZ9gAAAALW8UGBzBqXYTANBgkqhkiG9w0BAQQFADCBvDELMAkGA1UEBhMCREUx EDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoTMVRDIFRydXN0Q2Vu dGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNVBAsTGVRDIFRydXN0 Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRpZmljYXRlQHRydXN0Y2VudGVy LmRlMB4XDTA1MDIwNDE2NDg0N1oXDTA2MDIwNDE2NDg0N1owQDELMAkGA1UEBhMCREUxFTATBgNV BAMTDE1hcmMgTWFudGhleTEaMBgGCSqGSIb3DQEJARYLbWFyY0BsZXQuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDS9nE3SQ9KDSo3u8+OOuslCEV/AyW5owmQTC7Z5h4hKjK6Stq0 KbPBnJqd7ngfnaO5RsFO2B95uu+muV4cr3GmMJrtQtoC3wYjs24o22Sz/ebz9AKMH/R8rjuok0uN npe96vujCgmPITtacdUdW5Y/XMRXhnxV4hvDs9kDou7HyRwflafVlVPGSNSPDYmxf8ADfB82UnWy pBAKxmqwQmGfCRJvQu1GacXN38etT3jz/8+Y+BnkFbfoiORcwTJYNE+1uV9eg9MkLi0G9mo3mCYb LRQtCq2zvr/XlVpzrF8zmKPj5Dx+DurTisl9eBhSEymFk8MlOiLdN16zv5QL5/NJAgMBAAGjgcgw gcUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwMwYJYIZIAYb4QgEIBCYWJGh0dHA6Ly93 d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZIAYb4 QgEDBFAWTmh0dHBzOi8vd3d3LnRydXN0Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2stcmV2LmNnaS85 OUY2MDAwMDAwMDJENkYxNDE4MUNDMUE5NzYxPzANBgkqhkiG9w0BAQQFAAOBgQBd2aCE057B+UQ5 6w1kXmST7/VlBchj44yiFB0JRnhIPiWOE+W/EqxyRpMscqHNnY9xORu4ide95s+SCuNmIsy0TQnM N4GXEiUJfEqoiy+1Tf8XTmX22ShYQ0ra2kF4ISfbb6A+QjcxSm5Vu9VtIr9n9Uexj8EfpSgfUuWX o2Y/gjGCBCMwggQfAgEBMIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4G A1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERh dGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcG CSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTAJ BgUrDgMCGgUAoIICJzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NTA0MDYwOTI1NDNaMCMGCSqGSIb3DQEJBDEWBBTm+UZhnrwWIu2GZSbpYgKsNdNfEDCB4QYJKwYB BAGCNxAEMYHTMIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMH SGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0 d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3 DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTCB4wYLKoZI hvcNAQkQAgsxgdOggdAwgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQH EwdIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBO ZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZI hvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIPAJn2AAAAAtbxQYHMGpdhMA0GCSqG SIb3DQEBAQUABIIBADSYKoX0MZRZFfMXSyItidHle4MILU4bZrGoDbHqvUk87+og5G9orGCKKl4q 9+BIvPjFGMQc/RI5rWPQtR8I0cOrzULjmsxdLo5R6vMoY5UXnsvYDlgNviplHi1VWj8Oa9oRe049 0rPqOKHzgF5TnR+fUQ5DtCMcMEPJZ38JWOeNiD29W178dY8Tg6xhJGnFNno9W8CZJSUIi4nBMl9a NAggxu7dvNdxc4RhlJRNLFXhKsBme2J12wE6D3zFDS5deiu7qmylligdSyyJi3ryDN/RPOqq7K5q X/5s7BWmE25/Usdqvfa9C61KJRShH1mDuFo1sN36Hyk25cIzzFXEV7wAAAAAAAA= --Apple-Mail-87--819126016-- --===============1151456030== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1151456030==-- From mmusic-bounces@ietf.org Thu Apr 7 05:35:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02021 for ; Thu, 7 Apr 2005 05:35:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJTYY-0002K0-FH for mmusic-web-archive@ietf.org; Thu, 07 Apr 2005 05:44:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJTO5-000606-IC; Thu, 07 Apr 2005 05:33:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJTO2-0005zy-JI for mmusic@megatron.ietf.org; Thu, 07 Apr 2005 05:33:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01900 for ; Thu, 7 Apr 2005 05:33:15 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJTWY-0002FF-AN for mmusic@ietf.org; Thu, 07 Apr 2005 05:42:07 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j379X0h5027812; Thu, 7 Apr 2005 11:33:01 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 11:33:00 +0200 Received: from [147.214.97.154] ([147.214.97.154]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 11:33:00 +0200 Message-ID: <4254FE4B.3000405@ericsson.com> Date: Thu, 07 Apr 2005 11:32:59 +0200 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng Subject: Re: [MMUSIC] updated RTSP version number References: <758B5A159B385447B4F950DE72D7D7AD981DDD@srsdmail01.PVNS.COM> In-Reply-To: <758B5A159B385447B4F950DE72D7D7AD981DDD@srsdmail01.PVNS.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2005 09:33:00.0490 (UTC) FILETIME=[CA28F2A0:01C53B54] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Hi Thomas, Thomas Zeng wrote: > BTW, for some us not present in Minneapolis, is there an estimate on > when rfc2326bis will go WG LC? I will seriuously work to have a fully updated version to the Paris meeting. With fully I mean that we authors has editied in all known issues and reviewed it for consistency. That would mean that we could have a serious round of review around Paris meeting and then update it and resolve any then surfaced issue. If things goes decently well I would expect a WGLC by november IETF. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 7 06:04:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03810 for ; Thu, 7 Apr 2005 06:04:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJU0d-0003CQ-G4 for mmusic-web-archive@ietf.org; Thu, 07 Apr 2005 06:13:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJTmy-0005xa-Jo; Thu, 07 Apr 2005 05:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJTmw-0005vp-Tz for mmusic@megatron.ietf.org; Thu, 07 Apr 2005 05:59:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03563 for ; Thu, 7 Apr 2005 05:59:00 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJTvS-000341-Sw for mmusic@ietf.org; Thu, 07 Apr 2005 06:07:52 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j379weP8009777 for ; Thu, 7 Apr 2005 11:59:00 +0200 Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 11:35:39 +0200 Received: from [147.214.97.154] ([147.214.97.154]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 11:35:39 +0200 Message-ID: <4254FEEA.8090300@ericsson.com> Date: Thu, 07 Apr 2005 11:35:38 +0200 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2005 09:35:39.0370 (UTC) FILETIME=[28DC1CA0:01C53B55] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Backwards compatibility feature like keeping destination parameter in Transport header X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hi, It seems to be consensus on using version 1.1. Therefore I will start asking questions about features that we have kept to have backwards compatibility. First out is the source and destination parameters in the Transport header. As we have the new and more capable src_addr and dest_addr parameters, can we now remove source and destination? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 8 02:09:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25169 for ; Fri, 8 Apr 2005 02:09:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmoq-0002lb-3F for mmusic-web-archive@ietf.org; Fri, 08 Apr 2005 02:18:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmfA-000189-UG; Fri, 08 Apr 2005 02:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJID7-0007Ap-Ug for mmusic@megatron.ietf.org; Wed, 06 Apr 2005 17:37:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06962 for ; Wed, 6 Apr 2005 17:37:15 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJILY-0007pk-Cz for mmusic@ietf.org; Wed, 06 Apr 2005 17:46:00 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2005 14:36:55 -0700 X-IronPort-AV: i="3.92,82,1112598000"; d="scan'208"; a="246623645:sNHT1071643108" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j36LaqDr003831; Wed, 6 Apr 2005 14:36:53 -0700 (PDT) Received: from [10.32.245.158] (stealth-10-32-245-158.cisco.com [10.32.245.158]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j36LSh2K015343; Wed, 6 Apr 2005 14:28:44 -0700 In-Reply-To: <4250FA65.8080709@ericsson.com> References: <4250FA65.8080709@ericsson.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Date: Wed, 6 Apr 2005 17:36:49 -0400 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1112822924.661382"; x:"432200"; a:"rsa-sha1"; b:"nofws:2114"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"PdWV0YXd5mosq4BcwnagDb4sVpoXsTDehJw34JMpelkanEYe+PQqrSCr69HFba7I7Ing4/Qy" "bIgKFgPansG66DnV3B4SQP7hMQGaybii2cY0ELLwpar6P6NxmNPZ0rRPwT/2mf7ofGKxxLEAriZ" "DV2VigAhpNGzkYXoAksLkJBg="; c:"From: David R Oran "; c:"Subject: Re: Connection and connectivity preconditions"; c:"Date: Wed, 6 Apr 2005 17:36:49 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 08 Apr 2005 02:08:15 -0400 Cc: fandreas@cisco.com, mmusic , dwing@cisco.com Subject: [MMUSIC] Re: Connection and connectivity preconditions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Option 1 works for me as long as we are clear that "connection-oriented" means "with working transmission during the data phase". The semantics are the same in that case. For TCP pragmatically we can say that the data is likely to get through or the connection will get torn down. However, if we were to have a connection-oriented protocol that did *not* provide data-phase reliability (I get a small tingle that SCTP can actually be configured in this mode), one would want some confidence that data was actually getting through during the data phase and not just that some establishment handshake worked. So, a few words to that effect would tighten things up and make it clear that the requirement to satisfy the precondition is having confidence that the goodput of the subject flow is sufficiently greater than zero to make the flow usable or you will get an explicit teardown. If you can do that with just the handshake (as in the case of TCP) then nothing more is needed. Dave. On Apr 4, 2005, at 4:27 AM, Gonzalo Camarillo wrote: > Folks, > > in the last IETF we discussed how to proceed with the following both > drafts: > > draft-andreasen-mmusic-connectivityprecondition-02.txt > draft-ietf-mmusic-connection-precon-01.txt > > The former defines connectivity (e.g., RTP No-Op or ICE-based) > preconditions and the latter defines connection-oriented (e.g., TCP or > SCTP-based) preconditions. > > The question is what to do to handle scenarios using > connection-oriented protocols. The choices are: > > 1) Merge both documents so that only one precondition type is defined > which, for connection-oriented protocols, is met when the connection > establishment procedure finishes (e.g., a successful TCP 3-way > handshake). > > 2) Leave the second draft as it is and define in the first draft > further conditions that should be met for connection-oriented > protocols. For example, the connection establishment procedure needs > to be successfull *and* you have to run some type of connectivity > check on top of it to ensure that you are talking to the correct > remote endpoint. > > > In principle, Flemming and I thought that option 1) was the way to go, > but in the meeting some folks talked about option 2). > > Given that, at present, nobody is implementing something like option > 2) (if somebody is doing it please speak up), my proposal would be to > go for option 1). > > Comments? > > Thanks, > > Gonzalo > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 8 13:20:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15290 for ; Fri, 8 Apr 2005 13:20:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxIS-000183-PP for mmusic-web-archive@ietf.org; Fri, 08 Apr 2005 13:29:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJx8x-0005GQ-No; Fri, 08 Apr 2005 13:19:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJx6h-0003M9-UJ for mmusic@megatron.ietf.org; Fri, 08 Apr 2005 13:17:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14811; Fri, 8 Apr 2005 13:17:20 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxFU-0000vz-2q; Fri, 08 Apr 2005 13:26:28 -0400 Received: from netlab.hut.fi (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j38HH9Nk002962; Fri, 8 Apr 2005 19:17:15 +0200 (MEST) Message-ID: <4256BC95.4030008@netlab.hut.fi> Date: Fri, 08 Apr 2005 19:17:09 +0200 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: minutes@ietf.org Content-Type: multipart/mixed; boundary="------------080002030709030303080609" X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b X-Mailman-Approved-At: Fri, 08 Apr 2005 13:19:42 -0400 Cc: mmusic@ietf.org, Colin Perkins Subject: [MMUSIC] [Fwd: Re: Draft MMUSIC Minutes] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f This is a multi-part message in MIME format. --------------080002030709030303080609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, attached are the minutes for the meeting of the MMUSIC WG at the 62nd IETF. Colin and Joerg --------------080002030709030303080609 Content-Type: text/plain; name="minutes.txt" Content-Disposition: inline; filename="minutes.txt" Content-Transfer-Encoding: 7bit Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes ==================================================================== Reported by Colin Perkins and Joerg Ott The MMUSIC working group met once at the 62nd IETF meeting (Minneapolis, March 2005). Topics under discussion included SDP extensions for BFCP, content labels and connectivity preconditions, the ICE methodology for NAT traversal, the SDPng specification, stream tracking for resource management, harmonisation between SDPng and MPEG-21, RTSP, and Internet Media Guides. The meeting was chaired by Joerg Ott and Colin Perkins. SDP Format for BFCP draft-ietf-mmusic-sdp-bfcp-00.txt Gonzalo Camarillo presented the SDP Format for BFCP. The specification for BFCP now has support for different hashing algorithms, meaning that the SDP format needs to be updated to use the sdescriptions format, not than the "k=" line. There have also been a number of clarifications to the draft regarding peer-to-peer use of BFCP (this work is ongoing). Gonzalo solicited input, noting that he expected the next revision to be complete. There were no comments. SDP Content Label draft-hautakorpi-mmusic-sdp-media-content-00.txt Jani Hautakorpi discussed the SDP Content Label. This is a media level attribute that can be used to label streams with semantic meaning, so receivers can automatically treat each media stream appropriately. It is expected that labels will be things like "main camera", "speaker" or "presentation slides" and will be partly interoperable with roles defined by H.239. There was an extensive discussion regarding the difficulty of assigning labels and explicitly defining their semantics, with Brian Rosen noting that it may be hard to come to agreement about labels and their meaning. Gonzalo Camarillo and Roni Even disagreed about the difficulty, noting that there is a need for these labels, and that products exist that implement similar mechanisms. Jonathan Rosenberg and Brian Rosen both commented that there is related work ongoing in the SIMPLE and XCON working groups, and similar concepts in SMIL, with which we may need to align. Henning Schulzrinne and others noted that there are many possible labels, but that we only care about a small number of simple cases, and an application that receives an unknown label is no worse than one which receives no label. Joerg Ott finally wrapped up the discussion by noting that there is a clear interest in this work, and encouraged people to read and comment on the mailing list. SDP Connectivity Preconditions draft-andreasen-mmusic-connectivityprecondition-02.txt Flemming Andreasen presented the draft on connectivity preconditions for SDP media streams, outlining the problem and changes since the previous version. An open issue is that the draft does not mandate any particular way of verifying connectivity, although it does recommend the RTP NOOP format. Should the draft mandate a mechanism and if so which mechanism? Colin Perkins noted that the RTP NOOP draft has expired and will need to be updated if that is the choice. Flemming and Gonzalo Camarillo wondered about the overlap between the connection and connectivity precondition drafts and whether they should be merged? There was discussion about the semantics of connection establishment versus those of connectivity. Jonathan Rosenberg, Magnus Westerlund, Gonzalo and Flemming discussed the need for a three-way handshake to define connectivity and how NAT traversal issues may affect this. There was no real conclusion: it is clear further discussion is needed on the list. ICE draft-ietf-mmusic-ice-04.txt Jonathan Rosenberg discussed the ICE methodology for NAT traversal, noting that the -04 draft has not been changed compared to the -03, but that there are a number of open issues. Changes that have been agreed and will be incorporated include a clarification of re-INVITE behaviour, a change to make implementation of TURN optional, setting the RTCP bandwidth parameter to zero if you are not using RTCP, and some discussion on issues regarding congestion caused by STUN traffic using session startup. Open issue #1: obfuscating ICE addresses. Is there a need to try to obfuscate IP addresses to prevent "helpful" NATs from rewriting the addresses and breaking ICE? Consensus: no. Open issue #2: RTP specificity. The candidate attribute is RTP specific but we may need candidate addresses for non-RTP transports. Propose to define a more generic candidate attribute, using the priority field to group candidate addresses (e.g. to group RTP and RTCP). Consensus was to make this change. Open issue #3: TCP alternates for UDP. Currently the only alternatives you can choose for UDP are other UDP addresses; we cannot fall back to a TCP connection if all UDP addresses fail. Propose to extend the ICE specification to allow fallback to TCP as a connection of last resort, and to document both how this affects performance and the implications this has for sites that block UDP at their firewall as a policy measure to prevent VoIP. Cullen Jennings was concerned that this has potential to start an arms race with firewall vendors and administrators, and worried about circumvention of firewall policy. Colin Perkins and Jon Peterson noted that certain proprietary applications also fallback to TCP: this is not an unknown technique, we need to compete with those systems to ensure our protcols remain valid and useful. It seems that there was rough consensus that use of TCP was not ideal, and concern that one may not wish to implement fallback to TCP as a default, but that in the current Internet it may be necessary to allow such a fallback as an option. There are a number of other open issues, concerning fallback to TCP and identification of RTP profiles, diagnosis of problems since the final IP address and port are never signalled, interaction with preconditions and middleboxes, dynamic RTP address changes, the ugliness of demuxing STUN and RTP, and interactions with SRTP. Jonathan noted that the root cause of all these problems is the single fact that a peer in the dialog starts sending media to the new address once the connectivity check succeeds without signalling that address. Proposal: separate these and always send media to the address/port in the "m=" and "c=" lines, and only send connectivity checks to the address/port in the candidate lines. When connectivity checks succeed, do a re-INVITE or UPDATE that "promotes" the candidate address/port to the "m="/"c=" lines. Note that this does not increase call setup time or post-dial delay. [see slides for a sample call flow, illustrating operation of the proposal]. There was considerable discussion of the details of the idea, with the consensus being generally in favour. The details will be defined on the mailing list, with an updated draft to be published documenting the new approach. Stream Tracking for Resource Management in the Network draft-guenkova-mmusic-sdp-ng-streamtrack-00.txt Ingo Wolf presented a new proposal for streaming tracking for resource management in the network. This is a modification to SDP and SDPng to convey source addresses and ports, which is hoped can be used to signal stream details to middleboxes which can then attempt to ensure QoS. Cullen Jennings inquired the precise problem definition that the draft is supposed to solve and wanted to know why the proposed solution solved it. Ingo stated that the motivation is to provide an explicit grouping between source addresses of RTP and RTCP. However, Cullen argued that the draft seemed to be primarily about QoS with some missing information at present. Source port information are only one piece of these missing bits but there is a whole lot more. He wondered why the draft did not concern itself with these additional missing parameters. According to Ingo, this was beyond the scope of the draft -- which was understood, but this exactly raised the issue of what precisely the draft tries to address. Joerg Ott noted that SIP signalling provides a clear separation between the precondition work to signal that some sort of QoS is required and the mechanism used to establish the QoS. The two pieces are currently separate: this draft tries to combine them, but it is not clear that they belong together. Joerg noted that the draft assumes entities on the path have access to the content, and that source ports are accurate, but we have generally assumed the opposite in the IETF. Magnus Westerlund agreed with Joerg and Cullen, further noting that with NAT traversal being an increasing issue it is often the case that an end point is not aware of its address as seen by the peer endpoint. In summary, the added value of this proposal is unclear. Harmonization between SDPng and MPEG-21 draft-guenkova-mmusic-mpeg21-sdpng-00 Ingo Wolf presented further on a proposed harmonizatoin between SDPng and MPEG-21: He claimed that SDPng was transport-oriented while MPEG-21 DIA was technology-independent and focused on (media) presentation. He suggested an integration model in which all the SDPng containers are reused. The , , elements largely remain the same, only some adjustments are proposed to the RTP package. The element is augments to cover Usage Environment Descriptions (UED) and should be used to address constraints all levels of abstraction. Important extensions include the reference to external definitions using the href attribute, the application of MPEG-7 media stream and codec spefications, and some revisions to name-value pair based mechanism for cross referencing definitions within an SDPng document. Ingo walked through a detalied example (see slides for the details). Steve Casner noted that the namespace for MPEG-21 has a huge overlap to the one defined in RFC3551. He further pointed out that to the extent that MPEG-21 identifies how transport is to be done, the RTP names identify actual payload formats. One cannot simply skip that identification as this is needed in additon to the codec identification. Brian Rosen agreed that one needs to explicitly specify the mapping. Colin noted that the key advantage of SIP/SDP is that peers can negotiate arbitrary MIME types. He questions the benefit from the proposal which is limited to a subset of the codecs that are supported through the MIME type mechanism and adds that the proposal does not support application/*, text/*, etc. Magnus Westerlund pointed out that the proposal allows to describe streams that cannot be transported, and Dirk Kutscher uttered similar concerns to Colin and Magnus. In summary, it is questionable how the approach presented relates properly to the work in MMUSIC, AVT, and other groups in the IETF at large. SDPng draft-ietf-mmusic-sdpng-08.txt Dirk Kutscher presented the latest draft on SDPng. After a brief recap of the motivation and the overall structure, he stressed which aspects are not (supposed to be) covered by the SDPng base spec: application-specific vocaublary, application semantics, vocabulary for expressing constraints across multiple configurations, and vocabulary for metadata. This additional information needs be either specified as extensions/packages (e.g., transport protocols, codecs, packetization formats) or defined in the context of the respective applications (e.g., semantics). The changes in the most recent version include a more explicit inclusion of broadcast scenarios (cf. SAP, IMG), correspondingly make the element for negotiation optional, and the addition of descriptions of further scenarios. A "status" attribute has been added for the elements and a new child element is now allowed for the element that allows encapsulating arbitrary meta description formats. Open issues at this point include: the status element is currently overloaded (and part of the semantics will be moved to the RTP package), IANA considerations need to be written (a registry for package information needs to be set up), XLM schema and DTD definitions need to be done, and the examples need to be aligned with the spec. Finally, at some point, the spec needs a real name (other than "SDPng"). The group is encouraged to review the spec now and comment so that WGLC before 63rd IETF is possible. Next steps to take further include completing the RTP package definition, dealing with a security package, and providing for meta descriptions. Info Wolf noted that he wants to see more discussion about how people could extend SDPng. Colin Perkins agreed with that and encouraged further work to be put into this. RTSP draft-ietf-mmusic-rfc2326bis-09.txt Magnus Westerlund presents the current status and some issues with the current revision of the RTSP specification. Due to shortage of time, he skips most of the stuff and starts with the issue of explicit white spacing (slide #5): he reviews the RTSP rules for white spaces as separators between tokes. He wants to change the use of "," and ";" to explicitly allow for whitespaces around them for which he seeks input from the group. Another (related) issue are the RTSP headers that are currently defined with reference to RFC 2616. However, RFC 2616 does not use RFC 2234 BNF with explicit white spacing. His suggestion is to copy the syntax into RTSP and make the whitespaces explicit. The chairs urge people to review the draft and comment. Internet Media Guides Yuji Nomura shortly described the recent activities regarding IMGs. Due to lack of time, he keeps the presentation extremely short: He briefly summarizes the interim discussions on the IMG envelope to carry metadata: the authors and a few others have discussed the use of XML as envelope systax vs. MIME encapsulation. Both can be defined (or extended) to provide the right functions for IMG envelopes and allow the re-use of existing specifications. XML is expected to require more work and be not as efficient to encapsulate binary data but MIME is not a perfect match either. Open issues are related to the inclusion/representation of versioning information and a metadata URI, a validity period, and proper authentication of subsets of IMG metadata. For the next steps, input from the group is sought: a new draft on an IMG envelope based upon MIME may be defined, the other drafts will be updated. - + - --------------080002030709030303080609 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --------------080002030709030303080609-- From mmusic-bounces@ietf.org Mon Apr 11 02:56:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16335 for ; Mon, 11 Apr 2005 02:56:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKszc-0006hv-Jt for mmusic-web-archive@ietf.org; Mon, 11 Apr 2005 03:05:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKspQ-0002Qw-52; Mon, 11 Apr 2005 02:55:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKspM-0002Qq-AS for mmusic@megatron.ietf.org; Mon, 11 Apr 2005 02:55:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16310 for ; Mon, 11 Apr 2005 02:55:18 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKsyf-0006hO-4g for mmusic@ietf.org; Mon, 11 Apr 2005 03:04:58 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j3B6tDM8006513; Mon, 11 Apr 2005 08:55:13 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3B6tDLo028280; Mon, 11 Apr 2005 08:55:13 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <2SQ5H0JV>; Mon, 11 Apr 2005 08:55:13 +0200 Message-ID: From: Fries Steffen To: elisabetta.carrara@ericsson.com Date: Mon, 11 Apr 2005 08:55:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mmusic@ietf.org Subject: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi Elisabetta, recently a question came up in the usage of the key management extentions for SIP to use MIKEY: Section 3.1.2 of draft-ietf-mmusic-kmgmt-ext-14 contains the following statement: "If the key management rejects the offer and the session needs to be aborted, the answerer SHOULD return a "488 Not Acceptable Here" message, optionally also including one or more Warning headers (a 306 "Attribute not understood" when one of the parameters is not supported, and a 399 "Miscellaneous warning" with arbitrary information to be presented to a human user or logged, see Section 20.43 in [SIP]). Further details about the cause of failure MAY be described in an included message from the key management protocol. The session is then aborted (and it is up to local policy or end user to decide how to continue)." Concerning the sentence in bold (The sentence before the last sentence in quotes), how does it do that in the following scenario?: A UA receives an INVITE request containing an SDP offer with a MIKEY I_MESSAGE that is for some reason unacceptable. The receiving UA will return a 488 response, which does not contain an SDP answer. Therefore there is no way of embedding a MIKEY R_MESSAGE to indicate the error. Is there any way to signla the MIKEY error in this case? Regards Steffen _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 12 04:10:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06071 for ; Tue, 12 Apr 2005 04:10:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLGdP-0000Ai-PD for mmusic-web-archive@ietf.org; Tue, 12 Apr 2005 04:20:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGRw-0001ZE-75; Tue, 12 Apr 2005 04:08:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGRs-0001YU-5a for mmusic@megatron.ietf.org; Tue, 12 Apr 2005 04:08:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05904 for ; Tue, 12 Apr 2005 04:08:30 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLGbF-00006U-PN for mmusic@ietf.org; Tue, 12 Apr 2005 04:18:24 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j3C88R1a032137; Tue, 12 Apr 2005 10:08:27 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3C88PmY027437; Tue, 12 Apr 2005 10:08:25 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <2SQ524S6>; Tue, 12 Apr 2005 10:08:25 +0200 Message-ID: From: Fries Steffen To: Fries Steffen , elisabetta.carrara@ericsson.com Date: Tue, 12 Apr 2005 10:08:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mmusic@ietf.org Subject: [MMUSIC] Further Question to MIKEY embedding with kmgmt-ext. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Hi, I've got another question to MIKEY usage. When a SIP dialog has been established and further offer/answer messages are to be sent, does one need to include MIKEY container when no changes to the established MIKEY parameter are there? regards Steffen > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] On Behalf Of Fries Steffen > Sent: Monday, April 11, 2005 8:55 AM > To: elisabetta.carrara@ericsson.com > Cc: mmusic@ietf.org > Subject: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. > > Hi Elisabetta, > > recently a question came up in the usage of the key > management extentions for SIP to use MIKEY: > > Section 3.1.2 of draft-ietf-mmusic-kmgmt-ext-14 contains the following > statement: > > "If the key management rejects the offer and the session > needs to be aborted, the answerer SHOULD return a "488 Not > Acceptable Here" message, optionally also including one or > more Warning headers (a 306 "Attribute not understood" when > one of the parameters is not supported, and a 399 > "Miscellaneous warning" with arbitrary information to be > presented to a human user or logged, see Section 20.43 in > [SIP]). Further details about the cause of failure MAY be > described in an included message from the key management > protocol. The session is then aborted (and it is up to local > policy or end user to decide how to continue)." > > Concerning the sentence in bold (The sentence before the last > sentence in quotes), how does it do that in the following scenario?: > A UA receives an INVITE request containing an SDP offer with > a MIKEY I_MESSAGE that is for some reason unacceptable. The > receiving UA will return a 488 response, which does not > contain an SDP answer. Therefore there is no way of embedding > a MIKEY R_MESSAGE to indicate the error. Is there any way to > signla the MIKEY error in this case? > > Regards > Steffen > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 12 06:28:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16225 for ; Tue, 12 Apr 2005 06:28:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLImM-000451-SU for mmusic-web-archive@ietf.org; Tue, 12 Apr 2005 06:38:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLIWX-0007c7-A6; Tue, 12 Apr 2005 06:21:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLIWV-0007bP-Rg for mmusic@megatron.ietf.org; Tue, 12 Apr 2005 06:21:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15827 for ; Tue, 12 Apr 2005 06:21:16 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLIfn-0003uf-JV for mmusic@ietf.org; Tue, 12 Apr 2005 06:31:13 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j3CALBSX012855; Tue, 12 Apr 2005 12:21:11 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3CALAs0027861; Tue, 12 Apr 2005 12:21:10 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <2SQ52X97>; Tue, 12 Apr 2005 12:21:10 +0200 Message-ID: From: Fries Steffen To: "Karl Norrman (KI/EAB)" Subject: RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. Date: Tue, 12 Apr 2005 12:21:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: "Elisabetta Carrara \(AL/EAB\)" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Hi Karl, thank you for the answer. Does it mean you should send the MIKEY container even if you don't want to change any of the parameter? To my other question, does the "no" mean, the receiver of the 488 has to interpret it in some way? Regards Steffen > -----Original Message----- > From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com] > Sent: Tuesday, April 12, 2005 11:59 AM > To: Fries Steffen > Cc: Elisabetta Carrara (AL/EAB); mmusic@ietf.org > Subject: RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. > > Hello! > > As we understand the offer/answer model (rfc3264), you should > keep the parameters that you do not wish to change constant > in the re-INVITE. So we also assume that if you try to comply > to the offer/answer model, you will include the MIKEY > parameter, but "ignore" it at the receiver during the SDP > processing as it has not been changed. > > Regarding your question in your previous mail, the answer is no. > > Regards, > MIKEY-people > > > ---------------------------- Original Message > > ---------------------------- > > Subject: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. > > From: "Fries Steffen" > > Date: Mon, April 11, 2005 8:55 am > > To: elisabetta.carrara@ericsson.com > > Cc: mmusic@ietf.org > > -------------------------------------------------------------- > > ------------ > > > > Hi Elisabetta, > > > > recently a question came up in the usage of the key management > > extentions for SIP to use MIKEY: > > > > Section 3.1.2 of draft-ietf-mmusic-kmgmt-ext-14 contains > the following > > statement: > > > > "If the key management rejects the offer and the session > needs to be > > aborted, the answerer SHOULD return a "488 Not Acceptable Here" > > message, optionally also including one or more Warning > headers (a 306 > > "Attribute not understood" when one of the parameters is not > > supported, and a 399 "Miscellaneous warning" with arbitrary > > information to be presented to a human user or logged, see Section > > 20.43 in [SIP]). Further details about the cause of failure MAY be > > described in an included message from the key management > protocol. The > > session is then aborted (and it is up to local policy or > end user to > > decide how to continue)." > > > > Concerning the sentence in bold (The sentence before the > last sentence > > in quotes), how does it do that in the following scenario?: > > A UA receives an INVITE request containing an SDP offer > with a MIKEY > > I_MESSAGE that is for some reason unacceptable. The > receiving UA will > > return a 488 response, which does not contain an SDP > answer. Therefore > > there is no way of embedding a MIKEY R_MESSAGE to indicate > the error. > > Is there any way to signla the MIKEY error in this case? > > > > Regards > > Steffen > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 13 08:27:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21071 for ; Wed, 13 Apr 2005 08:27:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLh7m-0005h2-QZ for mmusic-web-archive@ietf.org; Wed, 13 Apr 2005 08:37:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLgux-0007ep-Iz; Wed, 13 Apr 2005 08:24:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLIQK-0007Kq-BV for mmusic@megatron.ietf.org; Tue, 12 Apr 2005 06:15:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15368 for ; Tue, 12 Apr 2005 06:15:01 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLIZi-0003j4-NE for mmusic@ietf.org; Tue, 12 Apr 2005 06:24:57 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3CAEmOA020679; Tue, 12 Apr 2005 12:14:58 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 11:58:58 +0200 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 11:58:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. Date: Tue, 12 Apr 2005 11:58:57 +0200 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB020147AF3D@esealmw104.eemea.ericsson.se> Thread-Topic: [Fwd: [MMUSIC] Question to MIKEY embedding with kmgmt-ext.] Thread-index: AcU/RaLeXQSC9DyPRxq96mRGobpofQAAA1Fw From: "Karl Norrman \(KI/EAB\)" To: X-OriginalArrivalTime: 12 Apr 2005 09:58:58.0106 (UTC) FILETIME=[3EA309A0:01C53F46] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 13 Apr 2005 08:24:26 -0400 Cc: "Elisabetta Carrara \(AL/EAB\)" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Hello! As we understand the offer/answer model (rfc3264), you should=20 keep the parameters that you do not wish to change constant in the re-INVITE. So we also assume that if you try to comply to the=20 offer/answer model, you will include the MIKEY parameter, but=20 "ignore" it at the receiver during the SDP processing as it has not been changed. Regarding your question in your previous mail, the answer is no. Regards, MIKEY-people > ---------------------------- Original Message=20 > ---------------------------- > Subject: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. > From: "Fries Steffen" > Date: Mon, April 11, 2005 8:55 am > To: elisabetta.carrara@ericsson.com > Cc: mmusic@ietf.org > -------------------------------------------------------------- > ------------ >=20 > Hi Elisabetta, >=20 > recently a question came up in the usage of the key=20 > management extentions > for SIP to use MIKEY: >=20 > Section 3.1.2 of draft-ietf-mmusic-kmgmt-ext-14 contains the following > statement: >=20 > "If the key management rejects the offer and the session needs to be > aborted, the answerer SHOULD return a "488 Not Acceptable=20 > Here" message, > optionally also including one or more Warning headers (a 306=20 > "Attribute > not understood" when one of the parameters is not supported, and a 399 > "Miscellaneous warning" with arbitrary information to be=20 > presented to a > human user or logged, see Section 20.43 in [SIP]). Further=20 > details about > the cause of failure MAY be described in an included message=20 > from the key > management protocol. The session is then aborted (and it is=20 > up to local > policy or end user to decide how to continue)." >=20 > Concerning the sentence in bold (The sentence before the last=20 > sentence in > quotes), how does it do that in the following scenario?: > A UA receives an INVITE request containing an SDP offer with a MIKEY > I_MESSAGE that is for some reason unacceptable. The receiving UA will > return a 488 response, which does not contain an SDP answer. Therefore > there is no way of embedding a MIKEY R_MESSAGE to indicate=20 > the error. Is > there any way to signla the MIKEY error in this case? >=20 > Regards > Steffen >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 13 08:27:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21089 for ; Wed, 13 Apr 2005 08:27:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLh7s-0005hE-9b for mmusic-web-archive@ietf.org; Wed, 13 Apr 2005 08:37:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLgux-0007eu-U0; Wed, 13 Apr 2005 08:24:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLKIM-0006JP-BL for mmusic@megatron.ietf.org; Tue, 12 Apr 2005 08:15:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23753 for ; Tue, 12 Apr 2005 08:14:56 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLKRn-00078V-TQ for mmusic@ietf.org; Tue, 12 Apr 2005 08:24:52 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3CCEfgm014082; Tue, 12 Apr 2005 14:14:56 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 14:13:28 +0200 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 14:13:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. Date: Tue, 12 Apr 2005 14:13:24 +0200 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB020147AF41@esealmw104.eemea.ericsson.se> Thread-Topic: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. Thread-index: AcU/SVq9VOmPDsWHTsKwZXqdysnf+AADsKTw From: "Karl Norrman \(KI/EAB\)" To: "Fries Steffen" X-OriginalArrivalTime: 12 Apr 2005 12:13:25.0406 (UTC) FILETIME=[071F53E0:01C53F59] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 13 Apr 2005 08:24:26 -0400 Cc: "Elisabetta Carrara \(AL/EAB\)" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Hello! > -----Original Message----- > From: Fries Steffen [mailto:steffen.fries@siemens.com] > Sent: den 12 april 2005 12:21 > To: Karl Norrman (KI/EAB) > Cc: Elisabetta Carrara (AL/EAB); mmusic@ietf.org > Subject: RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. >=20 >=20 > Hi Karl, >=20 > thank you for the answer. Does it mean you should send the=20 > MIKEY container > even if you don't want to change any of the parameter? Yes. >=20 > To my other question, does the "no" mean, the receiver of the=20 > 488 has to > interpret it in some way? That is up to the local policy. Regards, Karl >=20 > Regards > Steffen=20 >=20 > > -----Original Message----- > > From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com]=20 > > Sent: Tuesday, April 12, 2005 11:59 AM > > To: Fries Steffen > > Cc: Elisabetta Carrara (AL/EAB); mmusic@ietf.org > > Subject: RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. > >=20 > > Hello! > >=20 > > As we understand the offer/answer model (rfc3264), you should=20 > > keep the parameters that you do not wish to change constant=20 > > in the re-INVITE. So we also assume that if you try to comply=20 > > to the offer/answer model, you will include the MIKEY=20 > > parameter, but "ignore" it at the receiver during the SDP=20 > > processing as it has not been changed. > >=20 > > Regarding your question in your previous mail, the answer is no. > >=20 > > Regards, > > MIKEY-people > >=20 > > > ---------------------------- Original Message > > > ---------------------------- > > > Subject: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. > > > From: "Fries Steffen" > > > Date: Mon, April 11, 2005 8:55 am > > > To: elisabetta.carrara@ericsson.com > > > Cc: mmusic@ietf.org > > > -------------------------------------------------------------- > > > ------------ > > >=20 > > > Hi Elisabetta, > > >=20 > > > recently a question came up in the usage of the key management=20 > > > extentions for SIP to use MIKEY: > > >=20 > > > Section 3.1.2 of draft-ietf-mmusic-kmgmt-ext-14 contains=20 > > the following > > > statement: > > >=20 > > > "If the key management rejects the offer and the session=20 > > needs to be=20 > > > aborted, the answerer SHOULD return a "488 Not Acceptable Here"=20 > > > message, optionally also including one or more Warning=20 > > headers (a 306=20 > > > "Attribute not understood" when one of the parameters is not=20 > > > supported, and a 399 "Miscellaneous warning" with arbitrary=20 > > > information to be presented to a human user or logged,=20 > see Section=20 > > > 20.43 in [SIP]). Further details about the cause of=20 > failure MAY be=20 > > > described in an included message from the key management=20 > > protocol. The=20 > > > session is then aborted (and it is up to local policy or=20 > > end user to=20 > > > decide how to continue)." > > >=20 > > > Concerning the sentence in bold (The sentence before the=20 > > last sentence=20 > > > in quotes), how does it do that in the following scenario?: > > > A UA receives an INVITE request containing an SDP offer=20 > > with a MIKEY=20 > > > I_MESSAGE that is for some reason unacceptable. The=20 > > receiving UA will=20 > > > return a 488 response, which does not contain an SDP=20 > > answer. Therefore=20 > > > there is no way of embedding a MIKEY R_MESSAGE to indicate=20 > > the error.=20 > > > Is there any way to signla the MIKEY error in this case? > > >=20 > > > Regards > > > Steffen > > >=20 > > >=20 > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=20 > > >=20 > > >=20 > > >=20 > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 14 02:30:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06840 for ; Thu, 14 Apr 2005 02:30:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLy2N-0001hE-IL for mmusic-web-archive@ietf.org; Thu, 14 Apr 2005 02:41:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLxnp-0002Mh-W3; Thu, 14 Apr 2005 02:26:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLxnm-0002Kr-O4 for mmusic@megatron.ietf.org; Thu, 14 Apr 2005 02:26:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06468 for ; Thu, 14 Apr 2005 02:26:01 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLxxa-0001YY-Pi for mmusic@ietf.org; Thu, 14 Apr 2005 02:36:19 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j3E6Pt3D009268; Thu, 14 Apr 2005 08:25:55 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3E6PsUk005272; Thu, 14 Apr 2005 08:25:54 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <2SQ5JZT4>; Thu, 14 Apr 2005 08:25:54 +0200 Message-ID: From: Fries Steffen To: "Karl Norrman (KI/EAB)" Subject: RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. Date: Thu, 14 Apr 2005 08:25:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: "Elisabetta Carrara \(AL/EAB\)" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Hi Karl, by thinking about your anwer, there are still open questions for me. > As we understand the offer/answer model (rfc3264), you should > keep the parameters that you do not wish to change constant > in the re-INVITE. So we also assume that if you try to comply > to the offer/answer model, you will include the MIKEY > parameter, but "ignore" it at the receiver during the SDP > processing as it has not been changed. [stf] At the first glimpse this would mean that a sender of a MIKEY message should store the MIKEY container in some place for later reuse, but this is not really possible as parameter like timestamp and maybe RAND. Those may need to change (otherwise, how could you detect replay?). From that point of view the receiver of the MIKEY message needs to process the MIKEY container in any case. Would'nt it be more efficient to not sent the MIKEY container if non of the cryptographic context parameter has changed? This would save the processing at sender and receiver and also bandwidth. Regards Steffen > > Regarding your question in your previous mail, the answer is no. > > Regards, > MIKEY-people > > > ---------------------------- Original Message > > ---------------------------- > > Subject: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. > > From: "Fries Steffen" > > Date: Mon, April 11, 2005 8:55 am > > To: elisabetta.carrara@ericsson.com > > Cc: mmusic@ietf.org > > -------------------------------------------------------------- > > ------------ > > > > Hi Elisabetta, > > > > recently a question came up in the usage of the key management > > extentions for SIP to use MIKEY: > > > > Section 3.1.2 of draft-ietf-mmusic-kmgmt-ext-14 contains > the following > > statement: > > > > "If the key management rejects the offer and the session > needs to be > > aborted, the answerer SHOULD return a "488 Not Acceptable Here" > > message, optionally also including one or more Warning > headers (a 306 > > "Attribute not understood" when one of the parameters is not > > supported, and a 399 "Miscellaneous warning" with arbitrary > > information to be presented to a human user or logged, see Section > > 20.43 in [SIP]). Further details about the cause of failure MAY be > > described in an included message from the key management > protocol. The > > session is then aborted (and it is up to local policy or > end user to > > decide how to continue)." > > > > Concerning the sentence in bold (The sentence before the > last sentence > > in quotes), how does it do that in the following scenario?: > > A UA receives an INVITE request containing an SDP offer > with a MIKEY > > I_MESSAGE that is for some reason unacceptable. The > receiving UA will > > return a 488 response, which does not contain an SDP > answer. Therefore > > there is no way of embedding a MIKEY R_MESSAGE to indicate > the error. > > Is there any way to signla the MIKEY error in this case? > > > > Regards > > Steffen > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 14 03:13:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09641 for ; Thu, 14 Apr 2005 03:13:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLyhh-0002qs-Vg for mmusic-web-archive@ietf.org; Thu, 14 Apr 2005 03:23:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLyNA-0008Ah-2G; Thu, 14 Apr 2005 03:02:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLyMy-00088l-3K for mmusic@megatron.ietf.org; Thu, 14 Apr 2005 03:02:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09201 for ; Thu, 14 Apr 2005 03:02:22 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLyWm-0002dQ-BO for mmusic@ietf.org; Thu, 14 Apr 2005 03:12:41 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3E71YTm010956; Thu, 14 Apr 2005 09:02:21 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 09:02:20 +0200 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 09:02:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. Date: Thu, 14 Apr 2005 09:02:18 +0200 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB020147AF4D@esealmw104.eemea.ericsson.se> Thread-Topic: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. Thread-index: AcVAus/zJQULvAKMQtavXeGLLfdsSgABFcBA From: "Karl Norrman \(KI/EAB\)" To: "Fries Steffen" X-OriginalArrivalTime: 14 Apr 2005 07:02:20.0772 (UTC) FILETIME=[E6F5B240:01C540BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable Cc: "Elisabetta Carrara \(AL/EAB\)" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Hello! See inline... > -----Original Message----- > From: Fries Steffen [mailto:steffen.fries@siemens.com] > Sent: den 14 april 2005 08:26 > To: Karl Norrman (KI/EAB) > Cc: Elisabetta Carrara (AL/EAB); mmusic@ietf.org > Subject: RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. >=20 >=20 > Hi Karl, >=20 > by thinking about your anwer, there are still open questions for me.=20 >=20 > > As we understand the offer/answer model (rfc3264), you should=20 > > keep the parameters that you do not wish to change constant=20 > > in the re-INVITE. So we also assume that if you try to comply=20 > > to the offer/answer model, you will include the MIKEY=20 > > parameter, but "ignore" it at the receiver during the SDP=20 > > processing as it has not been changed. >=20 > [stf] At the first glimpse this would mean that a sender of a=20 > MIKEY message > should store the MIKEY container in some place for later=20 > reuse, but this is > not really possible as parameter like timestamp and maybe=20 > RAND. Those may > need to change (otherwise, how could you detect replay?).=20 > From that point of > view the receiver of the MIKEY message needs to process the=20 > MIKEY container > in any case.=20 If exactly the same container is sent in the response (without changing = it),=20 then the function processing SDP as such would not even bother to=20 send the vale to the MIKEY implementation as it is one of the parameters = that hasn't=20 been changed and shouldn't be processed (according to the offer/answer=20 model). > Would'nt it be more efficient to not sent the MIKEY container=20 > if non of the > cryptographic context parameter has changed? This would save=20 > the processing > at sender and receiver and also bandwidth. Yes, it is more effective to not send the MIKEY data in the response. However, this *has* to be done to comply to the offer/answer model, as we understand it. Regards, Karl >=20 > Regards > Steffen >=20 >=20 >=20 >=20 > >=20 > > Regarding your question in your previous mail, the answer is no. > >=20 > > Regards, > > MIKEY-people > >=20 > > > ---------------------------- Original Message > > > ---------------------------- > > > Subject: [MMUSIC] Question to MIKEY embedding with kmgmt-ext. > > > From: "Fries Steffen" > > > Date: Mon, April 11, 2005 8:55 am > > > To: elisabetta.carrara@ericsson.com > > > Cc: mmusic@ietf.org > > > -------------------------------------------------------------- > > > ------------ > > >=20 > > > Hi Elisabetta, > > >=20 > > > recently a question came up in the usage of the key management=20 > > > extentions for SIP to use MIKEY: > > >=20 > > > Section 3.1.2 of draft-ietf-mmusic-kmgmt-ext-14 contains=20 > > the following > > > statement: > > >=20 > > > "If the key management rejects the offer and the session=20 > > needs to be=20 > > > aborted, the answerer SHOULD return a "488 Not Acceptable Here"=20 > > > message, optionally also including one or more Warning=20 > > headers (a 306=20 > > > "Attribute not understood" when one of the parameters is not=20 > > > supported, and a 399 "Miscellaneous warning" with arbitrary=20 > > > information to be presented to a human user or logged,=20 > see Section=20 > > > 20.43 in [SIP]). Further details about the cause of=20 > failure MAY be=20 > > > described in an included message from the key management=20 > > protocol. The=20 > > > session is then aborted (and it is up to local policy or=20 > > end user to=20 > > > decide how to continue)." > > >=20 > > > Concerning the sentence in bold (The sentence before the=20 > > last sentence=20 > > > in quotes), how does it do that in the following scenario?: > > > A UA receives an INVITE request containing an SDP offer=20 > > with a MIKEY=20 > > > I_MESSAGE that is for some reason unacceptable. The=20 > > receiving UA will=20 > > > return a 488 response, which does not contain an SDP=20 > > answer. Therefore=20 > > > there is no way of embedding a MIKEY R_MESSAGE to indicate=20 > > the error.=20 > > > Is there any way to signla the MIKEY error in this case? > > >=20 > > > Regards > > > Steffen > > >=20 > > >=20 > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=20 > > >=20 > > >=20 > > >=20 > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic