From mmusic-bounces@ietf.org Sat Apr 01 12:55:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPkKJ-0005gJ-IS; Sat, 01 Apr 2006 12:55:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPkKI-0005gE-8S for mmusic@ietf.org; Sat, 01 Apr 2006 12:55:54 -0500 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPkKG-0001Va-R7 for mmusic@ietf.org; Sat, 01 Apr 2006 12:55:54 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by test-iport-3.cisco.com with ESMTP; 01 Apr 2006 09:55:52 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k31HtpYg010494; Sat, 1 Apr 2006 09:55:52 -0800 (PST) Received: from 10.21.97.234 ([10.21.97.234]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 1 Apr 2006 17:55:51 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Sat, 01 Apr 2006 09:55:51 -0800 Subject: Re: [MMUSIC] Optional SRTP? From: Cullen Jennings To: Alan Johnston , Rick Porter Message-ID: Thread-Topic: [MMUSIC] Optional SRTP? Thread-Index: AcZVtYN7whRHn8GoEdq8VQARJEEJ/A== In-Reply-To: <442C140B.2090602@sipstation.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: mmusic-bounces@ietf.org Hi Rick - this is an important problem and it needs to be solved. There are a lot of proposal but certainly no solutions yet. On 3/30/06 9:23 AM, "Alan Johnston" wrote: > Another bad alternative is to offer a secure SDP offer first, and then > if it fails, send a second insecure SDP offer. As has been pointed out before, one of the downsides of this is, if your voicemail system supports SRTP, and your phone does not. This guarantees that callers that do SRTP will only be able to get voicemail. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 04 13:26:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpI3-0007H9-BS; Tue, 04 Apr 2006 13:26:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpI2-0007Gz-8c for mmusic@ietf.org; Tue, 04 Apr 2006 13:26:02 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQpI1-0000uK-VL for mmusic@ietf.org; Tue, 04 Apr 2006 13:26:02 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:51462) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FQpI1-0002d0-7T; Tue, 04 Apr 2006 18:26:01 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-fec-grouping-03.txt Date: Tue, 4 Apr 2006 18:25:58 +0100 To: Adam Li X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 21 Mar 2006, at 20:50, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiparty Multimedia Session > Control Working Group of the IETF. > > Title : Forward Error Correction Grouping Semantics in Session > Description Protocol > Author(s) : A. Li > Filename : draft-ietf-mmusic-fec-grouping-03.txt > Pages : 7 > Date : 2006-3-21 > > This document defines the semantics that allows for grouping of > forward error correction (FEC) streams with the protected payload > streams in Session Description Protocol (SDP). The semantics > defined > in this document is to be used with Grouping of Media Lines in the > Session Description Protocol (RFC 3388) to group together "m" lines > in the same session. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fec- > grouping-03.txt Re-reading this, I noticed a bug in the SDP example (section 4.3). The parity FEC codes use the "application" media type, but should match the media they are protecting: v=0 o=adam 289083124 289083124 IN IP4 host.example.com s=ULP FEC Seminar t=0 0 c=IN IP4 224.2.17.12/127 a=group:FEC 1 2 a=group:FEC 3 4 m=audio 30000 RTP/AVP 0 a=mid:1 m=audio 30002 RTP/AVP 100 ^^^^^ a=rtpmap:100 ulpfec/8000 a=mid:2 m=video 30004 RTP/AVP 31 a=mid:3 m=video 30004 RTP/AVP 101 ^^^^^ c=IN IP4 224.2.17.13/127 a=rtpmap:101 ulpfec/8000 a=mid:4 Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 04 14:05:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpuL-0007vl-Mk; Tue, 04 Apr 2006 14:05:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpuL-0007vg-2B for mmusic@ietf.org; Tue, 04 Apr 2006 14:05:37 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQpuJ-0001ue-PG for mmusic@ietf.org; Tue, 04 Apr 2006 14:05:37 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A56D01E4; Tue, 04 Apr 2006 14:05:33 -0400 From: "Hadriel Kaplan" To: Date: Tue, 4 Apr 2006 14:05:40 -0400 Message-ID: <04f101c65812$624da870$6501a8c0@acmepacket.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZYEmIfD+5/lOgLT46KusoCa8scbA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [MMUSIC] Media security choices mailing list? 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="===============1729753787==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1729753787== Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F2_01C657F0.DB3C0870" This is a multi-part message in MIME format. ------=_NextPart_000_04F2_01C657F0.DB3C0870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I apologize if this has been answered previously, but is there a mailing list for the multiple-choice SRTP (and ZRTP) discussion? I thought I heard there would be when I listened to the audio-cast of the Dallas meeting, but I haven't been able to find it. Thanks! -hadriel ------=_NextPart_000_04F2_01C657F0.DB3C0870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I apologize if this has been answered previously, but = is there a mailing list for the multiple-choice SRTP (and ZRTP) = discussion?  I thought I heard there would be when I listened to the audio-cast of the = Dallas meeting, but I haven’t been able to find it. =

Thanks!

-hadriel

 

------=_NextPart_000_04F2_01C657F0.DB3C0870-- --===============1729753787== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1729753787==-- From mmusic-bounces@ietf.org Wed Apr 05 09:22:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7xY-0007wF-Kz; Wed, 05 Apr 2006 09:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7xX-0007wA-LG for mmusic@ietf.org; Wed, 05 Apr 2006 09:22:07 -0400 Received: from [63.110.43.12] (helo=mail.covergence.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR7xX-000689-Cw for mmusic@ietf.org; Wed, 05 Apr 2006 09:22:07 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [MMUSIC] Optional SRTP? Date: Wed, 5 Apr 2006 09:22:03 -0400 Message-ID: <0D1719326D64BD4E9F92A0C120237678BB2DC8@eserv.covergence.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Optional SRTP? Thread-index: AcZVtYN7whRHn8GoEdq8VQARJEEJ/AC7l5xw From: "Rick Porter" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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: , Errors-To: mmusic-bounces@ietf.org Thanks for all the responses. I'm fascinated by the discussion, as I = thought I would be when I asked the question. I raised my original = question due to a situation I encountered in the lab. I have two phones = as follows:=20 A - secure (SRTP, possibly TLS)=20 B - non-secure (no TLS or SRTP) When A calls B, B rejects the call because he is not configured to = accept a secure call (this phone requires TLS signaling to do SRTP). Per = the SDES draft (Section 5.1.2, top of page 10), this is the correct = behavior. I found the result (B didn't even ring, and call was not = completed) to be rather unsatisfying. This sounds like a known issue = with the current draft. I hate to throw more proposals in the mix, but I have a couple thoughts = on "simple" changes to the current draft to make a more deployable = solution. I'm trying to take a simple, pragmatic approach that will get = this deployed ASAP. It sounds like the conditional SDP is not deployed, = so I do not want to depend on that. Take these proposals with as many = shakers of salt as you see appropriate. 1) Use the same media stream. No special transport. Crypto is just = another "optional" attribute of the media description. 2) Add an "a=3Dencryption" attribute.=20 I believe those suggestions would result in the following behavior for = the above scenario. B would accept the call, but not provide a crypto attribute in the = 200/OK/SDP. Then, if A does not like the 200/OK/SDP without crypto he = can choose to CANCEL the call or continue the non-secure call. Based on = configuration, phone A may prompt the user to accept that it is a = non-secure call. B already knows that he is not configured to do secure = calls, so being non-secure is not news to him.=20 In an early draft by Ahmar Ghaffar at Snom, I liked the = "a=3Dencryption:" attribute that could be included = as part of the media description. If the encryption attribute is = present, you know whether you can accept the call even if you do not = share a common set of crypto algorithms/options. It could give the end = receiving the INVITE the chance to reject the call early (e.g. 480) = instead of sending the 200/OK (without crypto) and letting the other end = cancel the call upon receipt of the 200/OK. I know the above scenario is not the only one, so I probably missed = something... I believe Alan and Paul are correct with respect to not being concerned = about a bid-down attack. If you have access to the signaling stream, = then you have access to key material necessary to decrypt each and every = RTP packet. No need to bid it down crypto if you can decrypt the RTP = packets anyway. Until you do some sort of end-to-end public key exchange = (e.g. ZRTP), then you don't have end-to-end security. There are many = technical and political reasons why SRTP is done on a hop-by-hop = basis--please start another thread if you wish to discuss this.=20 I agree that the fa=E7ade of security is worse than having no security. = However, I don't think that there should be requirements for human = notification/intervention in the specification--network devices do not = typically have a per session user interface! IMHO, a "should" would be = reasonable, but a "must" is too strong. This also becomes sticky when = dealing with multiple streams that don't all have the same security = attributes. Additionally, would you display the session as secure if it = was negotiated with UNENCRYPTED_SRTP and UNAUTHENTICATED_SRTP? Cheers, Rick _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 05 09:51:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8PT-0000rN-LQ; Wed, 05 Apr 2006 09:50:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8PS-0000rC-Nj for mmusic@ietf.org; Wed, 05 Apr 2006 09:50:58 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR8PQ-000734-W4 for mmusic@ietf.org; Wed, 05 Apr 2006 09:50:58 -0400 Received: from [209.47.87.6] (helo=[209.47.87.6]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FR8PQ-000CaP-AG; Wed, 05 Apr 2006 09:50:56 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 209.47.87.6 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <4433CB3E.9020708@sipstation.com> Date: Wed, 05 Apr 2006 08:50:54 -0500 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rick Porter Subject: Re: [MMUSIC] Optional SRTP? References: <0D1719326D64BD4E9F92A0C120237678BB2DC8@eserv.covergence.com> In-Reply-To: <0D1719326D64BD4E9F92A0C120237678BB2DC8@eserv.covergence.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: , Errors-To: mmusic-bounces@ietf.org Rick, ZRTP essentially uses this approach - it uses a normal m= media line that any UA can accept and avoids all these failure modes. In the past I have proposed that other key management techniques could benefit from this as well by permitting the crypto and key-mgt attributes in normal m= lines, just as you discuss. If the SRTP session is then established, a re-INVITE could be sent to change the m= line to indicate that resulting session is in fact secure. I think any device performing this kind of function needs to provide an indication of the secure status of the call (hence a MUST), even if it is just a log or other non-real time indication. Thanks, Alan Rick Porter wrote: >Thanks for all the responses. I'm fascinated by the discussion, as I thought I would be when I asked the question. I raised my original question due to a situation I encountered in the lab. I have two phones as follows: > >A - secure (SRTP, possibly TLS) >B - non-secure (no TLS or SRTP) > >When A calls B, B rejects the call because he is not configured to accept a secure call (this phone requires TLS signaling to do SRTP). Per the SDES draft (Section 5.1.2, top of page 10), this is the correct behavior. I found the result (B didn't even ring, and call was not completed) to be rather unsatisfying. This sounds like a known issue with the current draft. > >I hate to throw more proposals in the mix, but I have a couple thoughts on "simple" changes to the current draft to make a more deployable solution. I'm trying to take a simple, pragmatic approach that will get this deployed ASAP. It sounds like the conditional SDP is not deployed, so I do not want to depend on that. Take these proposals with as many shakers of salt as you see appropriate. > >1) Use the same media stream. No special transport. Crypto is just another "optional" attribute of the media description. > >2) Add an "a=encryption" attribute. > >I believe those suggestions would result in the following behavior for the above scenario. > >B would accept the call, but not provide a crypto attribute in the 200/OK/SDP. Then, if A does not like the 200/OK/SDP without crypto he can choose to CANCEL the call or continue the non-secure call. Based on configuration, phone A may prompt the user to accept that it is a non-secure call. B already knows that he is not configured to do secure calls, so being non-secure is not news to him. > >In an early draft by Ahmar Ghaffar at Snom, I liked the "a=encryption:" attribute that could be included as part of the media description. If the encryption attribute is present, you know whether you can accept the call even if you do not share a common set of crypto algorithms/options. It could give the end receiving the INVITE the chance to reject the call early (e.g. 480) instead of sending the 200/OK (without crypto) and letting the other end cancel the call upon receipt of the 200/OK. > >I know the above scenario is not the only one, so I probably missed something... > >I believe Alan and Paul are correct with respect to not being concerned about a bid-down attack. If you have access to the signaling stream, then you have access to key material necessary to decrypt each and every RTP packet. No need to bid it down crypto if you can decrypt the RTP packets anyway. Until you do some sort of end-to-end public key exchange (e.g. ZRTP), then you don't have end-to-end security. There are many technical and political reasons why SRTP is done on a hop-by-hop basis--please start another thread if you wish to discuss this. > >I agree that the façade of security is worse than having no security. However, I don't think that there should be requirements for human notification/intervention in the specification--network devices do not typically have a per session user interface! IMHO, a "should" would be reasonable, but a "must" is too strong. This also becomes sticky when dealing with multiple streams that don't all have the same security attributes. Additionally, would you display the session as secure if it was negotiated with UNENCRYPTED_SRTP and UNAUTHENTICATED_SRTP? > >Cheers, >Rick > > >_______________________________________________ >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 05 12:54:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRBHS-0007dQ-N8; Wed, 05 Apr 2006 12:54:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRBHR-0007dL-7y for mmusic@ietf.org; Wed, 05 Apr 2006 12:54:53 -0400 Received: from [63.110.43.12] (helo=mail.covergence.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRBHQ-0007cF-UA for mmusic@ietf.org; Wed, 05 Apr 2006 12:54:53 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [MMUSIC] Optional SRTP? Date: Wed, 5 Apr 2006 12:54:51 -0400 Message-ID: <0D1719326D64BD4E9F92A0C120237678BB2E9A@eserv.covergence.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Optional SRTP? Thread-index: AcZYt/i889g2jyvKTUqz3z8HPa74GgAE8cpw From: "Rick Porter" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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: , Errors-To: mmusic-bounces@ietf.org Hi Alan,=20 Why would you send a re-INVITE if SRTP is established? I thought = everything you need to know is in the original INVITE/OK SDP pair.=20 I don't have any strong feelings regarding indication requirements. I = was afraid that you wanted real-time, user-interface indication which is = not practical for multi-user network devices (e.g. b2bua, = media-gateway). I agree that good UA's will provide the best indication = they can to their user. =20 Thanks, Rick -----Original Message----- From: Alan Johnston [mailto:alan@sipstation.com]=20 Sent: Wednesday, April 05, 2006 9:51 AM To: Rick Porter Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Optional SRTP? Rick, ZRTP essentially uses this approach - it uses a normal m=3D media line=20 that any UA can accept and avoids all these failure modes. In the past I have proposed that other key management techniques could=20 benefit from this as well by permitting the crypto and key-mgt=20 attributes in normal m=3D lines, just as you discuss. If the SRTP session is then established, a re-INVITE could be sent to=20 change the m=3D line to indicate that resulting session is in fact = secure. I think any device performing this kind of function needs to provide an=20 indication of the secure status of the call (hence a MUST), even if it=20 is just a log or other non-real time indication. Thanks, Alan Rick Porter wrote: >Thanks for all the responses. I'm fascinated by the discussion, as I = thought I would be when I asked the question. I raised my original = question due to a situation I encountered in the lab. I have two phones = as follows:=20 > >A - secure (SRTP, possibly TLS)=20 >B - non-secure (no TLS or SRTP) > >When A calls B, B rejects the call because he is not configured to = accept a secure call (this phone requires TLS signaling to do SRTP). Per = the SDES draft (Section 5.1.2, top of page 10), this is the correct = behavior. I found the result (B didn't even ring, and call was not = completed) to be rather unsatisfying. This sounds like a known issue = with the current draft. > >I hate to throw more proposals in the mix, but I have a couple thoughts = on "simple" changes to the current draft to make a more deployable = solution. I'm trying to take a simple, pragmatic approach that will get = this deployed ASAP. It sounds like the conditional SDP is not deployed, = so I do not want to depend on that. Take these proposals with as many = shakers of salt as you see appropriate. > >1) Use the same media stream. No special transport. Crypto is just = another "optional" attribute of the media description. > >2) Add an "a=3Dencryption" attribute.=20 > >I believe those suggestions would result in the following behavior for = the above scenario. > >B would accept the call, but not provide a crypto attribute in the = 200/OK/SDP. Then, if A does not like the 200/OK/SDP without crypto he = can choose to CANCEL the call or continue the non-secure call. Based on = configuration, phone A may prompt the user to accept that it is a = non-secure call. B already knows that he is not configured to do secure = calls, so being non-secure is not news to him.=20 > >In an early draft by Ahmar Ghaffar at Snom, I liked the = "a=3Dencryption:" attribute that could be included = as part of the media description. If the encryption attribute is = present, you know whether you can accept the call even if you do not = share a common set of crypto algorithms/options. It could give the end = receiving the INVITE the chance to reject the call early (e.g. 480) = instead of sending the 200/OK (without crypto) and letting the other end = cancel the call upon receipt of the 200/OK. > >I know the above scenario is not the only one, so I probably missed = something... > >I believe Alan and Paul are correct with respect to not being concerned = about a bid-down attack. If you have access to the signaling stream, = then you have access to key material necessary to decrypt each and every = RTP packet. No need to bid it down crypto if you can decrypt the RTP = packets anyway. Until you do some sort of end-to-end public key exchange = (e.g. ZRTP), then you don't have end-to-end security. There are many = technical and political reasons why SRTP is done on a hop-by-hop = basis--please start another thread if you wish to discuss this.=20 > >I agree that the fa=E7ade of security is worse than having no security. = However, I don't think that there should be requirements for human = notification/intervention in the specification--network devices do not = typically have a per session user interface! IMHO, a "should" would be = reasonable, but a "must" is too strong. This also becomes sticky when = dealing with multiple streams that don't all have the same security = attributes. Additionally, would you display the session as secure if it = was negotiated with UNENCRYPTED_SRTP and UNAUTHENTICATED_SRTP? > >Cheers, >Rick > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > > > =20 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 05 15:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDHm-00008k-HH; Wed, 05 Apr 2006 15:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDHl-0008M1-Ki for mmusic@ietf.org; Wed, 05 Apr 2006 15:03:21 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRDGI-0004tv-1K for mmusic@ietf.org; Wed, 05 Apr 2006 15:01:51 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2006 10:03:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,90,1144047600"; d="scan'208"; a="25251055:sNHT27003548" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k35H3bWc024531; Wed, 5 Apr 2006 13:03:38 -0400 (EDT) Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 13:03:37 -0400 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 Subject: RE: [MMUSIC] Optional SRTP? Date: Wed, 5 Apr 2006 13:03:37 -0400 Message-ID: <9EF3C46DC5D14D44B218FD5E93786CA201A6BC3A@xmb-rtp-201.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Optional SRTP? Thread-Index: AcZYt/i889g2jyvKTUqz3z8HPa74GgAE8cpwAAGx8FA= From: "Wayne Mills \(wmills\)" To: "Rick Porter" , X-OriginalArrivalTime: 05 Apr 2006 17:03:37.0712 (UTC) FILETIME=[E18CDF00:01C658D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: 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: , Errors-To: mmusic-bounces@ietf.org If I understand the ZRTP proposal correctly .... The initial media connection is made with RTP, then the endpoints = "upgrade" to SRTP using the media-inband key exchange suggested by ZRTP, = thus SRTP is negotiated outside the call signaling plane. Re-INVITE (by = correcting SDP after the fact) informs the signaling plane that it = happened. Regards, Wayne > -----Original Message----- > From: Rick Porter [mailto:rporter@covergence.com]=20 > Sent: Wednesday, April 05, 2006 12:55 PM > To: mmusic@ietf.org > Subject: RE: [MMUSIC] Optional SRTP? >=20 > Hi Alan,=20 >=20 > Why would you send a re-INVITE if SRTP is established? I=20 > thought everything you need to know is in the original=20 > INVITE/OK SDP pair.=20 >=20 > I don't have any strong feelings regarding indication=20 > requirements. I was afraid that you wanted real-time,=20 > user-interface indication which is not practical for=20 > multi-user network devices (e.g. b2bua, media-gateway). I=20 > agree that good UA's will provide the best indication they=20 > can to their user. =20 >=20 > Thanks, > Rick >=20 > -----Original Message----- > From: Alan Johnston [mailto:alan@sipstation.com] > Sent: Wednesday, April 05, 2006 9:51 AM > To: Rick Porter > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Optional SRTP? >=20 > Rick, >=20 > ZRTP essentially uses this approach - it uses a normal m=3D=20 > media line that any UA can accept and avoids all these failure modes. >=20 > In the past I have proposed that other key management=20 > techniques could benefit from this as well by permitting the=20 > crypto and key-mgt attributes in normal m=3D lines, just as you = discuss. >=20 > If the SRTP session is then established, a re-INVITE could be=20 > sent to change the m=3D line to indicate that resulting session=20 > is in fact secure. >=20 > I think any device performing this kind of function needs to=20 > provide an indication of the secure status of the call (hence=20 > a MUST), even if it is just a log or other non-real time indication. >=20 > Thanks, > Alan >=20 > Rick Porter wrote: >=20 > >Thanks for all the responses. I'm fascinated by the=20 > discussion, as I thought I would be when I asked the=20 > question. I raised my original question due to a situation I=20 > encountered in the lab. I have two phones as follows:=20 > > > >A - secure (SRTP, possibly TLS) > >B - non-secure (no TLS or SRTP) > > > >When A calls B, B rejects the call because he is not=20 > configured to accept a secure call (this phone requires TLS=20 > signaling to do SRTP). Per the SDES draft (Section 5.1.2, top=20 > of page 10), this is the correct behavior. I found the result=20 > (B didn't even ring, and call was not completed) to be rather=20 > unsatisfying. This sounds like a known issue with the current draft. > > > >I hate to throw more proposals in the mix, but I have a=20 > couple thoughts on "simple" changes to the current draft to=20 > make a more deployable solution. I'm trying to take a simple,=20 > pragmatic approach that will get this deployed ASAP. It=20 > sounds like the conditional SDP is not deployed, so I do not=20 > want to depend on that. Take these proposals with as many=20 > shakers of salt as you see appropriate. > > > >1) Use the same media stream. No special transport. Crypto=20 > is just another "optional" attribute of the media description. > > > >2) Add an "a=3Dencryption" attribute.=20 > > > >I believe those suggestions would result in the following=20 > behavior for the above scenario. > > > >B would accept the call, but not provide a crypto attribute=20 > in the 200/OK/SDP. Then, if A does not like the 200/OK/SDP=20 > without crypto he can choose to CANCEL the call or continue=20 > the non-secure call. Based on configuration, phone A may=20 > prompt the user to accept that it is a non-secure call. B=20 > already knows that he is not configured to do secure calls,=20 > so being non-secure is not news to him.=20 > > > >In an early draft by Ahmar Ghaffar at Snom, I liked the=20 > "a=3Dencryption:" attribute that could be=20 > included as part of the media description. If the encryption=20 > attribute is present, you know whether you can accept the=20 > call even if you do not share a common set of crypto=20 > algorithms/options. It could give the end receiving the=20 > INVITE the chance to reject the call early (e.g. 480) instead=20 > of sending the 200/OK (without crypto) and letting the other=20 > end cancel the call upon receipt of the 200/OK. > > > >I know the above scenario is not the only one, so I probably=20 > missed something... > > > >I believe Alan and Paul are correct with respect to not=20 > being concerned about a bid-down attack. If you have access=20 > to the signaling stream, then you have access to key material=20 > necessary to decrypt each and every RTP packet. No need to=20 > bid it down crypto if you can decrypt the RTP packets anyway.=20 > Until you do some sort of end-to-end public key exchange=20 > (e.g. ZRTP), then you don't have end-to-end security. There=20 > are many technical and political reasons why SRTP is done on=20 > a hop-by-hop basis--please start another thread if you wish=20 > to discuss this.=20 > > > >I agree that the fa=E7ade of security is worse than having no=20 > security. However, I don't think that there should be=20 > requirements for human notification/intervention in the=20 > specification--network devices do not typically have a per=20 > session user interface! IMHO, a "should" would be reasonable,=20 > but a "must" is too strong. This also becomes sticky when=20 > dealing with multiple streams that don't all have the same=20 > security attributes. Additionally, would you display the=20 > session as secure if it was negotiated with UNENCRYPTED_SRTP=20 > and UNAUTHENTICATED_SRTP? > > > >Cheers, > >Rick > > > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > =20 > > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 05 15:15:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDTP-0004jp-5Q; Wed, 05 Apr 2006 15:15:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDTN-0004jk-KG for mmusic@ietf.org; Wed, 05 Apr 2006 15:15:21 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRDTM-0005Ok-98 for mmusic@ietf.org; Wed, 05 Apr 2006 15:15:21 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A73A0320; Wed, 05 Apr 2006 15:15:06 -0400 From: "Hadriel Kaplan" To: "'Colin Perkins'" , "'Rick Porter'" Subject: RE: [MMUSIC] Optional SRTP? Date: Wed, 5 Apr 2006 15:15:12 -0400 Message-ID: <06fb01c658e5$433723c0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZUI209NOpFbDIoRuyvXYlK5cCC5AEv4eLA In-Reply-To: <34FA6108-14EA-409E-81FE-5BBD5A83410E@csperkins.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'Alan Johnston' , 'IETF MMUSIC WG' X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Colin, Was there a consensus to determine a single approach? I didn't hear it. (I was on audio-cast, and it was hard to hear) Or is the consensus to improve the SDP syntax so that a common mechanism could be chosen more easily during offer/answer? (if a common one exists) Assuming negotiation even occurs in SDP. Or by choosing a "single" approach do you mean choosing signaling handshake vs. bearer (ZRTP, RTP/DTLS). -hadriel > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Thursday, March 30, 2006 12:56 PM > To: Rick Porter > Cc: Alan Johnston; IETF MMUSIC WG > Subject: Re: [MMUSIC] Optional SRTP? > > Rick, > > It's important to note that there was a lot of discussion on this > subject in the MMUSIC and AVT working groups, and the RAI area > meeting, at the IETF last week. The zrtp draft is one of many > proposals, and it is by no means clear that there is consensus on any > single approach. > > Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 06 05:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQNS-0002FN-Cj; Thu, 06 Apr 2006 05:02:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQNQ-0002FI-Kt for mmusic@ietf.org; Thu, 06 Apr 2006 05:02:04 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRQNP-0007br-Ak for mmusic@ietf.org; Thu, 06 Apr 2006 05:02:04 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63197 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FRQNJ-0000RF-Gp; Thu, 06 Apr 2006 10:01:57 +0100 In-Reply-To: <06fb01c658e5$433723c0$6501a8c0@acmepacket.com> References: <06fb01c658e5$433723c0$6501a8c0@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4695EDA2-51D8-4D93-9439-C87A9E566BCE@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Optional SRTP? Date: Thu, 6 Apr 2006 10:01:54 +0100 To: Hadriel Kaplan X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Alan Johnston , IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hadriel, It's clear that a single approach is desirable, rather than multiple incompatible solutions, but I don't see any consensus on how to proceed yet. Colin On 5 Apr 2006, at 20:15, Hadriel Kaplan wrote: > Hi Colin, > Was there a consensus to determine a single approach? I didn't > hear it. (I > was on audio-cast, and it was hard to hear) > > Or is the consensus to improve the SDP syntax so that a common > mechanism > could be chosen more easily during offer/answer? (if a common one > exists) > Assuming negotiation even occurs in SDP. > > Or by choosing a "single" approach do you mean choosing signaling > handshake > vs. bearer (ZRTP, RTP/DTLS). > > -hadriel > > >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Thursday, March 30, 2006 12:56 PM >> To: Rick Porter >> Cc: Alan Johnston; IETF MMUSIC WG >> Subject: Re: [MMUSIC] Optional SRTP? >> >> Rick, >> >> It's important to note that there was a lot of discussion on this >> subject in the MMUSIC and AVT working groups, and the RAI area >> meeting, at the IETF last week. The zrtp draft is one of many >> proposals, and it is by no means clear that there is consensus on any >> single approach. >> >> Colin > > > _______________________________________________ > 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 06 08:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTj7-0007tH-8i; Thu, 06 Apr 2006 08:36:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTj5-0007rl-4o for mmusic@ietf.org; Thu, 06 Apr 2006 08:36:39 -0400 Received: from [63.110.43.12] (helo=mail.covergence.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRTj3-0006xg-Ug for mmusic@ietf.org; Thu, 06 Apr 2006 08:36:39 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [MMUSIC] Optional SRTP? Date: Thu, 6 Apr 2006 08:36:32 -0400 Message-ID: <0D1719326D64BD4E9F92A0C120237678BB303C@eserv.covergence.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Optional SRTP? Thread-index: AcZYt/i889g2jyvKTUqz3z8HPa74GgAE8cpwAAGx8FAAKDK7gA== From: "Rick Porter" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: , Errors-To: mmusic-bounces@ietf.org I could not see why a re-INVITE was necessary using the scheme outlined in the Security Descriptions draft (with possible modification).=20 I'm still a ZRTP novice, but I can understand the re-INVITE when doing ZRTP. However, the re-INVITE to keep signaling informed raises a red flag about layering. My instinct tells me that if it is important to the signaling, then the signaling should be driving the train. I still have many ZRTP discussions to catch up on...=20 Thanks, Rick -----Original Message----- From: Wayne Mills (wmills) [mailto:wmills@cisco.com]=20 Sent: Wednesday, April 05, 2006 1:04 PM To: Rick Porter; mmusic@ietf.org Subject: RE: [MMUSIC] Optional SRTP? If I understand the ZRTP proposal correctly .... The initial media connection is made with RTP, then the endpoints "upgrade" to SRTP using the media-inband key exchange suggested by ZRTP, thus SRTP is negotiated outside the call signaling plane. Re-INVITE (by correcting SDP after the fact) informs the signaling plane that it happened. Regards, Wayne _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 06 10:53:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVro-0005p4-Ry; Thu, 06 Apr 2006 10:53:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVrn-0005oz-UQ for mmusic@ietf.org; Thu, 06 Apr 2006 10:53:47 -0400 Received: from test-iport-2.cisco.com ([171.71.176.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRVrn-0002FO-Kh for mmusic@ietf.org; Thu, 06 Apr 2006 10:53:47 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-2.cisco.com with ESMTP; 06 Apr 2006 07:53:47 -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.12.10/8.12.6) with ESMTP id k36Erk7j018788; Thu, 6 Apr 2006 07:53:47 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 07:53:31 -0700 Received: from [192.168.0.10] ([10.21.123.165]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 07:53:30 -0700 In-Reply-To: <0D1719326D64BD4E9F92A0C120237678BB303C@eserv.covergence.com> References: <0D1719326D64BD4E9F92A0C120237678BB303C@eserv.covergence.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24A3C0C7-8CF2-45B8-B81F-ED467F849588@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] Optional SRTP? Date: Thu, 6 Apr 2006 07:53:27 -0700 To: Rick Porter X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 06 Apr 2006 14:53:30.0610 (UTC) FILETIME=[DE916520:01C65989] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Rick, all We've been promised a list to discuss these topics under the auspices of the RAI. I'd prefer to have this discussion there because it is more appropriate than MMUSIC. Note that zrtp and the other proposals were not submitted to mmusic nor discussed at the recent wg meeting. Mark On Apr 6, 2006, at 5:36 AM, Rick Porter wrote: > I could not see why a re-INVITE was necessary using the scheme > outlined > in the Security Descriptions draft (with possible modification). > > I'm still a ZRTP novice, but I can understand the re-INVITE when doing > ZRTP. However, the re-INVITE to keep signaling informed raises a red > flag about layering. My instinct tells me that if it is important > to the > signaling, then the signaling should be driving the train. I still > have > many ZRTP discussions to catch up on... > > Thanks, > Rick > > -----Original Message----- > From: Wayne Mills (wmills) [mailto:wmills@cisco.com] > Sent: Wednesday, April 05, 2006 1:04 PM > To: Rick Porter; mmusic@ietf.org > Subject: RE: [MMUSIC] Optional SRTP? > > If I understand the ZRTP proposal correctly .... > > The initial media connection is made with RTP, then the endpoints > "upgrade" to SRTP using the media-inband key exchange suggested by > ZRTP, > thus SRTP is negotiated outside the call signaling plane. Re- > INVITE (by > correcting SDP after the fact) informs the signaling plane that it > happened. > > Regards, > Wayne > > > _______________________________________________ > 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 06 13:32:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYLR-0004JZ-Ki; Thu, 06 Apr 2006 13:32:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYLQ-0004JU-AQ for mmusic@ietf.org; Thu, 06 Apr 2006 13:32:32 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRYLO-0000OC-Ry for mmusic@ietf.org; Thu, 06 Apr 2006 13:32:32 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 06 Apr 2006 10:32:25 -0700 X-IronPort-AV: i="4.04,93,1144047600"; d="scan'208,217"; a="1792477275:sNHT4837542814" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k36HWO1j021632; Thu, 6 Apr 2006 10:32:24 -0700 (PDT) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Apr 2006 17:32:24 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 06 Apr 2006 10:32:25 -0700 Subject: Re: [MMUSIC] Media security choices mailing list? From: Cullen Jennings To: Hadriel Kaplan , "mmusic@ietf.org" Message-ID: Thread-Topic: [MMUSIC] Media security choices mailing list? Thread-Index: AcZYEmIfD+5/lOgLT46KusoCa8scbABja9ja In-Reply-To: <04f101c65812$624da870$6501a8c0@acmepacket.com> Mime-version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: 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="===============1351589870==" Errors-To: mmusic-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1351589870== Content-type: multipart/alternative; boundary="B_3227164346_9290287" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3227164346_9290287 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable It has been set up but is not active yet. You can subscribe at http://www.imc.org/ietf-rtpsec On 4/4/06 11:05 AM, "Hadriel Kaplan" wrote: > I apologize if this has been answered previously, but is there a mailing = list > for the multiple-choice SRTP (and ZRTP) discussion? I thought I heard th= ere > would be when I listened to the audio-cast of the Dallas meeting, but I > haven=B9t been able to find it. > Thanks! > -hadriel > =20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic --B_3227164346_9290287 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [MMUSIC] Media security choices mailing list?
It has been set up but is not active yet. You can subscribe at http://www.imc.org/ietf-rtpsec

On 4/4/06 11:05 AM, "Hadriel Kaplan" <HKaplan@acmepacket.com&g= t; wrote:

I apologize if this has been answered previously, but is the= re a mailing list for the multiple-choice SRTP (and ZRTP) discussion?  = I thought I heard there would be when I listened to the audio-cast of the Da= llas meeting, but I haven’t been able to find it.
Thanks!
-hadriel
 

____________________= ___________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

 --B_3227164346_9290287-- --===============1351589870== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1351589870==-- From mmusic-bounces@ietf.org Fri Apr 07 08:47:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqN1-00019e-Ox; Fri, 07 Apr 2006 08:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqHa-0005r3-GK for mmusic@ietf.org; Fri, 07 Apr 2006 08:41:46 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRqHZ-0002za-WE for mmusic@ietf.org; Fri, 07 Apr 2006 08:41:46 -0400 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:343a]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k37CfJ81020892; Fri, 7 Apr 2006 14:41:20 +0200 (CEST) Message-ID: <44365DEE.1030402@netlab.hut.fi> Date: Fri, 07 Apr 2006 15:41:18 +0300 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo References: <4415642A.30906@ericsson.com> <441679D3.6030600@netlab.hut.fi> <441682E5.7000901@nokia.com> <44168B1A.4000702@netlab.hut.fi> <4417FC36.9010604@ericsson.com> <441EB56E.7070305@netlab.hut.fi> <4434C6ED.8060904@ericsson.com> In-Reply-To: <4434C6ED.8060904@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-Mailman-Approved-At: Fri, 07 Apr 2006 08:47:22 -0400 Cc: Cullen Jennings , Rohan Mahy , mmusic@ietf.org, Jon Peterson , Allison Mankin , Miguel Garcia , Joerg Ott , Markus Isomaki , "Salvatore Loreto \(SA/ERI\)" , Colin Perkins Subject: [MMUSIC] Re: File tranfer in SIP 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: , Errors-To: mmusic-bounces@ietf.org Hi Gonzalo, moving this to MMUSIC: > I agree that we want to provide the same information as existing file > description mechanisms provide. In particular, we have looked into MIME. > We will make sure that we go thru MIME again to see if we have forgotten > something (e.g., creation of the file timestamp). Sounds good. > I have looked into FLUTE, and it provides the same information as we > provide in the draft. From: > http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-revised-01.txt > > - Name, Identification and Location of file (specified by the URI) > - MIME media type of file > - Size of file > - Encoding of file > - Message digest of file > > In any case, this information needs to be encoded in the SDP way, and > therefore, we should use 'a' lines for that. I am still missing a last modification timestamp here. Regarding the encoding, I suppose we will have to worry about how to put this into SDP. This brings up -- again -- the discussion of whether to include some "blob" of, from an SDP perspective, opaque metadata (e.g., b64 encoded zip version of the FLUTE FDT, just to give some weird example) or whether to make these attributes explicit. If we make the attributes explicit, this is essentially a more general aspect of describing the purpuse of a media stream and would not be restricted to file transfer. We have some informal hints for audio and video already and this appears conceptually similar in that it identifies the purpose and helps the answerer to decide whether to accept it or not. Keeping this in mind, it would be extremely useful, not to invent independent sets of attributes for file transfer, MSRP sessions, audio, video, whiteboard, and so so. I clearly _do_not_ want to end up in an XCON-style discussion about metadata and the like, but it may be worthwhile given some consideration to future evolution of this stuff and compatibility with existing attributes. >> I am also concerned about motivating the use of inline images for >> icons. I can hardly see why you would need an icon to decide >> whether or not to accept a file transfer. > > A lot of commercial IM systems support it, and users find it very > useful. SIP-based systems need to be able to provide a similar user > experience if we do not want people to start doing things is proprietary > ways. It's your call in the end of the day. Often, icons are created based upon the filename extension -- and I suspect that the filename is going to be much more relevant that the icon in deciding whether or not to accept it. Icons are not worth much and only increase volume. But if we decide that it is useful: You must decide how much you worry about the SIP signaling architecture. Given that the INFO method is "damned" (which I fully support), I do not believe that turning parts of SDP into a transport is a particularly smart idea. It clearly does not ad efficiency. If you follow traditional SIPPING thinking, you will need to separate the desired effect from the mechanism to achieve it. There may be better ways. I am simply worried to open a door that we better leave closed. Would you want to limit the media type or the size of an icon? If so, what would be the right value? Would you negotiate it and come up with an "embedded contents too large" status code? Also, remember, that any SDP contents potentially wants to be signed. >> Performing file selection based upon only the hash may be nice for >> the receiver but it may be counter-intuitive and difficult to implement >> for the sender since it would require the sender to keep a hash of >> all its local files which if there are so many that on-the-fly >> calculation may not be a good idea. > > The user selects the file to send, the application hashes it on the fly, > and sends the hash to the receiver. I just calculated the MD5 and SHA1 > hashes of a big file (165 MB) on a non-very-powerful laptop, and it took > 8 and 10 seconds respectively. If you send pictures, which are much > smaller, the hash calculation would be very fast. I think I got somewhat confused that I constructed a close to impossible scenario. For the sender it is indeed trivial if the sending user selects the file. Of course, the filename should be included because otherwise the receiver does not easily find out whether or not it has a copy of the file already. If the receiving users wants to initiate a file transfer, of course, it does not have a checksum at hand to include. >> The draft refers to MSRP for connection setup and teardown but the >> examples only show trivia. The most interesting thing would be >> to show how sending, say, 4 files in each direction works and >> how the SDP descriptions grow (and if there will be a chance to >> shrink them again). > > We will include a note pointing out that 'm' lines can be reused after a > media stream is terminated. That is regular SDP behavior. True. But an example would still be nice (you know, most people code by example rather than by spec and we don't want them to screw up :-) After all, I would be surprised that re-INVITEs or UPDATEs with media stream addition, removal, addition, etc. have been common practice so far. But I may be wrong. >> Also, how do simultaneous initiations in both >> directions work (concerning counting the many m= lines)? > > I do not see any issue with having simultaneous media streams. It is > again regular SDP behavior. Well, I assume that if I send you a second offer within a session and you also send me one at the same time, we will have to do some conflict resolution since both of us will use the (n+1)st m-line for potentially different purposes. Since this has probably not received much implementation attention in the past (and happened rather rarely in practice), it have not been noticed. But it may be specified and just did not find this upon a quick search. Cheers, Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 10 18:50:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5Cv-0005BH-FQ; Mon, 10 Apr 2006 18:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5Cu-0005Ac-1G; Mon, 10 Apr 2006 18:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT5Cr-0000Gf-Po; Mon, 10 Apr 2006 18:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3AMo1BX001332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Apr 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FT5Cr-0000Zt-Ij; Mon, 10 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 10 Apr 2006 18:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-fec-grouping-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --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 : Forward Error Correction Grouping Semantics in Session Description Protocol Author(s) : A. Li, et al. Filename : draft-ietf-mmusic-fec-grouping-04.txt Pages : 7 Date : 2006-4-10 This document defines the semantics that allows for grouping of forward error correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document is to be used with Grouping of Media Lines in the Session Description Protocol (RFC 3388) to group together "m" lines in the same session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fec-grouping-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-fec-grouping-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-fec-grouping-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-10152621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-fec-grouping-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-fec-grouping-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-10152621.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Tue Apr 11 03:08:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCya-0007Xk-21; Tue, 11 Apr 2006 03:07:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCyY-0007XX-My for mmusic@ietf.org; Tue, 11 Apr 2006 03:07:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTCyX-0003iR-Aw for mmusic@ietf.org; Tue, 11 Apr 2006 03:07:46 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C2101C72; Tue, 11 Apr 2006 09:07:44 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 09:07:44 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 09:07:43 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 538B3238E; Tue, 11 Apr 2006 10:07:44 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1DFEE95C6A; Tue, 11 Apr 2006 10:07:44 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B225895C4A; Tue, 11 Apr 2006 10:07:43 +0300 (EEST) Message-ID: <443B55C0.4070209@ericsson.com> Date: Tue, 11 Apr 2006 10:07:44 +0300 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: mmusic@ietf.org, csp@csperkins.org, jo@netlab.hut.fi Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 11 Apr 2006 07:07:44.0091 (UTC) FILETIME=[A135C2B0:01C65D36] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: gonzalo.camarillo@ericsson.com Subject: [MMUSIC] Updated SDP Content Attribute draft 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: , Errors-To: mmusic-bounces@ietf.org Hi, I have incorporated all the WGLC comments to the SDP Content Attribute draft (given comments were mainly editorial). You can find the updated, and submitted, draft from: http://users.piuha.net/jantzgu/temp/draft-ietf-mmusic-sdp-media-content-03.txt Thanks to Tom Taylor once again for a thorough review! -- Jani _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 11 03:15:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTD6V-0001wS-3k; Tue, 11 Apr 2006 03:15:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTD6T-0001uR-GQ; Tue, 11 Apr 2006 03:15:57 -0400 Received: from mail5.audiocodes.com ([212.25.125.21] helo=imss.audiocodes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTD6O-0003ue-Ty; Tue, 11 Apr 2006 03:15:57 -0400 Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan Messaging Security Suite; Tue, 11 Apr 2006 10:18:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Apr 2006 10:15:17 +0300 Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD602018AB7@aclmsg.corp.audiocodes.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Video Transcoding using SIP & SDP Thread-Index: AcZdN6+fI6Zyomf2QtulmbGVHUUBJA== From: "Osher Hmelnizky" To: , X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Sharone Aloni , Oren Kudovitzky Subject: [MMUSIC] Video Transcoding using SIP & SDP 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="===============0840617953==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0840617953== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65D37.CE6D420B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65D37.CE6D420B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello, is it any work in progress regarding Video transcoding services using SIP and SDP. I'm looking something like RFC 4117 for video. =20 Thanks in advance =20 Osher =20 ------_=_NextPart_001_01C65D37.CE6D420B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello, is it any work in progress regarding Video transcoding services using SIP and SDP.

I’m looking something like RFC = 4117 for video.

 

Thanks in advance

 

Osher

 

------_=_NextPart_001_01C65D37.CE6D420B-- --===============0840617953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0840617953==-- From mmusic-bounces@ietf.org Tue Apr 11 10:13:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJcU-0005rN-2m; Tue, 11 Apr 2006 10:13:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJcS-0005rF-UY; Tue, 11 Apr 2006 10:13:24 -0400 Received: from cyber.robotics.net ([209.150.98.82] helo=barney.robotics.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJcR-0003Bf-NT; Tue, 11 Apr 2006 10:13:24 -0400 Received: from barney.robotics.net (barney.robotics.net [209.150.98.82]) by barney.robotics.net (8.12.10/8.12.10) with ESMTP id k3BEDNTe027054; Tue, 11 Apr 2006 10:13:23 -0400 Date: Tue, 11 Apr 2006 10:13:23 -0400 (EDT) From: Nathan Allen Stratton To: Osher Hmelnizky Subject: Re: [MMUSIC] Video Transcoding using SIP & SDP In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD602018AB7@aclmsg.corp.audiocodes.com> Message-ID: References: <79B4F738DDD4EF4F85A4641A0FE5EFD602018AB7@aclmsg.corp.audiocodes.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Sharone Aloni , mmusic@ietf.org, Oren Kudovitzky , xcon@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: , Errors-To: mmusic-bounces@ietf.org On Tue, 11 Apr 2006, Osher Hmelnizky wrote: > Hello, is it any work in progress regarding Video transcoding services > using SIP and SDP. > > I'm looking something like RFC 4117 for video. I am looking for the same, so far all the systems I have run into are proprietary. In talking with vendors they are saying it is because of lack of standard, but that could just be an easy out. -Nathan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 11 10:39:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTK1c-0006DA-2Y; Tue, 11 Apr 2006 10:39:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTK1a-0006D0-Vr for mmusic@ietf.org; Tue, 11 Apr 2006 10:39:22 -0400 Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTK1Y-00047N-IX for mmusic@ietf.org; Tue, 11 Apr 2006 10:39:22 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k3BEcmxf010566; Tue, 11 Apr 2006 10:38:48 -0400 Received: from [192.168.1.103] ([150.169.17.4]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AER59257; Tue, 11 Apr 2006 10:37:43 -0400 (EDT) Message-ID: <443BBF9B.9080406@research.panasonic.com> Date: Tue, 11 Apr 2006 10:39:23 -0400 From: Eunsoo Shim User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mmusic'" X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: jo@netlab.tkk.fi, csp@csperkins.org Subject: [MMUSIC] use cases of seamless session mobility 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: , Errors-To: mmusic-bounces@ietf.org Hi, In IETF 64, we presented requirements for seamless session mobility and one of the comments was that more use cases of session mobility would help in understanding the motivation and importance of seamless session mobility. So we listed a number of use cases of session mobility, categorized according to the merits for the users in draft-komiya-mmusic-session-mobility-usecases-00.txt. Unfortunately our presentation on the draft in IETF65 was cancelled because the WG meeting ran out of time. Below are the presentation slides. http://www3.ietf.org/proceedings/06mar/slides/mmusic-9.pdf We would appreciate if you take a look at the slides or the draft and provide us some comments. Here are our questions for the group: - What do the working group think of the use cases? - Is there any missing use case? - Do the group think the use cases should be supported? Thanks. Eunsoo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 11 12:58:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMC8-00026q-Ee; Tue, 11 Apr 2006 12:58:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMC7-00026d-AE for mmusic@ietf.org; Tue, 11 Apr 2006 12:58:23 -0400 Received: from ftwmail4.verizon.com ([192.76.86.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTMC6-0001A9-12 for mmusic@ietf.org; Tue, 11 Apr 2006 12:58:23 -0400 Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by ftwmail4.verizon.com (8.13.3/8.13.3) with ESMTP id k3BGwL1q021474 for ; Tue, 11 Apr 2006 12:58:21 -0400 (EDT) Received: from irvp1cvmma01.vzh.ent.verizon.com (irvp1cvmma01.verizon.com [138.83.34.82]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id k3BGunwb010616 for ; Tue, 11 Apr 2006 12:58:21 -0400 (EDT) Received: from 138.83.34.22 by irvp1cvmma01.vzh.ent.verizon.com with ESMTP (SMTP Relay); Tue, 11 Apr 2006 12:58:14 -0400 X-Server-Uuid: 33D99CC3-91DD-4C5F-B3C4-DE0A72F86AF5 Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id k3BGwDhW010267 for ; Tue, 11 Apr 2006 11:58:14 -0500 ( CDT) Date: Tue, 11 Apr 2006 12:58:13 -0400 MIME-Version: 1.0 To: mmusic@ietf.org cc: From: steven.d.whitehead@verizon.com X-Mailer: Microsoft Outlook v 11.00.6353, MSOC v 2.00.4007.00 Message-ID: X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.5.4HF453 | August 4, 2005) at 04/11/2006 11:58:13, Serialize complete at 04/11/2006 11:58:13 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-WSS-ID: 68253FACES01091561-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [MMUSIC] SDP clarification question 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: , Errors-To: mmusic-bounces@ietf.org In reading RFC 3264 it states in section 6.1: "The connection address and port in the answer indicate the address where the answerer wishes to receive the media ... This address and port MUST be present even for sendonly streams..." My interpretation of this and other text in the document is that the address/port information in an SDP offer / answer always refers only to where media wants to be receive, but NEVER to where media will be sourced/sent from. Is my understanding correct or am I confused? Thanks in advance. -Steve _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 11 13:08:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMLW-00067T-TC; Tue, 11 Apr 2006 13:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMLW-00066o-7d for mmusic@ietf.org; Tue, 11 Apr 2006 13:08:06 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTMLT-0001j0-Qa for mmusic@ietf.org; Tue, 11 Apr 2006 13:08:06 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3BHOQXe018971 for ; Tue, 11 Apr 2006 10:24:26 -0700 (MST) Received: from de01exm61.ds.mot.com (de01exm61.am.mot.com [10.176.8.106]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k3BHMDpE018201 for ; Tue, 11 Apr 2006 12:22:13 -0500 (CDT) 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 Subject: RE: [MMUSIC] use cases of seamless session mobility Date: Tue, 11 Apr 2006 13:08:02 -0400 Message-ID: <768EE6AB7D56D54BB5000EC2DD113E71808F39@de01exm61.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] use cases of seamless session mobility thread-index: AcZddeLc6m/aOKiTTq6s48G3dPgDYAAFFH2A From: "Montpetit Marie-Jose-MGIF0300" To: "Eunsoo Shim" , "mmusic" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: csp@csperkins.org, jo@netlab.tkk.fi 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: , Errors-To: mmusic-bounces@ietf.org =20 Is this really in the realm of the IETF? Session mobility is more like a "system capability" the type of work that is done in ETSI, CableLabs etc. Are you suggesting current IETF protocols could not suport your use cases? /mjm -----Original Message----- From: Eunsoo Shim [mailto:eunsoo@research.panasonic.com]=20 Sent: Tuesday, April 11, 2006 10:39 AM To: 'mmusic' Cc: jo@netlab.tkk.fi; csp@csperkins.org Subject: [MMUSIC] use cases of seamless session mobility Hi, In IETF 64, we presented requirements for seamless session mobility and one of the comments was that more use cases of session mobility would help in understanding the motivation and importance of seamless session mobility. So we listed a number of use cases of session mobility, categorized according to the merits for the users in draft-komiya-mmusic-session-mobility-usecases-00.txt. Unfortunately our presentation on the draft in IETF65 was cancelled because the WG meeting ran out of time. Below are the presentation slides. http://www3.ietf.org/proceedings/06mar/slides/mmusic-9.pdf We would appreciate if you take a look at the slides or the draft and provide us some comments. Here are our questions for the group: - What do the working group think of the use cases? - Is there any missing use case? - Do the group think the use cases should be supported? Thanks. Eunsoo _______________________________________________ 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 11 13:47:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMxb-00050S-QV; Tue, 11 Apr 2006 13:47:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMxa-00050N-Kq for mmusic@ietf.org; Tue, 11 Apr 2006 13:47:26 -0400 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTMxZ-00038P-C3 for mmusic@ietf.org; Tue, 11 Apr 2006 13:47:26 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 11 Apr 2006 10:47:24 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k3BHlO7T005208; Tue, 11 Apr 2006 10:47:24 -0700 (PDT) From: "Dan Wing" To: Subject: RE: [MMUSIC] SDP clarification question Date: Tue, 11 Apr 2006 10:47:24 -0700 Message-ID: <13da01c65d8f$fe049ee0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZdiUqXAUKpby4lRmCFPJpkc7L4ygABn/Aw In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Errors-To: mmusic-bounces@ietf.org Steven, You're correct, except that in order for SBCs or ICE to work, the same UDP port has to be used to send and to receive RTP. See draft-wing-behave-symmetric-rtprtcp-01.txt, which is in the RFC Editor's queue. -d > -----Original Message----- > From: steven.d.whitehead@verizon.com > [mailto:steven.d.whitehead@verizon.com] > Sent: Tuesday, April 11, 2006 9:58 AM > To: mmusic@ietf.org > Subject: [MMUSIC] SDP clarification question > > In reading RFC 3264 it states in section 6.1: > > "The connection address and port in the answer indicate the > address where > the answerer wishes to receive the media ... This address and > port MUST be > present even for sendonly streams..." > > My interpretation of this and other text in the document is that the > address/port information in an SDP offer / answer always > refers only to > where media wants to be receive, but NEVER to where media will be > sourced/sent from. > > Is my understanding correct or am I confused? > > Thanks in advance. > > -Steve > > > _______________________________________________ > 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 11 15:18:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTONV-0000SQ-SP; Tue, 11 Apr 2006 15:18:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTONV-0000SL-2Y for mmusic@ietf.org; Tue, 11 Apr 2006 15:18:17 -0400 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTONU-0006Jz-Op for mmusic@ietf.org; Tue, 11 Apr 2006 15:18:17 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 11 Apr 2006 12:18:16 -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.12.10/8.12.6) with ESMTP id k3BJIG7Z004699; Tue, 11 Apr 2006 12:18:16 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 12:18:06 -0700 Received: from [192.168.0.10] ([10.21.114.51]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 12:18:06 -0700 In-Reply-To: <13da01c65d8f$fe049ee0$c5f0200a@amer.cisco.com> References: <13da01c65d8f$fe049ee0$c5f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] SDP clarification question Date: Tue, 11 Apr 2006 12:18:04 -0700 To: "Dan Wing" X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 11 Apr 2006 19:18:06.0309 (UTC) FILETIME=[A9499150:01C65D9C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: steven.d.whitehead@verizon.com, 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: , Errors-To: mmusic-bounces@ietf.org Dan Seems that we have been mulling over this topic for years. Let me add to the muddle by claiming that the use of the SDP name "sendonly" can be defined in different ways by different application protocols such as SIP or SAP. Mark On Apr 11, 2006, at 10:47 AM, Dan Wing wrote: > Steven, > > You're correct, except that in order for SBCs or ICE to work, the > same UDP > port has to be used to send and to receive RTP. > > See draft-wing-behave-symmetric-rtprtcp-01.txt, which is in the RFC > Editor's > queue. > > -d > > >> -----Original Message----- >> From: steven.d.whitehead@verizon.com >> [mailto:steven.d.whitehead@verizon.com] >> Sent: Tuesday, April 11, 2006 9:58 AM >> To: mmusic@ietf.org >> Subject: [MMUSIC] SDP clarification question >> >> In reading RFC 3264 it states in section 6.1: >> >> "The connection address and port in the answer indicate the >> address where >> the answerer wishes to receive the media ... This address and >> port MUST be >> present even for sendonly streams..." >> >> My interpretation of this and other text in the document is that the >> address/port information in an SDP offer / answer always >> refers only to >> where media wants to be receive, but NEVER to where media will be >> sourced/sent from. >> >> Is my understanding correct or am I confused? >> >> Thanks in advance. >> >> -Steve >> >> >> _______________________________________________ >> 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 11 15:29:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOYZ-00052s-UE; Tue, 11 Apr 2006 15:29:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOYY-00052n-QI for mmusic@ietf.org; Tue, 11 Apr 2006 15:29:42 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOYX-0006je-GN for mmusic@ietf.org; Tue, 11 Apr 2006 15:29:42 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61988 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FTOYV-0001Wv-Fo; Tue, 11 Apr 2006 20:29:39 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <507977CC-385A-459A-953E-F1F261DAE551@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Tue, 11 Apr 2006 20:29:36 +0100 To: IETF MMUSIC WG X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Joerg Ott Subject: [MMUSIC] Working group last call: draft-ietf-mmusic-ice-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This is to announce a working group last call on ICE . Please send any final comments on this draft to the mailing list before 5th May 2006. If no substantive issues are raised by that time, we'll request the IESG consider the draft for publication as a proposed standard RFC. Due to the length and complexity of the draft, we are especially soliciting comments and reports from those who have implemented from the draft (either on the list, or privately to the chairs). Colin On 31 Mar 2006, at 00:50, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiparty Multimedia Session > Control Working Group of the IETF. > > Title : Interactive Connectivity Establishment (ICE): A > Methodology for Network Address Translator (NAT) Traversal for > Offer/Answer Protocols > Author(s) : J. Rosenberg > Filename : draft-ietf-mmusic-ice-08.txt > Pages : 96 > Date : 2006-3-30 > > This document describes a protocol for Network Address Translator > (NAT) traversal for multimedia session signaling protocols based on > the offer/answer model, such as the Session Initiation Protocol > (SIP). This protocol is called Interactive Connectivity > Establishment (ICE). ICE makes use of the Simple Traversal of UDP > through NAT (STUN), applying its binding discovery, connectivity > check and relay usages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-08.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 11 15:38:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOhA-0007Zc-Hf; Tue, 11 Apr 2006 15:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOh9-0007ZU-0O for mmusic@ietf.org; Tue, 11 Apr 2006 15:38:35 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOh8-00072Y-NB for mmusic@ietf.org; Tue, 11 Apr 2006 15:38:34 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62031 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FTOh8-00021l-5B; Tue, 11 Apr 2006 20:38:34 +0100 In-Reply-To: <507977CC-385A-459A-953E-F1F261DAE551@csperkins.org> References: <507977CC-385A-459A-953E-F1F261DAE551@csperkins.org> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B50A0AD-B03E-4153-BDD5-B58A23D42F7B@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Working group last call: draft-ietf-mmusic-ice-08.txt Date: Tue, 11 Apr 2006 20:38:30 +0100 To: IETF MMUSIC WG X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Joerg Ott 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: , Errors-To: mmusic-bounces@ietf.org On 11 Apr 2006, at 20:29, Colin Perkins wrote: > This is to announce a working group last call on ICE mmusic-ice-08.txt>. Please send any final comments on this draft to > the mailing list before 5th May 2006. If no substantive issues are > raised by that time, we'll request the IESG consider the draft for > publication as a proposed standard RFC. > > Due to the length and complexity of the draft, we are especially > soliciting comments and reports from those who have implemented > from the draft (either on the list, or privately to the chairs). Note that the IETF has been notified of potential IPR relating to this draft and owned by Tandberg Telecom AS. The licensing declaration states: The Patent Holder is prepare to grant - on the basis of reciprocity for the above IETF specification - a licence to an unrestricted number of applicants on a worldwide, non-discriminatory basis and on reasonable term and conditions to make, use and sell implementations of the above IETF specification. Negotiations are left to the parties concerned, and are performed outside the IETF. As used herein, the word "reciprocity" means that the Patent Holder shall only be required to license any prospective licencee if such prospective licensee will commit to license its essential patent(s) or essential patent claim(s) for implementation of any IETF specification for free under reasonable terms and conditions. For full details, see https://datatracker.ietf.org/public/ ipr_search.cgi?option=document_search&id_document_tag=11119 Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 11 16:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPV0-0007SE-FJ; Tue, 11 Apr 2006 16:30:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPUy-0007Ow-Sw for mmusic@ietf.org; Tue, 11 Apr 2006 16:30:04 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTPUy-0001dZ-Bc for mmusic@ietf.org; Tue, 11 Apr 2006 16:30:04 -0400 Received: from zrtphxm0.corp.nortel.com (zrtphxm0.corp.nortel.com [47.140.202.49]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3BKU1409664 for ; Tue, 11 Apr 2006 16:30:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Apr 2006 16:29:57 -0400 Message-ID: <447F856ACD7B494BAD02C85FD90DE2F808BDF5C1@zrtphxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP-RTSP Draft Feedback Thread-Index: AcZdprL7ffpRT0dwR1GB+lM+IRzkHw== From: "David Ress" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Subject: [MMUSIC] SIP-RTSP Draft Feedback 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="===============1569457833==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1569457833== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65DA6.B4173E03" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65DA6.B4173E03 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I too am pleased to see work going on to determine how to deal with the SIP-RTSP relationship and acknowledge the efforts of the authors to provide multiple options for consideration. As is evident from my comments below I do not believe that one of the models presented can possibly meet the needs of the application.=20 =20 I think it is very important to create a simple architectural rendering whereby a session and a stream are viewed as different architectural objects with different needs. SIP was created for the puprose of establishing a session and the session may in turn support some number of media streams. The streams however are transitive - they may come and go while the session persists. There seems to be an unstated assumption in some of the discussion points in the document that SIP is good for stream control. This is not its purpose and not what it is good for. =20 =20 There are many network elements which may be interested in or participate in establishing or managing a session. SIP proxies, B2BUAs, p-CSCF, s-CSCF, .... For the most part streams are endpoint to endpoint (yes, there are exceptions but the hierarchy should never approach that of the session control network). As such, stream control should be endpoint to endpoint. This is well accepted for VoIP where RTCP for example is point to point regardless as to whether SIP, H.323, H.248 or whatever was used to establish the session. Can we imagine replacing RTCP with some SIP extensions? (I'm sure someone has proposed this so forgive my ignorance) =20 As initially defined, RTSP encompasses both the session establishment as well as the stream management. This is as much a violation of the architectural principles I implied above as trying to use SIP to do both, but it has succeeded to this point because there has not been much of a session framework in place in the networks upon which it has been deployed. Clearly the industry is moving in a direction whereby a more complex session control plane is required and SIP has become accepted as the session control protocol of choice. =20 =20 While the document does highlight signaling latency as a key issue for the "all SIP" approach, I don't think it truly conveys the magnitude of the problem nor does it fully acknowledge the other performance issues associated with using SIP for streaming control. Consider an IMS network scenario whereby the p-CSCF and the s-CSCF are separated by some 1000 miles. Imagine signaling a trick play command across the access network - through the p-CSCF - across several more network hops to the s-CSCF - on to the video AS and finally across a few more network hops to the video source. Ok, latency is clearly a problem, but consider performance also. If 50K subscribers are viewing material, what is the hit to the p-CSCF, s-CSCF and video AS to process trick play commands? Suddenly, the session control plane components must scale to meet the needs of the media control plane. The problem can be expressed in non-IMS terms using SIP proxies, B2BUAs, etc. as well. =20 In summary, the SIP + RTSP coexistence model is the only scalable option presented and maps very well to a domain architecture model whereby sessions and media streams are related but separate objects with different needs. =20 =20 A few other minor comments: - The scenarios covered in section 3.4 - Use Cases should be worded more as simple scenario descriptions rather than positioning a solution option - In scenario one, it should be noted that TV and VoIP are two separate sessions and that the choice of protocols which are used to implement them is irrelevant in defining an interaction between them. That is, there must be an application level entity which is aware of both sessions and the need for the interaction between. This application level entity performs the logic of pausing one stream in order to present another. There is nothing inherent to SIP which enables the protocol layer to do this for free or enables the network to do it for the user.=20 - Section 6 - solution options discusses a Channel ID and Opaque token but does not define what either of these are. Perhaps one of the referenced documents discusses this, but I believe SDP can be used to describe an RTSP session without requiring Opaque data of any kind. That is, establishment of a video stream using SIP+SDP can include not only the video stream, but also the RTSP stream. I think this is kind of what was intended here but it wasn't obvious. =20 Regards, David =20 =20 ------_=_NextPart_001_01C65DA6.B4173E03 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I too = am pleased to=20 see work going on to determine how to deal with the SIP-RTSP = relationship and=20 acknowledge the efforts of the authors to provide multiple = options for=20 consideration.   As is evident from my comments = below I do=20 not believe that one of the models presented can possibly meet the = needs of=20 the application.
 
I = think it is very=20 important to create a simple architectural rendering whereby a session = and a=20 stream are viewed as different architectural objects with different = needs. =20 SIP was=20 created for the puprose of establishing a session and the session may in = turn=20 support some number of media streams.  The streams however are = transitive -=20 they may come and go while the session persists.  There seems to be = an=20 unstated assumption in some of the discussion points in the document = that SIP is=20 good for stream control.   This is not its purpose and not = what it is=20 good for.  
 
There = are many=20 network elements which may be interested in or participate in = establishing or=20 managing a session.  SIP proxies, B2BUAs, p-CSCF, s-CSCF, = ....  For=20 the most part streams are endpoint to endpoint (yes, there are = exceptions but=20 the hierarchy should never approach that of the session control = network). As=20 such, stream control should be endpoint to endpoint.  This is well = accepted=20 for VoIP where RTCP for example is point to point regardless as to = whether SIP,=20 H.323, H.248 or whatever was used to establish the session.   = Can we=20 imagine replacing RTCP with some SIP extensions? (I'm sure someone has = proposed=20 this so forgive my ignorance)
 
As = initially=20 defined, RTSP encompasses both the session establishment as well as the = stream=20 management.  This is as much a violation of the architectural = principles I=20 implied above as trying to use SIP to do both, but it has succeeded to = this=20 point because there has not been much of a session framework in place in = the=20 networks upon which it has been deployed.  Clearly the = industry is=20 moving in a direction whereby a more complex session control plane is = required=20 and SIP has become accepted as the session control protocol of = choice.=20  
 
While = the document=20 does highlight signaling latency as a key issue for the "all SIP" = approach, I=20 don't think it truly conveys the magnitude of the problem nor does it = fully=20 acknowledge the other performance issues associated with using SIP for = streaming=20 control.   Consider an IMS network scenario whereby the p-CSCF and = the s-CSCF=20 are separated by some 1000 miles.  Imagine signaling a trick play = command=20 across the access network - through the p-CSCF - across several more = network=20 hops to the s-CSCF - on to the video AS and finally across a = few more=20 network hops to the video source.   Ok, latency is = clearly a=20 problem, but consider performance also.  If 50K subscribers are = viewing=20 material, what is the hit to the p-CSCF, s-CSCF and video AS to process = trick=20 play commands? Suddenly, the session control plane components must scale = to meet=20 the needs of the media control plane.  The problem can be expressed = in=20 non-IMS terms using SIP proxies, B2BUAs, etc. as = well.
 
In = summary, the SIP=20 + RTSP coexistence model is the only scalable option presented and = maps=20 very well to a domain architecture model whereby sessions and media = streams are=20 related but separate objects with different needs.  =
 
A few = other minor=20 comments:
- The = scenarios=20 covered in section 3.4 - Use Cases should be worded more as simple = scenario=20 descriptions rather than positioning a solution = option
- In = scenario one,=20 it should be noted that TV and VoIP are two separate sessions and that = the=20 choice of protocols which are used to implement them is irrelevant in = defining=20 an interaction between them.  That is, there must be an application = level=20 entity which is aware of both sessions and the need for the interaction = between.=20 This application level entity performs the logic of pausing one stream = in order=20 to present another.  There is nothing inherent to SIP which enables = the=20 protocol layer to do this for free or enables the network to do it for = the user.=20
- = Section 6 -=20 solution options discusses a Channel ID and Opaque token but does not = define=20 what either of these are.  Perhaps one of the referenced documents=20 discusses this, but I believe SDP can be used to describe an RTSP = session=20 without requiring Opaque data of any kind.  That is, establishment = of a=20 video stream using SIP+SDP can include not only the video stream, but = also the=20 RTSP stream.   I think this is kind of what was intended here = but it=20 wasn't obvious.
 
Regards,
David
 
 
------_=_NextPart_001_01C65DA6.B4173E03-- --===============1569457833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1569457833==-- From mmusic-bounces@ietf.org Tue Apr 11 17:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQmS-0008Ef-5w; Tue, 11 Apr 2006 17:52:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQmQ-0008EP-Cf; Tue, 11 Apr 2006 17:52:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTP6j-0000oU-J9; Tue, 11 Apr 2006 16:05:01 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTOsE-0001eY-9x; Tue, 11 Apr 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3BJo1BX012217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Apr 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FTOsD-0006M3-TD; Tue, 11 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 11 Apr 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --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) Content Attribute Author(s) : J. Hautakorpi, G. Camarillo Filename : draft-ietf-mmusic-sdp-media-content-03.txt Pages : 12 Date : 2006-4-11 This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream in more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big screen or small screen) based on its content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-content-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-media-content-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-media-content-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-11141400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-media-content-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-media-content-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-11141400.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Tue Apr 11 19:29:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTSIE-0002EV-Az; Tue, 11 Apr 2006 19:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTSIA-00026x-BF; Tue, 11 Apr 2006 19:29:02 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTSIA-0001v5-07; Tue, 11 Apr 2006 19:29:02 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k3BNT1lT023616; Tue, 11 Apr 2006 16:29:01 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k3BNT1Ws023615; Tue, 11 Apr 2006 16:29:01 -0700 Date: Tue, 11 Apr 2006 16:29:01 -0700 Message-Id: <200604112329.k3BNT1Ws023615@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 4435 on A Framework for the Usage of Internet Media Guides (IMGs) 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: , Errors-To: mmusic-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4435 Title: A Framework for the Usage of Internet Media Guides (IMGs) Author: Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, H. Schulzrinne Status: Informational Date: April 2006 Mailbox: nom@flab.fujitsu.co.jp, rod.walsh@nokia.com, juha-pekka.luoma@nokia.com, asaeda@wide.ad.jp, schulzrinne@cs.columbia.edu Pages: 22 Characters: 51687 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-img-framework-09.txt URL: http://www.rfc-editor.org/rfc/rfc4435.txt This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol (SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure. This memo provides information for the Internet community. This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 12 00:05:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTWbi-0002I8-OO; Wed, 12 Apr 2006 00:05:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTWbg-0002I0-Up for mmusic@ietf.org; Wed, 12 Apr 2006 00:05:28 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTWbf-0003qI-Mg for mmusic@ietf.org; Wed, 12 Apr 2006 00:05:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id EA3D990005 for ; Wed, 12 Apr 2006 00:05:26 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18762-02 for ; Wed, 12 Apr 2006 00:05:25 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 12 Apr 2006 00:05:25 -0400 (EDT) Received: from EXCHINDIA2.starentnetworks.com ([10.4.0.4]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 Apr 2006 00:03:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Apr 2006 09:33:48 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP call flow examples for certain extensions? Thread-Index: AcZdprL7ffpRT0dwR1GB+lM+IRzkHwAPFKcw From: "Patankar, Sujay" To: X-OriginalArrivalTime: 12 Apr 2006 04:03:52.0654 (UTC) FILETIME=[1C5FCEE0:01C65DE6] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [MMUSIC] SIP call flow examples for certain extensions? 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="===============0109486146==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0109486146== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65DE6.1A2BCBF5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65DE6.1A2BCBF5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Is there any place where I can find SIP call flow examples that contain PRACK, UPDATE, SigComp, etc? Is there something similar to RFC 3665, which contains any of the above? Thanks, Sujay. ------_=_NextPart_001_01C65DE6.1A2BCBF5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi,

Is there any place where I can = find SIP call flow examples that contain PRACK, UPDATE, SigComp, = etc?

Is there something similar to RFC 3665, which contains any of the = above?

Thanks,

Sujay.

------_=_NextPart_001_01C65DE6.1A2BCBF5-- --===============0109486146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0109486146==-- From mmusic-bounces@ietf.org Wed Apr 12 14:14:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTjrG-0005ob-Ct; Wed, 12 Apr 2006 14:14:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTjrE-0005oM-Vl for mmusic@ietf.org; Wed, 12 Apr 2006 14:14:24 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTjrE-0007St-N2 for mmusic@ietf.org; Wed, 12 Apr 2006 14:14:24 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3CIEOBW021872 for ; Wed, 12 Apr 2006 18:14:24 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 14:14:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Apr 2006 14:14:24 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F43E7@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Announcement of Real Time Security list Thread-Index: AcZeXKy78fVDdW1nRM+R7gqCjkX5Hw== From: "Peterson, Jon" To: X-OriginalArrivalTime: 12 Apr 2006 18:14:24.0341 (UTC) FILETIME=[EDA14850:01C65E5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Subject: [MMUSIC] Announcement of Real Time Security list 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="===============0447870532==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0447870532== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65E5C.ED797586" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65E5C.ED797586 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Following our discussion in the RAI Open Area Meeting in Dallas a few = weeks ago on the many strategies circulating for securing RTP, we've = formed a new mailing list in order to further refine our understanding = of the problem space and figure out a way forward. Subscription information for the list is available here.=20 The agenda item from the RAI Open Meeting, including the list of = associated drafts, is pasted below. Interested parties, please move = discussion of these documents to this list. Jon Peterson NeuStar, Inc. ---- There are many proposal discussing keying for RTP when used with = SIP. These issues cross SIPPING, MMUSIC, AVT, and MSEC. What are the common underling requirements driving these proposals? At the high level what are the various architectures? What cross WG architectural level question do we need to answer? Can we come to consensus on high level approaches we would like to investigate? RFC 3830 (MIKEY) RFC 3711 (SRTP) draft-ietf-msec-mikey-rsa-r-02 draft-ietf-mmusic-sdescriptions-12 draft-ietf-mmusic-kmgmt-ext-15 draft-wing-mmusic-sdes-early-media-00 draft-mcgrew-srtp-ekt-00 draft-baugher-mmusic-sdp-dh-00 draft-zimmerman-avt-zrtp-00 draft-tschofenig-avt-rtp-dtls-00 draft-fischl-sipping-media-dtls-0 draft-fischl-mmusic-sdp-dtls-00 draft-rescorla-tls-partial-00 draft-modadugu-dtls-short-00 draft-fries-msec-mikey-applicability-00 draft-ietf-msec-mikey-dhhmac-11 draft-lehtovirta-srtp-rcc-01 draft-saito-mmusic-ipsec-negotiation-req-02 ------_=_NextPart_001_01C65E5C.ED797586 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Announcement of Real Time Security list

Following our discussion in the = RAI Open Area Meeting in Dallas a few weeks ago on the many strategies = circulating for securing RTP, we've formed a new mailing list in order = to further refine our understanding of the problem space and figure out = a way forward.

Subscription information for the = list is available here.

<http://www.imc.org/ietf-rtpsec/<= /A>>

The agenda item from the RAI Open = Meeting, including the list of associated drafts, is pasted below. = Interested parties, please move discussion of these documents to this = list.

Jon Peterson
NeuStar, Inc.

----

    There are many = proposal discussing keying for RTP when used with SIP.
    These issues = cross SIPPING, MMUSIC, AVT, and MSEC.
    What are the = common underling requirements driving these proposals?
    At the high = level what are the various architectures?
    What cross WG = architectural level question do we need to answer?
    Can we come = to consensus on high level approaches we would like to
    = investigate?


        RFC 3830 (MIKEY)
        RFC 3711 (SRTP)
        = draft-ietf-msec-mikey-rsa-r-02
        = draft-ietf-mmusic-sdescriptions-12
        = draft-ietf-mmusic-kmgmt-ext-15
        = draft-wing-mmusic-sdes-early-media-00
        = draft-mcgrew-srtp-ekt-00
        = draft-baugher-mmusic-sdp-dh-00
        = draft-zimmerman-avt-zrtp-00
        = draft-tschofenig-avt-rtp-dtls-00
        = draft-fischl-sipping-media-dtls-0
        = draft-fischl-mmusic-sdp-dtls-00
        = draft-rescorla-tls-partial-00
        = draft-modadugu-dtls-short-00
        = draft-fries-msec-mikey-applicability-00
        = draft-ietf-msec-mikey-dhhmac-11
        = draft-lehtovirta-srtp-rcc-01
        = draft-saito-mmusic-ipsec-negotiation-req-02

------_=_NextPart_001_01C65E5C.ED797586-- --===============0447870532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0447870532==-- From mmusic-bounces@ietf.org Thu Apr 13 13:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5k9-0003HE-NO; Thu, 13 Apr 2006 13:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5k7-0002YV-KR for mmusic@ietf.org; Thu, 13 Apr 2006 13:36:31 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU5Xl-00041f-F5 for mmusic@ietf.org; Thu, 13 Apr 2006 13:23:46 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:59727) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FU5Xk-0002Or-AH; Thu, 13 Apr 2006 18:23:44 +0100 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A03116D-6B26-4A32-9063-FE7A35707FCA@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Thu, 13 Apr 2006 18:23:42 +0100 To: ietf-types@alvestrand.no X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF MMUSIC WG Subject: [MMUSIC] Request for review: draft-ietf-mmusic-sdp-media-content-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org The MMUSIC working group is considering draft-ietf-mmusic-sdp-media- content-03.txt: This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream in more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big screen or small screen) based on its content. It has been suggested that members of the ietf-types list may have experience with this type of attribute in other areas. Accordingly, this message is to solicit cross-area review of the draft. We would be grateful if any comments could be provided before 1st May 2006. Thanks, Colin (mmusic co-chair) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 14 09:33:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUOQH-0004Q7-5v; Fri, 14 Apr 2006 09:33:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUOQG-0004Q2-QR for mmusic@ietf.org; Fri, 14 Apr 2006 09:33:16 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUOQF-0001j1-Er for mmusic@ietf.org; Fri, 14 Apr 2006 09:33:16 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63408 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FUOQ7-0000Ee-24 for mmusic@ietf.org; Fri, 14 Apr 2006 14:33:07 +0100 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <790A20F8-101C-4E2F-90D3-75360EE204E9@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 14 Apr 2006 14:33:05 +0100 To: IETF MMUSIC WG X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [MMUSIC] Working group last call: draft-ietf-mmusic-fec-grouping-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This is to announce a working group last call on the Forward Error Correction Grouping Semantics in SDP . Please send any final comments on this draft to the mailing list by 28 April 2006. If no substantive comments are received by that time, we will request the IESG consider this for publication as a proposed standard RFC. Colin On 10 Apr 2006, at 23:50, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiparty Multimedia Session > Control Working Group of the IETF. > > Title : Forward Error Correction Grouping Semantics in Session > Description Protocol > Author(s) : A. Li, et al. > Filename : draft-ietf-mmusic-fec-grouping-04.txt > Pages : 7 > Date : 2006-4-10 > > This document defines the semantics that allows for grouping of > forward error correction (FEC) streams with the protected payload > streams in Session Description Protocol (SDP). The semantics > defined > in this document is to be used with Grouping of Media Lines in the > Session Description Protocol (RFC 3388) to group together "m" lines > in the same session. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fec- > grouping-04.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 14 19:56:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUY9S-0007ty-1j; Fri, 14 Apr 2006 19:56:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUY9Q-0007tr-Mg for mmusic@ietf.org; Fri, 14 Apr 2006 19:56:32 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUY9P-0006Va-C8 for mmusic@ietf.org; Fri, 14 Apr 2006 19:56:32 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k3ENuQE07293; Fri, 14 Apr 2006 19:56:26 -0400 (EDT) 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 Date: Fri, 14 Apr 2006 18:56:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF08B20E1B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-mmusic-ice-tcp-00 Thread-Index: AcZdn69pwEHLzxCKTIOt8ZE4w/DGrQCeFCqg From: "Francois Audet" To: "IETF MMUSIC WG" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Colin Perkins Subject: [MMUSIC] Review of draft-ietf-mmusic-ice-tcp-00 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: , Errors-To: mmusic-bounces@ietf.org Jonathan, As promised in Dallas, I have done a review of = draft-ietf-mmusic-ice-tcp-00. Most of my comments are editorial in nature, except perhaps a minor = comment on section 3. Section 1 - 2nd paragraph, last line: change "communicatoins" to "communications". Section 2 - It would be much clearer if a reference to RFC 4145 be placed at the very begining of this section (after the first paragraph). It is very difficult to follow starting with the 2nd paragraph unless the concepts described in RFC 4145 on active/passive/actpass are = understood. - 4th paragraph, 4th line. Change "by the agent" to "by the remote = agent" or "by the other agent" to make it clear it is the other side you are = talking about. - 6th paragraph (top of p. 5). It is not clear what "specifications are=20 being developped". Perhaps an informative reference to the draft is in = =A0 order = (http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-00.txt). Section 3 - Top of page 7. The sentence "Only in cases ... be omitted" probably = should be removed as it seems very restrictive. I understand what you are = trying to do, i.e., get people to implement ICE-TCP in UAs, which I am OK = with.=20 What I think is important is that UAs have the ability to have ICE-TCP turned on or off depending on network preferences. For example, an=20 enterprise may decide that ICE-TCP inside the network is unacceptable and should be turned off: this could be communicated to the client = through Config-framework (so that it would work when the client is "nomad"). = Or maybe there is two configuration profiles for the client (one for = inside the enterprise, one for outside). In any case, I think the = explanation, or at least the last sentence, is overly restrictive and should be=20 adjusted. Section 5 - First paragraph, first line. Change "procedurs" to "procedures". - Second paragraph. Change "set to 9" to "set to 9 (i.e., Discard)" for=20 clarity. Section 6 - First paragraph, first line. Change "procedurs" to "procedures". Section 7 - First word of page 12. Change "Even Ta" to "Every Ta". _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 18 03:38:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVkms-0003CW-T3; Tue, 18 Apr 2006 03:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVkms-0003CR-Bb for mmusic@ietf.org; Tue, 18 Apr 2006 03:38:14 -0400 Received: from [130.209.249.184] (helo=mr1.dcs.gla.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVkmm-0003OG-Ab for mmusic@ietf.org; Tue, 18 Apr 2006 03:38:14 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62973 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FVkm6-0001kN-CE for mmusic@ietf.org; Tue, 18 Apr 2006 08:37:26 +0100 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <21E4C37D-8A69-40DA-8E2C-6573C84850D2@csperkins.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF MMUSIC WG From: Colin Perkins Date: Tue, 18 Apr 2006 08:37:24 +0100 X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Subject: [MMUSIC] Minutes from Dallas 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: , Errors-To: mmusic-bounces@ietf.org Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes ==================================================================== Reported by Colin Perkins The MMUSIC working group met once at the 65th IETF meeting (Dallas, March 2006). Topics under discussion included the SDP Content Attribute, ICE, secure media stream setup, SDP for file transfer, RTSP, SIP for streaming media, QoS identification for preconditions, codec- specific parameters in SDP, use cases for session mobility and requirements for IPsec negotiation in SDP. The meeting was chaired by Joerg Ott and Colin Perkins and attended by some 130 participants. Introduction and progress report The chairs introduced the session and gave a brief status review. The group has had one RFC published since the last meeting (offer/answer examples -> RFC 4317) and has a further ten drafts in the RFC Editor queue (including, finally, draft-ietf-mmusic-sdp-new-26.txt). There is one open rechartering issue, on how to continue with the Internet Media Guide work, and discussion on that subject is ongoing with the authors and area directors. SDP Content Attribute draft-ietf-mmusic-sdp-media-content-02.txt Jani Hautakorpi presented the SDP Content Attribute draft. This version clarifies the usage with offer/answer, but otherwise has no changes from the previous version. The group seemed happy with the draft, which looks to be ready for working group last call. ICE draft-ietf-mmusic-ice-07.txt draft-ietf-mmusic-ice-tcp-00.txt Jonathan Rosenberg presented ICE, summarising changes since the previous version (see slides for details). There were some questions and comments: - Flemming Andreasen asked why the "a=ice-pwd" SDP attribute is session level only, rather than both session level and media level? It has to be shared across all candidates, but that doesn't necessarily imply it is a session level attribute. - Derek MacDonald asked for clarification if reliable 183 can work with "m=" lines that are set to inactive in the 180? Yes. - Magnus Westerlund asked if there is a way of saying "don't send early media" for a particular complete ICE exchange, since this option might be useful for RTSP. Jonathan didn't want to add this for SIP, but it can be added for RTSP in a separate draft if needed. - Magnus Westerlund noted that the current text regarding setting the RTP marker bit is audio-codec specific; this should be clarified. - Rohan Mahy asked for clarification of the 183 retransmit intervals for STUN reliability. - Magnus Westerlund asked if a change in the source address could trigger the RTP SSRC collision detection algorithm? It's not clear that this is an issue, since one can tell it is a change in address rather than a collision through the signalling exchanges. Steve Casner also noted that the wording on SSRC collision detection has changed in RFC 3550, and that may affect this. - Erkki Koivusalo reminded the group of issues with using MAPPED- ADDRESS rather than XOR-MAPPED-ADDRESS and with learning new candidates from connectivity checks, as discussed on the mailing list. Jonathan Rosenberg stated that he considered the draft ready for working group last call apart from minor details. It is expected that an updated draft will be submitted shortly after the meeting to address these, then a working group last call. Jonathan Rosenberg also presented changes to the ICE-TCP draft. This is a major update, due to the changes to STUN and also the recognition that simultaneous open broke the mechanisms in the previous draft, requiring a rework of the specification. There are no known open issues, and there was little discussion (indeed, it appears that few people have read the draft). Joerg Ott asked for volunteers to provide detailed review: Jason Fischel, Rohan Mahy and Francois Audet volunteered. Secure media stream setup draft-baugher-mmusic-sdp-dh-00.txt Mark Baugher presented a new draft on Diffie-Hellman exchanges for multimedia sessions. This adds the ability for sdescriptions to do a Diffie-Hellman key exchange (using a new session level "a=DH:" SDP attribute), providing perfect forward secrecy for media keys, and removing the need for secure transport of the SDP by using public key cryptography. This does not solve the "early media" problem with SIP key establishment, but does reduce the potential vulnerabilities of sending plain text keys and relying on secure SDP transport. Alan Johnston commented that he liked the idea better than the standard sdescriptions. He noted that person to person identification is a MUST, but the draft does not specify how the fingerprint is to be displayed. To ensure interoperability, and standard mechanism should be defined. Erik Rescorla wondered how to propose two different types of DH crypto? This can be done by putting both in the SDP. Cullen Jennings and Joerg Ott noted that there are numerous proposals for updating security negotiation for SRTP, and that this fits within that general space. Discussion of this in comparison with the other proposals should take place within the RAI area meeting. SDP for file transfer sessions draft-isomaki-sipping-file-transfer-01.txt draft-garcia-sipping-file-transfer-mech-00.txt Gonzalo Camarillo presented drafts on file transfer in the offer/ answer model. The idea is to describe, using a set of new SDP attributes, the file to be transferred, and so allow MSRP sessions to be negotiated to transfer the file, e.g. as a part of a SIMPLE instant messaging system. Discussion centred on whether duplicating MIME headers in SDP is a good idea, and why content-indirection is not appropriate. There was a fair amount of requirements discussion, to understand why this is useful and to determine the correct home for the work (SIPPING or MMUSIC). There appears to be interest in the work, and it appears to make sense from an SDP perspective, so we should figure out the right home and proceed. RTSP draft-ietf-mmusic-rfc2326bis-12.txt draft-ietf-mmusic-rtsp-nat-04.txt draft-westerlund-mmusic-3gpp-sdp-rtsp-02.txt Magnus Westerlund presented RTSP/2.0, outlining open issues with the base specification. These include: the definition of non-interleaved TCP/RTP/AVP, the inclusion of 50 and 60 frames-per-second SMPTE time code formats, the format of error message bodies, the format of the URI list in 300 responses (multiple choices), whether the dest_addr should contain used addresses, should there be a scoped address for IPv6 multicast, use of unregistered media types in examples, should Expires also provide cache-control instructions, and proxy handling of Accept-Credentials. Details are provided in the slides. Regarding the SMPTE 50 and 60 FPS formats, Stephan Wenger volunteered to help with up a definition for the formats. Regarding the format of the error message body, Colin Perkins and Jonathan Rosenberg suggested stating that the format is HTML by default, with an Accept header being used to signal support for alternatives. Regarding the 200 response URI lists, Joerg Ott wondered why multiple Location headers couldn't be used? Regarding cache control, Colin Perkins noted that explicit specification is usually appropriate, rather than overloading the field, but Magnus doesn't want to diverge from HTTP behaviour more than necessary. Joerg Ott asked if live streams affect the cache behaviour? Not clear. Magnus noted that he hopes to resolve these open issues quickly, and is working with the TLS working group to review the TLS solution. Review of the draft was solicited to get it ready for working group last call: Stephan Wenger and Sean Sheedy volunteered to provide reviews. Magnus also briefly discussed the RTSP NAT traversal draft, noting that there have been no changes since the last meeting, and asking for help to complete the draft. SIP for Streaming Media draft-whitehead-mmusic-sip-for-streaming-media-00.txt Marie-Jose Montpetit presented a new draft on evaluating the use of SIP for streaming media applications. The aim here is to discuss whether it makes sense to use SIP as an alternative to RTSP to control streaming media, if the protocols might somehow be combined (e.g. with SIP for session initiation handing over to RTSP for control), or if the current separation is the best approach. There was considerable discussion on the requirements and use cases. It is clear that the idea of blended services is popular, but it is not at all clear that a combined is needed to achieve them. The authors were suggested to further consider use cases, looking how the existing pieces of protocol infrastructure can be combined to address those use cases, and where potential holes might lie, to come up with a better problem statement for further discussion. QoS Identification for Preconditions draft-polk-mmusic-qos-mechanism-identification-01.txt Gonzalo Camarillo briefly presented a new draft on QoS mechanism identification for use with preconditions. This adds a new attribute to identify which QoS mechanism is to be used to attempt to satisfy a QoS precondition. Flemming Andreasen agreed that this is a good idea, but asked if things like proxy-RSVP could be supported. The general consensus of the room was that this is conceptually a good idea, but not yet sufficiently baked to become a working group draft. Codec Specific Parameters draft-xu-mmusic-sdp-codec-param-01.txt Peili Xu updated the group of the codec specific parameters draft. This was discussed at the last meeting, where it was suggested to consider how existing mechanisms (SDP extensions, SDP grouping, SDPng) might be used. The draft now makes such a comparison. Adam Roach noted that it is much easier to use existing mechanisms, rather than defining a new SDP extension, since there is no deployment challenge. Colin Perkins supported this, noting that codec specific parameters could be supported using the SDP grouping mechanism. Colin also noted that implementations that require codec specific ptime are broken according to the RTP a/v profile (a point which Flemming Andreasen disputed somewhat, noting that there might be legitimate use cases for this). To summarise, it is not clear that there is a problem to solve here that cannot be solved using existing mechanisms. Further clarification of the problem is needed, before we consider defining SDP extensions. Use Cases for Session Mobility draft-komiya-mmusic-session-mobility-usecases-00.txt This presentation was dropped, due to lack of time. IPsec negotiation draft-saito-mmusic-ipsec-negotiation-req-02.txt This presentation was dropped, due to lack of time. - + - _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 18 08:08:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp0C-0003Vs-CY; Tue, 18 Apr 2006 08:08:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp0A-0003Vj-Pn for mmusic@ietf.org; Tue, 18 Apr 2006 08:08:14 -0400 Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVp0A-00023f-DX for mmusic@ietf.org; Tue, 18 Apr 2006 08:08:14 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp3.clb.oleane.net with ESMTP id k3IC8AOx012770 for ; Tue, 18 Apr 2006 14:08:13 +0200 Message-Id: <200604181208.k3IC8AOx012770@smtp3.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 18 Apr 2006 14:07:10 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZi4J7NI+tJID9/RieNy4Ex8HOQ2Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [MMUSIC] Mobile TV World Congress - Paris - France 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="===============1264962820==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1264962820== Content-Type: multipart/alternative; boundary="----=_NextPart_000_05A8_01C662F1.62A79CB0" This is a multi-part message in MIME format. ------=_NextPart_000_05A8_01C662F1.62A79CB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Mobile TV World Congress, will be held in Paris January 23 to 26, together with the worldwide leader event TVoDSL 2007. Carriers, content providers and equipment vendors will address technical issues, describe the standardization process and discuss business and content delivery models. A call for proposals is online at: http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm ------=_NextPart_000_05A8_01C662F1.62A79CB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Mobile TV World = Congress, will be held in Paris January 23 to 26, together with the worldwide leader event = TVoDSL = 2007.

Carriers, content providers and equipment = vendors will address technical issues, describe the standardization process and = discuss business and content delivery models.

 

A call for proposals is online = at:

http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm

 

------=_NextPart_000_05A8_01C662F1.62A79CB0-- --===============1264962820== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1264962820==-- From mmusic-bounces@ietf.org Tue Apr 18 10:32:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVrFs-0000KN-0I; Tue, 18 Apr 2006 10:32:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVrFq-0000ED-5o for mmusic@ietf.org; Tue, 18 Apr 2006 10:32:34 -0400 Received: from mx2.magma.ca ([206.191.0.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVrFp-0002RS-SZ for mmusic@ietf.org; Tue, 18 Apr 2006 10:32:34 -0400 Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx2.magma.ca (8.13.6/8.13.0) with ESMTP id k3IEVVp8000921; Tue, 18 Apr 2006 10:31:32 -0400 Received: from [192.168.1.119] (209-87-232-162.storm.ca [209.87.232.162]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id k3IEVT3c027697 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 18 Apr 2006 10:31:31 -0400 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44711429-AACA-40EF-86CE-507552900D39@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Tue, 18 Apr 2006 10:31:53 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: mmusic@ietf.org Subject: [MMUSIC] Some comments on draft-ietf-mmusic-ice-08 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: , Errors-To: mmusic-bounces@ietf.org Jonathan: Here are some comments. They are mostly pretty minor. I am still re-reading the draft to more fully understand it, so more may follow. General comments: - The grammar given in section 12 specifies that a colon (":") is to immediately follow the word "candidate" in the "a=candidate" line. This is consistent with the SDP syntax for an attribute with a value as specified in draft-ietf-mmusic-sdp-new-26. However, none of the examples given elsewhere in the document use a colon. Section 1: - (First PP) Misspelling - "Descrption" should be "Description". Section 2: - I found it difficult to understand much of the terminology on my first pass through the document, even though I had a basic understanding of how ICE works. In the end, I just skipped over it and then came back later. Perhaps consider placing the introductory sections before the terminology section, perhaps by making sections 3 - 6 subsections of section 1. If you did this, then the terminology section would clearly divide the Informative text from the Normative text. - It would be nice if the definitions of Reflexive Transport Address and Relayed Transport Address could make it clearer that these are subclasses of Derived Transport Addresses (for example, the definition text could start "A type of Derived Transport Address where ..."). - I found the definitions of the various Transport Address forms difficult to understand (I was familiar with the concepts, but hadn't see the terms before, and was uncertain for a while which term matched which concept). I might be useful to add a diagram (perhaps somewhere in sections 3-6) that illustrates the various forms (Derived, Reflexive, etc...) Section 3: - "in addition to private networks connected to the public Internet through NAT". The wording here suggests that the combination of the Internet plus various private networks connected to it via NAT boxes is one realm. - (top of page 10) "reply from that target Section 7.13". There is some sort of grammatical error here. Section 7.1: - In the case of a candidate whose components are all server- reflexive or relayed, must the component transport addresses all be derived from the same local address? I suspect so, but you don't say this. - (page 13) "Local candidates are obtained by binding to ephemeral ports on an interface ..." AND "... obtain a set of candidates (one for each interface) by binding to N ephemeral UDP ports ..." This text seems to imply that the UDP ports must be ephemeral. This seems overly restrictive. I believe that the specification will work fine if a well-known port is used instead. I suggest replacing these with the following: "Local candidates are obtained by binding to ports (typically ephemeral ports) on an interface ..." AND "... obtain a set of candidates (one for each interface) by binding to N UDP ports ..." - (page 14, indented paragraph) "The ability to process STUN connectivity checks allows for clients to obtain peer reflexive transport addresses that can be used by the network server to reach them without a relay, even through NATs with restrictive mapping and filtering policies." I don't understand this sentence. In general, I found the wording in this indented paragraph to be much below the very high standard set by the rest of the document. Perhaps you might rewrite this entire paragraph. - (page 15) "... where there are multiple layers of NAT, and that layering is known to the provider of the client." Suggest adding an extra "where", so it reads "... where there are multiple layers of NAT, and where that layering is known to the provider of the client." Section 7.8: - "symmetric NAT". Replace with BEHAVE terminology? Section 12: - In addition to all the SDP examples in section 11, it would be nice to see one or two examples of SDP that do NOT use $L1, $L-PRIV-1.IP, $STUN-PUB-2.PORT, etc. This would help the reader understand the grammar rules. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 21 10:19:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWwTD-0000YC-CI; Fri, 21 Apr 2006 10:18:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWwTC-0000WE-6J for mmusic@ietf.org; Fri, 21 Apr 2006 10:18:50 -0400 Received: from mx2.magma.ca ([206.191.0.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWwTB-0002nS-Ro for mmusic@ietf.org; Fri, 21 Apr 2006 10:18:50 -0400 Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx2.magma.ca (8.13.6/8.13.0) with ESMTP id k3LEIjFu022968; Fri, 21 Apr 2006 10:18:46 -0400 Received: from [10.1.5.201] (209-87-232-164.storm.ca [209.87.232.164]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id k3LEIhqW021637 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Apr 2006 10:18:45 -0400 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4887547D-99F4-4F15-B36A-4A03C16B7BE2@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Fri, 21 Apr 2006 10:19:13 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: mmusic@ietf.org Subject: [MMUSIC] Some more questions and comments on draft-ietf-mmusic-ice-08 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: , Errors-To: mmusic-bounces@ietf.org Jonathan: A few questions about the specification: 1) Can a single offer contain candidates for the same media stream that use different transport protocols?? The spec seems to handle this case, but I could not find a statement that this is allowed. 2) Must all components of a candidate use the same transport protocol? 3) Must the components of a candidate appear together in increasing order in the SDP, or can they appear in any order and intermixed with candidates from other components? And here are some comments. These are mostly editorial in nature. General comments: - Shouldn't this specification reference draft-ietf-mmusic-sdp-new instead of RFC 2327? (See, for example, the references in section 12) - RFC 3264 (offer/answer model) and draft-ietf-mmusic-sdp-new state that the address and port in the m/c line is the one used to receive media on. However, when using ICE in the presence of NAT, this must also be the address and port from which the media is _sent_. I think it would be helpful to state this explicitly somewhere near the beginning of the specification. Section 2: - In the definition of a Relayed Transport Address, it might be helpful to readers to mention TURN. Section 7.1: - "... transport addresses for each component of each component match". Delete "for each component" ? Section 7.2: - Must all the components of a given candidate have the same priority? Section 7.3 says "yes", but I feel that, to a reader looking for this information, section 7.2 would be the logical place to look. Suggest mentioning this in section 7.2 as well. - I think it would be helpful to have a clear statement in this section that the prioritization is between all the candidates for a single media stream, regardless of their transport type, address type, port, etc. - "If the active candidate pair in the initial offer is being validated, media will flow to that pair once it is validated." Suggest replacing with "The active candidate pair in the initial offer is validated first, and if that validation succeeds, media will immediately begin to flow between the pair." Section 7.3: - "If there is no active candidate, the agent MUST include an a=inactive attribute. The RTP address and port in the m/c-line is inconsequential, since it won't be used." In the second sentence, suggest replacing "RTP" by "media", to make the statement accurate even if something other than RTP is used. - "The candidate-id MUST be chosen randomly and contain at least 24 bits of randomness (this does not mean that the candidate-id is 24 bits long; just that it has at least 24 bits of randomness)." I personally found this sentence very confusing the first couple of times I read it. Suggest replacing this with the following text: "The candidate ID MUST be chosen randomly and contain at least 24 bits of randomness. This means that a candidate ID must be at least 4 characters long, since each character in the base64 alphabet used for candidate IDs contains at most 6 bits of randomness. A candidate ID MAY be longer than 4 characters, and different candidate IDs MAY have different lengths." - "It is needed only to prevent a possible simultaneous selection by two agents within a private network for the useful lifetime of the software or hardware." This sentence meant nothing to me until I read the example two pages later. Perhaps add a note "(For more explanation, see the example later in this section)"? - "... a unique identifier, call the tid" In this section, you use only the term "tid". By contrast, in section 7.4 you always write "transport address ID". Perhaps, in each section, say "transport address ID or tid" the first time the term appears in that section, and then use tid from then on? - "The tid gets combined ... to form the username that is placed in the STUN checks ...". Perhaps mention the "Transport Address Pair ID"? That is, perhaps reword as follows: "The tid gets combined ... to form the Transport Address Pair ID (see section 7.4) which is used as the username in the STUN checks ...". Section 12: - The rules DIGIT and SP are never defined. Suggest stating that they are from section 9 of draft-ietf-mmusic- sdp-new - " base64-char = ALPHANUM / DIGIT / "+" / "/" " Because of the overlap between ALPHANUM and DIGIT, I suggest it would be less confusing to write this as " base64-char = ALPHA / DIGIT / "+" / "/" " where ALPHA is also defined in section 9 of draft-ietf-mmusic-sdp- new. Alternatively, a rule for "base64-char" is defined explicitly in section 9 of draft-ietf-mmusic-sdp-new (albeit under the comment " ; sub-rules of 'k=' "). - The rule "token" is never defined. Presumably you mean "token" as defined in section 9 of draft-ietf- mmusic-sdp-new? - " addr SP ;addr from RFC 3266 " Suggest instead using instead either "unicast-address" or "connection-address" both of which are defined in section 9 of draft-ietf-mmusic-sdp-new. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 25 09:38:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNjl-0002NN-7s; Tue, 25 Apr 2006 09:37:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNjj-0002Lt-Ph for mmusic@ietf.org; Tue, 25 Apr 2006 09:37:51 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYNji-0000ZV-FA for mmusic@ietf.org; Tue, 25 Apr 2006 09:37:51 -0400 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, 25 Apr 2006 16:37:48 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C037AEBB7@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-mmusic-ice-tcp-00 Thread-Index: AcZdn69pwEHLzxCKTIOt8ZE4w/DGrQCeFCqgAekmHdA= From: "Even, Roni" To: "IETF MMUSIC WG" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Colin Perkins Subject: [MMUSIC] Review of draft-ietf-mmusic-ice-tcp-00 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: , Errors-To: mmusic-bounces@ietf.org Hi, Two more editorial comments: 1. In section 9 second paragraph "successul" should be "successful" 2. In section 7 " since it is the STUN requests identify the candidate = pairs." I think that a "that" is missing after the "STUN requests" Roni Even _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 26 06:13:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYh1J-0002V8-8P; Wed, 26 Apr 2006 06:13:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYh1I-0002UR-4m for mmusic@ietf.org; Wed, 26 Apr 2006 06:13:16 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYh1G-0001qz-Hl for mmusic@ietf.org; Wed, 26 Apr 2006 06:13:16 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB0021CQNLDX@szxga01-in.huawei.com> for mmusic@ietf.org; Wed, 26 Apr 2006 18:04:34 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB009RUQNL9H@szxga01-in.huawei.com> for mmusic@ietf.org; Wed, 26 Apr 2006 18:04:33 +0800 (CST) Received: from w52438 ([10.164.5.27]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYB002IKRABMI@szxml02-in.huawei.com> for mmusic@ietf.org; Wed, 26 Apr 2006 18:18:20 +0800 (CST) Date: Wed, 26 Apr 2006 18:04:01 +0800 From: Kylin Wei To: mmusic@ietf.org Message-id: <000001c66918$c19a8a20$1b05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [MMUSIC] A question about draft-ietf-mmusic-rfc2326bis-12 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: , Errors-To: mmusic-bounces@ietf.org I'm studying draft-ietf-mmusic-rfc2326bis-12 now. I had a question when I read an example about "SETUP" method at Page 48. Original text: C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 CSeq: 302 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", RTP/AVP/TCP;unicast;interleaved=0-1 I don't know why there isn't receiver's IP address after "dest_addr" parameter. It should be 'dest_addr="192.168.2.1:4588"/"192.168.2.1:4589"' mode because of unicast transport. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 26 06:57:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYhhq-0000Wg-Sm; Wed, 26 Apr 2006 06:57:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYhhq-0000Wb-Hd for mmusic@ietf.org; Wed, 26 Apr 2006 06:57:14 -0400 Received: from violet.upc.es ([147.83.2.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYhhp-0004Zu-09 for mmusic@ietf.org; Wed, 26 Apr 2006 06:57:14 -0400 Received: from localhost (localhost [127.0.0.1]) by violet.upc.es (8.13.6/8.13.6) with SMTP id k3QAvBTM016193 for ; Wed, 26 Apr 2006 12:57:12 +0200 Received: from localhost (wmail-mat.upc.es [147.83.39.70]) by violet.upc.es (8.13.6/8.13.6) with ESMTP id k3QAsdVl014849; Wed, 26 Apr 2006 12:54:40 +0200 Received: from 85.205.255.133 ( [85.205.255.133]) as user viamonte@mat.upc.es by wmail-mat.upc.es with HTTP; Wed, 26 Apr 2006 12:30:57 +0200 Message-ID: <1146047457.444f4be1cf996@wmail-mat.upc.es> Date: Wed, 26 Apr 2006 12:30:57 +0200 From: David Viamonte To: mmusic@ietf.org References: <1146044816.444f4190187e4@wmail-mat.upc.es> In-Reply-To: <1146044816.444f4190187e4@wmail-mat.upc.es> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 85.205.255.133 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [MMUSIC] RTSP pipelining revisited 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: , Errors-To: mmusic-bounces@ietf.org Dear mmusic experts, I would like to request some feedback about a question on RTSP and 3GPP PSS. I have been working and doing some research around streaming over wireless during the last years, so that’s where I am coming from. My understanding is that there is no real support for RTSP pipelining in standard RTSP. As far as I understand, this also stands for RTSP 2.0 I-D, but please correct me if I’m wrong. I was wondering that enabling RTSP pipelining is an interesting area to consider, particularly as we see that interactivity and fast session setup are key to keep user’s attention on the service. Additionally, enabling early activation of Secondary PDP-Context(s) in a 3GPP PSS environment would be a good idea (3GPP TS 26.234). All in all, IMMO I think some time could be saved in session setup by defining a proper standard extension to RTSP. Defining it under a feature tag would keep backwards compatibility untouched. Just wanted to trigger some discussion to see if anyone believes this could be an interesting area to think about. In case you believe it doesn’t make any sense, I am happy to hear your thoughts as well. Thanks in advance and kind regards, David PS.- I know that with WLAN and HSxPA out there, the gains of pipelining RTSP may be reduced. Still, in cases when signalling is carried over relatively narrowband bearers –leaving broadband connections for media- I believe a sort of extension would possibly help... ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 26 08:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYint-000605-He; Wed, 26 Apr 2006 08:07:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYinr-000600-Vu for mmusic@ietf.org; Wed, 26 Apr 2006 08:07:31 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYinq-0000Kh-6F for mmusic@ietf.org; Wed, 26 Apr 2006 08:07:31 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 728694F0003; Wed, 26 Apr 2006 14:07:29 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 14:07:28 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 14:07:27 +0200 Message-ID: <444F627E.2010101@ericsson.com> Date: Wed, 26 Apr 2006 14:07:27 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Kylin Wei Subject: Re: [MMUSIC] A question about draft-ietf-mmusic-rfc2326bis-12 References: <000001c66918$c19a8a20$1b05a40a@china.huawei.com> In-Reply-To: <000001c66918$c19a8a20$1b05a40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2006 12:07:27.0952 (UTC) FILETIME=[FC9F6D00:01C66929] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Errors-To: mmusic-bounces@ietf.org Please review the following statement from page 97: o The lack of the dest_addr parameter indicates that the server SHALL send media to same address for which the RTSP messages originates. Does not work for transports requiring explicitly given destination ports. Cheers Magnus Kylin Wei wrote: > I'm studying draft-ietf-mmusic-rfc2326bis-12 now. I had a question when > I read an example about "SETUP" method at Page 48. > Original text: > C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 > CSeq: 302 > Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", > RTP/AVP/TCP;unicast;interleaved=0-1 > > I don't know why there isn't receiver's IP address after "dest_addr" > parameter. > It should be 'dest_addr="192.168.2.1:4588"/"192.168.2.1:4589"' mode > because of unicast transport. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 26 08:30:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYjAB-0004XI-3Q; Wed, 26 Apr 2006 08:30:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYj9L-0004HE-6v for mmusic@ietf.org; Wed, 26 Apr 2006 08:29:43 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYivf-0000rY-74 for mmusic@ietf.org; Wed, 26 Apr 2006 08:15:36 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8FBF8E75; Wed, 26 Apr 2006 14:15:00 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 14:14:59 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 14:14:59 +0200 Message-ID: <444F6443.9030805@ericsson.com> Date: Wed, 26 Apr 2006 14:14:59 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: David Viamonte Subject: Re: [MMUSIC] RTSP pipelining revisited References: <1146044816.444f4190187e4@wmail-mat.upc.es> <1146047457.444f4be1cf996@wmail-mat.upc.es> In-Reply-To: <1146047457.444f4be1cf996@wmail-mat.upc.es> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 26 Apr 2006 12:14:59.0175 (UTC) FILETIME=[09929770:01C6692B] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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: , Errors-To: mmusic-bounces@ietf.org Hi David, Request pipelining is allowed. However it can't be applied between the=20 first and second SETUP for example. Also between the last SETUP and the=20 first PLAY there is a restriction on doing request pipelining to avoid=20 needing to deal with the unknown state. I think what you should call=20 this is session establishment optimization. I think there is a general interest in optimizing RTSP in regards to the=20 time it takes to do session establishment. However, I think that just=20 discussing it will not make it happen, because that have been the state=20 of things for the last 6 years. If you like something to happen in this=20 area you will need to step in and start proposing real solution and=20 actually write specification proposals for how to accomplish it. Cheers Magnus David Viamonte wrote: > Dear mmusic experts,=20 >=20 > I would like to request some feedback about a question on RTSP and 3GPP= PSS. I=20 > have been working and doing some research around streaming over wireles= s during=20 > the last years, so that=92s where I am coming from.=20 >=20 > My understanding is that there is no real support for RTSP pipelining i= n=20 > standard RTSP. As far as I understand, this also stands for RTSP 2.0 I-= D, but=20 > please correct me if I=92m wrong.=20 >=20 > I was wondering that enabling RTSP pipelining is an interesting area to= =20 > consider, particularly as we see that interactivity and fast session se= tup are=20 > key to keep user=92s attention on the service.=20 >=20 > Additionally, enabling early activation of Secondary PDP-Context(s) in = a 3GPP=20 > PSS environment would be a good idea (3GPP TS 26.234). All in all, IMMO= I think=20 > some time could be saved in session setup by defining a proper standard= =20 > extension to RTSP. Defining it under a feature tag would keep backwards= =20 > compatibility untouched.=20 >=20 > Just wanted to trigger some discussion to see if anyone believes this c= ould be=20 > an interesting area to think about. In case you believe it doesn=92t ma= ke any=20 > sense, I am happy to hear your thoughts as well.=20 >=20 > Thanks in advance and kind regards,=20 >=20 > David=20 >=20 > PS.- I know that with WLAN and HSxPA out there, the gains of pipelining= RTSP=20 > may be reduced. Still, in cases when signalling is carried over relativ= ely=20 > narrowband bearers =96leaving broadband connections for media- I believ= e a sort=20 > of extension would possibly help...=20 >=20 > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 --=20 Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 26 16:53:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYr0r-0004aL-CM; Wed, 26 Apr 2006 16:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYr0p-0004aG-Vo for mmusic@ietf.org; Wed, 26 Apr 2006 16:53:27 -0400 Received: from pproxy.gmail.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYr0p-0004wO-Gq for mmusic@ietf.org; Wed, 26 Apr 2006 16:53:27 -0400 Received: by pproxy.gmail.com with SMTP id t32so1706666pyc for ; Wed, 26 Apr 2006 13:53:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=TlP7NGzrZPopP9mpCJBozvy1fLEaGaxXRcQTXtIDkkjrgWBDVX1z3WpsyhfWRD2qn03PQ3BgCAqBIvCWwLRFIv+bQ8leBXZCFaY+n/2NobVVWLcJ3WdAo6EIpWA8IV9+Y9Zv0eT0PTT8Crp6f+QpTnKMVGDfRYDLxUvwPwz9mDg= Received: by 10.35.15.11 with SMTP id s11mr384694pyi; Wed, 26 Apr 2006 13:53:26 -0700 (PDT) Received: by 10.35.49.15 with HTTP; Wed, 26 Apr 2006 13:53:26 -0700 (PDT) Message-ID: <953beacc0604261353g35db3534ld2076960cc780ab0@mail.gmail.com> Date: Wed, 26 Apr 2006 13:53:26 -0700 From: "Rohan Mahy" To: mmusic@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Subject: [MMUSIC] quick WGLC comment on ICE 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="===============0995745813==" Errors-To: mmusic-bounces@ietf.org --===============0995745813== Content-Type: multipart/alternative; boundary="----=_Part_7831_28062945.1146084806298" ------=_Part_7831_28062945.1146084806298 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, ICE -08 still refers to offers and answers using terminology which contradicts Section 13.2.1 of RFC3261. By my reading, a session descriptio= n in an unreliable 18x is never an offer or an answer. I often describe this as an "early session description" or "courtesy SDP". Several places in ICE (particularly Section 8) talk about performing ICE operations once you receive an answer and refer to courtesy SDP as if it is an answer. For example, the current wording of Section 8 para 2: ICE requires a series of STUN-based connectivity checks to take place between endpoints. These checks start from the answerer on generation of its answer, and start from the offerer when it receives the answer. These checks can take time to complete, and as such, the selection of messages to use with offers and answers can effect perceived user latency. Two latency of figures are of particular interest. These are the post-pickup delay and the post-dial delay. The post-pickup delay refers to the time between when a user "answers the phone" and when any speech they utter can be delivered to the caller. The post-dial delay refers to the time between when a user enters the destination address for the user, and ringback begins as a consequence of having succesfully started ringing the phone of the called party. and my proposed rewording: ICE requires a series of STUN-based connectivity checks to take place between endpoints. These checks start from the answerer on generation of its first session description sent after the offer, and start from the offerer when it receives this first session description. If this first message arrives in an unreliable message, the actual answer will arrive in the first reliab= le message after the offer. STUN connectivity checks can take time to complete, and as such, the number and timing of messages used for these checks can affect perceived user latency. Two latency figures are of particular interest. These are the post-pickup delay and the post-dial delay. The post-pickup delay refers to the time between when a user "answers the phone" and when any speech they utter can be delivered to the caller. The post-dial delay refers to the time between when a user enters the destination address for the user, and ringback begins as a consequence of having succesfully started ringing the phone of the called party. and also in the 5th paragraph (currently): For this reason, if an offer is received in an INVITE request, the UAS SHOULD immediately gather its candidates and then generate an answer in a provisional response. When reliable provisional responses are not used, the SDP in the provisional response is not formally the answer; the value in the 200 OK is the actual answer. However, RFC 3261 allows for SDP to appear in an unreliable provisional response, in which case its value has to be identical to the value placed in the 200 OK. Thus, we refer to the SDP in the provisional response, even when unreliable, as the answer. To deal with possible losses of the provisional response, it SHOULD be retransmitted until some indication of receipt. This indication can either be through PRACK [11], or through the receipt of a STUN Binding Request with a correct username and password. Even if PRACK is not used, the provisional response SHOULD be retransmitted using the exponential backoff described in [11]. Furthermore, once the answer has been sent, the agent SHOULD begin its connectivity checks. Once a candidate reaches the Valid or Recv-Valid state, the UAS has a known-valid path for media packets towards the UAC. This point is called the connected point in ICE. and my proposed rewording: For this reason, if an offer is received in an INVITE request, the UAS SHOULD immediately gather its candidates and then generate a session descripition in a provisional response. When reliable provision= al responses are not used, the SDP in the provisional response is not formally the answer; the value in the 200 OK is the actual answer. However, RFC 3261 encourages implementors to include this "courtesy SDP" in an unreliable provisional response, in which case its value has to be identical to the value placed in the 200 OK. To deal with possible losses, the provisional response SHOULD be retransmitted until the UAS receives some indication of receipt.=20 This indication can either be through PRACK [11], or through the receipt of a STUN Binding Request with a correct username and password. Even if PRACK is not used, the provisional response SHOULD be retransmitted using the exponential backoff described in [11]. Furthermore, once the session description has been sent, the agent SHOULD begin its connectivity checks. Once a candidate reaches the Valid or Recv-Valid state, the UAS has a known-valid path for media packets towards the UAC. This point is called the connected point in ICE. I can propose specific text for the other usages if other agree this needs to be changed. thanks, -rohan ------=_Part_7831_28062945.1146084806298 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

ICE -08 still refers to offers and answers using terminology whi= ch contradicts Section 13.2.1 of RFC3261.  By my reading, a session de= scription in an unreliable 18x is never an offer or an answer.  I ofte= n describe this as an "early session description" or "courte= sy SDP".

Several places in ICE (particularly Section 8) talk about performin= g ICE operations once you receive an answer and refer to courtesy SDP as if= it is an answer.

For example, the current wording of Section 8 para= 2: 

   ICE requires a series of STUN-based connectivity checks to =
take place
   between endpoints.  These checks start from the answerer o=
n
   generation of its answer, and start from the offerer when it receiv=
es

   the answer.  These checks can take time to complete, and as such, th=
e
   selection of messages to use with offers and answers can effect
=
   perceived user latency.  Two latency of figures are of particular

   interest.  These are the post-pickup delay and the post-dial delay.
 =
  The post-pickup delay refers to the time between when a user "answer=
s
   the phone" and when any speech they utter can be delivered to =
the

   caller.  The post-dial delay refers to the time between when a user<=
br>   enters the destination address for the user, and ringback begins as a=

   consequence of having succesfully started ringing the phone of the

   called party.

and my proposed rewording:

   ICE=
 requires a series of STUN-based connectivity checks to take place
   be=
tween endpoints.  These checks start from the answerer on
   generation =
of its first session description sent after the offer,=20

   and start from the offerer when it receives
   this first session=
 description.  If this first message arrives in 
   an unreliable messag=
e, the actual answer will arrive in the first reliable
   message after =
the offer. =20


   STUN connectivity checks can take time to complete, and as such,=
 the
   number and timing of messages used for these checks can affect   perceived user latency.  Two latency figures are of particular

   interest.  These are the post-pickup delay and the post-dial delay.
 =
  The post-pickup delay refers to the time between when a user "answer=
s
   the phone" and when any speech they utter can be delivered to =
the

   caller.  The post-dial delay refers to the time between when a user<=
br>   enters the destination address for the user, and ringback begins as a=

   consequence of having succesfully started ringing the phone of the

   called party.

and also in the 5th paragraph (currently)= :

   For this reason, if an offer is received in an INVITE requ=
est, the
   UAS SHOULD immediately gather its candidates and then genera=
te an

   answer in a provisional response.  When reliable provisional
   r=
esponses are not used, the SDP in the provisional response is not
   for=
mally the answer; the value in the 200 OK is the actual answer.
   Howev=
er, RFC 3261 allows for SDP to appear in an unreliable

   provisional response, in which case its value has to be identical to=

   the value placed in the 200 OK.  Thus, we refer to the SDP in the   provisional response, even when unreliable, as the answer.  To deal

   with possible losses of the provisional response, it SHOULD be
  =
 retransmitted until some indication of receipt.  This indication can
  =
 either be through PRACK [11], or through the receipt of a STUN
   Bindi=
ng Request with a correct username and password.  Even if PRACK

   is not used, the provisional response SHOULD be retransmitted using<=
br>   the exponential backoff described in [11].  Furthermore, once the
=
   answer has been sent, the agent SHOULD begin its connectivity checks.

   Once a candidate reaches the Valid or Recv-Valid state, the UAS has =
a
   known-valid path for media packets towards the UAC.  This point is<=
br>   called the connected point in ICE.
and my proposed rewording= : 

   For this reason, if an offer is received in an INVITE reque=
st, the
   UAS SHOULD immediately gather its candidates and then generat=
e a
   session descripition in a provisional response.  When reliable pr=
ovisional

   responses are not used, the SDP in the provisional response is not   formally the answer; the value in the 200 OK is the actual answer.
=
   However, RFC 3261 encourages implementors to include this "courtesy=
 SDP"=20

   in an unreliable
   provisional response, in which case its value=
 has to be identical to
   the value placed in the 200 OK.  To deal
 =
  with possible losses, the provisional response SHOULD be
   retransmit=
ted until the UAS receives some indication of receipt.  This indication can

   either be through PRACK [11], or through the receipt of a STUN
  =
 Binding Request with a correct username and password.  Even if PRACK
  =
 is not used, the provisional response SHOULD be retransmitted using

   the exponential backoff described in [11].  Furthermore, once the
   =
session description has been sent, the agent SHOULD begin its connectivity =
checks.
   Once a candidate reaches the Valid or Recv-Valid state, the U=
AS has a

   known-valid path for media packets towards the UAC.  This point is   called the connected point in ICE.
I can propose specific tex= t for the other usages if other agree this needs to be changed.

thanks,
-rohan

------=_Part_7831_28062945.1146084806298-- --===============0995745813== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0995745813==-- From mmusic-bounces@ietf.org Thu Apr 27 10:45:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7jZ-0007Sa-IK; Thu, 27 Apr 2006 10:44:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7jX-0007SQ-TZ for mmusic@ietf.org; Thu, 27 Apr 2006 10:44:43 -0400 Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7jT-0000me-Fz for mmusic@ietf.org; Thu, 27 Apr 2006 10:44:43 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp3.clb.oleane.net with ESMTP id k3REiVKe028957 for ; Thu, 27 Apr 2006 16:44:37 +0200 Message-Id: <200604271444.k3REiVKe028957@smtp3.clb.oleane.net> From: "Chantal Ladouce" To: Date: Thu, 27 Apr 2006 16:43:28 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZqCPIMc6VQZHBsRiuebqEhKPEdfA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Subject: [MMUSIC] TVoDSL International Conference 2007 - Paris - France 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="===============2144181808==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============2144181808== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01C66A19.B5E68D30" This is a multi-part message in MIME format. ------=_NextPart_000_00B5_01C66A19.B5E68D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The fourth edition of the TVoDSL International Conference and the Triple Play Showcase will stand in Paris next January 23 to 26, 2007. With the opening of a second exhibition floor and the launch of the Mobile TV World Congress, TVoDSL will confirm his rank of very first worldwide rendez-vous in the IPTV realm. A call for proposals has been launched for the TVoDSL conference. All details at: http://www.upperside.fr/tvodsl2007/tvodsl2007intro.htm ------=_NextPart_000_00B5_01C66A19.B5E68D30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The fourth edition of the TVoDSL International = Conference and the Triple Play Showcase will stand in Paris next January 23 to 26, = 2007.

With the opening of a second exhibition floor = and the launch of the Mobile TV World Congress, TVoDSL will = confirm his rank of very first worldwide rendez-vous in the = IPTV realm.

 

A call for = proposals has been launched for the TVoDSL conference.

=

 

All details = at:

=

http://www.upperside.fr/tvodsl2007/tvodsl2007intro.htm

=

 

------=_NextPart_000_00B5_01C66A19.B5E68D30-- --===============2144181808== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============2144181808==-- From mmusic-bounces@ietf.org Thu Apr 27 14:08:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZAuR-0007Eu-CL; Thu, 27 Apr 2006 14:08:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZAuQ-0007Ep-QR for mmusic@ietf.org; Thu, 27 Apr 2006 14:08:10 -0400 Received: from mx1.magmacom.com ([206.191.0.217]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZAuQ-0006IJ-8K for mmusic@ietf.org; Thu, 27 Apr 2006 14:08:10 -0400 Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx1.magmacom.com (8.13.6/8.13.0) with ESMTP id k3RI88BJ005513; Thu, 27 Apr 2006 14:08:09 -0400 Received: from [10.1.5.201] (209-87-232-164.storm.ca [209.87.232.164]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id k3RI86qb018465 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Apr 2006 14:08:07 -0400 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Thu, 27 Apr 2006 14:08:49 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: mmusic@ietf.org Subject: [MMUSIC] Still more questions and comments on draft-ietf-mmusic-ice-08 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: , Errors-To: mmusic-bounces@ietf.org Jonathan: Below are some more questions and comments on draft-ietf-mmusic-ice-08. - Philip Technical comments and questions ============================ 1) If there are three m/c lines in the SDP, does the agent construct three candidate pair check orderings, or just one ordering containing the candidates for all three media streams? Viewed another way, is there just one Ta timer, or one Ta timer per m/c line? Taking this even farther, if the agent is taking to two or more different remote agents (because it is trying to establish two different call legs, perhaps for the same call or perhaps for different calls), then is the result one or multiple candidate pair check orderings? (It seems to me that, to reduce the load on intervening NATs, there should be just one.) 2) When an agent receives a STUN Request, section 7.8 seems to say that the agent validates the request and sends a reply based only on local information. In particular, the USERNAME is validated by checking for a match on the local tid (and not the remote tid). The reason for this seems to be the case when an the offerer receives a STUN Request but has not yet received the answer from the remote agent. (This case is presumably pretty common since STUN Requests go directly, but signaling goes indirectly). In this case, the text seems to say that the STUN Request is validated and a STUN response sent immediately, and information about the STUN Request is stored for further processing once the answer is received. However, I can see implementations deciding instead to ignore STUN Requests where there is not an exact match for the USERNAME. I can see them doing this for three reasons: a) It is easier. In this case, there is no need to queue up information about the STUN Request for later processing when the answer arrives. b) For security. The agent might be acting as a STUN server for more than one STUN usage, and use the USERNAME to differentiate the usages. For security and because of DoS attacks, the agent simply ignores STUN Requests with unknown USERNAMES. c) Better validity checking. If an agent just does a prefix match, then USERNAMES corresponding to illegal transport address combinations are not detected. For example, a request with USERNAME "Lxx:1:Ryy: 2" (mismatched component ids) or a request where the candidates are from different media streams, or use different transport addresses, etc. My proposal is that: - An agent always does an exact match against the USERNAME when a STUN Request arrives. - The answerer waits some time (say 50 or 100 msec) before starting its connectivity checks, or waits until it receives a STUN Request from the offerer, or doesn't bother waiting at all (because things will work out anyway after retries). 3) Another reason to do an exact match against the USERNAME might be the following. Consider two agents, L and R and a candidate pair Lxx:1:Ryy:2. L sends a STUN Request for this pair and receives a success response, and thus moves its local state machine into the Recv-Wait state. R sends a STUN Request for this pair, but due to some problem, L does not like this request, and sends an error response, which causes R to give up and move into the Invalid state. At this point, L continues to send STUN Requests each Tr interval , and R replies with a success response, and the candidate pair remains stuck in the (RECV-WAIT, INVALID) state combination. To avoid this problem, it might be appropriate for an agent to return an error response, when its local state machine is in the Invalid state. 4) According to section 7.10.1, when an agent receives a STUN request and discovers a new peer reflexive transport address, the agent generates a new candidate id from candidate IDs of the candidate pair specified by the USERNAME: "In particular, the candidate ID is constructed by concatenating the remote candidate ID with the native candidate ID (without the colon)." It is possible, due to routing changes or a glitch in the intervening NAT(s), that the same candidate pair might generate TWO or more peer reflexive transport addresses. For example, say L and R are the two agents. The network in which R resides is configured to send packets through NAT box N1 in normal use, but if N1 fails, packets are sent through NAT box N2. For a given candidate pair, R sends multiple STUN Requests to L. It may be that the first STUN Request goes through N1, but the second goes through N2. This causes L to see two different peer reflexive transport addresses for the same USERNAME. These two peer reflexive transport addresses will be assigned the same candidate ID by L, violating the rule that candidate IDs must be unique. I can see two possible ways to handle this situation: a) Append a string to the candidate ID to ensure they are unique (e.g., "1", "2", ...), OR b) Use the last (or the first) peer reflexive transport address seen for this USERNAME. Option (a) is may be tricky, especially when the remote (generating) candidate has multiple components, so I suggest option (b). 5) How are two candidate IDs of different lengths compared? My assumption is that the shorter one is padded at the end with Null's (0x00) until the two IDs have the same length. Is this correct? If so, then am I just confused, or is there an error in the following sentence? "For example, the candidate with candidate ID agD is greater than the candidate with ID ad7, and both of those are greater than the candidate with ID zz." I would have thought that, in reverse lexicographic order, the IDs would have be ordered as zz, agD, ad7, since the "zz" is padded at the end with a Null character. 6) If agent L has two candidates with the same derived address (but different local addresses) and picks one of the candidates as the one to put in the m/c line, then as the spec points out, the remote agent won't know which candidate the m/c line corresponds to. The spec recommends the remote agent just guesses and picks one to move to the head of the check ordering. Wouldn't it be better to: - Move BOTH candidates to the head of the ordering, or - Somehow indicate in the SDP which candidate was chosen? In other words, this case breaks the requirement that both endpoints create the same candidate pair check ordering. 7) Am I correct in saying that none of the example candidate IDs in the document are actually legal? Because they are all too short? If so, it might be useful to use realistic candidate IDs or at least say something about this. 8) In section 7.6, there is the sentence: "The check is started for the first transport address pair in the transport address pair check ordered list (which will be part of the active candidate) that is in the Waiting state" I don't understand the part in parentheses. Don't we check all the pairs, not just the pairs associated with the active candidate? Editorial comments =============== General: - In a number of places in the document, you use the phrase "reflexive or relayed" where it would be more general and more accurate to say "derived". (For example, "reflexive or relayed candidate", rather than "derived candidate", etc). - In the first part of the document, you use "NAT" to mean the technology (i.e., "Network Address Translation"), for example in "Numerous solutions have been proposed for allowing these protocols to operate through NAT" in section 1. But later in the document, you start using "NAT" to mean a single box (i.e., "Network Address Translator"), for example "...when two agents are separated by a NAT ..." in section 7.10. It would be nice if you were consistent. In my opinion, the most common usage is to use "NAT" to refer to a single device and "NATs" when referring to multiple devices. However, I would be happy with another solution as long as the usage was consistent and made explicit. Section 7.1: - "... transport addresses for each component of each component match ...". I suggest deleting "for each component". Section 7.3: - "even if the transport address from a previous session was being recycled." For consistency (in verb tense) with the rest of the sentence, suggest changing "was" to "is". - "In this case, thats ...". "thats" should be either "that's" or "that is". - "10.0.1.1:8866 and 8877". I understand what you are trying to say here, but you never explain this notation, and this paragraph is the only place in the document where you use it. (It is not, for example, legal in the a=candidate lines). Furthermore, you have just been talking about using a colon to construct tids and usernames. Perhaps write this in a different way to make sure the reader understands? Note also that a few sentences later, you say "A will send a STUN request to 10.0.1.1:8866 and 8877" when what you really mean is "A will send one STUN request to 10.0.1.1:8866 and another STUN request to 10.0.1.1:8877". - "To fix this, tid takes on ..." For consistency with previous usage, I think there should be a "the" before "tid", so the sentence reads "To fix this, the tid takes on ..." - "ususally" should be "usually" Section 7.4: - (first two PPs) The intermixing of the running example and the specification in these paragraphs is a bit confusing, because it is not clear which statements are normative and which just apply to the example. Suggest splitting the example out into its own paragraph. - "If an offer/answer exchange took place for a session comprised of an audio and a video stream, and each agent had two candidates per media stream, there would be 8 candidate pairs, 4 for audio and 4 for video." If an offer or answer can have candidates with different transport protocols (not sure if this is allowed -- I asked this question in my last message), then this assumes all candidates have the same transport protocol. - "Returning to the previous example, for each of the 8 candidate pairs, there would be two transport address pairs - one for RTP, and one for RTCP. If one candidate has more components than the other, those extra components will not be part of a transport address pair, won't be validated, and will effectively be treated as if they weren't included in the candidate pair in the first place." The first sentence seems to assume that the audio and video streams will use RTCP, and so both ends offered two components in each candidate. The second sentence then confuses things further -- is this supposed to be a continuation of the example, or a normative statement? Section 7.6: - "The state machine has six states - waiting, testing, Recv- Valid, Send-Valid, Valid and Invalid." I think "waiting" and "testing" should be capitalized. - Immediately after the state transition diagram, I suggest giving a brief description of the meaning of each state. Though there are some descriptions later on, I think it would be nice to have the descriptions complete and all together in one place - The notation in the state diagram indicates that the state machine moves from Waiting to Testing when timer Ta expires. However, this is true only if the state machine is the next in line to start testing. - "... captures the progress of connectivity checks." Grammar: Insert a "the" before "connectivity"? - "This is done by computing the matching transport address pair for each Binding Request. This is done by examining the USERNAME of the incoming Binding Request. " Suggest rewording these sentences along the following lines: "This is done by determining the matching transport address pair for each incoming STUN message. For an incoming Binding Request message, this is done by ... For an incoming response message, this is done by ... - "Extensions to ICE that describe other transport protocols SHOULD describe the state machine and the procedures for connectivity checks." To be clearer and more precise, perhaps reword as follows? "Extensions to ICE that describe other transport protocols SHOULD describe the state machine and procedures for those protocols." - "... in Figure 5" Missing period at end of sentence. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 28 03:40:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNa1-00072I-18; Fri, 28 Apr 2006 03:39:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNZz-00072D-5d for mmusic@ietf.org; Fri, 28 Apr 2006 03:39:55 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZNZx-0007SX-CD for mmusic@ietf.org; Fri, 28 Apr 2006 03:39:55 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8500FC3B; Fri, 28 Apr 2006 09:39:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:39:52 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:39:51 +0200 Received: from [131.160.126.3] (rvi2-126-3.lmf.ericsson.se [131.160.126.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 98E5E28E8; Fri, 28 Apr 2006 10:39:50 +0300 (EEST) Message-ID: <4451C6C6.7060705@ericsson.com> Date: Fri, 28 Apr 2006 10:39:50 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Joerg Ott References: <4415642A.30906@ericsson.com> <441679D3.6030600@netlab.hut.fi> <441682E5.7000901@nokia.com> <44168B1A.4000702@netlab.hut.fi> <4417FC36.9010604@ericsson.com> <441EB56E.7070305@netlab.hut.fi> <4434C6ED.8060904@ericsson.com> <44365DEE.1030402@netlab.hut.fi> <4451C625.6090102@ericsson.com> In-Reply-To: <4451C625.6090102@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 07:39:51.0296 (UTC) FILETIME=[EEEFA800:01C66A96] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Miguel Garcia , "Salvatore Loreto \(SA/ERI\)" , mmusic@ietf.org, Markus Isomaki Subject: [MMUSIC] Re: File tranfer in SIP 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: , Errors-To: mmusic-bounces@ietf.org [removing recipients so that the filters do not mark it as moderated] Hi Joerg, > moving this to MMUSIC: perfect. > Regarding the > encoding, I suppose we will have to worry about how to put this into > SDP. This brings up -- again -- the discussion of whether to include > some "blob" of, from an SDP perspective, opaque metadata (e.g., b64 > encoded zip version of the FLUTE FDT, just to give some weird example) > or whether to make these attributes explicit. I would go for explicit SDP attributed (i.e., 'a' lines). > If we make the attributes explicit, this is essentially a more general > aspect of describing the purpuse of a media stream and would not be > restricted to file transfer. We have some informal hints for audio > and video already and this appears conceptually similar in that it > identifies the purpose and helps the answerer to decide whether to > accept it or not. > > Keeping this in mind, it would be extremely useful, not to invent > independent sets of attributes for file transfer, MSRP sessions, > audio, video, whiteboard, and so so. The attributes defined in the draft describe a file to be transfered. If somebody comes up with different attributes to describe the contents of the audio being sent over a media stream, those will not have any interaction with our attributes. Different types of media streams need different attributes to describe their contents. > I clearly _do_not_ want to end up in an XCON-style discussion about > metadata and the like, but it may be worthwhile given some > consideration to future evolution of this stuff and compatibility > with existing attributes. We have not found any interactions with existing attributes. >>> I am also concerned about motivating the use of inline images for >>> icons. I can hardly see why you would need an icon to decide >>> whether or not to accept a file transfer. >> >> A lot of commercial IM systems support it, and users find it very useful. SIP-based systems need to be able to provide a similar user experience if we do not want people to start doing things is proprietary ways. > > It's your call in the end of the day. Often, icons are created based > upon the filename extension -- and I suspect that the filename is going > to be much more relevant that the icon in deciding whether or not to > accept it. Icons are not worth much and only increase volume. But if > we decide that it is useful: If I want to send you a picture called PCJ00234.JPG, you will not know whether or not you want to receive it. However, if you see a small icon of the picture, you will be in a better position to make that decision. Many people find icons very useful, in many cases much more than the file name. > You must decide how much you worry about the SIP signaling architecture. > Given that the INFO method is "damned" (which I fully support), I do not > believe that turning parts of SDP into a transport is a particularly > smart idea. It clearly does not ad efficiency. If you follow > traditional SIPPING thinking, you will need to separate the desired > effect from the mechanism to achieve it. There may be better ways. > > I am simply worried to open a door that we better leave closed. > Would you want to limit the media type or the size of an icon? > If so, what would be the right value? Would you negotiate it and > come up with an "embedded contents too large" status code? We have created small icons with a resolution of 32 x 24 pixels using 4 bits for depth color whose size was around 500 bytes. In any case, we can add text stating the problems of sending too large SIP messages. > I think I got somewhat confused that I constructed a close to impossible > scenario. For the sender it is indeed trivial if the sending user > selects the file. Of course, the filename should be included because > otherwise the receiver does not easily find out whether or not it has > a copy of the file already. If the receiving users wants to initiate > a file transfer, of course, it does not have a checksum at hand to > include. If some scenarios (e.g., file sharing) you will have the hash of the file you want, but you will not have the file yet. >> I do not see any issue with having simultaneous media streams. It is again regular SDP behavior. > > Well, I assume that if I send you a second offer within a session > and you also send me one at the same time, we will have to do some > conflict resolution since both of us will use the (n+1)st m-line > for potentially different purposes. Since this has probably not > received much implementation attention in the past (and happened > rather rarely in practice), it have not been noticed. But it may > be specified and just did not find this upon a quick search. That conflict resolution is already defined at the offer/answer level. Of course, we do not intend to redefine that behavior. Thanks, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 28 03:57:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNrC-000124-Vq; Fri, 28 Apr 2006 03:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNrB-00011x-2P for mmusic@ietf.org; Fri, 28 Apr 2006 03:57:41 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZNr6-00085O-HQ for mmusic@ietf.org; Fri, 28 Apr 2006 03:57:41 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CC7DA4F003C; Fri, 28 Apr 2006 09:57:35 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:57:35 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:57:35 +0200 Message-ID: <4451CAEF.9070303@ericsson.com> Date: Fri, 28 Apr 2006 09:57:35 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [MMUSIC] Question about v6 and V4 addresses in SDP for RTP References: <4.3.2.7.2.20060427153155.031d4790@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060427153155.031d4790@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 07:57:35.0384 (UTC) FILETIME=[692E9980:01C66A99] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: mmusic-bounces@ietf.org Hi James, This is described in RFC 4091 and RFC 4092: ftp://ftp.rfc-editor.org/in-notes/rfc4091.txt ftp://ftp.rfc-editor.org/in-notes/rfc4092.txt Cheers Magnus James M. Polk wrote: > Hey > > Can a SIP INVITE, carrying SDP have a "c=" line include both a IPv4 > address and an IPv6 address? > > The intent is for the offerer to offer both choices, and the answerer > answer with IPv6 if they have that stack (or both stacks), and v4 if > they only have this one stack. > > Is this example given/rules stated in any RFC? I don't see this usecase > in 3264. > > Is there a play on whether the "c=" line is above the "m=" line, or > within one/each media description? > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 28 03:59:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNsY-0001m3-Ts; Fri, 28 Apr 2006 03:59:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNsX-0001ls-G0; Fri, 28 Apr 2006 03:59:05 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZNsV-000879-Jb; Fri, 28 Apr 2006 03:59:05 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E333F4F003F; Fri, 28 Apr 2006 09:59:02 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:59:02 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:59:02 +0200 Received: from [131.160.126.3] (rvi2-126-3.lmf.ericsson.se [131.160.126.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 07B4F236E; Fri, 28 Apr 2006 10:59:01 +0300 (EEST) Message-ID: <4451CB44.7050602@ericsson.com> Date: Fri, 28 Apr 2006 10:59:00 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Amitkumar.Goel@infineon.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 07:59:02.0620 (UTC) FILETIME=[9D2DC1C0:01C66A99] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: sudha.vs@globaledgesoft.com, mmusic , OMA-MWG-IM@mail.openmobilealliance.org, Miguel.An.Garcia@nokia.com, simple@ietf.org, sipping@ietf.org Subject: [MMUSIC] Re: [Simple] Handling of incoming INVITE request for different MSRP session 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: , Errors-To: mmusic-bounces@ietf.org Hi, note that the policy we currently use is not to cross-post to the SIP, SIPPING, and SIMPLE mailing lists. A particular discussion should take place in one and only one of those lists. In any case, in the last IETF it was decided that this draft will be discussed in MMUSIC. I have cc:ed the MMUSIC mailing list in this message. Please, remove the SIPPING and SIMPLE mailing lists in your replies from now on. Thanks, Gonzalo SIPPING co-chair Amitkumar.Goel@infineon.com wrote: > Hi Miguel, > > If SDP offer/answer m-line ulr does not contain session id,as session ID > is a optional param, Is it mean that the offerer/answerer does not > support MSRP session multiplexing for sharing the same TCP connection? > > Regards, > Amit > > > > -----Original Message----- > From: Sudha [mailto:sudha.vs@globaledgesoft.com] > Sent: Friday, April 28, 2006 1:02 PM > To: Miguel Garcia > Cc: Goel Amitkumar (IFIN SW WS); sipping@ietf.org; simple@ietf.org; > OMA-MWG-IM@mail.openmobilealliance.org > Subject: Re: [Simple] Handling of incoming INVITE request for different > MSRP session > > Thanks Miguel. > Inline discussion > > > On Fri, 28 Apr 2006 11:46:42 +0530, Miguel Garcia > wrote: > >> Inline discussion. >> >> Sudha wrote: >>> Hi Miguel, >>> -Does "m=" lines have different port numbers? >>> If so, it would result in 2 TCP Connections and hence 2 MSRP >>> Sessions. This would naturally result in two "a=path:" attributes >>> which would complicate the message parsing. >>> else if the media lines have the same port numbers it is like >>> duplication of the previous media line and it doesnt carry any > meaning. >> Different m= lines will have the same port number, because they will >> be sharing the same TCP connection. There is nothing new here, the >> MSRP draft already discusses the TCP sharing in Sections 5.1 and 8.1. >> >> What we say in our draft is that each file transfer is identified with > >> a different MSRP session. We can discuss if we need to share the same >> session, but at the moment the draft says each m= line has a unique >> MSRP sessionId. Still the port number used for the TCP connection is > the same. > > With reference to sec. 8.1 of draft-ietf-simple-message-sessions-14.txt > the format of the m= line is: > m= The format list field MUST be > set to "*". > The media doesn't accomadate for the MSRP sessionId. > The SessionId is specified in the url of the "a=path" attribute. Can the > session Id be specified in the format list? > >>> -How to distinguish between which media line is for normal MSRP Chat > >>> and MSRP File Transfer. >> MSRP for File Transfer will have a file selector in the SDP. The file >> selector is described in Section 6.1 of the File Transfer draft. >> >>> -In the previous mail you had stated that, "Each m=message >>> represents an MSRP media stream. Both can use the same MSRP session >>> (TCP connection + session-id in MSRP), but they are different media >>> streams, just multiplexed over the same TCP connection and MSRP >>> session." >>> >> Note that sharing the same MSRP session is not correct, at least, >> according to what we have in the draft now, my apologies. >> >>> It is possible to mutliplex MSRP Sessions(Identified by the session > Id) >>> over the same TCP Connection. But I am not very clear with what you >>> meant here by "MSRP media stream". Can you please give some info on > how >>> to identify the media streams in the "m=" lines. >> That is probably the main point, we need a unique identifier, and that > >> is the session Id in MSRP. That is the reason why the session ID has > to >> be different. >> >> >> BR, >> >> Miguel >> >>> Regds, >>> Sudha. >>> On Thu, 27 Apr 2006 19:56:01 +0530, Miguel Garcia >>> wrote: >>> >>>> Hi Sudha: >>>> >>>> Inline discussion. >>>> >>>> Sudha wrote: >>>>> Hi all, >>>>> Is it valid to have two m= lines in a single INVITE? >>>> Yes, of course. >>>> >>>>> If such is a case, Is it valid to have two MSRP sessions created > for >>>>> each of the media line? >>>> yes, why not? >>>> >>>>> As per the draft on File transfer using MSRP, once the File > transfer >>>>> is completed, the MSRP Session associated with it will be closed. > So >>>>> it should be apt to have 2 sessions for each of the media line. >>>> I am not sure what you mean with "2 sessions fr each of the media >>>> line". Each m=message represents an MSRP media stream. Both can use > >>>> the same MSRP session (TCP connection + session-id in MSRP), but > they >>>> are different media streams, just multiplexed over the same TCP >>>> connection and MSRP session. >>>> >>>> BR, >>>> >>>> Miguel >>>> >>>> >>>>> Regds, >>>>> Sudha >>>>> On Thu, 27 Apr 2006 19:19:52 +0530, Miguel Garcia >>>>> wrote: >>>>> >>>>>> Hi Amit: >>>>>> >>>>>> As you correctly mentioned, the spirit of the file transfer draft > is >>>>>> to reuse existing MSRP sessions, if they are available. But we >>>>>> always signal them in different m= lines. Notice that in the > example >>>>>> you provided below there is only one m= line (for file transfer), > so >>>>>> if you wanted to have chat and file transfer, you should have two > >>>>>> m=message lines, one is a regular MSRP (chat), the other specific > >>>>>> for file transfer. >>>>>> >>>>>> So, your question... "how do we handle a case where we receive a > SIP >>>>>> INVITE with a SDP offer containing both types of attributes (for >>>>>> text messaging and file transfer) in a single m-line? " seems to > be >>>>>> not applicable. We will have two m=message line, each one can have > >>>>>> its own direction attribute if needed. >>>>>> >>>>>> BR, >>>>>> >>>>>> Miguel >>>>>> >>>>>> >>>>>> simple-bounces@ietf.org wrote: >>>>>>> Hi Garcia, Ben and all, >>>>>>> draft-garcia-sipping-file-transfer-mech-00.txt mandates that > there >>>>>>> should be separate msrp session (separate m-line) for the file >>>>>>> transfer. >>>>>>> But draft-ietf-simple-message-sessions-14.txt does not really >>>>>>> differentiate between normal chat session and file transfer > session. >>>>>>> Also, it also does not mention the direction attribute. So User > can >>>>>>> also >>>>>>> have uni directional MSRP session. If user wants to create a >>>>>>> session for chat and file transfer in the >>>>>>> single SIP INVITE. Considering the above mentioned drafts, our >>>>>>> understanding is that we will get two different m-lines in SDP >>>>>>> offer for >>>>>>> msrp sessions. In such a scenario, how do we handle a case where > >>>>>>> we receive a SIP >>>>>>> INVITE with a SDP offer containing both types of attributes (for > >>>>>>> text >>>>>>> messaging and file transfer) in a single m-line? For example if > we >>>>>>> receive an OFFER. >>>>>>> v=0 >>>>>>> o=alice 2890844526 2890844526 IN IP4 > host.atlanta.example.com >>>>>>> s= >>>>>>> c=IN IP4 host.atlanta.example.com >>>>>>> t=0 0 >>>>>>> m=message 7654 TCP/MSRP * >>>>>>> a=sendonly >>>>>>> a=accept-types:text/plain * >>>>>>> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >>>>>>> a=filename:My cool picture.jpg >>>>>>> a=filetype:image/jpeg >>>>>>> a=disposition:inline >>>>>>> a=filesize:32349 >>>>>>> a=icon:cid:id2@alicepc.example.com >>>>>>> a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >>>>>>> Regards, >>>>>>> Amit >>>>>>> _______________________________________________ >>>>>>> Simple mailing list >>>>>>> Simple@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>>> >>>>> --Best Regards, >>>>> Sudha V.S >>> --Best Regards, >>> Sudha V.S > > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 28 04:13:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZO6A-0000DE-SA; Fri, 28 Apr 2006 04:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZO6A-0000D9-5a for mmusic@ietf.org; Fri, 28 Apr 2006 04:13:10 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZO68-0000q3-K0 for mmusic@ietf.org; Fri, 28 Apr 2006 04:13:10 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CD4EBD67; Fri, 28 Apr 2006 10:13:07 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:13:05 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:13:05 +0200 Received: from [131.160.126.3] (rvi2-126-3.lmf.ericsson.se [131.160.126.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D7462236E; Fri, 28 Apr 2006 11:13:04 +0300 (EEST) Message-ID: <4451CE90.2080700@ericsson.com> Date: Fri, 28 Apr 2006 11:13:04 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Joerg Ott Subject: Transfer of Icons in SIP WAS (Re: [MMUSIC] Re: File tranfer in SIP) References: <4415642A.30906@ericsson.com> <441679D3.6030600@netlab.hut.fi> <441682E5.7000901@nokia.com> <44168B1A.4000702@netlab.hut.fi> <4417FC36.9010604@ericsson.com> <441EB56E.7070305@netlab.hut.fi> <4434C6ED.8060904@ericsson.com> <44365DEE.1030402@netlab.hut.fi> <4451C625.6090102@ericsson.com> <4451C6C6.7060705@ericsson.com> In-Reply-To: <4451C6C6.7060705@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 08:13:05.0426 (UTC) FILETIME=[9387BF20:01C66A9B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Miguel Garcia , "Salvatore Loreto \(SA/ERI\)" , mmusic@ietf.org, Markus Isomaki 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: , Errors-To: mmusic-bounces@ietf.org Joerg, regarding the issue about transferring icons in the body of a SIP message, note that this was already defined by RFC 3261. Section 20.11 of RFC 3261 says: "The disposition type "icon" indicates that the body part contains an image suitable as an iconic representation of the caller or callee that could be rendered informationally by a user agent when a message has been received, or persistently while a dialog takes place." You can find the registration of the 'icon' disposition type at: http://www.iana.org/assignments/mail-cont-disp Cheers, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 28 04:48:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZOek-0005Rx-Qj; Fri, 28 Apr 2006 04:48:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZOei-0005Rr-S7 for mmusic@ietf.org; Fri, 28 Apr 2006 04:48:52 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZOeh-0002jg-EB for mmusic@ietf.org; Fri, 28 Apr 2006 04:48:52 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3S8mkGp003175; Fri, 28 Apr 2006 11:48:47 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 11:48:46 +0300 Received: from [127.0.0.1] ([172.21.34.203]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Apr 2006 11:48:46 +0300 Message-ID: <4451D6ED.9010803@nokia.com> Date: Fri, 28 Apr 2006 11:48:45 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Amitkumar.Goel@infineon.com" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 08:48:46.0168 (UTC) FILETIME=[8F830D80:01C66AA0] X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sudha.vs@globaledgesoft.com, mmusic@ietf.org, OMA-MWG-IM@mail.openmobilealliance.org Subject: [MMUSIC] Re: Handling of incoming INVITE request for different MSRP session 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: , Errors-To: mmusic-bounces@ietf.org Continuing the discussion in mmusic... It is clear that the m= line does not contain the MSRP session-id, which is only visible in the a=path line. For example: c=IN IP4 atlanta.example.com m=message 7654 TCP/MSRP * a=accept-types:text/plain a=path:msrp://atlanta.example.com:7654/jshA7we;tcp I don't really understand your question below. MSRP multiplexing over the same TCP connection is an essential feature of MSRP, and it is at the discretion of the MSRP endpoint to decide whether to multiplex or not (although it is recommended to multiplex, otherwise you are bypassing the congestion control built into TCP). So, I don't really see your question about "support for multiplexing"... Perhaps you can enlight me. /Miguel Amitkumar.Goel@infineon.com wrote: > Hi Miguel, > > If SDP offer/answer m-line ulr does not contain session id,as session ID > is a optional param, Is it mean that the offerer/answerer does not > support MSRP session multiplexing for sharing the same TCP connection? > > Regards, > Amit > > > > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 28 05:00:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZOq0-0003JE-R2; Fri, 28 Apr 2006 05:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZOpz-0003Gr-Mx for mmusic@ietf.org; Fri, 28 Apr 2006 05:00:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZOcm-0002fA-DL for mmusic@ietf.org; Fri, 28 Apr 2006 04:46:52 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZOTf-0007GY-8Z for mmusic@ietf.org; Fri, 28 Apr 2006 04:37:28 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3S8bMFl026434; Fri, 28 Apr 2006 11:37:23 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 11:37:23 +0300 Received: from [127.0.0.1] ([172.21.34.203]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Apr 2006 11:37:22 +0300 Message-ID: <4451D441.5080000@nokia.com> Date: Fri, 28 Apr 2006 11:37:21 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Sudha References: <4450CC00.7010904@nokia.com> <4450D479.8090603@nokia.com> <4451B34A.30200@nokia.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 08:37:22.0286 (UTC) FILETIME=[F7E2F0E0:01C66A9E] X-Spam-Score: -2.6 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: OMA-MWG-IM@mail.openmobilealliance.org, Gonzalo Camarillo , Amitkumar.Goel@infineon.com, mmusic@ietf.org Subject: [MMUSIC] Re: Handling of incoming INVITE request for different MSRP session 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: , Errors-To: mmusic-bounces@ietf.org So now posting to MMUSIC and the OMA mailing list. I have cut the discussion only to one relevant point Sudha wrote: > With reference to sec. 8.1 of draft-ietf-simple-message-sessions-14.txt > the format of the m= line is: > m= > The format list field MUST be set to "*". > The media doesn't accomadate for the MSRP sessionId. > The SessionId is specified in the url of the "a=path" attribute. Can the > session Id be specified in the format list? > So, what you are saying is that if someone wants to establish a regular MSRP session for chatting, and a side-by MSRP session for file transfer, and it wants to multiplex both MSRP sessions over the same TCP connection, both m=message lines will be equal. True. What is the problem? I can't see a problem, one m=message line will have the typical MSRP attributes, the other one will contain, in addition to the typical, those specific for the file transfer. I don't see the problem. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 28 05:14:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZP3m-0002IS-Kj; Fri, 28 Apr 2006 05:14:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZP3l-0002Fu-Fa for mmusic@ietf.org; Fri, 28 Apr 2006 05:14:45 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZP3j-0004te-Dk for mmusic@ietf.org; Fri, 28 Apr 2006 05:14:45 -0400 Received: from localhost.localdomain ([172.16.4.194]) by gesmail.globaledgesoft.com (8.13.1/8.13.1) with ESMTP id k3S9EUo0015704; Fri, 28 Apr 2006 14:44:30 +0530 Date: Fri, 28 Apr 2006 14:43:43 +0530 To: "Miguel Garcia" References: <4450CC00.7010904@nokia.com> <4450D479.8090603@nokia.com> <4451B34A.30200@nokia.com> <4451D441.5080000@nokia.com> From: Sudha Organization: GESL Content-Type: multipart/mixed; boundary="----=neXtPaRt_1146214840" MIME-Version: 1.0 Message-ID: In-Reply-To: <4451D441.5080000@nokia.com> User-Agent: Opera M2/8.01 (Linux, build 1204) X-Spam-Status: No, score=-1.4 required=2.5 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on gesmail.globaledgesoft.com X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: OMA-MWG-IM@mail.openmobilealliance.org, Gonzalo Camarillo , Amitkumar.Goel@infineon.com, mmusic@ietf.org Subject: [MMUSIC] Re: Handling of incoming INVITE request for different MSRP session 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: , Errors-To: mmusic-bounces@ietf.org ------=neXtPaRt_1146214840 Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all, There wont be any problem if normal MSRP chat and Filetransfer takes place in 2 diffrent MSRP sessions, each of them having their own attributes. But what I meant to say in the previous discussions is: -File Transfer and Chat cant take place in single session. -I mistook the flow of SDP headers with two m= lines in the following way: v=0 o=alice 2890844526 2890844527 IN IP4 alice.example.com s= - c=IN IP4 alice.example.com t=0 0 m=message 7394 TCP/MSRP * m=message 7394 TCP/MSRP * a=accept-types:text/plain a=path:msrp://alice.example.com:7394/2s93i;tcp a=filename:My cool picture.jpg a=filetype:image/jpeg This would certainly create a problem coz, we will not be able to specify, the Session Ids of MSRP Sessions and their accept-types. Sample SDP Message with 2 m= lines: v=0 o=alice 2890844526 2890844527 IN IP4 alice.example.com s= - c=IN IP4 alice.example.com t=0 0 m=message 7394 TCP/MSRP * a=accept-types:text/plain a=path:msrp://alice.example.com:7394/2s93i;tcp m=message 7394 TCP/MSRP * a=path:msrp://atlanta.example.com:7394/jshA7we;tcp i=This is my latest picture a=sendonly a=accept-types:* a=filename:My cool picture.jpg a=filetype:image/jpeg .... Hope the above flow is valid, and I feel there wont be any problem. Thanks n Regds, Sudha. On Fri, 28 Apr 2006 14:07:21 +0530, Miguel Garcia wrote: > So now posting to MMUSIC and the OMA mailing list. > > I have cut the discussion only to one relevant point > > > Sudha wrote: >> With reference to sec. 8.1 of draft-ietf-simple-message-sessions-14.txt >> the format of the m= line is: >> m= >> The format list field MUST be set to "*". >> The media doesn't accomadate for the MSRP sessionId. >> The SessionId is specified in the url of the "a=path" attribute. Can >> the session Id be specified in the format list? >> > > So, what you are saying is that if someone wants to establish a regular > MSRP session for chatting, and a side-by MSRP session for file transfer, > and it wants to multiplex both MSRP sessions over the same TCP > connection, both m=message lines will be equal. True. What is the > problem? I can't see a problem, one m=message line will have the typical > MSRP attributes, the other one will contain, in addition to the typical, > those specific for the file transfer. I don't see the problem. > > /Miguel > -- Best Regards, Sudha V.S ------=neXtPaRt_1146214840 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1146214840 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------=neXtPaRt_1146214840-- From mmusic-bounces@ietf.org Fri Apr 28 06:22:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZQ6s-0005Gc-FI; Fri, 28 Apr 2006 06:22:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZQ6r-0005GP-3G for mmusic@ietf.org; Fri, 28 Apr 2006 06:22:01 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZQ6o-0007yn-H3 for mmusic@ietf.org; Fri, 28 Apr 2006 06:22:01 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3SALrK9026467; Fri, 28 Apr 2006 13:21:55 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 13:21:54 +0300 Received: from [127.0.0.1] ([172.21.34.203]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Apr 2006 13:21:54 +0300 Message-ID: <4451ECC2.7060609@nokia.com> Date: Fri, 28 Apr 2006 13:21:54 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Amitkumar.Goel@infineon.com" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 10:21:54.0801 (UTC) FILETIME=[9298C610:01C66AAD] X-Spam-Score: 0.5 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: mmusic@ietf.org, OMA-MWG-IM@mail.openmobilealliance.org Subject: [MMUSIC] Re: Handling of incoming INVITE request for different MSRP session 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: , Errors-To: mmusic-bounces@ietf.org I guess (my guess), that the syntax allows it to identify, for example, an MSRP relay. Probably you would need to input the MSRP URL of your relay in your endpoint configuration. So from that point of view, it is syntactically valid to have an MSRP URL without a session-ID. But when you include MSRP URLs in SDP, then you really need the session-id, as the draft indicates. /Miguel Amitkumar.Goel@infineon.com wrote: > Thanks Miguel for the clarification. > > The formal syntax in section 9 of the MSRP draft mislead me. > > ... > ... > ... > MSRP-URL = msrp-scheme "://" [userinfo "@"] hostport > ["/" session-id] ";" transport *( ";" url-parameter) > ; userinfo as defined in RFC3986, except > ; limited to unreserved. > ; hostport as defined in RFC3261 > ... > ... > > Regards, > Amit > > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: Friday, April 28, 2006 3:20 PM > To: Goel Amitkumar (IFIN SW WS) > Cc: sudha.vs@globaledgesoft.com; mmusic@ietf.org; > OMA-MWG-IM@mail.openmobilealliance.org > Subject: Re: Handling of incoming INVITE request for different MSRP > session > > Amit: > > You are arguing that that MSRP URLs that are included in a=path line may > not contain session-ids, as you indicated in your example below. > > I would argue that such idea is not possible. While it is true that you > can create an MSRP URL that does not include the session-id, it is only > valid as a way to refer to the endpoint. But here, in SDP, we are > referring not to an endpoint, but to a media stream of MSRP traffic, > thus, so the MSRP URL it has to be fully qualified with the session-id. > > I would refer to Section 8.2 of the MSRP draft. It mandates the usage of > session IDs: > > The rightmost URL in the path attribute MUST identify the endpoint > that generated the SDP document, or some other location where that > endpoint wishes to receive requests associated with the session. It > MUST be assigned for this particular session, and MUST NOT duplicate > any URL in use for any other session in which the endpoint is > currently participating. It SHOULD be hard to guess, and protected > from eavesdroppers. This is discussed in more detail in Section 14. > > So in my opinion your example below is not valid according to MSRP. > > Regards, > > Miguel > > Amitkumar.Goel@infineon.com wrote: >> Hi Miguel, >> >> Consider the case when we get sdp offer with two m-line (without >> session id)and corresponding attributes. >> >> c=IN IP4 atlanta.example.com >> m=message 7654 TCP/MSRP * >> a=accept-types:text/plain >> a=path:msrp://atlanta.example.com:7654;tcp >> >> c=IN IP4 atlanta.example.com >> m=message 7654 TCP/MSRP * >> a=accept-types:* >> a=path:msrp://atlanta.example.com:7654;tcp >> a=filename:My cool picture.jpg >> a=filetype:image/jpeg >> a=disposition:inline >> a=filesize:32349 >> a=icon:cid:id2@alicepc.example.com >> a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >> >> Here both the path attributes are without session id. >> >> Using this offer, 2 MSRP sessions are created. When MSRP data is >> received over the TCP connection, how will I demultiplex MSRP data? To > >> identify the recipient session for the received MSRP data, I think we >> must add session id to the MSRP URL. Hope I am clear this time. >> >> >> Thanks and Regards, >> Amit Kumar Goel >> >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >> Sent: Friday, April 28, 2006 2:19 PM >> To: Goel Amitkumar (IFIN SW WS) >> Cc: sudha.vs@globaledgesoft.com; mmusic@ietf.org; >> OMA-MWG-IM@mail.openmobilealliance.org >> Subject: Re: Handling of incoming INVITE request for different MSRP >> session >> >> Continuing the discussion in mmusic... >> >> It is clear that the m= line does not contain the MSRP session-id, >> which is only visible in the a=path line. For example: >> >> c=IN IP4 atlanta.example.com >> m=message 7654 TCP/MSRP * >> a=accept-types:text/plain >> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >> >> I don't really understand your question below. MSRP multiplexing over >> the same TCP connection is an essential feature of MSRP, and it is at >> the discretion of the MSRP endpoint to decide whether to multiplex or >> not (although it is recommended to multiplex, otherwise you are >> bypassing the congestion control built into TCP). >> >> So, I don't really see your question about "support for > multiplexing"... >> Perhaps you can enlight me. >> >> /Miguel >> >> Amitkumar.Goel@infineon.com wrote: >>> Hi Miguel, >>> >>> If SDP offer/answer m-line ulr does not contain session id,as session > >>> ID is a optional param, Is it mean that the offerer/answerer does not > >>> support MSRP session multiplexing for sharing the same TCP > connection? >>> Regards, >>> Amit >>> >>> >>> >>> > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 28 06:55:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZQdT-00026x-Gn; Fri, 28 Apr 2006 06:55:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZQdR-00026r-Ti for mmusic@ietf.org; Fri, 28 Apr 2006 06:55:41 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZQdQ-00016I-Lt for mmusic@ietf.org; Fri, 28 Apr 2006 06:55:41 -0400 Received: from localhost.localdomain ([172.16.4.194]) by gesmail.globaledgesoft.com (8.13.1/8.13.1) with ESMTP id k3SAtLcv028903; Fri, 28 Apr 2006 16:25:21 +0530 Date: Fri, 28 Apr 2006 16:24:33 +0530 To: "Gonzalo Camarillo" References: <4450CC00.7010904@nokia.com> <4450D479.8090603@nokia.com> <4451B34A.30200@nokia.com> <4451D441.5080000@nokia.com> <4451DE46.2010209@ericsson.com> From: Sudha Organization: GESL Content-Type: multipart/mixed; boundary="----=neXtPaRt_1146220896" MIME-Version: 1.0 Message-ID: In-Reply-To: <4451DE46.2010209@ericsson.com> User-Agent: Opera M2/8.01 (Linux, build 1204) X-Spam-Status: No, score=-1.4 required=2.5 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on gesmail.globaledgesoft.com X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Miguel Garcia , OMA-MWG-IM@mail.openmobilealliance.org, mmusic@ietf.org, Amitkumar.Goel@infineon.com Subject: [MMUSIC] Re: Handling of incoming INVITE request for different MSRP session 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: , Errors-To: mmusic-bounces@ietf.org ------=neXtPaRt_1146220896 Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Gonzali, Refer to inline discussion. On Fri, 28 Apr 2006 14:50:06 +0530, Gonzalo Camarillo wrote: > Hi Sudha, > > I do not fully understand what you mean, but note that you can transfer > files within an MSRP session as usual. In that case, you would only need > a single 'm' line, as usual. Did you mean to say, File transfer can take place in the same session which is used for chat? This is quiet impossible coz, you will not be able to differentiate which is the data frm the file and chat-data. Further MSRP Chat session will be terminated once the file transfer is complete. > > If you want to use another m line to transfer the file so that the other > party has a chance to accept or reject the transfer, you would add a > second 'm' line whose attributes would contain a different MSRP session > ID. > > I hope this helps, > > Cheers, > > Gonzalo > > Sudha wrote: >> Hi all, >> There wont be any problem if normal MSRP chat and Filetransfer takes >> place in 2 diffrent MSRP sessions, each of them having their own >> attributes. >> But what I meant to say in the previous discussions is: >> -File Transfer and Chat cant take place in single session. >> -I mistook the flow of SDP headers with two m= lines in the following >> way: >> v=0 >> o=alice 2890844526 2890844527 IN IP4 alice.example.com >> s= - >> c=IN IP4 alice.example.com >> t=0 0 >> m=message 7394 TCP/MSRP * >> m=message 7394 TCP/MSRP * >> a=accept-types:text/plain >> a=path:msrp://alice.example.com:7394/2s93i;tcp >> a=filename:My cool picture.jpg >> a=filetype:image/jpeg >> This would certainly create a problem coz, we will not be able to >> specify, the Session Ids of MSRP Sessions and their accept-types. >> Sample SDP Message with 2 m= lines: >> v=0 >> o=alice 2890844526 2890844527 IN IP4 alice.example.com >> s= - >> c=IN IP4 alice.example.com >> t=0 0 >> m=message 7394 TCP/MSRP * >> a=accept-types:text/plain >> a=path:msrp://alice.example.com:7394/2s93i;tcp >> m=message 7394 TCP/MSRP * >> a=path:msrp://atlanta.example.com:7394/jshA7we;tcp >> i=This is my latest picture >> a=sendonly >> a=accept-types:* >> a=filename:My cool picture.jpg >> a=filetype:image/jpeg >> .... >> Hope the above flow is valid, and I feel there wont be any problem. >> Thanks n Regds, >> Sudha. >> On Fri, 28 Apr 2006 14:07:21 +0530, Miguel Garcia >> wrote: >> >>> So now posting to MMUSIC and the OMA mailing list. >>> >>> I have cut the discussion only to one relevant point >>> >>> >>> Sudha wrote: >>>> With reference to sec. 8.1 of >>>> draft-ietf-simple-message-sessions-14.txt the format of the m= line >>>> is: >>>> m= >>>> The format list field MUST be set to "*". >>>> The media doesn't accomadate for the MSRP sessionId. >>>> The SessionId is specified in the url of the "a=path" attribute. Can >>>> the session Id be specified in the format list? >>>> >>> >>> So, what you are saying is that if someone wants to establish a >>> regular MSRP session for chatting, and a side-by MSRP session for file >>> transfer, and it wants to multiplex both MSRP sessions over the same >>> TCP connection, both m=message lines will be equal. True. What is the >>> problem? I can't see a problem, one m=message line will have the >>> typical MSRP attributes, the other one will contain, in addition to >>> the typical, those specific for the file transfer. I don't see the >>> problem. >>> >>> /Miguel >>> >> --Best Regards, >> Sudha V.S >> >> ------------------------------------------------------------------------ >> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended >> solely for the use of the addressee(s). If you are not the intended >> recipient, please notify the sender by e-mail and delete the original >> message.Global Edge Software Ltd has taken every reasonable precaution >> to minimize this risk, but is not liable for any damage you may sustain >> as a result of any virus in this e-mail. You should carry out your own >> virus checks before opening the e-mail or attachment. Global Edge >> Software Ltd reserves the right to monitor and review the content of >> all messages sent to or from this e-mail address -- Best Regards, Sudha V.S ------=neXtPaRt_1146220896 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1146220896 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------=neXtPaRt_1146220896-- From mmusic-bounces@ietf.org Fri Apr 28 08:01:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZRf4-000097-SO; Fri, 28 Apr 2006 08:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZRf3-00008z-8a for mmusic@ietf.org; Fri, 28 Apr 2006 08:01:25 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZPpY-0006fW-1W for mmusic@ietf.org; Fri, 28 Apr 2006 06:04:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZP8y-0007a9-Ru for mmusic@ietf.org; Fri, 28 Apr 2006 05:20:10 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 731CC4F0003; Fri, 28 Apr 2006 11:20:07 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 11:20:07 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 11:20:06 +0200 Received: from [131.160.126.3] (rvi2-126-3.lmf.ericsson.se [131.160.126.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8362A236E; Fri, 28 Apr 2006 12:20:06 +0300 (EEST) Message-ID: <4451DE46.2010209@ericsson.com> Date: Fri, 28 Apr 2006 12:20:06 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Sudha References: <4450CC00.7010904@nokia.com> <4450D479.8090603@nokia.com> <4451B34A.30200@nokia.com> <4451D441.5080000@nokia.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 09:20:06.0997 (UTC) FILETIME=[F092C850:01C66AA4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.3 (--) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Miguel Garcia , OMA-MWG-IM@mail.openmobilealliance.org, mmusic@ietf.org, Amitkumar.Goel@infineon.com Subject: [MMUSIC] Re: Handling of incoming INVITE request for different MSRP session 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: , Errors-To: mmusic-bounces@ietf.org Hi Sudha, I do not fully understand what you mean, but note that you can transfer files within an MSRP session as usual. In that case, you would only need a single 'm' line, as usual. If you want to use another m line to transfer the file so that the other party has a chance to accept or reject the transfer, you would add a second 'm' line whose attributes would contain a different MSRP session ID. I hope this helps, Cheers, Gonzalo Sudha wrote: > Hi all, > There wont be any problem if normal MSRP chat and Filetransfer takes > place in 2 diffrent MSRP sessions, each of them having their own > attributes. > > But what I meant to say in the previous discussions is: > -File Transfer and Chat cant take place in single session. > > -I mistook the flow of SDP headers with two m= lines in the following way: > v=0 > o=alice 2890844526 2890844527 IN IP4 alice.example.com > s= - > c=IN IP4 alice.example.com > t=0 0 > m=message 7394 TCP/MSRP * > m=message 7394 TCP/MSRP * > a=accept-types:text/plain > a=path:msrp://alice.example.com:7394/2s93i;tcp > a=filename:My cool picture.jpg > a=filetype:image/jpeg > This would certainly create a problem coz, we will not be able to > specify, the Session Ids of MSRP Sessions and their accept-types. > > > Sample SDP Message with 2 m= lines: > v=0 > o=alice 2890844526 2890844527 IN IP4 alice.example.com > s= - > c=IN IP4 alice.example.com > t=0 0 > m=message 7394 TCP/MSRP * > a=accept-types:text/plain > a=path:msrp://alice.example.com:7394/2s93i;tcp > m=message 7394 TCP/MSRP * > a=path:msrp://atlanta.example.com:7394/jshA7we;tcp > i=This is my latest picture > a=sendonly > a=accept-types:* > a=filename:My cool picture.jpg > a=filetype:image/jpeg > .... > > Hope the above flow is valid, and I feel there wont be any problem. > > Thanks n Regds, > Sudha. > > On Fri, 28 Apr 2006 14:07:21 +0530, Miguel Garcia > wrote: > >> So now posting to MMUSIC and the OMA mailing list. >> >> I have cut the discussion only to one relevant point >> >> >> Sudha wrote: >>> With reference to sec. 8.1 of >>> draft-ietf-simple-message-sessions-14.txt the format of the m= line is: >>> m= >>> The format list field MUST be set to "*". >>> The media doesn't accomadate for the MSRP sessionId. >>> The SessionId is specified in the url of the "a=path" attribute. Can >>> the session Id be specified in the format list? >>> >> >> So, what you are saying is that if someone wants to establish a >> regular MSRP session for chatting, and a side-by MSRP session for file >> transfer, and it wants to multiplex both MSRP sessions over the same >> TCP connection, both m=message lines will be equal. True. What is the >> problem? I can't see a problem, one m=message line will have the >> typical MSRP attributes, the other one will contain, in addition to >> the typical, those specific for the file transfer. I don't see the >> problem. >> >> /Miguel >> > > > > --Best Regards, > Sudha V.S > > > ------------------------------------------------------------------------ > > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 28 08:02:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZRfc-0000vn-V1; Fri, 28 Apr 2006 08:02:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZRfb-0000u6-4c for mmusic@ietf.org; Fri, 28 Apr 2006 08:01:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZPpS-0006gT-67 for mmusic@ietf.org; Fri, 28 Apr 2006 06:04:02 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZPGW-0007hh-BF for mmusic@ietf.org; Fri, 28 Apr 2006 05:27:58 -0400 Received: from unknown (HELO sinse211.ap.infineon.com) ([172.17.65.149]) by smtp3.infineon.com with ESMTP; 28 Apr 2006 17:27:53 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse211.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Apr 2006 17:27:53 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Apr 2006 14:57:51 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Handling of incoming INVITE request for different MSRP session thread-index: AcZqoJ1DhOBomktMTg2h5qzEci/z5AABTLkQ From: To: X-OriginalArrivalTime: 28 Apr 2006 09:27:53.0181 (UTC) FILETIME=[0670D0D0:01C66AA6] X-Spam-Score: -1.3 (-) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mmusic@ietf.org, OMA-MWG-IM@mail.openmobilealliance.org Subject: [MMUSIC] RE: Handling of incoming INVITE request for different MSRP session 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: , Errors-To: mmusic-bounces@ietf.org Hi Miguel, Consider the case when we get sdp offer with two m-line (without session id)and corresponding attributes. =20 c=3DIN IP4 atlanta.example.com m=3Dmessage 7654 TCP/MSRP * a=3Daccept-types:text/plain a=3Dpath:msrp://atlanta.example.com:7654;tcp =20 c=3DIN IP4 atlanta.example.com m=3Dmessage 7654 TCP/MSRP * a=3Daccept-types:* a=3Dpath:msrp://atlanta.example.com:7654;tcp a=3Dfilename:My cool picture.jpg a=3Dfiletype:image/jpeg a=3Ddisposition:inline a=3Dfilesize:32349 a=3Dicon:cid:id2@alicepc.example.com a=3Dhash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e Here both the path attributes are without session id. =20 Using this offer, 2 MSRP sessions are created. When MSRP data is received over the TCP connection, how will I demultiplex MSRP data? To identify the recipient session for the received MSRP data, I think we must add session id to the MSRP URL. Hope I am clear this time. Thanks and Regards, Amit Kumar Goel -----Original Message----- From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 Sent: Friday, April 28, 2006 2:19 PM To: Goel Amitkumar (IFIN SW WS) Cc: sudha.vs@globaledgesoft.com; mmusic@ietf.org; OMA-MWG-IM@mail.openmobilealliance.org Subject: Re: Handling of incoming INVITE request for different MSRP session Continuing the discussion in mmusic... It is clear that the m=3D line does not contain the MSRP session-id, = which is only visible in the a=3Dpath line. For example: c=3DIN IP4 atlanta.example.com m=3Dmessage 7654 TCP/MSRP * a=3Daccept-types:text/plain a=3Dpath:msrp://atlanta.example.com:7654/jshA7we;tcp I don't really understand your question below. MSRP multiplexing over the same TCP connection is an essential feature of MSRP, and it is at the discretion of the MSRP endpoint to decide whether to multiplex or not (although it is recommended to multiplex, otherwise you are bypassing the congestion control built into TCP). So, I don't really see your question about "support for multiplexing"... Perhaps you can enlight me. /Miguel Amitkumar.Goel@infineon.com wrote: > Hi Miguel, >=20 > If SDP offer/answer m-line ulr does not contain session id,as session=20 > ID is a optional param, Is it mean that the offerer/answerer does not=20 > support MSRP session multiplexing for sharing the same TCP connection? >=20 > Regards, > Amit >=20 > =20 >=20 > --=20 Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 28 08:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZRm6-0003nq-IM; Fri, 28 Apr 2006 08:08:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZRm5-0003nl-NT for mmusic@ietf.org; Fri, 28 Apr 2006 08:08:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZPpE-0006fW-06 for mmusic@ietf.org; Fri, 28 Apr 2006 06:03:48 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZPbb-0007tw-8Y for mmusic@ietf.org; Fri, 28 Apr 2006 05:49:44 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3S9na6e032032; Fri, 28 Apr 2006 12:49:39 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 12:49:36 +0300 Received: from [127.0.0.1] ([172.21.34.203]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Apr 2006 12:49:36 +0300 Message-ID: <4451E52F.5060901@nokia.com> Date: Fri, 28 Apr 2006 12:49:35 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Amitkumar.Goel@infineon.com" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 09:49:36.0010 (UTC) FILETIME=[0EFCBEA0:01C66AA9] X-Spam-Score: -2.6 (--) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: mmusic@ietf.org, OMA-MWG-IM@mail.openmobilealliance.org Subject: [MMUSIC] Re: Handling of incoming INVITE request for different MSRP session 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: , Errors-To: mmusic-bounces@ietf.org Amit: You are arguing that that MSRP URLs that are included in a=path line may not contain session-ids, as you indicated in your example below. I would argue that such idea is not possible. While it is true that you can create an MSRP URL that does not include the session-id, it is only valid as a way to refer to the endpoint. But here, in SDP, we are referring not to an endpoint, but to a media stream of MSRP traffic, thus, so the MSRP URL it has to be fully qualified with the session-id. I would refer to Section 8.2 of the MSRP draft. It mandates the usage of session IDs: The rightmost URL in the path attribute MUST identify the endpoint that generated the SDP document, or some other location where that endpoint wishes to receive requests associated with the session. It MUST be assigned for this particular session, and MUST NOT duplicate any URL in use for any other session in which the endpoint is currently participating. It SHOULD be hard to guess, and protected from eavesdroppers. This is discussed in more detail in Section 14. So in my opinion your example below is not valid according to MSRP. Regards, Miguel Amitkumar.Goel@infineon.com wrote: > Hi Miguel, > > Consider the case when we get sdp offer with two m-line (without > session id)and corresponding attributes. > > c=IN IP4 atlanta.example.com > m=message 7654 TCP/MSRP * > a=accept-types:text/plain > a=path:msrp://atlanta.example.com:7654;tcp > > c=IN IP4 atlanta.example.com > m=message 7654 TCP/MSRP * > a=accept-types:* > a=path:msrp://atlanta.example.com:7654;tcp > a=filename:My cool picture.jpg > a=filetype:image/jpeg > a=disposition:inline > a=filesize:32349 > a=icon:cid:id2@alicepc.example.com > a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e > > Here both the path attributes are without session id. > > Using this offer, 2 MSRP sessions are created. When MSRP data is > received over the TCP connection, how will I demultiplex MSRP data? To > identify the recipient session for the received MSRP data, I think we > must add session id to the MSRP URL. Hope I am clear this time. > > > Thanks and Regards, > Amit Kumar Goel > > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: Friday, April 28, 2006 2:19 PM > To: Goel Amitkumar (IFIN SW WS) > Cc: sudha.vs@globaledgesoft.com; mmusic@ietf.org; > OMA-MWG-IM@mail.openmobilealliance.org > Subject: Re: Handling of incoming INVITE request for different MSRP > session > > Continuing the discussion in mmusic... > > It is clear that the m= line does not contain the MSRP session-id, which > is only visible in the a=path line. For example: > > c=IN IP4 atlanta.example.com > m=message 7654 TCP/MSRP * > a=accept-types:text/plain > a=path:msrp://atlanta.example.com:7654/jshA7we;tcp > > I don't really understand your question below. MSRP multiplexing over > the same TCP connection is an essential feature of MSRP, and it is at > the discretion of the MSRP endpoint to decide whether to multiplex or > not (although it is recommended to multiplex, otherwise you are > bypassing the congestion control built into TCP). > > So, I don't really see your question about "support for multiplexing"... > > Perhaps you can enlight me. > > /Miguel > > Amitkumar.Goel@infineon.com wrote: >> Hi Miguel, >> >> If SDP offer/answer m-line ulr does not contain session id,as session >> ID is a optional param, Is it mean that the offerer/answerer does not >> support MSRP session multiplexing for sharing the same TCP connection? >> >> Regards, >> Amit >> >> >> >> -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Apr 29 07:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZnzA-0001wa-9t; Sat, 29 Apr 2006 07:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZPrx-000551-Hd for mmusic@ietf.org; Fri, 28 Apr 2006 06:06:37 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZPrv-0006xM-78 for mmusic@ietf.org; Fri, 28 Apr 2006 06:06:37 -0400 Received: from unknown (HELO sinse212.ap.infineon.com) ([172.17.65.148]) by smtp3.infineon.com with ESMTP; 28 Apr 2006 18:06:33 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse212.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Apr 2006 18:06:33 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Apr 2006 15:36:08 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Handling of incoming INVITE request for different MSRP session thread-index: AcZqqRjUzCEkSOmuTPq3tLuGT7vnPgAAEP/g From: To: X-OriginalArrivalTime: 28 Apr 2006 10:06:33.0092 (UTC) FILETIME=[6D372440:01C66AAB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d X-Mailman-Approved-At: Sat, 29 Apr 2006 07:51:38 -0400 Cc: mmusic@ietf.org, OMA-MWG-IM@mail.openmobilealliance.org Subject: [MMUSIC] RE: Handling of incoming INVITE request for different MSRP session 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: , Errors-To: mmusic-bounces@ietf.org Thanks Miguel for the clarification.=20 The formal syntax in section 9 of the MSRP draft mislead me.=20 ... ... ... MSRP-URL =3D msrp-scheme "://" [userinfo "@"] hostport ["/" session-id] ";" transport *( ";" url-parameter) ; userinfo as defined in RFC3986, except ; limited to unreserved. ; hostport as defined in RFC3261 ... ... Regards, Amit -----Original Message----- From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 Sent: Friday, April 28, 2006 3:20 PM To: Goel Amitkumar (IFIN SW WS) Cc: sudha.vs@globaledgesoft.com; mmusic@ietf.org; OMA-MWG-IM@mail.openmobilealliance.org Subject: Re: Handling of incoming INVITE request for different MSRP session Amit: You are arguing that that MSRP URLs that are included in a=3Dpath line = may not contain session-ids, as you indicated in your example below. I would argue that such idea is not possible. While it is true that you can create an MSRP URL that does not include the session-id, it is only valid as a way to refer to the endpoint. But here, in SDP, we are referring not to an endpoint, but to a media stream of MSRP traffic, thus, so the MSRP URL it has to be fully qualified with the session-id. I would refer to Section 8.2 of the MSRP draft. It mandates the usage of session IDs: The rightmost URL in the path attribute MUST identify the endpoint that generated the SDP document, or some other location where that endpoint wishes to receive requests associated with the session. It MUST be assigned for this particular session, and MUST NOT duplicate any URL in use for any other session in which the endpoint is currently participating. It SHOULD be hard to guess, and protected From mmusic-bounces@ietf.org Sat Apr 29 07:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZnzA-0001wa-9t; Sat, 29 Apr 2006 07:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZPrx-000551-Hd for mmusic@ietf.org; Fri, 28 Apr 2006 06:06:37 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZPrv-0006xM-78 for mmusic@ietf.org; Fri, 28 Apr 2006 06:06:37 -0400 Received: from unknown (HELO sinse212.ap.infineon.com) ([172.17.65.148]) by smtp3.infineon.com with ESMTP; 28 Apr 2006 18:06:33 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse212.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Apr 2006 18:06:33 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Apr 2006 15:36:08 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Handling of incoming INVITE request for different MSRP session thread-index: AcZqqRjUzCEkSOmuTPq3tLuGT7vnPgAAEP/g From: To: X-OriginalArrivalTime: 28 Apr 2006 10:06:33.0092 (UTC) FILETIME=[6D372440:01C66AAB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d X-Mailman-Approved-At: Sat, 29 Apr 2006 07:51:38 -0400 Cc: mmusic@ietf.org, OMA-MWG-IM@mail.openmobilealliance.org Subject: [MMUSIC] RE: Handling of incoming INVITE request for different MSRP session 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: , Errors-To: mmusic-bounces@ietf.org Thanks Miguel for the clarification.=20 The formal syntax in section 9 of the MSRP draft mislead me.=20 ... ... ... MSRP-URL =3D msrp-scheme "://" [userinfo "@"] hostport ["/" session-id] ";" transport *( ";" url-parameter) ; userinfo as defined in RFC3986, except ; limited to unreserved. ; hostport as defined in RFC3261 ... ... Regards, Amit -----Original Message----- From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 Sent: Friday, April 28, 2006 3:20 PM To: Goel Amitkumar (IFIN SW WS) Cc: sudha.vs@globaledgesoft.com; mmusic@ietf.org; OMA-MWG-IM@mail.openmobilealliance.org Subject: Re: Handling of incoming INVITE request for different MSRP session Amit: You are arguing that that MSRP URLs that are included in a=3Dpath line = may not contain session-ids, as you indicated in your example below. I would argue that such idea is not possible. While it is true that you can create an MSRP URL that does not include the session-id, it is only valid as a way to refer to the endpoint. But here, in SDP, we are referring not to an endpoint, but to a media stream of MSRP traffic, thus, so the MSRP URL it has to be fully qualified with the session-id. I would refer to Section 8.2 of the MSRP draft. It mandates the usage of session IDs: The rightmost URL in the path attribute MUST identify the endpoint that generated the SDP document, or some other location where that endpoint wishes to receive requests associated with the session. It MUST be assigned for this particular session, and MUST NOT duplicate any URL in use for any other session in which the endpoint is currently participating. It SHOULD be hard to guess, and protected from eavesdroppers. This is discussed in more detail in Section 14. So in my opinion your example below is not valid according to MSRP. Regards, Miguel Amitkumar.Goel@infineon.com wrote: > Hi Miguel, >=20 > Consider the case when we get sdp offer with two m-line (without=20 > session id)and corresponding attributes. >=20 > c=3DIN IP4 atlanta.example.com > m=3Dmessage 7654 TCP/MSRP * > a=3Daccept-types:text/plain > a=3Dpath:msrp://atlanta.example.com:7654;tcp =20 >=20 > c=3DIN IP4 atlanta.example.com > m=3Dmessage 7654 TCP/MSRP * > a=3Daccept-types:* > a=3Dpath:msrp://atlanta.example.com:7654;tcp > a=3Dfilename:My cool picture.jpg > a=3Dfiletype:image/jpeg > a=3Ddisposition:inline > a=3Dfilesize:32349 > a=3Dicon:cid:id2@alicepc.example.com > a=3Dhash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >=20 > Here both the path attributes are without session id. > =20 > Using this offer, 2 MSRP sessions are created. When MSRP data is=20 > received over the TCP connection, how will I demultiplex MSRP data? To > identify the recipient session for the received MSRP data, I think we=20 > must add session id to the MSRP URL. Hope I am clear this time. >=20 >=20 > Thanks and Regards, > Amit Kumar Goel >=20 > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: Friday, April 28, 2006 2:19 PM > To: Goel Amitkumar (IFIN SW WS) > Cc: sudha.vs@globaledgesoft.com; mmusic@ietf.org;=20 > OMA-MWG-IM@mail.openmobilealliance.org > Subject: Re: Handling of incoming INVITE request for different MSRP=20 > session >=20 > Continuing the discussion in mmusic... >=20 > It is clear that the m=3D line does not contain the MSRP session-id,=20 > which is only visible in the a=3Dpath line. For example: >=20 > c=3DIN IP4 atlanta.example.com > m=3Dmessage 7654 TCP/MSRP * > a=3Daccept-types:text/plain > a=3Dpath:msrp://atlanta.example.com:7654/jshA7we;tcp >=20 > I don't really understand your question below. MSRP multiplexing over=20 > the same TCP connection is an essential feature of MSRP, and it is at=20 > the discretion of the MSRP endpoint to decide whether to multiplex or=20 > not (although it is recommended to multiplex, otherwise you are=20 > bypassing the congestion control built into TCP). >=20 > So, I don't really see your question about "support for multiplexing"... >=20 > Perhaps you can enlight me. >=20 > /Miguel >=20 > Amitkumar.Goel@infineon.com wrote: >> Hi Miguel, >> >> If SDP offer/answer m-line ulr does not contain session id,as session >> ID is a optional param, Is it mean that the offerer/answerer does not >> support MSRP session multiplexing for sharing the same TCP connection? >> >> Regards, >> Amit >> >> =20 >> >> --=20 Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Apr 29 07:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZnzA-0001wR-1j; Sat, 29 Apr 2006 07:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNXT-0004bg-An for mmusic@ietf.org; Fri, 28 Apr 2006 03:37:19 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZNXR-0007I0-4R for mmusic@ietf.org; Fri, 28 Apr 2006 03:37:19 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2F3CCD2D; Fri, 28 Apr 2006 09:37:16 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:37:15 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, from eavesdroppers. This is discussed in more detail in Section 14. So in my opinion your example below is not valid according to MSRP. Regards, Miguel Amitkumar.Goel@infineon.com wrote: > Hi Miguel, >=20 > Consider the case when we get sdp offer with two m-line (without=20 > session id)and corresponding attributes. >=20 > c=3DIN IP4 atlanta.example.com > m=3Dmessage 7654 TCP/MSRP * > a=3Daccept-types:text/plain > a=3Dpath:msrp://atlanta.example.com:7654;tcp =20 >=20 > c=3DIN IP4 atlanta.example.com > m=3Dmessage 7654 TCP/MSRP * > a=3Daccept-types:* > a=3Dpath:msrp://atlanta.example.com:7654;tcp > a=3Dfilename:My cool picture.jpg > a=3Dfiletype:image/jpeg > a=3Ddisposition:inline > a=3Dfilesize:32349 > a=3Dicon:cid:id2@alicepc.example.com > a=3Dhash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >=20 > Here both the path attributes are without session id. > =20 > Using this offer, 2 MSRP sessions are created. When MSRP data is=20 > received over the TCP connection, how will I demultiplex MSRP data? To > identify the recipient session for the received MSRP data, I think we=20 > must add session id to the MSRP URL. Hope I am clear this time. >=20 >=20 > Thanks and Regards, > Amit Kumar Goel >=20 > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: Friday, April 28, 2006 2:19 PM > To: Goel Amitkumar (IFIN SW WS) > Cc: sudha.vs@globaledgesoft.com; mmusic@ietf.org;=20 > OMA-MWG-IM@mail.openmobilealliance.org > Subject: Re: Handling of incoming INVITE request for different MSRP=20 > session >=20 > Continuing the discussion in mmusic... >=20 > It is clear that the m=3D line does not contain the MSRP session-id,=20 > which is only visible in the a=3Dpath line. For example: >=20 > c=3DIN IP4 atlanta.example.com > m=3Dmessage 7654 TCP/MSRP * > a=3Daccept-types:text/plain > a=3Dpath:msrp://atlanta.example.com:7654/jshA7we;tcp >=20 > I don't really understand your question below. MSRP multiplexing over=20 > the same TCP connection is an essential feature of MSRP, and it is at=20 > the discretion of the MSRP endpoint to decide whether to multiplex or=20 > not (although it is recommended to multiplex, otherwise you are=20 > bypassing the congestion control built into TCP). >=20 > So, I don't really see your question about "support for multiplexing"... >=20 > Perhaps you can enlight me. >=20 > /Miguel >=20 > Amitkumar.Goel@infineon.com wrote: >> Hi Miguel, >> >> If SDP offer/answer m-line ulr does not contain session id,as session >> ID is a optional param, Is it mean that the offerer/answerer does not >> support MSRP session multiplexing for sharing the same TCP connection? >> >> Regards, >> Amit >> >> =20 >> >> --=20 Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Apr 29 07:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZnzA-0001wR-1j; Sat, 29 Apr 2006 07:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNXT-0004bg-An for mmusic@ietf.org; Fri, 28 Apr 2006 03:37:19 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZNXR-0007I0-4R for mmusic@ietf.org; Fri, 28 Apr 2006 03:37:19 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2F3CCD2D; Fri, 28 Apr 2006 09:37:16 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:37:15 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:37:14 +0200 Received: from [131.160.126.3] (rvi2-126-3.lmf.ericsson.se [131.160.126.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6DF0E236E; Fri, 28 Apr 2006 10:37:11 +0300 (EEST) Message-ID: <4451C625.6090102@ericsson.com> Date: Fri, 28 Apr 2006 10:37:09 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Joerg Ott References: <4415642A.30906@ericsson.com> <441679D3.6030600@netlab.hut.fi> <441682E5.7000901@nokia.com> <44168B1A.4000702@netlab.hut.fi> <4417FC36.9010604@ericsson.com> <441EB56E.7070305@netlab.hut.fi> <4434C6ED.8060904@ericsson.com> <44365DEE.1030402@netlab.hut.fi> In-Reply-To: <44365DEE.1030402@netlab.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 07:37:14.0977 (UTC) FILETIME=[91C34510:01C66A96] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-Mailman-Approved-At: Sat, 29 Apr 2006 07:51:38 -0400 Cc: Cullen Jennings , Rohan Mahy , mmusic@ietf.org, Jon Peterson , Allison Mankin , Miguel Garcia , Joerg Ott , Markus Isomaki , "Salvatore Loreto \(SA/ERI\)" , Colin Perkins Subject: [MMUSIC] Re: File tranfer in SIP 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: , Errors-To: mmusic-bounces@ietf.org Hi Joerg, > moving this to MMUSIC: perfect. > Regarding the > encoding, I suppose we will have to worry about how to put this into > SDP. This brings up -- again -- the discussion of whether to include > some "blob" of, from an SDP perspective, opaque metadata (e.g., b64 > encoded zip version of the FLUTE FDT, just to give some weird example) > or whether to make these attributes explicit. I would go for explicit SDP attributed (i.e., 'a' lines). > If we make the attributes explicit, this is essentially a more general > aspect of describing the purpuse of a media stream and would not be > restricted to file transfer. We have some informal hints for audio > and video already and this appears conceptually similar in that it > identifies the purpose and helps the answerer to decide whether to > accept it or not. > > Keeping this in mind, it would be extremely useful, not to invent > independent sets of attributes for file transfer, MSRP sessions, > audio, video, whiteboard, and so so. The attributes defined in the draft describe a file to be transfered. If somebody comes up with different attributes to describe the contents of the audio being sent over a media stream, those will not have any interaction with our attributes. Different types of media streams need different attributes to describe their contents. > I clearly _do_not_ want to end up in an XCON-style discussion about > metadata and the like, but it may be worthwhile given some > consideration to future evolution of this stuff and compatibility > with existing attributes. We have not found any interactions with existing attributes. >>> I am also concerned about motivating the use of inline images for >>> icons. I can hardly see why you would need an icon to decide >>> whether or not to accept a file transfer. >> >> A lot of commercial IM systems support it, and users find it very >> useful. SIP-based systems need to be able to provide a similar user >> experience if we do not want people to start doing things is >> proprietary ways. > > It's you 28 Apr 2006 09:37:14 +0200 Received: from [131.160.126.3] (rvi2-126-3.lmf.ericsson.se [131.160.126.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6DF0E236E; Fri, 28 Apr 2006 10:37:11 +0300 (EEST) Message-ID: <4451C625.6090102@ericsson.com> Date: Fri, 28 Apr 2006 10:37:09 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Joerg Ott References: <4415642A.30906@ericsson.com> <441679D3.6030600@netlab.hut.fi> <441682E5.7000901@nokia.com> <44168B1A.4000702@netlab.hut.fi> <4417FC36.9010604@ericsson.com> <441EB56E.7070305@netlab.hut.fi> <4434C6ED.8060904@ericsson.com> <44365DEE.1030402@netlab.hut.fi> In-Reply-To: <44365DEE.1030402@netlab.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 07:37:14.0977 (UTC) FILETIME=[91C34510:01C66A96] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-Mailman-Approved-At: Sat, 29 Apr 2006 07:51:38 -0400 Cc: Cullen Jennings , Rohan Mahy , mmusic@ietf.org, Jon Peterson , Allison Mankin , Miguel Garcia , Joerg Ott , Markus Isomaki , "Salvatore Loreto \(SA/ERI\)" , Colin Perkins Subject: [MMUSIC] Re: File tranfer in SIP 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: , Errors-To: mmusic-bounces@ietf.org Hi Joerg, > moving this to MMUSIC: perfect. > Regarding the > encoding, I suppose we will have to worry about how to put this into > SDP. This brings up -- again -- the discussion of whether to include > some "blob" of, from an SDP perspective, opaque metadata (e.g., b64 > encoded zip version of the FLUTE FDT, just to give some weird example) > or whether to make these attributes explicit. I would go for explicit SDP attributed (i.e., 'a' lines). > If we make the attributes explicit, this is essentially a more general > aspect of describing the purpuse of a media stream and would not be > restricted to file transfer. We have some informal hints for audio > and video already and this appears conceptually similar in that it > identifies the purpose and helps the answerer to decide whether to > accept it or not. > > Keeping this in mind, it would be extremely useful, not to invent > independent sets of attributes for file transfer, MSRP sessions, > audio, video, whiteboard, and so so. The attributes defined in the draft describe a file to be transfered. If somebody comes up with different attributes to describe the contents of the audio being sent over a media stream, those will not have any interaction with our attributes. Different types of media streams need different attributes to describe their contents. > I clearly _do_not_ want to end up in an XCON-style discussion about > metadata and the like, but it may be worthwhile given some > consideration to future evolution of this stuff and compatibility > with existing attributes. We have not found any interactions with existing attributes. >>> I am also concerned about motivating the use of inline images for >>> icons. I can hardly see why you would need an icon to decide >>> whether or not to accept a file transfer. >> >> A lot of commercial IM systems support it, and users find it very >> useful. SIP-based systems need to be able to provide a similar user >> experience if we do not want people to start doing things is >> proprietary ways. > > It's your call in the end of the day. Often, icons are created based > upon the filename extension -- and I suspect that the filename is going > to be much more relevant that the icon in deciding whether or not to > accept it. Icons are not worth much and only increase volume. But if > we decide that it is useful: If I want to send you a picture called PCJ00234.JPG, you will not know whether or not you want to receive it. However, if you see a small icon of the picture, you will be in a better position to make that decision. Many people find icons very useful, in many cases much more than the file name. > You must decide how much you worry about the SIP signaling architecture. > Given that the INFO method is "damned" (which I fully support), I do not > believe that turning parts of SDP into a transport is a particularly > smart idea. It clearly does not ad efficiency. If you follow > traditional SIPPING thinking, you will need to separate the desired > effect from the mechanism to achieve it. There may be better ways. > > I am simply worried to open a door that we better leave closed. > Would you want to limit the media type or the size of an icon? > If so, what would be the right value? Would you negotiate it and > come up with an "embedded contents too large" status code? We have created small icons with a resolution of 32 x 24 pixels using 4 bits for depth color whose size was around 500 bytes. In any case, we can add text stating the problems of sending too large SIP messages. > I think I got somewhat confused that I constructed a close to impossible > scenario. For the sender it is indeed trivial if the sending user > selects the file. Of course, the filename should be included because > otherwise the receiver does not easily find out whether or not it has > a copy of the file already. If the receiving users wants to initiate > a file transfer, of course, it does not have a checksum at hand to > include. If some scenarios (e.g., file sharing) you will have the hash of the file you want, but you will not have the file yet. >> I do not see any issue with having simultaneous media streams. It is >> again regular SDP behavior. > > Well, I assume that if I send you a second offer within a session > and you also send me one at the same time, we will have to do some > conflict resolution since both of us will use the (n+1)st m-line > for potentially different purposes. Since this has probably not > received much implementation attention in the past (and happened > rather rarely in practice), it have not been noticed. But it may > be specified and just did not find this upon a quick search. That conflict resolution is already defined at the offer/answer level. Of course, we do not intend to redefine that behavior. Thanks, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic r call in the end of the day. Often, icons are created based > upon the filename extension -- and I suspect that the filename is going > to be much more relevant that the icon in deciding whether or not to > accept it. Icons are not worth much and only increase volume. But if > we decide that it is useful: If I want to send you a picture called PCJ00234.JPG, you will not know whether or not you want to receive it. However, if you see a small icon of the picture, you will be in a better position to make that decision. Many people find icons very useful, in many cases much more than the file name. > You must decide how much you worry about the SIP signaling architecture. > Given that the INFO method is "damned" (which I fully support), I do not > believe that turning parts of SDP into a transport is a particularly > smart idea. It clearly does not ad efficiency. If you follow > traditional SIPPING thinking, you will need to separate the desired > effect from the mechanism to achieve it. There may be better ways. > > I am simply worried to open a door that we better leave closed. > Would you want to limit the media type or the size of an icon? > If so, what would be the right value? Would you negotiate it and > come up with an "embedded contents too large" status code? We have created small icons with a resolution of 32 x 24 pixels using 4 bits for depth color whose size was around 500 bytes. In any case, we can add text stating the problems of sending too large SIP messages. > I think I got somewhat confused that I constructed a close to impossible > scenario. For the sender it is indeed trivial if the sending user > selects the file. Of course, the filename should be included because > otherwise the receiver does not easily find out whether or not it has > a copy of the file already. If the receiving users wants to initiate > a file transfer, of course, it does not have a checksum at hand to > include. If some scenarios (e.g., file sharing) you will have the hash of the file you want, but you will not have the file yet. >> I do not see any issue with having simultaneous media streams. It is >> again regular SDP behavior. > > Well, I assume that if I send you a second offer within a session > and you also send me one at the same time, we will have to do some > conflict resolution since both of us will use the (n+1)st m-line > for potentially different purposes. Since this has probably not > received much implementation attention in the past (and happened > rather rarely in practice), it have not been noticed. But it may > be specified and just did not find this upon a quick search. That conflict resolution is already defined at the offer/answer level. Of course, we do not intend to redefine that behavior. Thanks, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic