From dworley@avaya.com Fri Jul 1 11:15:38 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF9D1F0CA1 for ; Fri, 1 Jul 2011 11:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.332 X-Spam-Level: X-Spam-Status: No, score=-103.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiZxnRStKCqi for ; Fri, 1 Jul 2011 11:15:33 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0A71F0CBB for ; Fri, 1 Jul 2011 11:14:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFINDk6HCzI1/2dsb2JhbABEDqgBd64XApsbgx+DEwSXRYs6 X-IronPort-AV: E=Sophos;i="4.65,460,1304308800"; d="scan'208";a="254474448" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Jul 2011 14:14:23 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Jul 2011 14:07:44 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 1 Jul 2011 14:14:22 -0400 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" , "gunnar.hellstrom@omnitor.se" , "arnoud@realtimetext.org" Date: Fri, 1 Jul 2011 14:12:55 -0400 Thread-Topic: Questions about draft-hellstrom-text-conference-04 Thread-Index: AQHMOBp/1nMJQofaCUmUdI2XS3Ucwg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Questions about draft-hellstrom-text-conference-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 18:15:38 -0000 Following are some questions I have about draft-hellstrom-text-conference-04, "Text media handling in RTP based real-time conferences". I am not on the appropriate working group mailing list, so some of these questions may already have been discussed and solved. Also, I don't know the proper forum for this draft, so I am sending this to Dispatch (where the original e-mail was sent) and to the authors of the draft. The draft is a useful specification to how to do text mixing. 1. Negotiation The draft is mostly a set of standards or best practices for mixing text media. There seem to be three modes for generating the mixing output, identified via the "rtp-mixer", "t140-mixer", and "text-mixer" values of the "rtt-mixer" media tag. BTW, the values "rtp-mix" and "rtp-mixer" are both used in the draft. I suspect the first is a mistake. It appears that the rtp-mixer system is described in sections 3, 4, and 5; the t140-mixer system is described in section 6; and the text-mixer system is described (very minimally) in section 7. As the negotiation of these capabilities is very important for successful interoperation, I suggest that at the start of the draft there be an outline of the three different methods and an explicit description of how the text mixing mode is negotiated between the UA and the mixer (including the various compatibility considerations). 2. Use of CSRC In concept, the rtp-mixer technique is a method of multiplexing several T.140 streams, with the intention that the receiving UA will de-multiplex them, and then display the set of streams in the way the user desires. Each T.140 stream is identified by the (one) CSRC value in the RTP packets that carry its content. The draft states (section 2.1): The source of the primary text in each RTP packet is identified by the CSRC parameter, containing the SSRC of the initial source of text. I may be misreading this sentence, but it appears to specify that the CSRC of a T.140 stream that is sent by the mixer should be the SSRC of the RTP stream that brought the content to the mixer. However, I think that a better specification would be: The source of the primary text in each RTP packet is identified by the CSRC parameter, containing the CSRC of the source of text, or if that is not available, the SSRC of the source of text. With the latter specification, if a mixer receives a multiplexed T.140 RTP stream, it will carry the associated CSRCs from the input stream into the output streams. Consider the following configuration (which is fairly common in audio mixing): User 1 User 3 \ / \ / Mixer 1----------------Mixer 2 / \ / \ User 2 User 4 The RTP from Mixer 1 to Mixer 2 would carry the SSRCs of User 1 and User 2 as CSRC values, and Mixer 2 would copy those values into the RTP to User 3 and User 4. That would allow User 4 to see the text from all of the other users identified properly. 3. Redundancy BTW, although the text describes the use of RFC 2198 redundancy, that RFC is not mentioned in the references. The use of RFC 2198 redundancy in text conferencing seems to require excessive numbers of packets when more than one user is typing simultaneously. The governing text seems to be: The mixer MUST NOT transmit redundant levels of text from one source together with primary text from another source. Thus, when there is text available for primary or redundant transmission from more than one source, the mixer MUST buffer text from other sources until all the redundant transmissions of a packet from one selected source has been transmitted. Thus, if user A transmits text fragments A1, A2, etc. and user B transmits text fragments B1, B2, etc., and these transmissions are interleaved in time, the mixer is required to transmit the following RTP packets (for two-fold redundancy): CSRC A: empty/A1 CSRC A: A1/empty CSRC B: empty/B1 CSRC B: B1/empty CSRC A: empty/A2 CSRC A: A2/empty CSRC B: empty/B2 CSRC B: B2/empty CSRC A: empty/A3 CSRC A: A3/empty CSRC B: empty/B3 CSRC B: B3/empty (Within each RTP packet, I list the contained t140 sub-payloads in forward time order, as they would be placed in the packet. Thus, the most recent payload is last.) This requires doubling the number of RTP packets sent, whereas in an ordinary redundant-t140 environment, the number of RTP packets sent would be about the same as without redundancy (though the total payload size would still double). This scheme also sends each redundant packet closely in time to its primary packet, which increases the chance that both packets will be lost (since packet losses are correlated for packets that are close in time). Note that this situation, multiple users typing simultaneously, is expected to be common in RTT mixing. (It is already common in the Unix 'talk' tool.) It seems to me that the problem is that we assume that the RFC 2198 redundancy decoding will be done *before* the t140-stream demultiplexing, which causes problems because RFC 2198 redundancy does not carry CSRC values separately for each sub-payload. A better alternative would be to do the redundancy decoding *after* the t140-stream demultiplexing, which allows each substream of packets (which is from a single source, with a single CSRC value) to be *separately* redundant. The parallel example would be: CSRC A: empty/empty/A1 CSRC B: empty/empty/B1 CSRC A: empty/A1/A2 CSRC B: empty/B1/B2 CSRC A: [A1]/A2/A3 CSRC B: [B1]/B2/B3 CSRC A: [A2]/A3/empty CSRC B: [B2]/B3/empty (The use of three-fold redundancy here and the "[...]" sub-payloads are described below.) In this scheme, text arriving from one user would not force "idle" packets (with empty final sub-payload) to be sent for another user. Even in this short example, the packet count is reduced by 33%. Each sub-stream can be decoded for redundancy as if it was a separate RFC 2198 RTP stream, with one large exception: The sub-stream does not have consecutive RTP sequence numbers, and so missing sequence numbers can not be used to determine if there are missing payloads that cannot be reconstructed. (The display of t140 text requires identifying gaps in the received text stream to the user.) As an alternative to using sequence numbers, we can use the RTP timestamps, as each sub-payload does carry its own timestamp (as an offset from the RTP packet's timestamp). Thus, we can identify and eliminate duplicate sub-payloads from different packets by comparing timestamps. However, the only way to detect that no sub-payload is missing is if the timestamps from one packet overlap the timestamps from a previous packet. That is, if one packet contains T1, T2, T3, and another packet contains T3, T4, T5, then we know that the sequence of sub-payloads with timestamps T1, T2, T3, T4, T5 has no gaps. But if one packet contains T1, T2, T3, and another contains T4, T5, T6, the receiver has no way of knowing if there is a T3B between T3 and T4. Thus, for this scheme to have the same reliability as RFC 2198 applied to a single t140 stream, this scheme needs *one more* sub-payload per packet. Thus, the example above uses three-fold redundancy, whereas the first example used only two-fold redundancy. But since the oldest sub-payload is needed only for its timestamp (since it is expected to overlap with a previous packet, the sub-payload contents are already known), we can omit the sub-payload bytes themselves. This is the meaning of "[A1]", etc. in the example: The sub-payload carries A1's timestamp, but the payload bytes are omitted (and the block length is 0). The net extra overhead is 4 bytes per RTT packet, which is no greater than if RFC 2198 redundancy was reorganized so that each sub-payload had its own CSRC field. It could be objected that this approach violates the concept that RFC 2198 redundancy processed independently of the sub-payload carried within it, but the draft is already violating that concept by placing restrictions on how redundancy is applied. And even within RFC 2198, which envisions redundant audio sub-payloads to be lower-bit-rate versions of the primary audio sub-payloads, encoding and decoding the redundancy would not be done independently of processing the sub-payloads. 4. Graphic rendition The mechanism used by T.140/RFC 4103 to control graphic rendition is *stateful*, in that there is always a current rendition mode, which is changed by sending/receiving an SGR escape sequence. Given the possibility that characters in the T.140 stream may occasionally be lost, the graphic rendition mode at the receiver can become desynchronized from the graphic rendition mode at the sender. For example, if some text is emphasized by first sending CSI 1;5;31 m (bold, blink, red), but the CSI 0 m (all attributes off) that follows is lost, the remainder of the conversation may be painful to behold. In order to allow for this, it would be useful to recommend that the sender periodically insert an SGR for "all attributes off", followed by an SGR to reestablish the graphic rendition mode that it thinks is in effect. (The second SGR can be omitted in the common case that the current mode is "all attributes off".) It seems that the natural place to insert these SGRs is at "the beginnings of lines", that is, before the first character after a new line indicator (x2028 or x0D/x0A). Dale From eckelcu@cisco.com Fri Jul 1 17:51:41 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD7611E80F7 for ; Fri, 1 Jul 2011 17:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+EKU3R9oL0I for ; Fri, 1 Jul 2011 17:51:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id BA56411E80D0 for ; Fri, 1 Jul 2011 17:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2230; q=dns/txt; s=iport; t=1309567884; x=1310777484; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=sEzybie4HEdQ4JaC9sfdFQY4d99NivNlQ1Asrc1i/JU=; b=VwdoP6cCd+2sftktWFgfDXaoNx3cgCubXF7akxpkQeUhfzsbiPQvhGdN AiriUtGzbiPIngXskwNjKOGarjeLIYT6Xpf3O6f/pJdeMP5LiJjxPV7SK b7nD/p7+W+7w6b0H25nJ+KW+qhj630MpRjctP2RpV8GWnIUdOtbXU7PHD o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYBAFBrDk6rRDoH/2dsb2JhbABShEKUCkKNfHd3q2uBIo0UkEiBK4N7gQwEhz6Pc4tS X-IronPort-AV: E=Sophos;i="4.65,461,1304294400"; d="scan'208";a="473789591" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2011 00:51:24 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p620pOj1031469 for ; Sat, 2 Jul 2011 00:51:24 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 17:51:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 1 Jul 2011 17:51:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-sandbakken-dispatch-bfcp-udp-02.txt Thread-Index: Acw4UEucaXCqnSseSD6/OuWTrcQ+pAAAIQ0w From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 02 Jul 2011 00:51:24.0238 (UTC) FILETIME=[2ABC9EE0:01CC3852] Subject: [dispatch] FW: New Version Notification for draft-sandbakken-dispatch-bfcp-udp-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 00:51:41 -0000 SGVyZSBpcyBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhlIEJGQ1Agb3ZlciBVbnJlbGlhYmxlIFRy YW5zcG9ydCBkcmFmdC4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhbmRiYWtr ZW4tZGlzcGF0Y2gtYmZjcC11ZHAtMDINCg0KVGhlIGRyYWZ0IGhhcyBiZWVuIGNoYW5nZWQgZnJv bSBzdGFuZGFyZHMgdHJhY2sgdG8gaW5mb3JtYXRpb25hbCwgYW5kIGFuIGF0dGVtcHQgaGFzIGJl ZW4gbWFkZSB0byBhZGRyZXNzIHRoZSBjb25jZXJucyByYWlzZWQgcHJldmlvdXNseS4gTWlub3Ig dGVjaG5pY2FsIGNoYW5nZXMgdG8gdGhlIHByb3RvY29sIGhhdmUgYmVlbiBtYWRlIGFzIHdlbGwu DQpZb3VyIHJldmlldyBvZiB0aGUgZHJhZnQgd291bGQgYmUgZ3JlYXRseSBhcHByZWNpYXRlZCwg YW5kIHlvdXIgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNClRoYW5rcywNCkNoYXJsZXMNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIEp1bHkgMDEs IDIwMTEgNTozNiBQTQ0KVG86IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQpDYzogR2VpciBTYW5k YmFra2VuIChnZWlyc2FuZCk7IEVvaW4gTWNMZW9kIChlb2ltY2xlbyk7IENoYXJsZXMgRWNrZWwg KGVja2VsY3UpOyBNYXJrIFRob21wc29uIChtYXJrdGgyKTsgVG9tIEtyaXN0ZW5zZW4gKHRvbWty aXN0KQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zYW5kYmFr a2VuLWRpc3BhdGNoLWJmY3AtdWRwLTAyLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtc2FuZGJha2tlbi1kaXNwYXRjaC1iZmNwLXVkcC0wMi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBDaGFybGVzIEVja2VsIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1zYW5kYmFra2VuLWRpc3BhdGNoLWJmY3AtdWRw DQpSZXZpc2lvbjoJIDAyDQpUaXRsZToJCSBSZXZpc2lvbiBvZiB0aGUgQmluYXJ5IEZsb29yIENv bnRyb2wgUHJvdG9jb2wgKEJGQ1ApIGZvciB1c2Ugb3ZlciBhbiB1bnJlbGlhYmxlIHRyYW5zcG9y dA0KQ3JlYXRpb24gZGF0ZToJIDIwMTEtMDctMDINCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAzMw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgZGVz Y3JpYmVzIGhvdyB0byBleHRlbmQgdGhlIEJpbmFyeSBGbG9vciBDb250cm9sIFByb3RvY29sDQog ICAoQkZDUCkgZm9yIHVzZSBvdmVyIGFuIHVucmVsaWFibGUgdHJhbnNwb3J0LiAgSXQgZGV0YWls cyB0aGUNCiAgIGRpZmZlcmVuY2VzIGZyb20gdGhlIEJGQ1AgcHJvdG9jb2wgZGVmaW5pdGlvbiBk b2N1bWVudCBhbmQgdGhlDQogICBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIGZv cm1hdCBzcGVjaWZpZWQgZm9yIEJGQ1Agc3RyZWFtcy4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From gunnar.hellstrom@omnitor.se Sun Jul 3 11:32:24 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C22211E8088 for ; Sun, 3 Jul 2011 11:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dIv6bRaNHFw for ; Sun, 3 Jul 2011 11:32:23 -0700 (PDT) Received: from vsp-outgoing2.binero.net (vsp-outgoing2.binero.net [193.17.218.161]) by ietfa.amsl.com (Postfix) with SMTP id 2665C11E807E for ; Sun, 3 Jul 2011 11:32:18 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing2.binero.net (Halon Mail Gateway) with ESMTP for ; Sun, 3 Jul 2011 20:32:09 +0200 (CEST) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id EC8423A009; Sun, 3 Jul 2011 20:32:07 +0200 (CEST) Message-ID: <4E10B5A8.6050309@omnitor.se> Date: Sun, 03 Jul 2011 20:32:08 +0200 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" , "dispatch@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "arnoud@realtimetext.org" Subject: Re: [dispatch] Questions about draft-hellstrom-text-conference-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 18:32:24 -0000 Dale, You are placing good questions on the multi-party real-time text draft. And since we have not got it placed in any specific working group, it seems appropriate to have the discussion in Dispatch. I think it relates either to some of the avi groups or xcon. Users of it would possibly include ecrit and clue. I want to start with a short recognition of your observation, and expand into proper answers later. 1. Negotiation. You are right that three possible mixer methods are described. One case of "rtp-mixer" was also by mistake shortened to "rtp-mix". I agree that it is good to have an initial section on this and the capability negotiation. The specification you find very thin is that one for conference-unaware clients. It is documented at http://www.realtimetext.org/index.php?pagina=62 Please help us to judge if this description of what to do with multiparty real-time text calls when the client does not understand the multi-party features. Should it be included in the IETF draft, or kept separate? 2. CSRC usage. Yes, it is a good idea to let the focus separate contents per contributor, even if the sessions come mixed to the focus. And doing it by the extra rules for CSRC usage seem good. 3. Redundancy. Yes, I have realized that the restriction to not merge different sources to contents in primary and secondary text in the same packets as described easily creates long waiting before transmission of a specific text item. That is not favourable. We should find a way to circumvent that limitation. Your proposal to analyze the time stamps is one interesting initial way. Having a more specialized redundancy format providing more info per text item could also be considered. RFC 4351 transmits real-time text and has a special added sequence number field in the redundancy information. Such solutions but specifying the source could be created for the central rtp-based method if so decided. 4. Graphic rendition. You are right that the graphic rendition is stateful information, and loss can mess up the presentation. A requirement to iterate the commands for rendition after each Line Separator is a good idea. Also read the spec in realtimetext.org for more hints. Something like this should be brought into the spec. A question is if the three alternative methods are too many. Maybe the rtp-mixer method should be deleted and only the t140-mixer used for multi-party-aware clients???? Thanks, Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 Worley, Dale R (Dale) skrev 2011-07-01 20:12: > Following are some questions I have about > draft-hellstrom-text-conference-04, "Text media handling in RTP based > real-time conferences". I am not on the appropriate working group > mailing list, so some of these questions may already have been > discussed and solved. Also, I don't know the proper forum for this > draft, so I am sending this to Dispatch (where the original e-mail was > sent) and to the authors of the draft. > > The draft is a useful specification to how to do text mixing. > > 1. Negotiation > > The draft is mostly a set of standards or best practices for mixing > text media. There seem to be three modes for generating the mixing > output, identified via the "rtp-mixer", "t140-mixer", and "text-mixer" > values of the "rtt-mixer" media tag. > > BTW, the values "rtp-mix" and "rtp-mixer" are both used in the draft. > I suspect the first is a mistake. > > It appears that the rtp-mixer system is described in sections 3, 4, > and 5; the t140-mixer system is described in section 6; and the > text-mixer system is described (very minimally) in section 7. > > As the negotiation of these capabilities is very important for > successful interoperation, I suggest that at the start of the draft > there be an outline of the three different methods and an explicit > description of how the text mixing mode is negotiated between the UA > and the mixer (including the various compatibility considerations). > > 2. Use of CSRC > > In concept, the rtp-mixer technique is a method of multiplexing > several T.140 streams, with the intention that the receiving UA will > de-multiplex them, and then display the set of streams in the way the > user desires. Each T.140 stream is identified by the (one) CSRC value > in the RTP packets that carry its content. > > The draft states (section 2.1): > > The source of the primary text in each RTP packet is > identified by the CSRC parameter, containing the SSRC of the initial > source of text. > > I may be misreading this sentence, but it appears to specify that the > CSRC of a T.140 stream that is sent by the mixer should be the SSRC of > the RTP stream that brought the content to the mixer. > > However, I think that a better specification would be: > > The source of the primary text in each RTP packet is identified by > the CSRC parameter, containing the CSRC of the source of text, or > if that is not available, the SSRC of the source of text. > > With the latter specification, if a mixer receives a multiplexed T.140 > RTP stream, it will carry the associated CSRCs from the input stream > into the output streams. > > Consider the following configuration (which is fairly common in audio > mixing): > > User 1 User 3 > \ / > \ / > Mixer 1----------------Mixer 2 > / \ > / \ > User 2 User 4 > > The RTP from Mixer 1 to Mixer 2 would carry the SSRCs of User 1 and > User 2 as CSRC values, and Mixer 2 would copy those values into the > RTP to User 3 and User 4. That would allow User 4 to see the text > from all of the other users identified properly. > > 3. Redundancy > > BTW, although the text describes the use of RFC 2198 redundancy, that > RFC is not mentioned in the references. > > The use of RFC 2198 redundancy in text conferencing seems to require > excessive numbers of packets when more than one user is typing > simultaneously. > > The governing text seems to be: > > The mixer MUST NOT transmit redundant levels of text from one source > together with primary text from another source. Thus, when there is > text available for primary or redundant transmission from more than > one source, the mixer MUST buffer text from other sources until all > the redundant transmissions of a packet from one selected source has > been transmitted. > > Thus, if user A transmits text fragments A1, A2, etc. and user B > transmits text fragments B1, B2, etc., and these transmissions are > interleaved in time, the mixer is required to transmit the following > RTP packets (for two-fold redundancy): > > CSRC A: empty/A1 > CSRC A: A1/empty > CSRC B: empty/B1 > CSRC B: B1/empty > CSRC A: empty/A2 > CSRC A: A2/empty > CSRC B: empty/B2 > CSRC B: B2/empty > CSRC A: empty/A3 > CSRC A: A3/empty > CSRC B: empty/B3 > CSRC B: B3/empty > > (Within each RTP packet, I list the contained t140 sub-payloads in > forward time order, as they would be placed in the packet. Thus, the > most recent payload is last.) > > This requires doubling the number of RTP packets sent, whereas in an > ordinary redundant-t140 environment, the number of RTP packets sent > would be about the same as without redundancy (though the total > payload size would still double). This scheme also sends each > redundant packet closely in time to its primary packet, which > increases the chance that both packets will be lost (since packet > losses are correlated for packets that are close in time). > > Note that this situation, multiple users typing simultaneously, is > expected to be common in RTT mixing. (It is already common in the > Unix 'talk' tool.) > > It seems to me that the problem is that we assume that the RFC 2198 > redundancy decoding will be done *before* the t140-stream > demultiplexing, which causes problems because RFC 2198 redundancy does > not carry CSRC values separately for each sub-payload. > > A better alternative would be to do the redundancy decoding *after* > the t140-stream demultiplexing, which allows each substream of packets > (which is from a single source, with a single CSRC value) to be > *separately* redundant. The parallel example would be: > > CSRC A: empty/empty/A1 > CSRC B: empty/empty/B1 > CSRC A: empty/A1/A2 > CSRC B: empty/B1/B2 > CSRC A: [A1]/A2/A3 > CSRC B: [B1]/B2/B3 > CSRC A: [A2]/A3/empty > CSRC B: [B2]/B3/empty > > (The use of three-fold redundancy here and the "[...]" sub-payloads > are described below.) > > In this scheme, text arriving from one user would not force "idle" > packets (with empty final sub-payload) to be sent for another user. > Even in this short example, the packet count is reduced by 33%. > > Each sub-stream can be decoded for redundancy as if it was a separate > RFC 2198 RTP stream, with one large exception: The sub-stream does > not have consecutive RTP sequence numbers, and so missing sequence > numbers can not be used to determine if there are missing payloads > that cannot be reconstructed. (The display of t140 text requires > identifying gaps in the received text stream to the user.) > > As an alternative to using sequence numbers, we can use the RTP > timestamps, as each sub-payload does carry its own timestamp (as an > offset from the RTP packet's timestamp). Thus, we can identify and > eliminate duplicate sub-payloads from different packets by comparing > timestamps. > > However, the only way to detect that no sub-payload is missing is if > the timestamps from one packet overlap the timestamps from a previous > packet. That is, if one packet contains T1, T2, T3, and another > packet contains T3, T4, T5, then we know that the sequence of > sub-payloads with timestamps T1, T2, T3, T4, T5 has no gaps. But if > one packet contains T1, T2, T3, and another contains T4, T5, T6, the > receiver has no way of knowing if there is a T3B between T3 and T4. > > Thus, for this scheme to have the same reliability as RFC 2198 applied > to a single t140 stream, this scheme needs *one more* sub-payload per > packet. Thus, the example above uses three-fold redundancy, whereas > the first example used only two-fold redundancy. > > But since the oldest sub-payload is needed only for its timestamp > (since it is expected to overlap with a previous packet, the > sub-payload contents are already known), we can omit the sub-payload > bytes themselves. This is the meaning of "[A1]", etc. in the example: > The sub-payload carries A1's timestamp, but the payload bytes are > omitted (and the block length is 0). > > The net extra overhead is 4 bytes per RTT packet, which is no greater > than if RFC 2198 redundancy was reorganized so that each sub-payload > had its own CSRC field. > > It could be objected that this approach violates the concept that RFC > 2198 redundancy processed independently of the sub-payload carried > within it, but the draft is already violating that concept by placing > restrictions on how redundancy is applied. And even within RFC 2198, > which envisions redundant audio sub-payloads to be lower-bit-rate > versions of the primary audio sub-payloads, encoding and decoding the > redundancy would not be done independently of processing the > sub-payloads. > > 4. Graphic rendition > > The mechanism used by T.140/RFC 4103 to control graphic rendition is > *stateful*, in that there is always a current rendition mode, which is > changed by sending/receiving an SGR escape sequence. Given the > possibility that characters in the T.140 stream may occasionally be > lost, the graphic rendition mode at the receiver can become > desynchronized from the graphic rendition mode at the sender. > > For example, if some text is emphasized by first sending CSI 1;5;31 m > (bold, blink, red), but the CSI 0 m (all attributes off) that follows > is lost, the remainder of the conversation may be painful to behold. > > In order to allow for this, it would be useful to recommend that the > sender periodically insert an SGR for "all attributes off", followed > by an SGR to reestablish the graphic rendition mode that it thinks is > in effect. (The second SGR can be omitted in the common case that the > current mode is "all attributes off".) > > It seems that the natural place to insert these SGRs is at "the > beginnings of lines", that is, before the first character after a new > line indicator (x2028 or x0D/x0A). > > Dale From dworley@avaya.com Tue Jul 5 10:56:49 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C983F21F891B for ; Tue, 5 Jul 2011 10:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.326 X-Spam-Level: X-Spam-Status: No, score=-103.326 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlnyNZ5py7sk for ; Tue, 5 Jul 2011 10:56:48 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id C40C321F891A for ; Tue, 5 Jul 2011 10:56:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFhPE07GmAcF/2dsb2JhbAAoK6gJd4h6JaZsApshhjYEl0uLPU0 X-IronPort-AV: E=Sophos;i="4.65,480,1304308800"; d="scan'208";a="288873806" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Jul 2011 13:56:47 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Jul 2011 13:55:38 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 5 Jul 2011 13:56:46 -0400 From: "Worley, Dale R (Dale)" To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "dispatch@ietf.org" Date: Tue, 5 Jul 2011 13:56:46 -0400 Thread-Topic: Questions about draft-hellstrom-text-conference-04 Thread-Index: Acw5r5Yl3XWeIBstRRSDzk4LUt3mZgBijdwP Message-ID: References: , <4E10B5A8.6050309@omnitor.se> In-Reply-To: <4E10B5A8.6050309@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "arnoud@realtimetext.org" Subject: Re: [dispatch] Questions about draft-hellstrom-text-conference-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 17:56:49 -0000 > From: Gunnar Hellstr=F6m [gunnar.hellstrom@omnitor.se] >=20 > The specification you find very thin is that one for conference-unaware > clients. > It is documented at http://www.realtimetext.org/index.php?pagina=3D62 >=20 > Please help us to judge if this description of what to do with > multiparty real-time text calls when the client does not understand the > multi-party features. Should it be included in the IETF draft, or kept > separate? It's probably not important to include it in the Internet Draft, but I see no reference from the I-D to multiparty-real-time-text-mixer-2011-03-06.pdf. > 3. Redundancy. > Yes, I have realized that the restriction to not merge different sources > to contents in primary and secondary text in the same packets as > described easily creates long waiting before transmission of a specific > text item. That is not favourable. >=20 > We should find a way to circumvent that limitation. Your proposal to > analyze the time stamps is one interesting initial way. >=20 > Having a more specialized redundancy format providing more info per text > item could also be considered. > RFC 4351 transmits real-time text and has a special added sequence > number field in the redundancy information. Such solutions but > specifying the source could be created for the central rtp-based method > if so decided. I have just skimmed that RFC. It appears that the core of the idea is to define a new "t140c" format, which includes a 16-bit "sequence number" in the payload, along with the T.140 character octets. That would be a cleaner way to deal with the redundancy problems, assuming that each sub-stream of t140c blocks (identified by CSRC) has its own sqeuence numbers. > 4. Graphic rendition. > You are right that the graphic rendition is stateful information, and > loss can mess up the presentation. There is one aspect of "SGR" that may not have been incorporated into multiparty-real-time-text-mixer-2011-03-06.pdf: SGR codes are *cumulative*, that is, the graphic rendition state consists of multiple components, and an SGR code modifies only one or a few of those components, leaving the others unchanged. You can see evidence of this in the structure of the SGR codes. (See http://en.wikipedia.org/wiki/ANSI_escape_sequences#graphics.) There are SGR codes to turn on special characteristics (blink, underline, color, etc.) and corresponding codes to turn off each characteristic. However, looking at ECMA 48 standard (http://www.ecma-international.org/publications/standards/Ecma-048.htm), I see that there is a "Set Mode" escape sequence which can control the "Graphic Rendition Combination Mode". If GRCM is off, each SGR clears the effect of any previous SGR before applying its own effect. If GRCM is on, each SGR is cumulative with previous SGRs. (Excepting SGR "0", of course, which clears all special rendition modes.) It appears that T.140, multiparty-real-time-text-mixer-2011-03-06.pdf, and draft-hellstrom-text-conference-04 do not consider how to handle the Graphic Rendition Combination Mode. It appears that none of these standards support Set Mode and Clear Mode, but they do not specify whether GRCM is set or clear relative to interpreting SGR. My memory is that computer terminals generally used to assume GRCM is set, but I may be wrong about that. This needs to be clarified in a consistent way. I suspect that "GRCM clear" would be the easiest mode to implement, as an element that manipulated text streams (e.g., a mixer) could simply remember the last SGR rather than having to accumulate and combine the SGRs. Dale From partr@cisco.com Wed Jul 6 11:10:57 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1127F21F889D for ; Wed, 6 Jul 2011 11:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27xceQrjBIY8 for ; Wed, 6 Jul 2011 11:10:55 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6683821F872D for ; Wed, 6 Jul 2011 11:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=11319; q=dns/txt; s=iport; t=1309975854; x=1311185454; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DWNMZ57vKjjmkwLMoIcnrk4Ud00CjJpl/sDMFrhzyZQ=; b=BEbhIdXKuJAwTF/gjUVyoidY7xmnWTzFKZ86BAaIgJ9q45/9bPeB8ftK pquAkGa299K+ndML3OuoNcAV4wT8PDdIKkT4Nkyvp/wdYJPSKEvZMKLDX Wjv2xUOrs17f4gKsBJCntNmW4rbAQZEB3D5AXnHf+HpRDx3VCIDayy6Le c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAOijFE5Io8UT/2dsb2JhbABTmFqPLneIeqU7ng+DNIMDBIdEkACLQg X-IronPort-AV: E=Sophos;i="4.65,488,1304294400"; d="scan'208";a="40894821" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 06 Jul 2011 18:10:51 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p66I9ufL021159; Wed, 6 Jul 2011 18:10:50 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 23:40:35 +0530 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: Wed, 6 Jul 2011 23:40:32 +0530 Message-ID: In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102F5E3CE@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP Load balancing (SIPLB) Charter proposal Thread-Index: AcwlI7mmed+XiSHkQYGxFFc59kn/+QABrDoAADxf01AAIw4MoAADqpCwAAUcWcAAG/XmIAAJujqQAMLBBiAEXo/VgA== References: <9ECCF01B52E7AB408A7EB8535264214102E4435E@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102EE636C@ftrdmel0.rd.francetelecom.fr><4DEE3D38.3080106@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102F28BC2@ftrdmel0.rd.francetelecom.fr> <14C85D6CCBE92743AF33663BF5D24EBA0A43F39F@gaalpa1msgusr7e.ugd.att.com><9ECCF01B52E7AB408A7EB8535264214102F297ED@ftrdmel0.rd.francetelecom.fr> <006d01cc26b7$1140ecc0$33c2c640$@us> <9ECCF01B52E7AB408A7EB8535264214102F29ABE@ftrdmel0.rd.francetelecom.fr> <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FF0@gaalpa1msgusr7e.ugd.att.com> <9ECCF01B52E7AB408A7EB8535264214102F5E3CE@ftrdmel0.rd.francetelecom.fr> From: "Parthasarathi R (partr)" To: , , , X-OriginalArrivalTime: 06 Jul 2011 18:10:35.0016 (UTC) FILETIME=[00595080:01CC3C08] Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 18:10:57 -0000 Bruno, Sorry for the delay reply. Please read inline. Thanks Partha=20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com]=20 > Sent: Tuesday, June 14, 2011 2:43 PM > To: md3135@att.com; Parthasarathi R (partr);=20 > richard@shockey.us; vkg@bell-labs.com > Cc: dispatch@ietf.org > Subject: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal >=20 > I agree it should be an option not THE only solution. I just=20 > want to make sure that this option is not ruled out of the=20 > scope of the WG. >=20 > Actually the "DNS approach" does not over complicate the DNS.=20 > It just makes use of DNS UPDATE (RFC2136). The "complexity",=20 > if any, is not on the DNS itself but rather on=20 >=20 > i) The logical entity that collects load information from the=20 > servers and updates the DNS using RFC2136. This logical=20 > entity can be co-located with the servers=20 In case DNS server & SIP entity are co-located, then it is just = protocol choice and no architecture/performance impact or implemented as a=20 > standalone off path node that uses e.g. SNMP to collect (or=20 > be notified of) load information Here, the assumption is that load balancing report update delay = is less but the algorithm efficiency will not while nearing overload = scenario in some of the downstream entity. IMO, the best load balancer = has to work well when some portion of the downstream entity is = overloaded as well. The advantage with information in co-located = solution is that the updation happens instantaneously. >=20 > ii) The clients that make load balancing decisions based on=20 > priority and weight fields found in DNS records I'm not DNS expert but this proposed mechanism may have other = side-effect with DNS enhancement like DNS caching based on TTL. DNS = caching is the most common behavior in DNS client implementation whereas = here the caching should not be enabled. >=20 > Bruno >=20 > > -----Message d'origine----- > > De=A0: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com] Envoy=E9=A0 > : vendredi=20 > > 10 juin 2011 13:35 =C0=A0: CHATRAS Bruno RD-CORE-ISS; = partr@cisco.com;=20 > > richard@shockey.us; vkg@bell-labs.com Cc=A0:=20 > dispatch@ietf.org Objet=A0:=20 > > RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal > >=20 > > AT&T supports the approach in the current draft, and would view the=20 > > "DNS approach" as an option. > > Let DNS do what it does well, and donot over complicate it. > >=20 > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-=20 > > ftgroup.com] > > Sent: Friday, June 10, 2011 3:03 AM > > To: partr@cisco.com; richard@shockey.us; DOLLY, MARTIN C (ATTSI);=20 > > vkg@bell-labs.com > > Cc: dispatch@ietf.org > > Subject: RE: [dispatch] SIP Load balancing (SIPLB) Charter proposal > >=20 > > I think it's more than just a protocol issue. There are=20 > architectural=20 > > aspects here as well (in-path vs. out-path load balancer). I think=20 > > both approaches should be covered. > >=20 > > In-path: All SIP traffic goes through the load balancer, which is=20 > > itself a SIP entity > >=20 > > Out-Path: SIP entities balance the load themselves, based on=20 > > information received from a load balancer (DNS, 3GPP LDF or=20 > something > > else) > >=20 > > Bruno > >=20 > > > -----Message d'origine----- > > > De=A0: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Envoy=E9=A0: jeudi=20 > > > 9 juin 2011 19:45 =C0=A0: Richard Shockey; CHATRAS Bruno = RD-CORE-ISS;=20 > > > md3135@att.com; vkg@bell-labs.com Cc=A0: dispatch@ietf.org=20 > Objet=A0: RE:=20 > > > [dispatch] SIP Load balancing (SIPLB) Charter proposal > > > > > > Bruno, > > > > > > Thanks for your information about DNS based SIP load balancing in > > 3GPP > > > spec (in different mail thread). > > > > > > IMO, There are two parts in feedback based SIP load balancing > > > > > > 1) Feedback value > > > 2) Feedback protocol choice (SIP, DNS, SNMP) > > > > > > The current mail thread is about feedback protocol which has to be > > used. > > > I agree with you that it is possible for other protocols for SIP=20 > > > load balancing. We will add the consideration and discuss=20 > in detail=20 > > > about protocol choice to sort out the discussion. > > > > > > > > > I really didn't see the usage of DNS based load balancing=20 > mechanism > > in > > > Enterprise deployment. But initially, I have explored to=20 > use SNMP to=20 > > > pass feedback value as a trap and I got the comments that=20 > SIP based=20 > > > feedback mechanism will reduce the dependency on another protocol > > stack > > > in the system. I guess that the comment will apply for DNS as well > > and > > > also FQDN in SIP URI is not mandatory in SIP. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org]=20 > > > On Behalf Of Richard Shockey > > > Sent: Thursday, June 09, 2011 8:38 PM > > > To: bruno.chatras@orange-ftgroup.com; md3135@att.com; vkg@bell- > > labs.com > > > Cc: dispatch@ietf.org > > > Subject: Re: [dispatch] SIP Load balancing (SIPLB)=20 > Charter proposal > > > > > > > > > Humm .. an application specific use of DNS technology in a closed=20 > > > controlled environment. I heard of these kind of things before. > > > Sounds like a interesting idea. :-) > > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org]=20 > > > On Behalf Of bruno.chatras@orange-ftgroup.com > > > Sent: Thursday, June 09, 2011 9:28 AM > > > To: md3135@att.com; vkg@bell-labs.com > > > Cc: dispatch@ietf.org > > > Subject: Re: [dispatch] SIP Load balancing (SIPLB)=20 > Charter proposal > > > > > > Hi Martin, > > > The load balancing capability can be implemented on dedicated DNS=20 > > > servers only. This does not put the service provider's DNS=20 > > > infrastructure at risk. > > > Bruno > > > > > > > > > > -----Message d'origine----- > > > > De=A0: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com] = Envoy=E9=A0: > > > mercredi > > > > 8 juin 2011 22:39 =C0=A0: CHATRAS Bruno RD-CORE-ISS;=20 > vkg@bell-labs.com > > > Cc > > > > : dispatch@ietf.org Objet=A0: RE: [dispatch] SIP Load balancing > > (SIPLB) > > > > Charter proposal > > > > > > > > Bruno, > > > > > > > > Do we really want to impact the DNS with a load balancing > > capability > > > > linked to overload control? > > > > > > > > Martin > > > > > > > > -----Original Message----- > > > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] > > On > > > > Behalf Of bruno.chatras@orange-ftgroup.com > > > > Sent: Tuesday, June 07, 2011 11:54 AM > > > > To: vkg@bell-labs.com > > > > Cc: dispatch@ietf.org > > > > Subject: Re: [dispatch] SIP Load balancing (SIPLB) Charter=20 > > > > proposal > > > > > > > > Vijay, > > > > > > > > Speaking as a representative of a Service Provider, I=20 > can tell you=20 > > > > that we are interested in DNS-based solutions. I=20 > believe that the > > WG > > > > should address both types of solutions. > > > > > > > > Bruno > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com]=20 > Envoy=E9=A0: mardi=20 > > > > > 7 juin 2011 17:01 =C0=A0: CHATRAS Bruno RD-CORE-ISS Cc=A0: > > partr@cisco.com; > > > > > dispatch@ietf.org Objet=A0: Re: [dispatch] SIP Load balancing > > (SIPLB) > > > > > Charter proposal > > > > > > > > > > On 06/07/2011 04:13 AM,=20 > bruno.chatras@orange-ftgroup.com wrote: > > > > > bruno> Comment: In the list of considerations that=20 > must be taken=20 > > > > > bruno> into > > > > > account I > > > > > bruno> would add =AB Whether the load balancer is=20 > SIP-aware or not. > > > > > bruno> > > > > > partha> Till now, we are discussing about SIP-aware load=20 > > > > > partha> balancer > > > > only. > > > > > partha> In case the load balancer is SIP-unaware, is it=20 > > > > > partha> something > > > > like > > > > > partha> load-balance by open-loop model wherein there is no > > > feedback > > > > > required > > > > > partha> from downstream servers or load balance in=20 > the transport > > > > layer > > > > > instead > > > > > partha> of SIP layer ?. Could you please explain your > > consideration > > > > in > > > > > detail. > > > > > partha> > > > > > bruno> I was referring to a load balancer at the=20 > transport layer=20 > > > > > bruno> with feedback from downstream servers./* > > > > > > > > > > Dear Bruno: I envision a SIP-aware load balancer with=20 > feedback=20 > > > > > mechanism, where the feedback is carried in SIP signaling. > > > > > > > > > > More inline. > > > > > > > > > > bruno> Question: Is the Charter intended to cover=20 > architectures > > > with > > > > an > > > > > in-path > > > > > bruno> load balancer in front of a farm of SIP=20 > servers only or=20 > > > > > bruno> is > > > it > > > > > expected > > > > > bruno> to cover as well other architectures where the load > > balancer > > > > is > > > > > off-path > > > > > bruno> or even architectures where load balancing=20 > just relies on > > > > > frequent > > > > > bruno> updates of the DNS? > > > > > > > > > > My understanding is that service providers are loath to update > > DNS. > > > > > As such, a solution that does not depend on DNS is preferable. > > > > > This, then, means that an in-path solution that does=20 > not require > > > DNS > > > > > would be the most preferred. > > > > > > > > > > I note that the LDF function you mention from [1] is=20 > a backward=20 > > > > > feedback solution with the LDF updating the DNS periodically. > > > > > > > > > > I think that it would be good to have substantive=20 > input from the=20 > > > > > service provider community as well as the working group to > > > determine > > > > > whether a solution that does not depend on DNS being=20 > updated is=20 > > > > > preferred or not. > > > > > > > > > > Thoughts? > > > > > > > > > > [1]=20 > > > > > http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/23812- > > > > > 115.zip > > > > > > > > > > Thanks, > > > > > > > > > > - vijay > > > > > -- > > > > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent=20 > 1960 Lucent=20 > > > > > Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > > > > > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel- > > > lucent.com > > > > > Web: http://ect.bell-labs.com/who/vkg/ > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch >=20 From arnoud.vanwijk@realtimetext.org Fri Jul 8 03:50:16 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71D321F89AC for ; Fri, 8 Jul 2011 03:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRbQFUic5rGL for ; Fri, 8 Jul 2011 03:50:16 -0700 (PDT) Received: from mx-in02.nouzelle.com (mx-in02.nouzelle.com [87.119.194.141]) by ietfa.amsl.com (Postfix) with ESMTP id 81D8621F89B1 for ; Fri, 8 Jul 2011 03:50:15 -0700 (PDT) Received: from internal02.nouzelle.com (mail.local [172.29.32.13]) by mx-in02.nouzelle.com (Postfix) with ESMTP id 9864B1021420E; Fri, 8 Jul 2011 12:50:11 +0200 (CEST) Received: from mailscan.nouzelle.com (unknown [172.29.32.10]) by internal02.nouzelle.com (Postfix) with ESMTP id 44BBE10219B0B; Fri, 8 Jul 2011 12:50:11 +0200 (CEST) X-Virus-Scanned: by amavisd-new at nouzelle.com Received: from internal02.nouzelle.com ([172.29.32.13]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id ftIkg6vOMYfx; Fri, 8 Jul 2011 12:50:10 +0200 (CEST) Received: from arnoud-van-wijks-macbook-pro.local (541BD3CF.cm-5-4d.dynamic.ziggo.nl [84.27.211.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by internal02.nouzelle.com (Postfix) with ESMTPSA id CE5B010219B03; Fri, 8 Jul 2011 12:50:09 +0200 (CEST) Message-ID: <4E16E0E0.6050603@realtimetext.org> Date: Fri, 08 Jul 2011 12:50:08 +0200 From: Arnoud van Wijk Organization: R3TF User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: , <4E10B5A8.6050309@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "arnoud@realtimetext.org" , "dispatch@ietf.org" Subject: Re: [dispatch] Questions about draft-hellstrom-text-conference-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arnoud.vanwijk@realtimetext.org List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 10:50:16 -0000 Hi Dale, Thanks for the excellent feedback and we will look into these matters and address them where possible in the next draft versions. And to discuss the possible solutions. Sincerely Arnoud van Wijk On 05-07-11 19:56, Worley, Dale R (Dale) wrote: >> From: Gunnar Hellström [gunnar.hellstrom@omnitor.se] >> >> The specification you find very thin is that one for conference-unaware >> clients. >> It is documented at http://www.realtimetext.org/index.php?pagina=62 >> >> Please help us to judge if this description of what to do with >> multiparty real-time text calls when the client does not understand the >> multi-party features. Should it be included in the IETF draft, or kept >> separate? > It's probably not important to include it in the Internet Draft, but I > see no reference from the I-D to > multiparty-real-time-text-mixer-2011-03-06.pdf. > >> 3. Redundancy. >> Yes, I have realized that the restriction to not merge different sources >> to contents in primary and secondary text in the same packets as >> described easily creates long waiting before transmission of a specific >> text item. That is not favourable. >> >> We should find a way to circumvent that limitation. Your proposal to >> analyze the time stamps is one interesting initial way. >> >> Having a more specialized redundancy format providing more info per text >> item could also be considered. >> RFC 4351 transmits real-time text and has a special added sequence >> number field in the redundancy information. Such solutions but >> specifying the source could be created for the central rtp-based method >> if so decided. > I have just skimmed that RFC. It appears that the core of the idea is > to define a new "t140c" format, which includes a 16-bit "sequence > number" in the payload, along with the T.140 character octets. That > would be a cleaner way to deal with the redundancy problems, assuming > that each sub-stream of t140c blocks (identified by CSRC) has its own > sqeuence numbers. > >> 4. Graphic rendition. >> You are right that the graphic rendition is stateful information, and >> loss can mess up the presentation. > There is one aspect of "SGR" that may not have been incorporated into > multiparty-real-time-text-mixer-2011-03-06.pdf: SGR codes are > *cumulative*, that is, the graphic rendition state consists of > multiple components, and an SGR code modifies only one or a few of > those components, leaving the others unchanged. > > You can see evidence of this in the structure of the SGR codes. (See > http://en.wikipedia.org/wiki/ANSI_escape_sequences#graphics.) There > are SGR codes to turn on special characteristics (blink, underline, > color, etc.) and corresponding codes to turn off each characteristic. > > However, looking at ECMA 48 standard > (http://www.ecma-international.org/publications/standards/Ecma-048.htm), > I see that there is a "Set Mode" escape sequence which can control the > "Graphic Rendition Combination Mode". If GRCM is off, each SGR clears > the effect of any previous SGR before applying its own effect. If > GRCM is on, each SGR is cumulative with previous SGRs. (Excepting SGR > "0", of course, which clears all special rendition modes.) > > It appears that T.140, multiparty-real-time-text-mixer-2011-03-06.pdf, > and draft-hellstrom-text-conference-04 do not consider how to handle > the Graphic Rendition Combination Mode. It appears that none of these > standards support Set Mode and Clear Mode, but they do not specify > whether GRCM is set or clear relative to interpreting SGR. > > My memory is that computer terminals generally used to assume GRCM is > set, but I may be wrong about that. > > This needs to be clarified in a consistent way. I suspect that "GRCM > clear" would be the easiest mode to implement, as an element that > manipulated text streams (e.g., a mixer) could simply remember the > last SGR rather than having to accumulate and combine the SGRs. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From john.elwell@siemens-enterprise.com Fri Jul 15 07:56:39 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9423221F881C for ; Fri, 15 Jul 2011 07:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.473 X-Spam-Level: X-Spam-Status: No, score=-106.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0GgyciRWXku for ; Fri, 15 Jul 2011 07:56:39 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id A9BB021F85B5 for ; Fri, 15 Jul 2011 07:56:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1310741796!22739172!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 20777 invoked from network); 15 Jul 2011 14:56:36 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-6.tower-174.messagelabs.com with SMTP; 15 Jul 2011 14:56:36 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id D594B23F03E2 for ; Fri, 15 Jul 2011 16:56:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 15 Jul 2011 16:56:36 +0200 From: "Elwell, John" To: "dispatch@ietf.org" Date: Fri, 15 Jul 2011 16:56:34 +0200 Thread-Topic: Comments on draft-sandbakken-dispatch-bfcp-udp-02 Thread-Index: AcxC/2PMPaVHerZwTRSwqGAexam9nQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Comments on draft-sandbakken-dispatch-bfcp-udp-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 14:56:39 -0000 Just a few minor comments. Although this is still to be "dispatched", they = will need attending to in due course. 1. The Introduction dives too quickly into what the draft does. It should f= irst introduce BFCP and explain that it is designed for transport over TCP. 2. "Existing implementations, in the spirit of the approach detailed in earlier versions of this draft (see Appendix A), have demonstrated the approach to be feasible." This seems to suggest that the approach in this version is in some respects= different from the approach in earlier versions, and implies that existing= implementations do not follow the approach in this version. I don't think = that is intended, so perhaps some better words can be found. In addition, i= n the final RFC we will presumably no longer be able to refer to Appendix A= (that would be removed) and the words "earlier versions of this draft" wil= l be inappropriate. 3. In section 4.9.2: "Implicit subscriptions, such as FloorRequest messages that have multiple responses as the floor control server processes intermediate states until Granted or Denied terminal states attained, can be characterized by a client-initiated request transaction whose acknowledgement is implied by the first FloorRequestStatus response from the floor control server. The subsequent changes in state for the request are new transactions whose Transaction ID is determined by the floor control server and whose receipt by the client participant shall be acknowledged with a FloorRequestStatusAck message. [Editorial note: would it be more straightforward to have all FloorRequestStatus messages acknowledged with a FloorRequestStatusAck message?]" Would it not be better to avoid implicit responses, i.e., have an explicit = response to the client-initiated request, and an explicit response to each = FloorRequestStatus? 4. There are several instances where the word "clause" is used to refer to = text in the existing RFC. It is not always clear what is meant, e.g., I thi= nk "sentence" is sometimes the intention. John From eckelcu@cisco.com Fri Jul 15 12:25:04 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98F821F8AFC for ; Fri, 15 Jul 2011 12:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.655 X-Spam-Level: X-Spam-Status: No, score=-4.655 tagged_above=-999 required=5 tests=[AWL=-2.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdU6RP600XuE for ; Fri, 15 Jul 2011 12:25:01 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C0A3721F85B8 for ; Fri, 15 Jul 2011 12:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3076; q=dns/txt; s=iport; t=1310757901; x=1311967501; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=94ctS1CclQK/b9p/CFC/BY7LQCdLUTwPCp7gT3IJN9c=; b=Jzgjiy4j+SlnbClv83uisKPzHZjJgmdW9OUDA7+FzA89ueuxJ5wrvg3u Q/sryciBwSLVhVCY04fa46nUkvUmnobDBHpDweOb79y0Mns1oYrjkgYh9 7QLCHvCcGJzB4BFf7ewyzXc19PO0AB0EKvTWfRGVPUnHe4mQQtI0cdvEa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAJGTIE6rRDoG/2dsb2JhbABUmC2PQXeIeqNnnieFW18Eh1SQHItp X-IronPort-AV: E=Sophos;i="4.67,209,1309737600"; d="scan'208";a="3406319" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 15 Jul 2011 19:25:00 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6FJOxgT004175; Fri, 15 Jul 2011 19:24:59 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Jul 2011 12:24:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jul 2011 12:24:57 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on draft-sandbakken-dispatch-bfcp-udp-02 Thread-Index: AcxC/2PMPaVHerZwTRSwqGAexam9nQAJCsZA References: From: "Charles Eckel (eckelcu)" To: "Elwell, John" , X-OriginalArrivalTime: 15 Jul 2011 19:24:59.0749 (UTC) FILETIME=[E3414150:01CC4324] Subject: Re: [dispatch] Comments on draft-sandbakken-dispatch-bfcp-udp-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 19:25:05 -0000 Hi John, Thank you for the comments. Please see inline. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, July 15, 2011 7:57 AM > To: dispatch@ietf.org > Subject: [dispatch] Comments on draft-sandbakken-dispatch-bfcp-udp-02 >=20 > Just a few minor comments. Although this is still to be "dispatched", they will need attending to in > due course. >=20 > 1. The Introduction dives too quickly into what the draft does. It should first introduce BFCP and > explain that it is designed for transport over TCP. Good idea. I will add that. > 2. "Existing implementations, in the spirit > of the approach detailed in earlier versions of this draft (see > Appendix A), have demonstrated the approach to be feasible." > This seems to suggest that the approach in this version is in some respects different from the > approach in earlier versions, and implies that existing implementations do not follow the approach in > this version. I don't think that is intended, so perhaps some better words can be found. In addition, > in the final RFC we will presumably no longer be able to refer to Appendix A (that would be removed) > and the words "earlier versions of this draft" will be inappropriate. Good point. I will clean this up. > 3. In section 4.9.2: > "Implicit > subscriptions, such as FloorRequest messages that have multiple > responses as the floor control server processes intermediate states > until Granted or Denied terminal states attained, can be > characterized by a client-initiated request transaction whose > acknowledgement is implied by the first FloorRequestStatus response > from the floor control server. The subsequent changes in state for > the request are new transactions whose Transaction ID is determined > by the floor control server and whose receipt by the client > participant shall be acknowledged with a FloorRequestStatusAck > message. [Editorial note: would it be more straightforward to have > all FloorRequestStatus messages acknowledged with a > FloorRequestStatusAck message?]" > Would it not be better to avoid implicit responses, i.e., have an explicit response to the client- > initiated request, and an explicit response to each FloorRequestStatus? I was thinking the same thing, and led me to add the editorial note. I will take your input as a vote of explicit responses. One tradeoff will be the weight the benefit vs. backward compatibility with implementations based on previous versions of this draft. =20 > 4. There are several instances where the word "clause" is used to refer to text in the existing RFC. > It is not always clear what is meant, e.g., I think "sentence" is sometimes the intention. I will work on those. Cheers, Charles > John >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From eckelcu@cisco.com Fri Jul 15 13:37:00 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF3321F8B47 for ; Fri, 15 Jul 2011 13:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd4y93J+r-eC for ; Fri, 15 Jul 2011 13:37:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 82B5821F8B5E for ; Fri, 15 Jul 2011 13:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4623; q=dns/txt; s=iport; t=1310762197; x=1311971797; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=KOhDb+e/DddEtjItECVCG48Skya15fsds8jqJpWt4zI=; b=O/js07gNRqnoEkfD8ouvb01wvdZX8tgs/IezyLXqn4Evq4Epry+i9gs3 OliYu2f0ZEjw0wZINnEkTLBo/4xqTeyhKxQb5sW8/anDbhhQB8LZPqjvq FnSovccRpmq+hbCVWcWsoHLzCadv/BZCTc+4RZ64zAqXXlui8AcdKHn70 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAIukIE6rRDoH/2dsb2JhbABUmC2PQneIeqQ3niKFW18Eh1SQHItp X-IronPort-AV: E=Sophos;i="4.67,210,1309737600"; d="scan'208";a="3424320" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 15 Jul 2011 20:36:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6FKaTOc020386; Fri, 15 Jul 2011 20:36:32 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Jul 2011 13:36:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jul 2011 13:36:28 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Comments on draft-sandbakken-dispatch-bfcp-udp-02 Thread-Index: AcxC/2PMPaVHerZwTRSwqGAexam9nQAJCsZAAAIziHA= References: From: "Charles Eckel (eckelcu)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , X-OriginalArrivalTime: 15 Jul 2011 20:36:29.0233 (UTC) FILETIME=[DFFC9210:01CC432E] Subject: Re: [dispatch] Comments on draft-sandbakken-dispatch-bfcp-udp-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 20:37:00 -0000 One more comment inline. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Charles Eckel > (eckelcu) > Sent: Friday, July 15, 2011 12:25 PM > To: Elwell, John; dispatch@ietf.org > Subject: Re: [dispatch] Comments on draft-sandbakken-dispatch-bfcp-udp-02 >=20 > Hi John, >=20 > Thank you for the comments. Please see inline. >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Friday, July 15, 2011 7:57 AM > > To: dispatch@ietf.org > > Subject: [dispatch] Comments on draft-sandbakken-dispatch-bfcp-udp-02 > > > > Just a few minor comments. Although this is still to be "dispatched", > they will need attending to in > > due course. > > > > 1. The Introduction dives too quickly into what the draft does. It > should first introduce BFCP and > > explain that it is designed for transport over TCP. >=20 > Good idea. I will add that. >=20 > > 2. "Existing implementations, in the spirit > > of the approach detailed in earlier versions of this draft (see > > Appendix A), have demonstrated the approach to be feasible." > > This seems to suggest that the approach in this version is in some > respects different from the > > approach in earlier versions, and implies that existing > implementations do not follow the approach in > > this version. I don't think that is intended, so perhaps some better > words can be found. In addition, > > in the final RFC we will presumably no longer be able to refer to > Appendix A (that would be removed) > > and the words "earlier versions of this draft" will be inappropriate. >=20 > Good point. I will clean this up. >=20 > > 3. In section 4.9.2: > > "Implicit > > subscriptions, such as FloorRequest messages that have multiple > > responses as the floor control server processes intermediate states > > until Granted or Denied terminal states attained, can be > > characterized by a client-initiated request transaction whose > > acknowledgement is implied by the first FloorRequestStatus response > > from the floor control server. The subsequent changes in state for > > the request are new transactions whose Transaction ID is determined > > by the floor control server and whose receipt by the client > > participant shall be acknowledged with a FloorRequestStatusAck > > message. [Editorial note: would it be more straightforward to have > > all FloorRequestStatus messages acknowledged with a > > FloorRequestStatusAck message?]" > > Would it not be better to avoid implicit responses, i.e., have an > explicit response to the client- > > initiated request, and an explicit response to each > FloorRequestStatus? >=20 > I was thinking the same thing, and led me to add the editorial note. I > will take your input as a vote of explicit responses. One tradeoff will > be the weight the benefit vs. backward compatibility with > implementations based on previous versions of this draft. Note that the Transaction Initiator flag provides a mechanism to deal with this.=20 I: The Transaction Initiator (I) flag-bit has relevance only for use of BFCP over unreliable transport. When clear, it indicates that this message is a request initiating a new transaction, and the Transaction ID that follows has been generated for this transaction. When set, it indicates that this message is a response to a previous request, and the Transaction ID that follows is the one associated with that request. When BFCP is used over reliable transports, the flag has no significance and SHOULD be cleared. Given the change in semantics introduced in the -02 version of the draft, I think there is no longer any ambiguity whether a FloorRequestStatusAck is required or not when receiving a FloorRequestStatus. Cheers, Charles > > 4. There are several instances where the word "clause" is used to > refer to text in the existing RFC. > > It is not always clear what is meant, e.g., I think "sentence" is > sometimes the intention. >=20 > I will work on those. >=20 > Cheers, > Charles >=20 > > John > > > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From ietf@meetecho.com Sun Jul 24 18:56:17 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D053E21F85CA for ; Sun, 24 Jul 2011 18:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWJcG5PIShAT for ; Sun, 24 Jul 2011 18:56:17 -0700 (PDT) Received: from smtplqs02.aruba.it (smtplqs-out48.aruba.it [62.149.158.88]) by ietfa.amsl.com (Postfix) with SMTP id BE01321F85C6 for ; Sun, 24 Jul 2011 18:56:16 -0700 (PDT) Received: (qmail 3063 invoked by uid 89); 25 Jul 2011 01:56:14 -0000 Received: from unknown (HELO smtpw2.aruba.it) (62.149.128.188) by smtplqs02.aruba.it with SMTP; 25 Jul 2011 01:56:14 -0000 Received: (qmail 2153 invoked by uid 89); 25 Jul 2011 01:56:14 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw2.ad.aruba.it with SMTP; 25 Jul 2011 01:56:14 -0000 Date: Mon, 25 Jul 2011 03:56:14 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: dispatch@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 173.176.0.94 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplqs02.aruba.it 1.6.2 0/1000/N Subject: [dispatch] Meetecho support for DISPATCH WG meeting session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 01:56:17 -0000 Hi all, a virtual room has been reserved on the Meetecho system for tomorrow DISP= ATCH WG meeting session. Access to the on-line session (including audio and video streams) will be= available from 8:50am at: http://www.meetecho.com/ietf81/dispatch The Meetecho session automatically logs you into the standard IETF jabber= room. So, from there, you can have an integrated experience involving al= l media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf81/tutorials For further information you can contact us at support-ietf@meetecho.com. Cheers, the Meetecho Team From keith.drage@alcatel-lucent.com Mon Jul 25 09:16:42 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536BB21F84F5 for ; Mon, 25 Jul 2011 09:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.112 X-Spam-Level: X-Spam-Status: No, score=-106.112 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YT7652nGXgtO for ; Mon, 25 Jul 2011 09:16:41 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id B67D221F9048 for ; Mon, 25 Jul 2011 09:05:11 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6PG5AD9001533 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 25 Jul 2011 18:05:10 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 25 Jul 2011 18:05:10 +0200 From: "DRAGE, Keith (Keith)" To: "dispatch@ietf.org" Date: Mon, 25 Jul 2011 18:05:08 +0200 Thread-Topic: draft-sandbakken-dispatch-bfcp-udp-02.txt Thread-Index: AcxK5J/J1buRlvqqQqyhB/fh7j2SQQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [dispatch] draft-sandbakken-dispatch-bfcp-udp-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:16:42 -0000 So just to amplify my comment in the meeting. BFCP was designed so that all requests and responses were sent reliably, i.= e. that responses had the same level of protection provided by the underlyi= ng TCP that the requests had. This means that the responses can also carry data, with the same assumption= that the underlying layer will ensure that the response is received. What this draft appears to be assuming is that the responses are there only= to acknowledge the requests, and therefore adding responses to the request= s that do not have them is sufficient. That is incorrect. Responses are the= re because the response carries data that was requested in the request. Now while it may not be that all data in responses is essential to receive,= it does change the future extensions status of BFCP, in that we now need t= o ask exactly the same question we ask everytime we need to proposa data i= n responses in SIP, i.e. what happens if the data in the response is lost. = We should not have to have such questions in BFCP. Keith From gonzalo.camarillo@ericsson.com Mon Jul 25 14:41:32 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358FA11E80C7 for ; Mon, 25 Jul 2011 14:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.606 X-Spam-Level: X-Spam-Status: No, score=-106.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiJXQeZfjf5o for ; Mon, 25 Jul 2011 14:41:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BAE8911E80C0 for ; Mon, 25 Jul 2011 14:41:31 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-aa-4e2de30a9c45 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FC.57.20773.A03ED2E4; Mon, 25 Jul 2011 23:41:30 +0200 (CEST) Received: from [131.160.126.141] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 25 Jul 2011 23:41:30 +0200 Message-ID: <4E2DE309.7020800@ericsson.com> Date: Mon, 25 Jul 2011 17:41:29 -0400 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Fwd: Progressing the INVOKE-related work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 21:41:32 -0000 FYI. -------- Original Message -------- Subject: Progressing the INVOKE-related work Date: Mon, 25 Jul 2011 17:35:38 -0400 From: Gonzalo Camarillo To: rai@ietf.org Folks, as you know, the following draft has lately been discussed in the SPLICES and RAI area mailing lists: https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ >From all the discussions, there seems to be interest in working on a call/device control mechanism. In order to do that, we need to clearly define the scope of such an effort (i.e., which types of primitives would be in scope and which ones wouldn't). In addition to defining the scope, there are open issues related to how to model the mechanism (i.e., using SIP directly vs. using SIP to establish a control channel). They will need to be resolved at some point as well. As some people have pointed out, the charter of SPLICES excludes working on such a mechanism. Therefore, the next step is to have DISPATCH work on a charter proposal for this effort. Nevertheless, we want to take advantage of the current momentum behind this effort. So, this topic will be discussed in SPLICES, as planned, during the IETF. Cheers, Gonzalo From ietf@meetecho.com Tue Jul 26 08:15:19 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0981621F8584 for ; Tue, 26 Jul 2011 08:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-uTGEgf84qw for ; Tue, 26 Jul 2011 08:15:18 -0700 (PDT) Received: from smtplqs01.aruba.it (smtplqs-out17.aruba.it [62.149.158.57]) by ietfa.amsl.com (Postfix) with SMTP id F1F9721F857E for ; Tue, 26 Jul 2011 08:15:17 -0700 (PDT) Received: (qmail 14047 invoked by uid 89); 26 Jul 2011 15:15:15 -0000 Received: from unknown (HELO smtpw1.aruba.it) (62.149.128.188) by smtplqs01.aruba.it with SMTP; 26 Jul 2011 15:15:15 -0000 Received: (qmail 13807 invoked by uid 89); 26 Jul 2011 15:15:15 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw1.ad.aruba.it with SMTP; 26 Jul 2011 15:15:15 -0000 Date: Tue, 26 Jul 2011 17:15:15 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: dispatch@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 130.129.21.177 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplqs01.aruba.it 1.6.2 0/1000/N Subject: [dispatch] DISPATCH recording available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:15:19 -0000 Dear all,=0A=0Athe full recording (synchronized video, audio, slides and = jabber room) =0Aof yesterdays's DISPATCH session is available at the foll= owing URL:=0A=0Ahttp://www.meetecho.com/ietf81/recordings=0A=0AIn case of= problems with the playout, just drop an e-mail to =0Aietf-support@meetec= ho.com.=0A=0ACheers,=0Athe Meetecho Team From eckelcu@cisco.com Tue Jul 26 08:19:20 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5C21F0C3A for ; Tue, 26 Jul 2011 08:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.003 X-Spam-Level: X-Spam-Status: No, score=-3.003 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDL9pgqHrdEV for ; Tue, 26 Jul 2011 08:19:19 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B45BE1F0C36 for ; Tue, 26 Jul 2011 08:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2088; q=dns/txt; s=iport; t=1311693559; x=1312903159; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ooDgjqkGypJTnGQN9hQoznE2hx0nLo0dp6xbruw02F8=; b=Lds3Et4dEKVIswDFzFnwspzbNJoNR4icVZJDl06qHq/NmB+lSQpXaAj6 JONNcXe5PgFX7jRB9gFF5tUUMSrfRO2ymb9gcJvoD7rcXnJCjIalbZRem dSAI8pgTU9ZIbQEx+yK9oUl6K701zkDpznaAvT/CoAkAy7DjD7l0AZrth 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4AAM/aLk6rRDoJ/2dsb2JhbAA2AQEBAQMBAQERASEKMwcXBQIBCREEAQELBiMBBgETGCMOCAEBBQEWDBQHl1yPWneJAKJ/nmCFYV8Eh1eQK4tw X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208";a="6520601" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2011 15:19:19 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6QFJHoT003680; Tue, 26 Jul 2011 15:19:18 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 08:19:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 08:19:16 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-sandbakken-dispatch-bfcp-udp-02.txt Thread-Index: AcxK5J/J1buRlvqqQqyhB/fh7j2SQQAwiAUA References: From: "Charles Eckel (eckelcu)" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 26 Jul 2011 15:19:18.0523 (UTC) FILETIME=[6357ECB0:01CC4BA7] Subject: Re: [dispatch] draft-sandbakken-dispatch-bfcp-udp-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:19:20 -0000 Hi Keith, You raise a very valid point. Sorry if it seemed to get glossed over in the WG session. I agree that we need to look at this carefully. There are several ways to address it including: - additional explicit ACK messages - additional timers and/or timer expiration handling requirements I believe we already have these to the extent they are required for the SIP videoconference use case described in the draft, but we need to take a more thorough look at it. If you have any suggestions for solutions, I'd love to hear them. Cheers, Charles > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: Monday, July 25, 2011 12:05 PM > To: dispatch@ietf.org > Subject: [dispatch] draft-sandbakken-dispatch-bfcp-udp-02.txt >=20 > So just to amplify my comment in the meeting. >=20 > BFCP was designed so that all requests and responses were sent reliably, i.e. that responses had the > same level of protection provided by the underlying TCP that the requests had. >=20 > This means that the responses can also carry data, with the same assumption that the underlying layer > will ensure that the response is received. >=20 > What this draft appears to be assuming is that the responses are there only to acknowledge the > requests, and therefore adding responses to the requests that do not have them is sufficient. That is > incorrect. Responses are there because the response carries data that was requested in the request. >=20 > Now while it may not be that all data in responses is essential to receive, it does change the future > extensions status of BFCP, in that we now need to ask exactly the same question we ask everytime we > need to proposa data in responses in SIP, i.e. what happens if the data in the response is lost. We > should not have to have such questions in BFCP. >=20 > Keith > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Tue Jul 26 15:22:56 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3AD11E80C4 for ; Tue, 26 Jul 2011 15:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=-2.185, BAYES_00=-2.599, MANGLED_PRBLMS=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyIXOikGHfa9 for ; Tue, 26 Jul 2011 15:22:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 02EDA11E80C0 for ; Tue, 26 Jul 2011 15:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=17799; q=dns/txt; s=iport; t=1311718974; x=1312928574; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=xOvMZgpF203sh8Cq9hP2l5W1LBUf7YOtqtR3Np7qdgI=; b=P8xPqjcLdzy9W2pnWOO7jnh5Ix2qGUYhhvyItOwYHa+Hr92JnZ0DsDhk 2541jyAkEBIrePZT8zRBz3SmgJ1IlxMFe2+zXR+ea0J6/ehcoOwR/hHT1 98XRLtOMP1If3ABMOgjSNMDTT43MJMrwGVUaqUhApVPrCwEkVAB8Wwz0j 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAANs9L06rRDoJ/2dsb2JhbAA1AQEBAQIBAQEBEQErNwMEBwUHBQwOAwQBATQHFBgjDggHFxkHB5dOj1x3iHwEoz2eUYVhXwSScpB8 X-IronPort-AV: E=Sophos;i="4.67,271,1309737600"; d="scan'208";a="6678051" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jul 2011 22:22:53 +0000 Received: from sjc-vpn4-1404.cisco.com (sjc-vpn4-1404.cisco.com [10.21.85.123]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6QMMpgK016200; Tue, 26 Jul 2011 22:22:52 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> Date: Tue, 26 Jul 2011 18:22:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com> References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> To: Andrew Allen X-Mailer: Apple Mail (2.1084) Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:22:56 -0000 On May 27, 2011, at 23:07 , Andrew Allen wrote: > Cullen >=20 > Responses to your technical points below: >=20 > regards > Andrew >=20 >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Cullen Jennings >> Sent: Wednesday, May 18, 2011 1:11 PM >> To: DISPATCH list >> Subject: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen- >> dispatch-imei-urn-as-instanceid >>=20 >>=20 >> I have said in the past, I have several concerns around the combined >> proposal in these two drafts. In this email, I've tried to focus on > the >> high level problems and ignore small problems in the drafts that can > be >> fixed by change a bit of text in the drat. >>=20 >> The biggest issues is that this is going to reduce interoperability > with >> systems that don't use this type of instance id yet this does not > provide >> features that could not be done in away that did not reduce >> interoperability. >=20 > Can you please elaborate on what your interoperability concerns are? I > don't see any issue with end to end interoperability since with public > GRUU the gr parameter is opaque. Devices that contain an IMEI are only > those devices specified by 3GPP. Only 3GPP mandates that the IMEI is > included in the instance ID, non 3GPP devices or devices not operating > in an IMS network do not need to use an IMEI (indeed a non 3PP device > would not even have an IMEI to use). RFC 5626 allows the possibility = for > URNs other than UUID to be used as an instance ID and RFC 5627 does = not > mandate an algorithm for the generation of GRUUs based on the instance > ID. If the 3GPP determines that its devices that already contain an = IMEI > for their device ID need to use that as an Instance ID and defines a > GRUU generation algorithm that satisfies its requirements when = receiving > an Instance ID that contains the IMEI URN then that seems fine to me. = Is > your concern regarding a 3GPP IMS terminal registering in a non IMS > domain? I think that in reality a device acting as an IMS terminal > registering in a non IMS compliant network isn't a practical scenario. > There are so many 3GPP and IMS compliant things that would need to > happen in the network for the device (acting as an IMS terminal) to > register and obtain service that basically the network would need to = be > an IMS compliant network. Of course there is nothing preventing a = device > that is IMS capable being configured to either act as an IMS compliant > device or a basic SIP compliant device (quite a few devices have such > dual mode capabilities). The use of the IMEI as the instance ID should > not in itself prevent the successful registration of the device in a = non > IMS network (since as Dale points out the registrar is likely to treat > the instance ID opaquely if it doesn't understand it). What happens in 3GPP tends to leak out into other standard and into = other systems.=20 >=20 >> To be concrete, let me offer an alternative solution >> that would be interoperable, would not have any IPR that I am aware > of, >> and would provide the same functionality as the goals of these drafts > - or >> at least the goals that have been stated at the IETF. >>=20 >> To indicate the version of the software, I would suggest using the = SIP >> User Agent header. If a more structured form is required to > specifically >> line up with existing mobile systems, I would suggest defining an = well >> structured format to use inside the User Agent header field. The > advantage >> is that this is what most sip systems do today and many management > systems >> already can look at this header and use it. A more structured form > would >> be useful by systems outside the GSMA space and would also be > backwards >> compatible with existing systems that treat it as an unstructured > string. >=20 > I am not against the proposal of including the software version in the > User Agent header but don't see it as an alternative to the > representation of the IMEI-SV as part of the IMEI URN. One of the main > objectives of the use of the IMEI and IMEI-SV in SIP signaling is to > maintain compatibility with the IMEI and IMEI-SV use in Circuit = Switched > signaling. In some case in circuit switched signaling the device will > return the IMEI and in other cases the device will return the IMEI-SV. > It needs to be possible that devices registered in circuit switched > domain and in the IMS domain can use whichever is returned IMEI or > IMEI-SV in the same identifier. I understand both are used in circuit switched but I don't see that that = would require a design like this.=20 >>=20 >> For the issue of identifying stolen handsets and correlating devices >> between SIP and non SIP calls, I would propose that you use a UUID as > the >> URN but that the UUID be created using IMEI or a hash of the IMEI > instead >> of the MAC. This would involve an extension to RFC 4122 but would > result >> in a system that meets the needs. Even if a hash is used, the server > side >> can do the same hash to match. >=20 > I don't fully understand the details of your proposal but a clear > requirement is that the IMEI in the instance ID be recoverable and > understandable by the registrar as the IMEI value of the terminal. = Does > this proposal allow the IMEI value to be obtained and understood by = the > registrar? The requirement was that they be matchable not recoverable which this = meets >=20 > If an extension to RFC 4122 is required isn't this more overhead and = has > more impact than simply defining and using a URN that represents the > namespace that you wish to include? UUID itself is also heavier in > computational resources and less efficient in size than the IMEI URN. This extension to 4122 is pretty easy and has no IPR I am aware of.=20 >=20 >>=20 >> If the WG is interest in such an idea, I am glad to write up an ID = for >> each of these and submit it to the group so that it can be properly >> considered in contrast to = draft-allen-dispatch-imei-urn-as-instanceid. >>=20 >> As the draft-allen-dispatch-imei-urn-as-instanceid stands today, I am > not >> in favor of publishing it as is because I believe it will result in >> interoperability failures with the many SIP devices that don't = support > it, >=20 > This needs justification. 3GPP specifications also support handling > devices that use UUID and not IMEI as many IMS compatible devices do = not > actually have an IMEI (only GSM mobile devices have an IMEI). I think I have provided this on more than one occasion. >=20 >> and it has IPR that we can easily avoid and provide the same >> functionality. I also have issues with some of the technical details > in it >> but theses could all be fairly easily resolved with a few back and > forth >> of suggested text. RIM is offering awful licensing terms for = something >> that I believe you would have to implement to be workable in the bulk >> mobile SIP deployments. Give this is easily avoidable, I think we > should >> avoid it. It's not really a topic for this WG but if this draft > proceeded, >> it was very late IPR disclosure. When it came to IETF LC, I would = also >> want to point out that the only teeth IETF has to enforce very late > IPR >> disclosures is to say no. I'm not particularly interested in talking > about >> this here as I don't think it will help solve the proble >> m but I have brought this up in the past in context of this draft and > I >> don't want anyone to be surprised if I brought it up in an IETF LC. >>=20 >> There are also significant privacy concerns around this proposal. A > key >> design of GRUU is being able to meet people goals of privacy while = not >> revealing private information. >=20 > Privacy in GRUU is achieved through temporary GRUUs. Properties of > temporary GRUUs are unaffected by using the IMEI as an instance ID. >=20 >> The IMEI is sometimes used as a security >> identifier between a user and SP as a shared secret. This proposal > would >> break theses systems. >=20 > The IMEI is easily readable from the UI of mobile phones and is quite > often printed on the case under the battery. Mobile phone stores > sometimes keep lists (sometimes on paper) of IMEIs and the customers = who > have been allocated them (warranty reasons etc). agree with what you are saying but you do agree it is used as a secret = often used to show proof of possession of the phone? > It is hardly a super > secret security identifier. I am not aware of the security usage you > describe and if it does exist it seems pretty flawed. >=20 >> The privacy and security aspects of this would need to be addressed. >=20 > 3GPP has addressed aspects of revealing the IMEI when generating GRUUs > in their specifications. right, send them on over=20 >=20 >> It's conceivable that in many cases IMEI is Personal >> Identifiable Information. >=20 > IMEI is not really anymore personal information than IP address=20 <..snip..> I'll note I think you are just wrong on this. First of all, IMEI are = more revealing than IP because they tend to be tighter bound to a single = suer instead of multiple and exist over longer time and second of all = many people, myself included, consider IP as PII in many cases. =20 >=20 >> The idea that every call would have to have PII >> information in it or my call would be blocked as coming form a stolen >> phone seems like a pretty serious flaw in this proposal. >=20 > In general the IMEI is not placed in an IMS call. The blocking would = be > achieved via the registration. Blocked mobiles simply would be unable = to > register in IMS (which in IMS means they are unable to make calls). If > an IMEI check is needed during a call the mobile can be requested by = the > network to re-register. The only use in 3GPP of the IMEI during an IMS > call is for emergency calls. again, I think there are much better designs for this without IPR issues=20= >=20 >> I'll note I brought up the privacy issues in 2007 and have yet to get > a reply on it. >=20 > I don't recall your previous comment (but it was 4 years ago). If we > have failed to respond adequately to a previous comment then please > restate it if the above responses do not cover it. >>=20 >> On the topic of draft-montemurro-gsma-imei-urn, I of course think it > is >> fine for the GSMA to be able to allocate a namespace where they need > it. >> However, there are bunch of changes that would be needed to make this >> draft fit all the URN rules. They are all small actionable things = like >> defining how comparison of things such as svn is defined and how >> allocation of new things works. >=20 > Of course all technical issues and concerns can be fixed. Please = supply > details on those so they can be addressed. >=20 >> As I have also brought up many times in >> the past, what the relationship between GSMA and 3GPP on this is very >> weird and I would want clarity on that before proceeding. In the time > we >> have been discussing this draft, people constantly tell me that GSMA > is >> the group that will handle the namespace allocation for the 3GPP >> deployments yet at the same time we have approved RFC 5279 which = oddly >> looks like a better namespace for this than the GSMA one. I would = want > to >> have a clear understanding of how these different spaces interact. = The >> more we splinter this namespace, the less interoperability we have. >=20 > My understanding is that in order to be allocated a URN namespace the > registrant of the namespace has to guarantee uniqueness of the > namespace. GSMA provides for the allocation of IMEIs and ensures > adherence to the guidelines for IMEI allocation "GSMA Association, = "IMEI > Allocation and Approval Guidelines", PRD DG.06". Thus for the IMEI the > GSMA is the appropriate registrant for that namespace. 3GPP has no > responsibility for allocation of IMEIs so should not be the = responsible > registrant. 3GPP namespace would seem appropriate for items which are > completely specified (including all their values) in 3GPP > specifications. It should be noted that 3GPP is not a legal entity and > might not exist for the entire period of time that IMEIs are being > allocated and used. >>=20 >> On the topic of including the software version as part of the device >> identifier, given the software is upgraded, I think this is a mistake > and >> it is better to consider the software version as a separate thing = from > the >> unique device identifier. It does not seem consistent with the goals > and >> requirements of a device id URN. >=20 > As stated above the software version is included for backward > compatibility with the IMEI-SV usage in circuit switched signaling. = The > SVN is a parameter and so the original IMEI which does not change can = be > easily obtained. Registrars and other devices that understand the IMEI > URN with the SVN parameter can ignore the parameter when generating > GRUUs for instance. If a book has a 2nd edition with different content > doesn't that warrant being assigned a new value within the ISBN URN > namespace? Similarly if the software is upgraded the nature and > capabilities of the device may change so doesn't this warrant a new > value? Note that RFC 5626 and RFC 5627 do not require that the = instance > IDs or GRUUs be forever persistent (RFC 5626 only requires that it = MUST > be persistent through a power cycle). I doubt very much that most > embedded SIP endpoints will after a complete software upgrade (such as > involving completely rewriting flash memory) still use the same UUID = as > previously used either. >>=20 >> I will also note that as far as process is concerned, I would prefer > the >> problem, not the solution was brought to dispatch and we could figure > out >> how to solve it. I do think the problem here is well worth solving, I > just >> think there are solutions that will work better that this when > considering >> the whole eco systems of SIP endpoints and not just the GSM ones. >=20 > When this was first proposed in 2006 all that was being done was > registering a namespace. I doubt that is true. Please look at the drafts from 2006. I have never = objected to the idea that some other SDO might want a URN namespace. If = that was all that was requested, this would have been done long ago and = the current draft would not be requesting anything more than that.=20 > I don't think that 3GPP needs to bring > requirements to the dispatch WG, propose a charter etc for every = problem > that can be solved by registering a namespace or a parameter. In fact > the SIP change process has moved away from that with only = specification > required and expert review needed for defining "proprietary" SIP = header > fields. As stated above the IMEI only applies to the GSM family of > technology mobiles not all SIP endpoints and I fail to see the impact = of > the use of the IMEI URN by the GSM family of technology mobiles when > registering with IMS on any other SIP endpoints. This proposal does = not > mandate the use of the IMEI URN as an Instance ID by non 3GPP = terminals > and is not being proposed to become part of an IETF standard. This is > just trying to follow the process whereby external users of IETF > protocols register their identifiers with IANA and provide = informational > documentation to the internet community about such usage. It seems to = me > that some of the issues of principle being raised are those > considerations that more appropriately apply to standards track > submissions and not to these informational submissions. > If the same > level of consideration and debate about different solutions takes = place > for informational submissions as would take place for standards track > submissions then I fear this will become a big deterrent to outside > users of IETF protocol submitting their proprietary usages as > informational RFCs for the benefit of the internet community and in > ensuring that are no conflicts with the IANA registry. You are asking for something that can not be approved as an information = draft by the ISE because it impacts interoperability of SIP devices. The = bar here is somewhat higher than some information drafts. If what you = needed to be approved could be done by the ISE, I would suggest you take = it there but it can't.=20 >>=20 >> Cullen in my individual contributor role >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From paulej@packetizer.com Sat Jul 30 23:29:20 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D308811E8084 for ; Sat, 30 Jul 2011 23:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueLddGR7L51v for ; Sat, 30 Jul 2011 23:29:20 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 18C8A11E8082 for ; Sat, 30 Jul 2011 23:29:17 -0700 (PDT) Received: from sydney (rrcs-98-101-150-155.midsouth.biz.rr.com [98.101.150.155]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p6V6TD5W024248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 31 Jul 2011 02:29:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1312093759; bh=DaGaHJE6ila4FhyWhMBBWqy13dYsJauB0yyukB6iYHY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=l+3uAyVa+lHhJXpNh6hOwDCLMpPXS5zloN0JTQqsR+p2JXaf79JgAuTZGMkKXHZKy BqjRWgfEycNAXQz0M25AhhxNwa6CVvf5pE86Mux+id+aQ1N0jKp7VIFZ8zP4EKlxlU hanG4Y/nUXwCGV/NFAMdYfQ/cQHGKYgH8NKl5JbA= From: "Paul E. Jones" To: References: <20110731062456.11484.11296.idtracker@ietfa.amsl.com> In-Reply-To: <20110731062456.11484.11296.idtracker@ietfa.amsl.com> Date: Sun, 31 Jul 2011 02:29:13 -0400 Message-ID: <06b701cc4f4b$2da82ec0$88f88c40$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDZ4y4vOk8fWkadGCaDwqsqtQXCXJbqz2nQ Content-language: en-us Subject: [dispatch] FW: I-D Action: draft-jones-ipmc-session-id-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 06:29:20 -0000 Folks, I just wanted to alert you to the fact that we revised the document we prepared that describes signaling and end-to-end session identifier. The primary change was really to just refer to the requirements document explicitly, since we now have a new one we're progressing separately. Paul > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Sunday, July 31, 2011 2:25 AM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-jones-ipmc-session-id-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : End-to-End Session Identification in IP-Based > Multimedia Communication Networks > Author(s) : Paul E. Jones > Chris Pearce > James Polk > Gonzalo Salgueiro > Filename : draft-jones-ipmc-session-id-02.txt > Pages : 8 > Date : 2011-07-30 > > This document describes an end-to-end Session Identifier for use in > IP-based Multimedia Communication systems that enables endpoints, > intermediate devices, and management systems to identify a session > end-to-end, associate multiple endpoints with a given multipoint > conference, track communication sessions when they are redirected, > and associate one or more media flows with a given communication > session. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jones-ipmc-session-id-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-jones-ipmc-session-id-02.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt