From jmpolk@cisco.com Fri Jan 6 15:55:30 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DABE21F8820 for ; Fri, 6 Jan 2012 15:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuJab1lAxLxK for ; Fri, 6 Jan 2012 15:55:29 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DBA4421F881F for ; Fri, 6 Jan 2012 15:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1019; q=dns/txt; s=iport; t=1325894129; x=1327103729; h=message-id:date:to:from:subject:mime-version; bh=SX8l8chPngfkYBBJidZACt2sSlPGwmhxBGtmmhJOH3E=; b=EMr/gXtBrc9+cOqPXjHAz3JSbM2FZ6ul6rzJrLEyHTMralteA+N8PglI Yf6pYVAj1hpSDbTF9GaRbEMGYu/tkhnGJ80Td3M0MaSRYBpJ9b9KzPJwv jYjs/M+k/zJHKG4jWC46jnE3l0S809H6Vw1baACJsQJAi+YnjA+XZy6yJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEALGJB0+rRDoG/2dsb2JhbABErEKBBYILASUCVjopeZ4+gSYBngiId4MaBIg5nyI X-IronPort-AV: E=Sophos;i="4.71,470,1320624000"; d="scan'208";a="22515091" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 06 Jan 2012 23:55:29 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q06NtTb6003148 for ; Fri, 6 Jan 2012 23:55:29 GMT Message-Id: <201201062355.q06NtTb6003148@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Jan 2012 17:55:28 -0600 To: mmusic@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Flaw in traffic class ID regarding payload type X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 23:55:30 -0000 WG It's been pointed out to me that I omitted distinguishing traffic class labels by payload type. I remember thinking that was necessary, but somehow lost the thought a while ago. Because more than one payload type can be in each m= line, ISTM it is reasonable to have cases in which one/some/each payload type has a different traffic class label. Is this concept agreeable within the WG? If so, I propose I change the draft to reflect that by simply adding a "pt=x" to the ABNF after "trafficclass" and before the label itself. For example (one that's in the draft now), change a=trafficclass Conversational.video.immersive._foo._bar to a=trafficclass pt=112 Conversational.video.immersive._foo._bar (or whatever payload type(s) are in the m= line). I could add an example that shows - within the same m= line - more than one payload type each having their own respective traffic class label. The ABNF is easily (even for me) corrected. Comments please? James From pkyzivat@alum.mit.edu Mon Jan 9 15:10:25 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCE521F8605 for ; Mon, 9 Jan 2012 15:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EV5OIuEf2rOj for ; Mon, 9 Jan 2012 15:10:23 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 31CDC21F8513 for ; Mon, 9 Jan 2012 15:10:12 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by QMTA11.westchester.pa.mail.comcast.net with comcast id KayN1i0011ap0As5BbACNF; Mon, 09 Jan 2012 23:10:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id KbAC1i01H07duvL3ibACuh; Mon, 09 Jan 2012 23:10:12 +0000 Message-ID: <4F0B73D2.9000809@alum.mit.edu> Date: Mon, 09 Jan 2012 18:10:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <201201062355.q06NtTb6003148@mtv-core-1.cisco.com> In-Reply-To: <201201062355.q06NtTb6003148@mtv-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Flaw in traffic class ID regarding payload type X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 23:10:25 -0000 On 1/6/12 6:55 PM, James M. Polk wrote: > WG > > It's been pointed out to me that I omitted distinguishing traffic class > labels by payload type. I remember thinking that was necessary, but > somehow lost the thought a while ago. > > Because more than one payload type can be in each m= line, ISTM it is > reasonable to have cases in which one/some/each payload type has a > different traffic class label. > > Is this concept agreeable within the WG? > > If so, I propose I change the draft to reflect that by simply adding a > "pt=x" to the ABNF after "trafficclass" and before the label itself. For > example (one that's in the draft now), change > > a=trafficclass Conversational.video.immersive._foo._bar > > to > > a=trafficclass pt=112 Conversational.video.immersive._foo._bar > > (or whatever payload type(s) are in the m= line). > > I could add an example that shows - within the same m= line - more than > one payload type each having their own respective traffic class label. > > The ABNF is easily (even for me) corrected. > > Comments please? > Can you clarify the intended semantics? - Is the pt= optional? - If so, when absent does it imply all payload types? - Is it possible to specify a default for all payload types and then a specific value for certain payload types? Thanks, Paul From wuym2000cn@gmail.com Thu Jan 12 22:34:22 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D4321F858B for ; Thu, 12 Jan 2012 22:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fbsY06qIxnA for ; Thu, 12 Jan 2012 22:34:22 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 055AF21F8589 for ; Thu, 12 Jan 2012 22:34:21 -0800 (PST) Received: by qcsc1 with SMTP id c1so113346qcs.31 for ; Thu, 12 Jan 2012 22:34:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=b5dtimIfLfAF/rzJhxjA/KbTzuzr44zEcCoSXYL7gVQ=; b=lNS4PjLgh+Mw+AUjBMUgZIrDyJLWDSsqRcmaXLbjE1OX25OMjoPmDgoCdCfeWjpWaA drusdJNn2HWgrWWtTZWhUNcTe9VjdguogMSNCc6PYjiW1fOeuQSxUqlrtbXiaRxEB4ns MsqI3C0oZkW15lpVUHDdMysGPjDUAc+i63Iow= MIME-Version: 1.0 Received: by 10.229.137.131 with SMTP id w3mr356459qct.27.1326436461543; Thu, 12 Jan 2012 22:34:21 -0800 (PST) Received: by 10.229.73.136 with HTTP; Thu, 12 Jan 2012 22:34:21 -0800 (PST) Date: Fri, 13 Jan 2012 14:34:21 +0800 Message-ID: From: Woo Johnman To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [MMUSIC] question about H.264 SDP Grammer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 06:34:22 -0000 Hi, I have a H.264 SDP sample whose fmtp attribute is as following: "a=fmtp:109 profile-level-id=428014;max-mbps=11880;max-fs=396;" As usual,last parameter(max-fs) should not be appended with ';' But I am not sure if it is also legal with ';'? Woo, Best Regards! From wuym2000cn@gmail.com Thu Jan 12 22:37:48 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9B821F865A for ; Thu, 12 Jan 2012 22:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSA5BlYnR18j for ; Thu, 12 Jan 2012 22:37:48 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD3DC21F85D4 for ; Thu, 12 Jan 2012 22:37:47 -0800 (PST) Received: by qcsc1 with SMTP id c1so114578qcs.31 for ; Thu, 12 Jan 2012 22:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=b5dtimIfLfAF/rzJhxjA/KbTzuzr44zEcCoSXYL7gVQ=; b=K/oACfjnJG8JeLs6kfJ3RWq81alvn3Ox6ar9fRV5WfYPQsKkxIXxuVPHDLGe7UTi+x fnZqlDopmwIQCOo2W9is/HG4PeX7jabuSiIcbqGFwEHZB5dW7fDRYtYotJShi3s2sub1 1xu+yK6jMUcnpjzoGlkw38WqE2uGiqsdyzo5U= MIME-Version: 1.0 Received: by 10.229.107.33 with SMTP id z33mr368732qco.7.1326436667437; Thu, 12 Jan 2012 22:37:47 -0800 (PST) Received: by 10.229.73.136 with HTTP; Thu, 12 Jan 2012 22:37:47 -0800 (PST) Date: Fri, 13 Jan 2012 14:37:47 +0800 Message-ID: From: Woo Johnman To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [MMUSIC] question about H.264 SDP Grammer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 06:37:48 -0000 Hi, I have a H.264 SDP sample whose fmtp attribute is as following: "a=fmtp:109 profile-level-id=428014;max-mbps=11880;max-fs=396;" As usual,last parameter(max-fs) should not be appended with ';' But I am not sure if it is also legal with ';'? Woo, Best Regards! From 2mkristensen@gmail.com Fri Jan 13 13:20:37 2012 Return-Path: <2mkristensen@gmail.com> X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D665F21F84D5 for ; Fri, 13 Jan 2012 13:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcYywscJUp62 for ; Fri, 13 Jan 2012 13:20:37 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8818C21F84D2 for ; Fri, 13 Jan 2012 13:20:36 -0800 (PST) Received: by lagv3 with SMTP id v3so632842lag.31 for ; Fri, 13 Jan 2012 13:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ICRWoUNe7Eu2hDBV39vFnh4UbYOCLsmFR8VoIfWRVCU=; b=Ii/c7Y0oDlDzQTnMEZJJU0D72ZuS4OjJs3OcJ37Ozzx+Eyv7rWSJIn+MJrPJ7+KGP2 ZSL3OUcgCU5V3Vc/mmxsE0/fDK1qnoSy3O+aQz47RCsouDhspsbbiYaIXWUNyvXb0rCm QNi0sl5ie9Fq5cXLw83aGsaSMNG64iaOMoba4= MIME-Version: 1.0 Received: by 10.152.109.161 with SMTP id ht1mr625428lab.33.1326489635529; Fri, 13 Jan 2012 13:20:35 -0800 (PST) Received: by 10.152.37.131 with HTTP; Fri, 13 Jan 2012 13:20:35 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Jan 2012 22:20:35 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Woo Johnman Content-Type: text/plain; charset=ISO-8859-1 Cc: mmusic@ietf.org, Tom Kristensen Subject: Re: [MMUSIC] question about H.264 SDP Grammer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 21:20:38 -0000 On 13/01/2012, Woo Johnman wrote: > Hi, > I have a H.264 SDP sample whose fmtp attribute is as following: > "a=fmtp:109 profile-level-id=428014;max-mbps=11880;max-fs=396;" > > As usual,last parameter(max-fs) should not be appended with ';' > But I am not sure if it is also legal with ';'? When building your SDP there's no reason for adding the last semicolon. However, as always you need to be liberal in what you accept. When parsing and decoding the SDP you should tolerate this trailing semicolon as well as presence of space/blanks between the parameters. The SDP spec in RFC 4566 has left the actual content of a=fmtp to the different RTP payload specs. The RTP payload spec. (RFC 6184 for H.264) only states the a=fmtp parameter/value list to be "a semicolon-separated list of parameter=value pairs". So, whether the trailing semicolon is legal or not isn't too relevant - is it? You should cope with it! -- Tom -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ From miguel.a.garcia@ericsson.com Fri Jan 20 00:03:55 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8592421F8599 for ; Fri, 20 Jan 2012 00:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.939 X-Spam-Level: X-Spam-Status: No, score=-8.939 tagged_above=-999 required=5 tests=[AWL=1.660, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0UsGG4x-Z0Z for ; Fri, 20 Jan 2012 00:03:51 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5466121F857D for ; Fri, 20 Jan 2012 00:03:51 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-b2-4f191fe68a3e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A7.75.23425.6EF191F4; Fri, 20 Jan 2012 09:03:50 +0100 (CET) Received: from [159.107.48.31] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 20 Jan 2012 09:03:49 +0100 Message-ID: <4F191FE4.4010008@ericsson.com> Date: Fri, 20 Jan 2012 09:03:48 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] 4566bis and private IP addresses in the origin line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 08:03:55 -0000 Folks, you know we have a revision of rfc4566 open in the format of this draft: http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ I was reading the description of the origin line, and I found something that might be out of date, and we may want to revise. I would like to hear other opinions. The origin line is described in Section 5.2 of RFC 4566, and it has the following format: o= Let's take a look at the description of . The RFC says: ... For both IP4 and IP6, the fully qualified domain name is the form that SHOULD be given unless this is unavailable, in which case a globally unique address MAY be substituted. A local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful (for example, a local address MUST NOT be included in an application-level referral that might leave the scope). Ok, so if I write an IP address, it has to be globally routable, or I need to make sure that the SDP is not going beyond the domain where it is routable. So, I cannot write private IP addresses... got it!! But now, take a look at ICE, RFC 5245. I haven't seen ICE saying anything about the o= line in SDP, but I can see the examples in Section 4.3, where the o= line contains a private IP address. And later in Section 17, where again the o= line is populated with a private IP address- So, I guess RFC 5245 should have updated RFC 4566 at least in this aspect. But since that wasn't done, and since we have 4566bis in the pipe, I wonder if it is time to amend the quoted paragraph and change the MUST NOT by a "SHOULD NOT", and explain that if you are using ICE, as a mechanism to traverse NATs, then you can write private IP addresses in the origin line. Comments? BR, Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From magnus.westerlund@ericsson.com Mon Jan 23 01:29:46 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC7721F8642 for ; Mon, 23 Jan 2012 01:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.572 X-Spam-Level: X-Spam-Status: No, score=-109.572 tagged_above=-999 required=5 tests=[AWL=1.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IStVW4ULQiFx for ; Mon, 23 Jan 2012 01:29:46 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 309CE21F8673 for ; Mon, 23 Jan 2012 01:29:45 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-ee-4f1d2888f374 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DA.42.23425.8882D1F4; Mon, 23 Jan 2012 10:29:45 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 23 Jan 2012 10:29:44 +0100 Message-ID: <4F1D2887.3090607@ericsson.com> Date: Mon, 23 Jan 2012 10:29:43 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Ross Finlayson References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Question about the various "range-spec"s defined for RTSP 2.0 (and RTSP 1.0) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 09:29:47 -0000 On 2011-11-26 20:53, Ross Finlayson wrote: > In "draft-ietf-mmusic-rfc2326bis-28" (and preceding), a "npt-range-spec" > is defined as > npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) > (ditto for "smtp-range-spec" and "utc-range-spec"). > > This suggests that the following are valid: > npt = -now > npt = -12.34 > > What are these supposed to mean (especially given that - in section 4.5 > - you say that "Negative values are not defined")? It means play from "now" or stored playout point _until_ the given value. I agree that npt=-now does not make sense, so that should be made clear is not valid. Please also remember that the timescale can go backwards. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From joe.pallas@gmail.com Mon Jan 23 13:47:27 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5C321F8667 for ; Mon, 23 Jan 2012 13:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t01mVlyqGuf for ; Mon, 23 Jan 2012 13:47:27 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81021F8670 for ; Mon, 23 Jan 2012 13:47:27 -0800 (PST) Received: by ghbg16 with SMTP id g16so1149591ghb.31 for ; Mon, 23 Jan 2012 13:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=gtV8xznZ68nEKcRv3fLs9Jk6bIf5+XjVJzt7EJzYBNg=; b=QYP8Ywq4LSu4todyoGO3ZOZwMH6ssgGa6PEP81b7ApC3F6t4AyJU7bZQ9my5zKllQT Bh4ExGE15pZL6nxsNCDHrCY0+BdfqdQH4+AmyuO36n7Etq9Lm4W/N4EG+/vyoktmaxNY jgJ4VWQxOOPLYGqdMh3P8xJY92sAG6P8AloYw= Received: by 10.236.79.135 with SMTP id i7mr12743914yhe.4.1327355246984; Mon, 23 Jan 2012 13:47:26 -0800 (PST) Received: from [127.0.0.1] (inet-hqmc01-o.oracle.com. [148.87.19.194]) by mx.google.com with ESMTPS id r34sm13659008yhe.1.2012.01.23.13.47.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jan 2012 13:47:26 -0800 (PST) Sender: Joe Pallas Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Joe Pallas In-Reply-To: Date: Mon, 23 Jan 2012 13:47:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: mmusic@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [MMUSIC] Question about the various "range-spec"s defined for RTSP 2.0 (and RTSP 1.0) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 21:47:27 -0000 On Jan 23, 2012, at 12:00 PM, mmusic-request@ietf.org wrote: > On 2011-11-26 20:53, Ross Finlayson wrote: >> In "draft-ietf-mmusic-rfc2326bis-28" (and preceding), a = "npt-range-spec" >> is defined as >> npt-range-spec =3D ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) >> (ditto for "smtp-range-spec" and "utc-range-spec"). >>=20 >> This suggests that the following are valid: >> npt =3D -now >> npt =3D -12.34 >>=20 >> What are these supposed to mean (especially given that - in section = 4.5 >> - you say that "Negative values are not defined")? >=20 >=20 > It means play from "now" or stored playout point _until_ the given > value. I agree that npt=3D-now does not make sense, so that should be = made > clear is not valid. Please also remember that the timescale can go > backwards. Whoops. Don=92t say "now" when you mean the current pause point, it = will confuse everyone. I disagree and would say that =93npt =3D -now=94 makes sense. How else = would I express =93fast forward from the pause point to the current = time=94 (that is, fast forward to live after pause) in a DVR-like system = if not by a scale > 1 and a range of (implicit) pause-point to now? joe From magnus.westerlund@ericsson.com Mon Jan 23 23:57:20 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD7221F8475 for ; Mon, 23 Jan 2012 23:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.645 X-Spam-Level: X-Spam-Status: No, score=-109.645 tagged_above=-999 required=5 tests=[AWL=0.954, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oD3lwvxi1Sn for ; Mon, 23 Jan 2012 23:57:20 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C5D8B21F8478 for ; Mon, 23 Jan 2012 23:57:19 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-45-4f1e645e01bb Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 08.68.27041.E546E1F4; Tue, 24 Jan 2012 08:57:18 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 24 Jan 2012 08:57:18 +0100 Message-ID: <4F1E645D.9030304@ericsson.com> Date: Tue, 24 Jan 2012 08:57:17 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] Question about the various "range-spec"s defined for RTSP 2.0 (and RTSP 1.0) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 07:57:20 -0000 On 2012-01-23 22:47, Joe Pallas wrote: > > On Jan 23, 2012, at 12:00 PM, mmusic-request@ietf.org wrote: > >> On 2011-11-26 20:53, Ross Finlayson wrote: >>> In "draft-ietf-mmusic-rfc2326bis-28" (and preceding), a >>> "npt-range-spec" is defined as npt-range-spec = ( npt-time "-" [ >>> npt-time ] ) / ( "-" npt-time ) (ditto for "smtp-range-spec" and >>> "utc-range-spec"). >>> >>> This suggests that the following are valid: npt = -now npt = >>> -12.34 >>> >>> What are these supposed to mean (especially given that - in >>> section 4.5 - you say that "Negative values are not defined")? >> >> >> It means play from "now" or stored playout point _until_ the given >> value. I agree that npt=-now does not make sense, so that should be >> made clear is not valid. Please also remember that the timescale >> can go backwards. > > Whoops. Don’t say "now" when you mean the current pause point, it > will confuse everyone. The "now" in my above text do apply for live streams that aren't recorded, where there is no other point then what is currently being transmitted. > > I disagree and would say that “npt = -now” makes sense. How else > would I express “fast forward from the pause point to the current > time” (that is, fast forward to live after pause) in a DVR-like > system if not by a scale > 1 and a range of (implicit) pause-point to > now? Yes, in that context is makes sense. It doesn't make sense if you are in a live context without recording where you can't play anything else than now. Then it completes immediately. But, there is obviously some expansion on what can occur under different media properties. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From miguel.a.garcia@ericsson.com Sat Jan 28 04:23:08 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128BC21F8501 for ; Sat, 28 Jan 2012 04:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.769 X-Spam-Level: X-Spam-Status: No, score=-9.769 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpiR5khIVXBL for ; Sat, 28 Jan 2012 04:23:07 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 073F721F84FF for ; Sat, 28 Jan 2012 04:23:06 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-1c-4f23e8a9c699 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 64.29.02613.9A8E32F4; Sat, 28 Jan 2012 13:23:05 +0100 (CET) Received: from [159.107.48.113] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Sat, 28 Jan 2012 13:23:04 +0100 Message-ID: <4F23E8A7.7070302@ericsson.com> Date: Sat, 28 Jan 2012 13:23:03 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Do we need to update in time 4566bis? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 12:23:08 -0000 Hi all, You know we are revising RFC 4566. So far, the effort has been in bug fixing. The first SDP version was published as RFC 2327 in 1998 (i.e., 14 years ago), and was then revised as RFC 4566 in 2006. Lots of things have happened since then. We have SDP offer answer, Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. From the point of view of a reader who takes 4566 (or its current 4566bis incarnation), I think it will be difficult for her or him to understand a protocol that ignores those other extensions. For example, I recently post another e-mail where there is an apparent contradiction between 4566 and ICE (see http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). So, I was wondering if time has come to make not a bug correction in 4566bis, but also put that RFC in context with the other extensions that exist. This may include: - Add minor extensions to the core document, similarly to what we did with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which of these extensions make sense to include, this would be an exercise to do, but let me give you one potential example: RFC 4574, the SDP "label" attribute is a 6 pages RFC. - Adding references to extensions, when it makes sense. For example, ICE should be referred somewhere (see my previous post regarding the "o" line). I guess capneg could be also mentioned, perhaps others. I know this is a bigger effort than anticipated, but the result could really help newcomers to this world. Now, it is your turn to express your opinions. Please do it. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From mperumal@cisco.com Sun Jan 29 18:39:28 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3BE21F84EB for ; Sun, 29 Jan 2012 18:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ApX4dFcbRHU for ; Sun, 29 Jan 2012 18:39:27 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 71D8421F848A for ; Sun, 29 Jan 2012 18:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=36998; q=dns/txt; s=iport; t=1327891165; x=1329100765; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=TUAKEtXERB8AtpNeCoZBhtYuEShxUvAbRNEomCJt89k=; b=fwdYU5jAo/Dfl9+ugBfzRHkIcZP3V9R1p+AVDY0ESTdADhk3EROuv66T jgWYLGte/Gffu3BSX/p/51IMYwfMQ73NcZlnNb8PPEjPmZok6xzalj+72 YAwMAwmXINqzPEcx2QWYIq1KccM7WCrw7Ro9egs1+Uz1szc0lM5oumxCh Y=; X-IronPort-AV: E=Sophos;i="4.71,590,1320624000"; d="scan'208,217";a="4365433" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 30 Jan 2012 02:39:24 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0U2dNg2009053; Mon, 30 Jan 2012 02:39:23 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 08:09:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCDEF8.6060D422" Date: Mon, 30 Jan 2012 08:07:16 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020768179C@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mmusic-media-path-middleboxes-03 Thread-Index: Acyy7OWlIMiIX7z4R1asc+bbi190nQsCPi3w References: <1D062974A4845E4D8A343C65380492020513F329@XMB-BGL-414.cisco.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Gonzalo Salgueiro (gsalguei)" X-OriginalArrivalTime: 30 Jan 2012 02:39:24.0346 (UTC) FILETIME=[60C1A1A0:01CCDEF8] Cc: mmusic Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-media-path-middleboxes-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 02:39:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCDEF8.6060D422 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gonzalo, =20 My apologies for the delay. =20 |Where did you think this text should be added ? =20 This should be added to section 7 -- Preliminary Recommendations. Here is my take: =20 REC #5: It is recommended that middleboxes present on the media path allow at least a nominal amount of traffic to be exchanged=20 between endpoints for at least one RTT after the middlebox=20 receives a message from the MIDCOM agent indicating the media=20 session being terminated. This will ensure that any transit=20 signaling packets on the media path exchanged during the session=20 termination pass through the middle box. =20 Muthu =20 From: Gonzalo Salgueiro (gsalguei)=20 Sent: Monday, December 05, 2011 6:56 AM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Gonzalo Salgueiro (gsalguei); mmusic Subject: Re: Comments on draft-ietf-mmusic-media-path-middleboxes-03 =20 Muthu -=20 =20 Please forgive the delayed response, but I have been buried under work with some of my new responsibilities at work. I am getting ready to release the new version of this draft and had a quick question about your one major comment. =20 =20 On Mar 29, 2011, at 9:21 AM, Muthu ArulMozhi Perumal (mperumal) wrote: Overall this draft looks to be in a good shape. =20 I've one major comment. Similar to REC #2 in section 7, it would be desirable to have a recommendation that the middlebox present on the media path allow at least a nominal amount of traffic to be exchanged between endpoints for a small duration of time (say, one RTT) after the middlebox receives a message from theMIDCOM agent that indicates the media session being terminated. This will ensure that any transit signaling packets on the media path exchanged during the session termination, like RTCP Bye packets, pass through the middle box. =20 =20 I think I understand the intent of this recommendation and think it might be useful to address specifically. Where did you think this text should be added ? =20 Regards, =20 Gonzalo =20 =20 =20 ------_=_NextPart_001_01CCDEF8.6060D422 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Gonzalo,

 

My = apologies for the delay.

 

|Where = did you think this text should be added ?

 

This = should be added to section 7 -- Preliminary Recommendations. Here is my = take:

 

REC #5: It is recommended that = middleboxes present on the = media

      path = allow at least a nominal amount of traffic to be exchanged

      between endpoints for at least one RTT after the middlebox 

      = receives a message from the MIDCOM agent indicating the media =

      session = being terminated. This will ensure that any transit

      = signaling packets on the media path exchanged during the session =

      = termination pass through the middle box.

 

Muthu

 

From: Gonzalo Salgueiro (gsalguei)
Sent: Monday, December 05, 2011 6:56 AM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Gonzalo Salgueiro (gsalguei); mmusic
Subject: Re: Comments on = draft-ietf-mmusic-media-path-middleboxes-03

 

Muthu - 

 

Please forgive the delayed response, but I have been buried under work with = some of my new responsibilities at work.  I am getting ready to release the = new version of this draft and had a quick question about your one major = comment.

 

 

On Mar 29, 2011, at 9:21 AM, Muthu ArulMozhi Perumal (mperumal) = wrote:



Overall this draft looks to = be in a good shape.

 

I've one major comment. = Similar to REC #2 in section 7, it would be = desirable to have a recommendation that the middlebox present on the media path allow at least a nominal amount of traffic to be = exchanged between endpoints for a small duration of time (say, one RTT) after the middlebox receives a message from = theMIDCOM agent that indicates the media session being terminated. This will ensure that = any transit signaling packets on the media path exchanged during the session termination, like RTCP Bye packets, pass through the middle box.

 

 

I think I understand the intent of this recommendation and think it might = be useful to address specifically.  Where did you think this text = should be added ?

 

Regards,

 

Gonzalo

 

 

 

------_=_NextPart_001_01CCDEF8.6060D422-- From internet-drafts@ietf.org Sun Jan 29 23:16:51 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B39F21F8595; Sun, 29 Jan 2012 23:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFE0eGCiMPdi; Sun, 29 Jan 2012 23:16:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AAE21F84C3; Sun, 29 Jan 2012 23:16:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120130071634.32253.67245.idtracker@ietfa.amsl.com> Date: Sun, 29 Jan 2012 23:16:34 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 07:16:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Analysis of Middlebox Interactions for Signaling Protoco= l Communication along the Media Path Author(s) : Brian Stucker Hannes Tschofenig Gonzalo Salgueiro Filename : draft-ietf-mmusic-media-path-middleboxes-04.txt Pages : 22 Date : 2012-01-29 Middleboxes are defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as described in the MIDCOM architecture, then problems may occur in the transport of media traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult for the end points to detect or predict problematic behavior and to determine whether the media path is reliably available for packet exchange. This document aims to summarize the various sources and effects of NAT and firewall control, the reasons that they exist, and possible means of improving their behavior to allow protocols that rely upon signaling along the media path to operate effectively. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-path-middleboxe= s-04.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-ietf-mmusic-media-path-middleboxes= -04.txt From gsalguei@cisco.com Sun Jan 29 23:22:29 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F074021F8568 for ; Sun, 29 Jan 2012 23:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaYcidWgqaeV for ; Sun, 29 Jan 2012 23:22:29 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD2E21F855D for ; Sun, 29 Jan 2012 23:22:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0U7MR7A009491 for ; Mon, 30 Jan 2012 02:22:27 -0500 (EST) Received: from rtp-gsalguei-8714.cisco.com (rtp-gsalguei-8714.cisco.com [10.116.61.53]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0U7MR5g011952 for ; Mon, 30 Jan 2012 02:22:27 -0500 (EST) From: Gonzalo Salgueiro Content-Type: multipart/alternative; boundary=Apple-Mail-202--438887067 Date: Mon, 30 Jan 2012 02:22:27 -0500 Message-Id: To: mmusic Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [MMUSIC] draft-ietf-mmusic-media-path-middleboxes-04 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 07:22:30 -0000 --Apple-Mail-202--438887067 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks: Pursuant to the discussions we had on the list regarding the = completion of the middlebox interactions draft [1], I have released -04 = of the Middlebox Interactions draft. It is available in the archives = [2]. This version includes the comments of the reviewers assigned by the WG = chairs. More specifically the major changes in this version are: 1) Added an additional preliminary recommendation (REC #5); 2) Updated references; 3) Variety of minor edits, nits, and grammatical issues; The diff between -03 and -04 is available at [3]. [1] http://www.ietf.org/mail-archive/web/mmusic/current/msg08558.html [2] = http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-04 [3] = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-path-middlebo= xes-04.txt Consensus from the reviewers is that this "draft looks to be in a good = shape" and is "quite readable and useful". There was some discussion = around the possibility of changing the terminology from "SIP ALG" to = something like "SIP proxy" or "SIP user agent" or "SIP B2BUA". There = were various differing viewpoints and consensus was not reached. Thank you all for review comments and feedback. Regards, - Gonzalo= --Apple-Mail-202--438887067 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Folks: Pursuant to the = discussions we had on the list regarding the completion of the = middlebox interactions draft [1], I have released -04 of = the Middlebox Interactions draft. It is available in the = archives [2].

This version includes the comments of the reviewers = assigned by the WG chairs.

More specifically the major changes in = this version are:

 1) Added an additional preliminary = recommendation (REC #5);
 2) Updated references;
 3) = Variety of minor edits, nits, and grammatical issues;

The diff = between -03 and -04 is available at [3].

[1] http://www.ietf.org/mail-archive/web/mmusic/current/msg08558.html
= [2] http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-= 04
[3] http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic= -media-path-middleboxes-04.txt

Consensus from the reviewers = is that this "draft looks to be in a good shape" and is "quite = readable and useful". There was some discussion around the possibility = of changing the terminology from "SIP ALG" to something like "SIP = proxy" or "SIP user agent" or "SIP B2BUA". There were various = differing viewpoints and consensus was not reached.

Thank you all = for review comments and feedback.

Regards,

- = Gonzalo
= --Apple-Mail-202--438887067-- From christer.holmberg@ericsson.com Tue Jan 31 05:08:34 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3B621F848C for ; Tue, 31 Jan 2012 05:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.131 X-Spam-Level: X-Spam-Status: No, score=-9.131 tagged_above=-999 required=5 tests=[AWL=1.468, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOFolsTcYWLR for ; Tue, 31 Jan 2012 05:08:34 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AE92321F844E for ; Tue, 31 Jan 2012 05:08:33 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-70-4f27e7d0d648 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.69.02613.0D7E72F4; Tue, 31 Jan 2012 14:08:32 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 31 Jan 2012 14:08:31 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Date: Tue, 31 Jan 2012 14:08:31 +0100 Thread-Topic: Suggestion to moving ahead with BUNDLE Thread-Index: AQHM4BlkoRrWUt69ykuo5ZFipVGDNA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31B9B3@ESESSCMS0356.eemea.ericsson.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 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Suggestion to moving ahead with BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 13:08:34 -0000 Hi, At the Taipei IETF I presented the BUNDLE draft, written by myself and Hara= ld, which extends the SDP grouping framework in order to allow the usage of= identical port values in multiple m- lines in an SDP offer/answer. http://tools.ietf.org/id/draft-holmberg-mmusic-sdp-multiplex-negotiation-00= .txt It can be used when negotiating the usage of multiplexing of multiple media= streams. Such mechanism is very likely going to be needed e.g. in the work= being done in RTCWEB. When presented, some people indicated that they may want to look at other a= lternatives. However, as no alternative solutions have been brought forward since then, = my question is whether people now would be interested in moving ahead with = the BUNDLE mechanism, and adopt the above draft as a starting point? Best regards, Christer From ari.keranen@nomadiclab.com Tue Jan 31 08:23:26 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559D311E80CF for ; Tue, 31 Jan 2012 08:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTucoTDfS+5I for ; Tue, 31 Jan 2012 08:23:25 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA3411E80BE for ; Tue, 31 Jan 2012 08:23:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 61B144E6E9; Tue, 31 Jan 2012 18:23:24 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiEKGNhN902E; Tue, 31 Jan 2012 18:23:23 +0200 (EET) Received: from n102.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 63E914E679; Tue, 31 Jan 2012 18:23:23 +0200 (EET) Message-ID: <4F281577.4070204@nomadiclab.com> Date: Tue, 31 Jan 2012 18:23:19 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <4F191FE4.4010008@ericsson.com> In-Reply-To: <4F191FE4.4010008@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: Re: [MMUSIC] 4566bis and private IP addresses in the origin line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 16:23:26 -0000 Hi Miguel, On 1/20/12 10:03 AM, Miguel A. Garcia wrote: [...] > So, I guess RFC 5245 should have updated RFC 4566 at least in this > aspect. But since that wasn't done, and since we have 4566bis in the > pipe, I wonder if it is time to amend the quoted paragraph and change > the MUST NOT by a "SHOULD NOT", and explain that if you are using ICE, > as a mechanism to traverse NATs, then you can write private IP addresses > in the origin line. > > Comments? I think you are right and your proposal for fixing the issue is good. Although, later on RFC4566 does say "arbitrary and private MAY be chosen to populate the "o=" field [for privacy reasons]", so ICE is not technically violating RFC4566, but definitely it would make sense to be more clear with that in the bis version. By the way, one nit: 4566bis should also say in the abstract that it's obsoleting 4566. Cheers, Ari From trac+mmusic@trac.tools.ietf.org Tue Jan 31 09:44:55 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40AF11E80FF for ; Tue, 31 Jan 2012 09:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doeQBH0BPZIZ for ; Tue, 31 Jan 2012 09:44:55 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABD511E80EF for ; Tue, 31 Jan 2012 09:44:54 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RsHkg-0002Kr-3W; Tue, 31 Jan 2012 12:44:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 31 Jan 2012 17:44:17 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/4 Message-ID: <063.2b351d5217e1a7d41df6a2b9b08298a8@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120131174455.1ABD511E80EF@ietfa.amsl.com> Resent-Date: Tue, 31 Jan 2012 09:44:54 -0800 (PST) Resent-From: trac+mmusic@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 31 Jan 2012 11:33:01 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #4: #4: Multi-stream demultiplexing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:44:55 -0000 #4: #4: Multi-stream demultiplexing From Magnus: 22. Section 6. Media loopback, if a loopback source would send more than one stream how does the loopback mirror indicate which source is which in its return stream? SDES CNAME could be copied but would be confusing for anyone monitoring this stream as SSRCs from both end-points would appear to have the same CNAME. The ssrc-grouping could possibly be used, but I think one needs to consider the effect of that the SSRCs to be grouped are not on the same end-point. I don't even know if my SRCNAME proposal could deal with this case well. -- --------------------------+------------------------------------------------ Reporter: hkaplan@… | Owner: draft-ietf-mmusic-media-loopback@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: media- | Version: 1.0 loopback | Keywords: Severity: In WG Last | Call | --------------------------+------------------------------------------------ Ticket URL: mmusic From trac+mmusic@trac.tools.ietf.org Tue Jan 31 09:45:39 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DBB11E80EF for ; Tue, 31 Jan 2012 09:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olVUgjGRMDfe for ; Tue, 31 Jan 2012 09:45:38 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B04EC11E8080 for ; Tue, 31 Jan 2012 09:45:38 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RsHlu-0002Mt-CP; Tue, 31 Jan 2012 12:45:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 31 Jan 2012 17:45:34 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/5 Message-ID: <063.e1029da131b62c6b604af950aed417f9@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120131174538.B04EC11E8080@ietfa.amsl.com> Resent-Date: Tue, 31 Jan 2012 09:45:38 -0800 (PST) Resent-From: trac+mmusic@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 31 Jan 2012 11:33:01 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #5: #5: Marker bit handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:45:39 -0000 #5: #5: Marker bit handling From Magnus: 23. Section 7.1.1: Marker (M) bit: If the received RTP packet is looped back in multiple RTP packets, the M bit is set to 1 in the last packet, otherwise it is set to 0. I don't like this definition as it means that complete non fragment packets will have a m=0 the same as non last fragements. would it not be better to define it so that all packets have m=1 except non-last fragments. -- --------------------------+------------------------------------------------ Reporter: hkaplan@… | Owner: draft-ietf-mmusic-media-loopback@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: media- | Version: 1.0 loopback | Keywords: Severity: In WG Last | Call | --------------------------+------------------------------------------------ Ticket URL: mmusic From trac+mmusic@trac.tools.ietf.org Tue Jan 31 09:48:51 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4245F21F850C for ; Tue, 31 Jan 2012 09:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0PDdVxBKf9m for ; Tue, 31 Jan 2012 09:48:50 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 686F821F8503 for ; Tue, 31 Jan 2012 09:48:50 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RsHov-0004nd-9O; Tue, 31 Jan 2012 12:48:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 31 Jan 2012 17:48:41 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/6 Message-ID: <063.51ae082f90ef143996ba440744be8ed8@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120131174850.686F821F8503@ietfa.amsl.com> Resent-Date: Tue, 31 Jan 2012 09:48:50 -0800 (PST) Resent-From: trac+mmusic@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 31 Jan 2012 11:33:01 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #6: Clock-rate per payload type X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:48:51 -0000 #6: Clock-rate per payload type From Magnus: 24.section 7.1.1.: The RTP timestamp MUST use the same clock rate used by the loopback-source. I think this needs to be defined as the same clock rate used by the packet being encapsulated. Otherwise this becomes ambigous when the loopback source have payload types with multiple rates. -- --------------------------+------------------------------------------------ Reporter: hkaplan@… | Owner: draft-ietf-mmusic-media-loopback@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: media- | Version: 1.0 loopback | Keywords: Severity: In WG Last | Call | --------------------------+------------------------------------------------ Ticket URL: mmusic From trac+mmusic@trac.tools.ietf.org Tue Jan 31 09:50:29 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE25B11E8075 for ; Tue, 31 Jan 2012 09:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q9ovR9aYX7h for ; Tue, 31 Jan 2012 09:50:28 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 81F3021F8523 for ; Tue, 31 Jan 2012 09:50:15 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RsHqJ-0007AM-OO; Tue, 31 Jan 2012 12:50:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 31 Jan 2012 17:50:07 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/7 Message-ID: <063.de10303cc890e70e8d8a6c55265441d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120131175015.81F3021F8523@ietfa.amsl.com> Resent-Date: Tue, 31 Jan 2012 09:50:15 -0800 (PST) Resent-From: trac+mmusic@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 31 Jan 2012 11:33:01 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #7: Encapsulated packet format X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:50:29 -0000 #7: Encapsulated packet format From Magnus: 25. Section 7.1.2: Payload strucutre. I think it is unclear. Which of the following options do you really want. Outer RTP header (optional CSRC list or Header ext) Receive timestamp Inner RTP packet { - RTP header - (optional CSRC list or Header ext) - RTP payload } or Outer RTP header (optional CSRC list or Header ext) RTP Payload header { Receive timestamp Inner RTP packet header fields as specified in 7.1.2 } Inner RTP payload Note that the second doesn't echo back the extension header In general the text is not clear that the inner RTP payload should be included. -- --------------------------+------------------------------------------------ Reporter: hkaplan@… | Owner: draft-ietf-mmusic-media-loopback@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: media- | Version: 1.0 loopback | Keywords: Severity: In WG Last | Call | --------------------------+------------------------------------------------ Ticket URL: mmusic From trac+mmusic@trac.tools.ietf.org Tue Jan 31 09:52:02 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941A211E8080 for ; Tue, 31 Jan 2012 09:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPnyN9yGF+l2 for ; Tue, 31 Jan 2012 09:52:02 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1A13111E8074 for ; Tue, 31 Jan 2012 09:52:02 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RsHs4-0000SL-N9; Tue, 31 Jan 2012 12:51:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 31 Jan 2012 17:51:56 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/8 Message-ID: <063.36a21c8ae2201648ed1fc600bd2822b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120131175202.1A13111E8074@ietfa.amsl.com> Resent-Date: Tue, 31 Jan 2012 09:52:02 -0800 (PST) Resent-From: trac+mmusic@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 31 Jan 2012 11:33:01 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #8: Mirrored packet field overwriting X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:52:02 -0000 #8: Mirrored packet field overwriting From Magnus: 26. Section 7.1.2: You decide to overwrite the version field in the packet echoed back that is likely fine, however, why are you overwriting the P and X bits? Why not include the header extension in what is being echoed back so that mirror doesn't have to remove them in case they are present. -- --------------------------+------------------------------------------------ Reporter: hkaplan@… | Owner: draft-ietf-mmusic-media-loopback@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: media- | Version: 1.0 loopback | Keywords: Severity: In WG Last | Call | --------------------------+------------------------------------------------ Ticket URL: mmusic From trac+mmusic@trac.tools.ietf.org Tue Jan 31 09:54:43 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3CC21F85DB for ; Tue, 31 Jan 2012 09:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv4sF1uEEjZM for ; Tue, 31 Jan 2012 09:54:43 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2A09221F85D5 for ; Tue, 31 Jan 2012 09:54:43 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RsHuc-0000Wn-4g; Tue, 31 Jan 2012 12:54:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 31 Jan 2012 17:54:34 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/9 Message-ID: <063.44ff21944ceee55a80e50994a1d23be1@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120131175443.2A09221F85D5@ietfa.amsl.com> Resent-Date: Tue, 31 Jan 2012 09:54:43 -0800 (PST) Resent-From: trac+mmusic@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 31 Jan 2012 11:33:01 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #9: Header extensions in fragmented mirror packet X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:54:43 -0000 #9: Header extensions in fragmented mirror packet From Magnus: 27. Section 7.1.2: The fragmentation procedures are unclear. I guess you want the RTP header part to be duplicated with each fragment but that isn't clearly specified. But, will you include header extensions also in the repeat if you include them? -- --------------------------+------------------------------------------------ Reporter: hkaplan@… | Owner: draft-ietf-mmusic-media-loopback@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: media- | Version: 1.0 loopback | Keywords: Severity: In WG Last | Call | --------------------------+------------------------------------------------ Ticket URL: mmusic From trac+mmusic@trac.tools.ietf.org Tue Jan 31 10:00:28 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B0E21F8642 for ; Tue, 31 Jan 2012 10:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvYRT0-ywQz2 for ; Tue, 31 Jan 2012 10:00:27 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB7D21F8634 for ; Tue, 31 Jan 2012 10:00:27 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RsI03-0000hG-P1; Tue, 31 Jan 2012 13:00:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 31 Jan 2012 18:00:11 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/10 Message-ID: <063.07ba0297eaf42eaa2184d6af45879e65@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120131180027.9FB7D21F8634@ietfa.amsl.com> Resent-Date: Tue, 31 Jan 2012 10:00:27 -0800 (PST) Resent-From: trac+mmusic@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 31 Jan 2012 11:33:01 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #10: Source and mirror clock synchronization X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:00:28 -0000 #10: Source and mirror clock synchronization From Magnus: 28. Section 7.1.2: The Receive timestamp MUST be based on the same clock used by the loopback-source. This is an impossibility. The two end-points can't have the same clock. The can have a common clock reference like NTP. But, they are still not the same clocks, but possibly synchronized well enough for your needs What I guess you are after is that the clock rate should be the same as for the packet encapsulated. The Timestamp in the outer header should also be corrected. I also think you should clarify that the receive timestamp and the timestamp in the header needs to be from the same clock in the mirror. Otherwise the time spent on the mirror for the packet is not useful. I think it might also be worth actually writing up the measurements that become possible by these two timestamps plus having the source logg transmission and arrival times. The fact that one can derive both one way delay and jitter for each loopback packet is kind of important. However, to have correct one way delays the mirror clock needs to be synchronized with the source clock, or at least the current offset. -- --------------------------+------------------------------------------------ Reporter: hkaplan@… | Owner: draft-ietf-mmusic-media-loopback@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: media- | Version: 1.0 loopback | Keywords: Severity: In WG Last | Call | --------------------------+------------------------------------------------ Ticket URL: mmusic From trac+mmusic@trac.tools.ietf.org Tue Jan 31 10:03:58 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D115E21F864A for ; Tue, 31 Jan 2012 10:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrctOSySUCGa for ; Tue, 31 Jan 2012 10:03:58 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id BDA9321F8647 for ; Tue, 31 Jan 2012 10:03:49 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RsI3U-00070E-2e; Tue, 31 Jan 2012 13:03:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 31 Jan 2012 18:03:44 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/11 Message-ID: <063.4bd7c6dda0aff547eeb6d5483307c23f@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120131180349.BDA9321F8647@ietfa.amsl.com> Resent-Date: Tue, 31 Jan 2012 10:03:49 -0800 (PST) Resent-From: trac+mmusic@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 31 Jan 2012 11:33:01 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #11: Padding in mirrored packets X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:03:58 -0000 #11: Padding in mirrored packets From Magnus: 29. Section 7.1.2: "Any padding octets in the original packet MUST NOT be included in the loopback packet generated by a loopback-mirror." What is the motivation behind this? If the reason I want to do packet loopback is to find out if somebody is manipulating the packets between the source and the mirror you need to include the whole packet as it is, not throw away parts of it. What if padding is added or removed on path. That might matter for the one doing the active measurement. -- --------------------------+------------------------------------------------ Reporter: hkaplan@… | Owner: draft-ietf-mmusic-media-loopback@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: media- | Version: 1.0 loopback | Keywords: Severity: In WG Last | Call | --------------------------+------------------------------------------------ Ticket URL: mmusic From trac+mmusic@trac.tools.ietf.org Tue Jan 31 10:08:22 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE1C21F84E6 for ; Tue, 31 Jan 2012 10:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooIiNxTktzCs for ; Tue, 31 Jan 2012 10:08:21 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 31A2A21F84BF for ; Tue, 31 Jan 2012 10:08:21 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RsI7m-0007AX-F5; Tue, 31 Jan 2012 13:08:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 31 Jan 2012 18:08:10 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/12 Message-ID: <063.88288e22e77a8504c75e33201a2edc37@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120131180821.31A2A21F84BF@ietfa.amsl.com> Resent-Date: Tue, 31 Jan 2012 10:08:21 -0800 (PST) Resent-From: trac+mmusic@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 31 Jan 2012 11:33:01 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #12: MUST vs. SHOULD for mirror RTP seq number X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:08:22 -0000 #12: MUST vs. SHOULD for mirror RTP seq number From Magnus: 30. Section 7.2.1: Sequence Number: The RTP sequence number SHOULD be generated by the loopback-mirror in the usual manner with a constant random offset. What is the acceptable cases for when to break it? I assume the intention with not saying MUST is that one can copy it from the incomming packet. Thus when source -> mirror packet losses occur causing wholes in the return path which isn't real loss on the mirror->source path. It also causes third party monitor to report losses that aren't real on this stream. -- --------------------------+------------------------------------------------ Reporter: hkaplan@… | Owner: draft-ietf-mmusic-media-loopback@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: media- | Version: 1.0 loopback | Keywords: Severity: In WG Last | Call | --------------------------+------------------------------------------------ Ticket URL: mmusic