From dean.willis@softarmor.com Mon Apr 2 10:02:44 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E42C21F8598 for ; Mon, 2 Apr 2012 10:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ur-mWR4Gbowv for ; Mon, 2 Apr 2012 10:02:43 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4247521F8549 for ; Mon, 2 Apr 2012 10:02:43 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1479149yhk.31 for ; Mon, 02 Apr 2012 10:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; bh=3gvOXP25dLKt49bZp6BF7FuPRntZh0M9SAVdRmeirIs=; b=Ff3Ab85CfSvoPDmTlMXxZEKHRvdAglgcelQYViizmExj0I4rcpr8Ek3BPKvrafymFn SU+Oyco0Cf/T8LRiBPSbwByfhOzDx/oFdVrZNWhfEqxbf+mmshaacl10IVqJlWcvg12e d19L7YUSzuHqqhgRwV6v7TAPl/cTfZ+BuDRdA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer :x-gm-message-state; bh=3gvOXP25dLKt49bZp6BF7FuPRntZh0M9SAVdRmeirIs=; b=l6x9oLqLgZAgSVPZRke7PJdlj8Qwa8riysDm6V+C4R69i7j+UGt7MQ1+SYkD0YQsSA Xuok32m3jmInMIvcISNNLMiVPjCHjQ4B3Jpkf4vNbb90jafWTE7jhCScITSFjtJH0xDO iurZcLEDFouz4xe/qd4arLRDEAsEkbRUpnbf/eiRv2DXRXOXxbJUHdN5aHC0FpoMgegN ikrU7DxUrt9wtxJ5xyTrdHSPv2wl9A2RbUt9Zx41D98cKD0QlxHR7iQJZ5xi5Ip6Wq5q f135khV5/3Uqac3lAv9L1zc6Sdv9mW1S0mR8VXoMhaIyNrorFoMjXT+aE9q0ju2jS5/6 BtYg== Received: by 10.60.24.201 with SMTP id w9mr2263543oef.49.1333386162778; Mon, 02 Apr 2012 10:02:42 -0700 (PDT) Received: from [192.168.2.124] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id k7sm14577894oei.0.2012.04.02.10.02.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 10:02:42 -0700 (PDT) References: <4F646ACC.6030905@ericsson.com>, <4F64F466.90908@alum.mit.edu> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Mon, 2 Apr 2012 12:02:40 -0500 To: Nancy Greene X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQki78ODUfeIK1yB3vlu5owN5tHJ2Bz0W/eFeXMiGN+d1SumvP5yFdV2OLWb6hm2wuGh87od Cc: "rai@ietf.org" Subject: Re: [RAI] Review of 6 new SIP header fields defined by OMA X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:02:44 -0000 On Mar 19, 2012, at 8:20 PM, Nancy Greene wrote: > Hi, here is some more information on these headers and why the = suggested alternatives were not used: >=20 >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] > ... >> OMA Header Possible Alternative >> -------------------------- ------------------------------------- >> Conversation-ID Message-ID of 1st message > There was a requirement in the OMA CPM work for more than just = messages to be grouped together. It was meant to also cover file = transfers and chat sessions, for example. So any standalone message, = chat session or file transfer that was all related to the same = "conversation" would have the same conversation-id. >=20 >> Contribution-ID Message-ID > Again, it has to apply to more than messages - it has to apply to chat = sessions and file transfers too. >=20 >>=20 So the same Conversation-ID and Contribution-ID can occur in multiple = INVITE-initiated dialogs? In other words, they identify logical = sequences of communications that span more than one call? This would = clearly differentiate them from Call-ID. If it hasn't already been done, you may wish to have OMA consider US = patent 7,983,240 within the OMA IPR context. You might also want to = consider US patent application 11/646,982. -- Dean= From fluffy@cisco.com Mon Apr 23 10:29:07 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A4B21F8796 for ; Mon, 23 Apr 2012 10:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.265 X-Spam-Level: X-Spam-Status: No, score=-110.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 UYvqs0T0wO4E for ; Mon, 23 Apr 2012 10:29:06 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1C921F8792 for ; Mon, 23 Apr 2012 10:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2357; q=dns/txt; s=iport; t=1335202145; x=1336411745; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=GdTV474zR9rZR/k0ThSWYdPvzfZOWnhP0SQFGH4oZzM=; b=JiNKeZgELH2YIj2xkdJ0lLRUEc4C4cj+O4ZY82c9CcjQr2YC46sV5aOq teob1tdH8aeq+1lw6FtnBNH9iih1QaI3nHkgBO5zaBE+6+p5VUlpKuWMa D3LuhQDaZ4hcozxLh2KVVSZIYxMbpsxbP5heLNIj5varYninQ4kmKZ8kU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAISQlU+rRDoG/2dsb2JhbABEsVGBB4IJAQEBAwEBAQEPASc0EAsLRicwGSKHaAQMmkegIIlohEKCQmMEiGONF4ERjUSBaYMJgTw X-IronPort-AV: E=Sophos;i="4.75,467,1330905600"; d="scan'208";a="41802191" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 23 Apr 2012 17:29:04 +0000 Received: from sjc-vpn7-1727.cisco.com (sjc-vpn7-1727.cisco.com [10.21.150.191]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3NHSXV4018821 for ; Mon, 23 Apr 2012 17:29:04 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Cullen Jennings In-Reply-To: <4F4CB861.4090805@ericsson.com> Date: Mon, 23 Apr 2012 07:53:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <61A262A2-2538-406B-8A08-AA0414D021B5@cisco.com> References: <4F4CB861.4090805@ericsson.com> To: rai@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [RAI] How to exchange metadata about the media streams established with a SIP session X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:29:07 -0000 worth nothing the RTCweb folks also want to exchange metadata to do with = labeling streams. I always find just classifying it as "metadata" sort = of makes it hard to decide what to do with it. I'd prefer the groups to = specifically outline what data they need to exchange and then I think it = becomes clearer the best way to exchange the different types of = information. Knowing if the information changes per RTP packet, or only = one when the session is set up helps. On Feb 28, 2012, at 3:20 , Gonzalo Camarillo wrote: > Folks, >=20 > I am sending this email to the RAI list because it is about an > architectural issue that affects more than one WG. >=20 > Both the CLUE and SIPREC WGs have identified the need to exchange > metadata about media streams that have been established using SIP. = Both > groups need to transport such metadata between SIP UAs. >=20 > In CLUE, they are studying how to transport their metadata, as > documented in: > http://tools.ietf.org/html/draft-wenger-clue-transport-01 >=20 > In SIPREC, they are planning to piggyback the metadata in SIP UPDATEs = as > an XML-encoded body part. When they need to send a request for full > state (as opposed to partial state), they use an UPDATE request with a > particular body type, as documented in: > http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 >=20 > The best way to exchange metadata within a SIP session depends on the > type of metadata and on how the UAs need to interact with each other > (e.g., a UA simply pushing information to the other UA or a more > complicated protocol). Given that SIPREC and CLUE have different > metadata and interactions, it may well be that we decide to use a > different mechanism in each group. Nevertheless, I think both groups > would benefit from architecturally-inclined RAI people having a look = at > their work. Please, continue this discussion focusing on their = specific > requirements on either the CLUE list or the SIPREC list. >=20 > Somewhat related to this issue, the RTCWeb group discussed the use of > SCTP over UDP as a reliable NAT-friendly way to exchange data between > endpoints. >=20 > Cheers, >=20 > Gonzalo >=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From pkyzivat@alum.mit.edu Mon Apr 23 12:22:46 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A82E21F85D3 for ; Mon, 23 Apr 2012 12:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 0PMFvGCH0TvF for ; Mon, 23 Apr 2012 12:22:45 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 725A521F85A2 for ; Mon, 23 Apr 2012 12:22:45 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta14.westchester.pa.mail.comcast.net with comcast id 1XAj1j0080xGWP85EXNmL2; Mon, 23 Apr 2012 19:22:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta12.westchester.pa.mail.comcast.net with comcast id 1XNk1j00v07duvL3YXNkf9; Mon, 23 Apr 2012 19:22:44 +0000 Message-ID: <4F95AC03.1020706@alum.mit.edu> Date: Mon, 23 Apr 2012 15:22:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: rai@ietf.org References: <4F4CB861.4090805@ericsson.com> <61A262A2-2538-406B-8A08-AA0414D021B5@cisco.com> In-Reply-To: <61A262A2-2538-406B-8A08-AA0414D021B5@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [RAI] How to exchange metadata about the media streams established with a SIP session X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:22:46 -0000 On 4/23/12 10:53 AM, Cullen Jennings wrote: > > worth nothing the RTCweb folks also want to exchange metadata to do with labeling streams. I always find just classifying it as "metadata" sort of makes it hard to decide what to do with it. I'd prefer the groups to specifically outline what data they need to exchange and then I think it becomes clearer the best way to exchange the different types of information. Knowing if the information changes per RTP packet, or only one when the session is set up helps. Cullen, I agree that just talking about "metadata" isn't especially helpful. OTOH, getting too far into the weeds about the specifics of the metadata makes it hard for people with differing contexts to talk with one another and find commonalities. In CLUE we realize that not all of our metadata can be treated the same way. There are varying degrees of real-time-ed-ness to deal with. We definitely have some stuff that changes at the signaling rate or less, and some that changes at the media rate, and some stuff that that falls in between. We also have issues that some of the stuff is too big to reasonably transmit in sip signaling, which we are considering a separate "data stream" for. We do think that CLUE should be able to work with RTCWEB based endpoints. So its possible that the RTCWEB data stream mechanism might work for us. But we will need to have it even with non-rtcweb-endpoints. In SIPREC, we have a lot of descriptive stuff, mostly about signaling. The rate is tied to the signaling rate, but possibly about multiple calls and hence higher in aggregate. We decided that sending in the sip signaling was appropriate for this stuff, though the size of the data precludes doing so over UDP. For this app we decided we could just require TCP transport for the sip signaling of the recording session. (It doesn't constrain the transport for the calls being recorded.) This could be a problem in some topologies, but seems acceptable for the application. If there had been a mechanism that for a separate "data stream" that we could have reused we *might* have found that an attractive direction. ISTM that it would be helpful to have a "brainstorming session" with some reps from rtcweb, clue, siprec, bfcp, and mediactrl to see whether we can find some common machinery that could support multiples of these cases. I'm thinking that the sctp over udp stack being worked on for rtcweb might be more broadly applicable, both as a data stream transport negotiated with o/a, and maybe as a new sip transport as well. Thanks, Paul > On Feb 28, 2012, at 3:20 , Gonzalo Camarillo wrote: > >> Folks, >> >> I am sending this email to the RAI list because it is about an >> architectural issue that affects more than one WG. >> >> Both the CLUE and SIPREC WGs have identified the need to exchange >> metadata about media streams that have been established using SIP. Both >> groups need to transport such metadata between SIP UAs. >> >> In CLUE, they are studying how to transport their metadata, as >> documented in: >> http://tools.ietf.org/html/draft-wenger-clue-transport-01 >> >> In SIPREC, they are planning to piggyback the metadata in SIP UPDATEs as >> an XML-encoded body part. When they need to send a request for full >> state (as opposed to partial state), they use an UPDATE request with a >> particular body type, as documented in: >> http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 >> >> The best way to exchange metadata within a SIP session depends on the >> type of metadata and on how the UAs need to interact with each other >> (e.g., a UA simply pushing information to the other UA or a more >> complicated protocol). Given that SIPREC and CLUE have different >> metadata and interactions, it may well be that we decide to use a >> different mechanism in each group. Nevertheless, I think both groups >> would benefit from architecturally-inclined RAI people having a look at >> their work. Please, continue this discussion focusing on their specific >> requirements on either the CLUE list or the SIPREC list. >> >> Somewhat related to this issue, the RTCWeb group discussed the use of >> SCTP over UDP as a reliable NAT-friendly way to exchange data between >> endpoints. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai > From andrew.hutton@siemens-enterprise.com Tue Apr 24 01:35:29 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943CF21F8715 for ; Tue, 24 Apr 2012 01:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 JQfXwVIN963N for ; Tue, 24 Apr 2012 01:35:28 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id F28CA21F8714 for ; Tue, 24 Apr 2012 01:35:26 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 731411EB8491; Tue, 24 Apr 2012 10:35:25 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 24 Apr 2012 10:35:25 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "rai@ietf.org" Date: Tue, 24 Apr 2012 10:35:24 +0200 Thread-Topic: [RAI] How to exchange metadata about the media streams established with a SIP session Thread-Index: Ac0hhnvNQcknHW61Rduwt/MAwoM88wAaZzNg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3129917F608@MCHP058A.global-ad.net> References: <4F4CB861.4090805@ericsson.com> <61A262A2-2538-406B-8A08-AA0414D021B5@cisco.com> <4F95AC03.1020706@alum.mit.edu> In-Reply-To: <4F95AC03.1020706@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [RAI] How to exchange metadata about the media streams established with a SIP session X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 08:35:29 -0000 Hi, Whilst I of course agree that it is a good idea to look for a common soluti= on if at all possible it is important to keep in mind the charter of the va= rious working groups and the environment which the solutions will operate. Both the SIPREC and CLUE working groups are chartered to produce SIP based = solutions which is possibly open to some different interpretations but it d= oes impose some constraints on the solution. In the SIPREC case we therefor= e defined a SIP body based mechanism for metadata and stated that other mec= hanism although possible were out of scope I have no problem with looking a= t other mechanisms and would participate in any brainstorming session but I= don't think we should change track regarding the current SIPREC mechanism = especially since there are quite a few implementations already. Regards Andy > -----Original Message----- > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 23 April 2012 20:23 > To: rai@ietf.org > Subject: Re: [RAI] How to exchange metadata about the media streams > established with a SIP session >=20 > On 4/23/12 10:53 AM, Cullen Jennings wrote: > > > > worth nothing the RTCweb folks also want to exchange metadata to do > with labeling streams. I always find just classifying it as "metadata" > sort of makes it hard to decide what to do with it. I'd prefer the > groups to specifically outline what data they need to exchange and then > I think it becomes clearer the best way to exchange the different types > of information. Knowing if the information changes per RTP packet, or > only one when the session is set up helps. >=20 > Cullen, >=20 > I agree that just talking about "metadata" isn't especially helpful. > OTOH, getting too far into the weeds about the specifics of the > metadata > makes it hard for people with differing contexts to talk with one > another and find commonalities. >=20 > In CLUE we realize that not all of our metadata can be treated the same > way. There are varying degrees of real-time-ed-ness to deal with. We > definitely have some stuff that changes at the signaling rate or less, > and some that changes at the media rate, and some stuff that that falls > in between. We also have issues that some of the stuff is too big to > reasonably transmit in sip signaling, which we are considering a > separate "data stream" for. We do think that CLUE should be able to > work > with RTCWEB based endpoints. So its possible that the RTCWEB data > stream > mechanism might work for us. But we will need to have it even with > non-rtcweb-endpoints. >=20 > In SIPREC, we have a lot of descriptive stuff, mostly about signaling. > The rate is tied to the signaling rate, but possibly about multiple > calls and hence higher in aggregate. We decided that sending in the sip > signaling was appropriate for this stuff, though the size of the data > precludes doing so over UDP. For this app we decided we could just > require TCP transport for the sip signaling of the recording session. > (It doesn't constrain the transport for the calls being recorded.) This > could be a problem in some topologies, but seems acceptable for the > application. If there had been a mechanism that for a separate "data > stream" that we could have reused we *might* have found that an > attractive direction. >=20 > ISTM that it would be helpful to have a "brainstorming session" with > some reps from rtcweb, clue, siprec, bfcp, and mediactrl to see whether > we can find some common machinery that could support multiples of these > cases. I'm thinking that the sctp over udp stack being worked on for > rtcweb might be more broadly applicable, both as a data stream > transport > negotiated with o/a, and maybe as a new sip transport as well. >=20 > Thanks, > Paul >=20 > > On Feb 28, 2012, at 3:20 , Gonzalo Camarillo wrote: > > > >> Folks, > >> > >> I am sending this email to the RAI list because it is about an > >> architectural issue that affects more than one WG. > >> > >> Both the CLUE and SIPREC WGs have identified the need to exchange > >> metadata about media streams that have been established using SIP. > Both > >> groups need to transport such metadata between SIP UAs. > >> > >> In CLUE, they are studying how to transport their metadata, as > >> documented in: > >> http://tools.ietf.org/html/draft-wenger-clue-transport-01 > >> > >> In SIPREC, they are planning to piggyback the metadata in SIP > UPDATEs as > >> an XML-encoded body part. When they need to send a request for full > >> state (as opposed to partial state), they use an UPDATE request with > a > >> particular body type, as documented in: > >> http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 > >> > >> The best way to exchange metadata within a SIP session depends on > the > >> type of metadata and on how the UAs need to interact with each other > >> (e.g., a UA simply pushing information to the other UA or a more > >> complicated protocol). Given that SIPREC and CLUE have different > >> metadata and interactions, it may well be that we decide to use a > >> different mechanism in each group. Nevertheless, I think both groups > >> would benefit from architecturally-inclined RAI people having a look > at > >> their work. Please, continue this discussion focusing on their > specific > >> requirements on either the CLUE list or the SIPREC list. > >> > >> Somewhat related to this issue, the RTCWeb group discussed the use > of > >> SCTP over UDP as a reliable NAT-friendly way to exchange data > between > >> endpoints. > >> > >> Cheers, > >> > >> Gonzalo > >> > >> _______________________________________________ > >> RAI mailing list > >> RAI@ietf.org > >> https://www.ietf.org/mailman/listinfo/rai > > > > _______________________________________________ > > RAI mailing list > > RAI@ietf.org > > https://www.ietf.org/mailman/listinfo/rai > > >=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From pravindran@sonusnet.com Tue Apr 24 02:34:40 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5706621F8751 for ; Tue, 24 Apr 2012 02:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 v1Fhg5bd9bUk for ; Tue, 24 Apr 2012 02:34:39 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id B355C21F86A2 for ; Tue, 24 Apr 2012 02:34:38 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKT5Zzrvbc6vzToJqlQ/zNynicOMX6pGZ9@postini.com; Tue, 24 Apr 2012 02:34:38 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 24 Apr 2012 05:34:38 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 15:04:32 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , Paul Kyzivat , "rai@ietf.org" Thread-Topic: [RAI] How to exchange metadata about the media streams established with a SIP session Thread-Index: AQHNIYZ6YIVMz/h1yUC22aEQ7zGiuZapSyIAgABlU8A= Date: Tue, 24 Apr 2012 09:34:31 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E237FE9@inba-mail01.sonusnet.com> References: <4F4CB861.4090805@ericsson.com> <61A262A2-2538-406B-8A08-AA0414D021B5@cisco.com> <4F95AC03.1020706@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E3129917F608@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E3129917F608@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [RAI] How to exchange metadata about the media streams established with a SIP session X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 09:34:40 -0000 I agree with Andy as defining the metadata for SIPREC itself took=20 nearly 2 years by now, slowly folks understand SIPREC metadata model=20 and now we are discussing about SIPREC XML usage with individual=20 implementation. In case we are aiming at come up with the common metadata model=20 for RTCWeb and SIPREC, then it takes ages as recording=20 is outside the scope of RTCWeb 1.0 usecases and XML vs. JSON will be just a debate. I understand the importance of CLUE signaling metadata & SIPREC=20 metadata to have commonality in the usage as both are based on SIP and also SIPREC RTP usage with CLUE media & media-signaling metadata as=20 some of the telepresence entities may wish to record telepresence=20 session using SIPREC mechanism. I guess that it will be better to forward=20 SIPREC metadata draft, SIPREC RTP usage draft to CLUE folks to =20 understand any CLUE specific attributes has to be added. But I'm not sure=20 whether CLUE is in the state to provide those inputs at this moment. Also, SIPREC may not require SCTP over UDP transport as most of the=20 deployed recording is based on UDP or TCP transport and there is no real recording requirement to change SIP transport. =20 Thanks Partha =20 >-----Original Message----- >From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of >Hutton, Andrew >Sent: Tuesday, April 24, 2012 2:05 PM >To: Paul Kyzivat; rai@ietf.org >Subject: Re: [RAI] How to exchange metadata about the media streams >established with a SIP session > >Hi, > >Whilst I of course agree that it is a good idea to look for a common >solution if at all possible it is important to keep in mind the charter >of the various working groups and the environment which the solutions >will operate. > >Both the SIPREC and CLUE working groups are chartered to produce SIP >based solutions which is possibly open to some different interpretations >but it does impose some constraints on the solution. In the SIPREC case >we therefore defined a SIP body based mechanism for metadata and stated >that other mechanism although possible were out of scope I have no >problem with looking at other mechanisms and would participate in any >brainstorming session but I don't think we should change track regarding >the current SIPREC mechanism especially since there are quite a few >implementations already. > >Regards >Andy > > > > >> -----Original Message----- >> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: 23 April 2012 20:23 >> To: rai@ietf.org >> Subject: Re: [RAI] How to exchange metadata about the media streams >> established with a SIP session >> >> On 4/23/12 10:53 AM, Cullen Jennings wrote: >> > >> > worth nothing the RTCweb folks also want to exchange metadata to do >> with labeling streams. I always find just classifying it as "metadata" >> sort of makes it hard to decide what to do with it. I'd prefer the >> groups to specifically outline what data they need to exchange and >> then I think it becomes clearer the best way to exchange the different >> types of information. Knowing if the information changes per RTP >> packet, or only one when the session is set up helps. >> >> Cullen, >> >> I agree that just talking about "metadata" isn't especially helpful. >> OTOH, getting too far into the weeds about the specifics of the >> metadata makes it hard for people with differing contexts to talk with >> one another and find commonalities. >> >> In CLUE we realize that not all of our metadata can be treated the >> same way. There are varying degrees of real-time-ed-ness to deal with. >> We definitely have some stuff that changes at the signaling rate or >> less, and some that changes at the media rate, and some stuff that >> that falls in between. We also have issues that some of the stuff is >> too big to reasonably transmit in sip signaling, which we are >> considering a separate "data stream" for. We do think that CLUE should >> be able to work with RTCWEB based endpoints. So its possible that the >> RTCWEB data stream mechanism might work for us. But we will need to >> have it even with non-rtcweb-endpoints. >> >> In SIPREC, we have a lot of descriptive stuff, mostly about signaling. >> The rate is tied to the signaling rate, but possibly about multiple >> calls and hence higher in aggregate. We decided that sending in the >> sip signaling was appropriate for this stuff, though the size of the >> data precludes doing so over UDP. For this app we decided we could >> just require TCP transport for the sip signaling of the recording >session. >> (It doesn't constrain the transport for the calls being recorded.) >> This could be a problem in some topologies, but seems acceptable for >> the application. If there had been a mechanism that for a separate >> "data stream" that we could have reused we *might* have found that an >> attractive direction. >> >> ISTM that it would be helpful to have a "brainstorming session" with >> some reps from rtcweb, clue, siprec, bfcp, and mediactrl to see >> whether we can find some common machinery that could support multiples >> of these cases. I'm thinking that the sctp over udp stack being worked >> on for rtcweb might be more broadly applicable, both as a data stream >> transport negotiated with o/a, and maybe as a new sip transport as >> well. >> >> Thanks, >> Paul >> >> > On Feb 28, 2012, at 3:20 , Gonzalo Camarillo wrote: >> > >> >> Folks, >> >> >> >> I am sending this email to the RAI list because it is about an >> >> architectural issue that affects more than one WG. >> >> >> >> Both the CLUE and SIPREC WGs have identified the need to exchange >> >> metadata about media streams that have been established using SIP. >> Both >> >> groups need to transport such metadata between SIP UAs. >> >> >> >> In CLUE, they are studying how to transport their metadata, as >> >> documented in: >> >> http://tools.ietf.org/html/draft-wenger-clue-transport-01 >> >> >> >> In SIPREC, they are planning to piggyback the metadata in SIP >> UPDATEs as >> >> an XML-encoded body part. When they need to send a request for full >> >> state (as opposed to partial state), they use an UPDATE request >> >> with >> a >> >> particular body type, as documented in: >> >> http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 >> >> >> >> The best way to exchange metadata within a SIP session depends on >> the >> >> type of metadata and on how the UAs need to interact with each >> >> other (e.g., a UA simply pushing information to the other UA or a >> >> more complicated protocol). Given that SIPREC and CLUE have >> >> different metadata and interactions, it may well be that we decide >> >> to use a different mechanism in each group. Nevertheless, I think >> >> both groups would benefit from architecturally-inclined RAI people >> >> having a look >> at >> >> their work. Please, continue this discussion focusing on their >> specific >> >> requirements on either the CLUE list or the SIPREC list. >> >> >> >> Somewhat related to this issue, the RTCWeb group discussed the use >> of >> >> SCTP over UDP as a reliable NAT-friendly way to exchange data >> between >> >> endpoints. >> >> >> >> Cheers, >> >> >> >> Gonzalo >> >> >> >> _______________________________________________ >> >> RAI mailing list >> >> RAI@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rai >> > >> > _______________________________________________ >> > RAI mailing list >> > RAI@ietf.org >> > https://www.ietf.org/mailman/listinfo/rai >> > >> >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai >_______________________________________________ >RAI mailing list >RAI@ietf.org >https://www.ietf.org/mailman/listinfo/rai From pkyzivat@alum.mit.edu Tue Apr 24 06:36:01 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6428E21F85A4 for ; Tue, 24 Apr 2012 06:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 xNNdCazJ6gAG for ; Tue, 24 Apr 2012 06:36:00 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 628F021F85A2 for ; Tue, 24 Apr 2012 06:36:00 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id 1pbh1j0041GhbT853pc1lG; Tue, 24 Apr 2012 13:36:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id 1pc21j00H07duvL3Tpc2xh; Tue, 24 Apr 2012 13:36:02 +0000 Message-ID: <4F96AC3E.7090700@alum.mit.edu> Date: Tue, 24 Apr 2012 09:35:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Hutton, Andrew" References: <4F4CB861.4090805@ericsson.com> <61A262A2-2538-406B-8A08-AA0414D021B5@cisco.com> <4F95AC03.1020706@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E3129917F608@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E3129917F608@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rai@ietf.org" Subject: Re: [RAI] How to exchange metadata about the media streams established with a SIP session X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 13:36:01 -0000 On 4/24/12 4:35 AM, Hutton, Andrew wrote: > Hi, > > Whilst I of course agree that it is a good idea to look for a common solution if at all possible it is important to keep in mind the charter of the various working groups and the environment which the solutions will operate. > > Both the SIPREC and CLUE working groups are chartered to produce SIP based solutions which is possibly open to some different interpretations but it does impose some constraints on the solution. In the SIPREC case we therefore defined a SIP body based mechanism for metadata and stated that other mechanism although possible were out of scope I have no problem with looking at other mechanisms and would participate in any brainstorming session but I don't think we should change track regarding the current SIPREC mechanism especially since there are quite a few implementations already. Andy, I don't see how anything that might be done about a general mechanism now would affect the output of SIPREC under its current charter. We are simply too far down the road for that. *Conceivably* some general mechanism might eventually become a candidate for some future evolution/revision to siprec, but I wouldn't hold my breath for that to happen. I see info about SIPREC as simply providing some perspective about the kinds of things a general mechanism might help with. Thanks, Paul > Regards > Andy > > > > >> -----Original Message----- >> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: 23 April 2012 20:23 >> To: rai@ietf.org >> Subject: Re: [RAI] How to exchange metadata about the media streams >> established with a SIP session >> >> On 4/23/12 10:53 AM, Cullen Jennings wrote: >>> >>> worth nothing the RTCweb folks also want to exchange metadata to do >> with labeling streams. I always find just classifying it as "metadata" >> sort of makes it hard to decide what to do with it. I'd prefer the >> groups to specifically outline what data they need to exchange and then >> I think it becomes clearer the best way to exchange the different types >> of information. Knowing if the information changes per RTP packet, or >> only one when the session is set up helps. >> >> Cullen, >> >> I agree that just talking about "metadata" isn't especially helpful. >> OTOH, getting too far into the weeds about the specifics of the >> metadata >> makes it hard for people with differing contexts to talk with one >> another and find commonalities. >> >> In CLUE we realize that not all of our metadata can be treated the same >> way. There are varying degrees of real-time-ed-ness to deal with. We >> definitely have some stuff that changes at the signaling rate or less, >> and some that changes at the media rate, and some stuff that that falls >> in between. We also have issues that some of the stuff is too big to >> reasonably transmit in sip signaling, which we are considering a >> separate "data stream" for. We do think that CLUE should be able to >> work >> with RTCWEB based endpoints. So its possible that the RTCWEB data >> stream >> mechanism might work for us. But we will need to have it even with >> non-rtcweb-endpoints. >> >> In SIPREC, we have a lot of descriptive stuff, mostly about signaling. >> The rate is tied to the signaling rate, but possibly about multiple >> calls and hence higher in aggregate. We decided that sending in the sip >> signaling was appropriate for this stuff, though the size of the data >> precludes doing so over UDP. For this app we decided we could just >> require TCP transport for the sip signaling of the recording session. >> (It doesn't constrain the transport for the calls being recorded.) This >> could be a problem in some topologies, but seems acceptable for the >> application. If there had been a mechanism that for a separate "data >> stream" that we could have reused we *might* have found that an >> attractive direction. >> >> ISTM that it would be helpful to have a "brainstorming session" with >> some reps from rtcweb, clue, siprec, bfcp, and mediactrl to see whether >> we can find some common machinery that could support multiples of these >> cases. I'm thinking that the sctp over udp stack being worked on for >> rtcweb might be more broadly applicable, both as a data stream >> transport >> negotiated with o/a, and maybe as a new sip transport as well. >> >> Thanks, >> Paul >> >>> On Feb 28, 2012, at 3:20 , Gonzalo Camarillo wrote: >>> >>>> Folks, >>>> >>>> I am sending this email to the RAI list because it is about an >>>> architectural issue that affects more than one WG. >>>> >>>> Both the CLUE and SIPREC WGs have identified the need to exchange >>>> metadata about media streams that have been established using SIP. >> Both >>>> groups need to transport such metadata between SIP UAs. >>>> >>>> In CLUE, they are studying how to transport their metadata, as >>>> documented in: >>>> http://tools.ietf.org/html/draft-wenger-clue-transport-01 >>>> >>>> In SIPREC, they are planning to piggyback the metadata in SIP >> UPDATEs as >>>> an XML-encoded body part. When they need to send a request for full >>>> state (as opposed to partial state), they use an UPDATE request with >> a >>>> particular body type, as documented in: >>>> http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 >>>> >>>> The best way to exchange metadata within a SIP session depends on >> the >>>> type of metadata and on how the UAs need to interact with each other >>>> (e.g., a UA simply pushing information to the other UA or a more >>>> complicated protocol). Given that SIPREC and CLUE have different >>>> metadata and interactions, it may well be that we decide to use a >>>> different mechanism in each group. Nevertheless, I think both groups >>>> would benefit from architecturally-inclined RAI people having a look >> at >>>> their work. Please, continue this discussion focusing on their >> specific >>>> requirements on either the CLUE list or the SIPREC list. >>>> >>>> Somewhat related to this issue, the RTCWeb group discussed the use >> of >>>> SCTP over UDP as a reliable NAT-friendly way to exchange data >> between >>>> endpoints. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> _______________________________________________ >>>> RAI mailing list >>>> RAI@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rai >>> >>> _______________________________________________ >>> RAI mailing list >>> RAI@ietf.org >>> https://www.ietf.org/mailman/listinfo/rai >>> >> >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai > From andrew.hutton@siemens-enterprise.com Tue Apr 24 08:57:11 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FF121F86FD for ; Tue, 24 Apr 2012 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LmXBr7cnPZL for ; Tue, 24 Apr 2012 08:57:10 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5969321F8671 for ; Tue, 24 Apr 2012 08:57:10 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 690AC1EB84BB; Tue, 24 Apr 2012 17:57:09 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 24 Apr 2012 17:57:09 +0200 From: "Hutton, Andrew" To: Paul Kyzivat Date: Tue, 24 Apr 2012 17:57:07 +0200 Thread-Topic: [RAI] How to exchange metadata about the media streams established with a SIP session Thread-Index: Ac0iHzB8xWElrVJiSWOKkVNVwJmMiAAE6qeA Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3129917FA51@MCHP058A.global-ad.net> References: <4F4CB861.4090805@ericsson.com> <61A262A2-2538-406B-8A08-AA0414D021B5@cisco.com> <4F95AC03.1020706@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E3129917F608@MCHP058A.global-ad.net> <4F96AC3E.7090700@alum.mit.edu> In-Reply-To: <4F96AC3E.7090700@alum.mit.edu> 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 Cc: "rai@ietf.org" Subject: Re: [RAI] How to exchange metadata about the media streams established with a SIP session X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 15:57:11 -0000 Hi Paul, I think we are in sync. Regards Andy > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 24 April 2012 15:36 > To: Hutton, Andrew > Cc: rai@ietf.org > Subject: Re: [RAI] How to exchange metadata about the media streams > established with a SIP session >=20 > On 4/24/12 4:35 AM, Hutton, Andrew wrote: > > Hi, > > > > Whilst I of course agree that it is a good idea to look for a common > solution if at all possible it is important to keep in mind the charter > of the various working groups and the environment which the solutions > will operate. > > > > Both the SIPREC and CLUE working groups are chartered to produce SIP > based solutions which is possibly open to some different > interpretations but it does impose some constraints on the solution. In > the SIPREC case we therefore defined a SIP body based mechanism for > metadata and stated that other mechanism although possible were out of > scope I have no problem with looking at other mechanisms and would > participate in any brainstorming session but I don't think we should > change track regarding the current SIPREC mechanism especially since > there are quite a few implementations already. >=20 > Andy, >=20 > I don't see how anything that might be done about a general mechanism > now would affect the output of SIPREC under its current charter. We are > simply too far down the road for that. >=20 > *Conceivably* some general mechanism might eventually become a > candidate > for some future evolution/revision to siprec, but I wouldn't hold my > breath for that to happen. >=20 > I see info about SIPREC as simply providing some perspective about the > kinds of things a general mechanism might help with. >=20 > Thanks, > Paul >=20 > > Regards > > Andy > > > > > > > > > >> -----Original Message----- > >> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf > Of > >> Paul Kyzivat > >> Sent: 23 April 2012 20:23 > >> To: rai@ietf.org > >> Subject: Re: [RAI] How to exchange metadata about the media streams > >> established with a SIP session > >> > >> On 4/23/12 10:53 AM, Cullen Jennings wrote: > >>> > >>> worth nothing the RTCweb folks also want to exchange metadata to do > >> with labeling streams. I always find just classifying it as > "metadata" > >> sort of makes it hard to decide what to do with it. I'd prefer the > >> groups to specifically outline what data they need to exchange and > then > >> I think it becomes clearer the best way to exchange the different > types > >> of information. Knowing if the information changes per RTP packet, > or > >> only one when the session is set up helps. > >> > >> Cullen, > >> > >> I agree that just talking about "metadata" isn't especially helpful. > >> OTOH, getting too far into the weeds about the specifics of the > >> metadata > >> makes it hard for people with differing contexts to talk with one > >> another and find commonalities. > >> > >> In CLUE we realize that not all of our metadata can be treated the > same > >> way. There are varying degrees of real-time-ed-ness to deal with. We > >> definitely have some stuff that changes at the signaling rate or > less, > >> and some that changes at the media rate, and some stuff that that > falls > >> in between. We also have issues that some of the stuff is too big to > >> reasonably transmit in sip signaling, which we are considering a > >> separate "data stream" for. We do think that CLUE should be able to > >> work > >> with RTCWEB based endpoints. So its possible that the RTCWEB data > >> stream > >> mechanism might work for us. But we will need to have it even with > >> non-rtcweb-endpoints. > >> > >> In SIPREC, we have a lot of descriptive stuff, mostly about > signaling. > >> The rate is tied to the signaling rate, but possibly about multiple > >> calls and hence higher in aggregate. We decided that sending in the > sip > >> signaling was appropriate for this stuff, though the size of the > data > >> precludes doing so over UDP. For this app we decided we could just > >> require TCP transport for the sip signaling of the recording > session. > >> (It doesn't constrain the transport for the calls being recorded.) > This > >> could be a problem in some topologies, but seems acceptable for the > >> application. If there had been a mechanism that for a separate "data > >> stream" that we could have reused we *might* have found that an > >> attractive direction. > >> > >> ISTM that it would be helpful to have a "brainstorming session" with > >> some reps from rtcweb, clue, siprec, bfcp, and mediactrl to see > whether > >> we can find some common machinery that could support multiples of > these > >> cases. I'm thinking that the sctp over udp stack being worked on for > >> rtcweb might be more broadly applicable, both as a data stream > >> transport > >> negotiated with o/a, and maybe as a new sip transport as well. > >> > >> Thanks, > >> Paul > >> > >>> On Feb 28, 2012, at 3:20 , Gonzalo Camarillo wrote: > >>> > >>>> Folks, > >>>> > >>>> I am sending this email to the RAI list because it is about an > >>>> architectural issue that affects more than one WG. > >>>> > >>>> Both the CLUE and SIPREC WGs have identified the need to exchange > >>>> metadata about media streams that have been established using SIP. > >> Both > >>>> groups need to transport such metadata between SIP UAs. > >>>> > >>>> In CLUE, they are studying how to transport their metadata, as > >>>> documented in: > >>>> http://tools.ietf.org/html/draft-wenger-clue-transport-01 > >>>> > >>>> In SIPREC, they are planning to piggyback the metadata in SIP > >> UPDATEs as > >>>> an XML-encoded body part. When they need to send a request for > full > >>>> state (as opposed to partial state), they use an UPDATE request > with > >> a > >>>> particular body type, as documented in: > >>>> http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 > >>>> > >>>> The best way to exchange metadata within a SIP session depends on > >> the > >>>> type of metadata and on how the UAs need to interact with each > other > >>>> (e.g., a UA simply pushing information to the other UA or a more > >>>> complicated protocol). Given that SIPREC and CLUE have different > >>>> metadata and interactions, it may well be that we decide to use a > >>>> different mechanism in each group. Nevertheless, I think both > groups > >>>> would benefit from architecturally-inclined RAI people having a > look > >> at > >>>> their work. Please, continue this discussion focusing on their > >> specific > >>>> requirements on either the CLUE list or the SIPREC list. > >>>> > >>>> Somewhat related to this issue, the RTCWeb group discussed the use > >> of > >>>> SCTP over UDP as a reliable NAT-friendly way to exchange data > >> between > >>>> endpoints. > >>>> > >>>> Cheers, > >>>> > >>>> Gonzalo > >>>> > >>>> _______________________________________________ > >>>> RAI mailing list > >>>> RAI@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rai > >>> > >>> _______________________________________________ > >>> RAI mailing list > >>> RAI@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rai > >>> > >> > >> _______________________________________________ > >> RAI mailing list > >> RAI@ietf.org > >> https://www.ietf.org/mailman/listinfo/rai > > From dworley@avaya.com Fri Apr 27 15:01:29 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A4C21F8600; Fri, 27 Apr 2012 15:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.837 X-Spam-Level: X-Spam-Status: No, score=-102.837 tagged_above=-999 required=5 tests=[AWL=-0.238, 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 DIdhL54BGIWP; Fri, 27 Apr 2012 15:01:28 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id ECF1621F85FF; Fri, 27 Apr 2012 15:01:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANcVm0/GmAcF/2dsb2JhbABEsgSBB4IQEig4BxIBFRcJCUInBAENDQwOh2sLngidC4sCgmqCTmMElw6FBYoqgwSBOA X-IronPort-AV: E=Sophos;i="4.75,493,1330923600"; d="scan'208";a="6588193" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 27 Apr 2012 18:01:25 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Apr 2012 17:58:47 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 27 Apr 2012 18:01:25 -0400 From: "Worley, Dale R (Dale)" To: "rai@ietf.org" , Al Morton , "draft-ietf-bmwg-sip-bench-term@tools.ietf.org" , "bmwg@ietf.org" Date: Fri, 27 Apr 2012 17:56:42 -0400 Thread-Topic: RAI-ART review of draft-ietf-bmwg-sip-bench-term-04 and draft-ietf-bmwg-sip-bench-meth-04 Thread-Index: AQHNJMFJRhoQSDLmPUGO2SgZHs/AAA== 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: [RAI] RAI-ART review of draft-ietf-bmwg-sip-bench-term-04 and draft-ietf-bmwg-sip-bench-meth-04 X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 22:01:29 -0000 I am the assigned RAI-ART reviewer for this draft. For background on RAI-ART, please see the FAQ at . Please resolve these comments along with any other comments you may receive. This draft is on the right track but has open issues, described in the review. Please note that I am quite familiar with SIP but have little familiarity with benchmarking. Thus, some of the points I make might have implicit answers in the usual practice of benchmarking. But since one audience of these documents is the SIP community, such implicit answers should probably be made explicit. I. Technical issues A. Media The drafts seem to be undecided as to whether they want to benchmark media processing or not. At one point, it says that the benchmarking is entirely in the signaling plane. At another point, it is specified how to set the number of media streams per INVITE dialog. I suspect the conflict is that there are devices the WG wants to benchmark which do handle the media and their media handling affects performance significantly, but the WG is unsure how to parametrize media benchmarking. The simplest situation, of course, is if the DUT is a proxy and the media bypasses it entirely. Beyond that, even in the simplest media relaying situations, significant processing costs can arise. Even if the DUT isn't transcoding, it may have to rewrite the RTP codec numbers (as it may have modified the SDP passing through it). In more complex situations, the DUT may have to transcode the codecs. Some consideration has to be made of how to specify exactly what the media loads are. SDP already has ways to specify the exact encoding of media streams, including the number of samples per packet, which implies the packet size and packet rate. These drafts only allow specifying the packet size as a benchmark parameter, but packet size is notoriously ambiguous -- which layers of encapsulation of the encoded media are counted? But specifying the detailed encoding side-steps that question. The draft wants to consider the duration of a media stream to be separately adjustable from the duration of the containing dialog, but the draft explicitly places out of scope the re-INVITE which is necessary to accomplish that realistically (that is, with the signaling matching the presented media packets). B. INVITE dialog structure The drafts seem to want to consider the establishment (or failure thereof) of an INVITE dialog to be instantaneous, after which the dialog continues for a chosen length of time, and then vanishes instantly. Little or no consideration is given to the various scenarios of call establishment, including the most common case: INVITE sent -- 183 response -- significant delay -- 200 response. Dialog teardown is not conceptualized as being a processing step that involves significant cost and may fail: "Session disconnect is not considered in the scope of this work item." This lack of consideration is enhanced in the forking cases, as the variety of scenarios (and their durations) increases. In addition, the drafts only consider forking which is done within the DUT, whereas it will be common in practice for forking to be done downstream of the DUT, presenting the DUT with a stream of 1xx responses from multiple endpoints, with a 2xx after an extended delay. Also, in regard to signaling benchmarking, INVITEs that ultimately fail are likely to be as costly as INVITEs that succeed, but there doesn't seem to be a defined parameter "fraction of attempted calls which succeed" (which controls the callee EAs). C. Loop detection All discussions of loop detection needs to based on the revised loop detection requirements in RFC 5393. D. Authentication In some SIP operations, authentication is commonly done. This can have various effects on the message flows that need to be taken into account in the benchmarks. For instance, a registrar may require that the registering UA authenticate itself. Commonly, the UA sends a REGISTER request, which is rejected with 401 because it contains a nonce that is too old. The UA then immediately sends another REGISTER with the nonce provided in the 401 response, and that request receives a 200 response. In this scenario, the number of effective REGISTER requests is half of the total REGISTER requests, leading to an apparent attempt failure rate of 50%, even though the middlebox is doing the Right Thing 100% of the time. This suggests that the definition of "attempt failure" needs to be updated so that a 4xx response "passed upstream" by the DUT is not counted as an attempt failure. In other scenarios, the DUT itself might be expected to enforce SIP authentication, which would require a somewhat different definition of attempt failure, and would be expected to have lower throughput. So some thought needs to be given as to whether these scenarios are to be benchmarked, and to document how authentication is to be handled in whatever benchmarks are defined. II. Editorial issues The drafts appear to me to be, well, drafts. That is, they generally contain the intended technical content but the exposition is not complete or clear, and at points the reader has to guess at the exact meaning. At various points the sentences are not correct English, references are not complete or correct, and there are various points of contradiction between different parts of the documents. The document needs a proper final revision, with each paragraph edited over carefully to maximize its clarity and to verify that all parts of the documents are consistent with each other. Examples of editorial problems are: draft-ietf-bmwg-sip-bench-term-04 section 1 The term Throughput is defined in RFC2544 [RFC2544]. The definition is in RFC 1242; RFC 2544 refers to RFC 1242. This document uses existing terminology defined in other BMWG work. Examples include, but are not limited to: Device under test (DUT) (c.f., Section 3.1.1 RFC 2285 [RFC2285]). System under test (SUT) (c.f., Section 3.1.2, RFC 2285 [RFC2285]). In what way would the reader determine the relevant "other BMWG work"? This reference needs to be made definite in some way. The behavior of a stateful proxy is further defined in Section 16. This sentence was copied directly from RFC 3261, in whose section 16 the referenced definition exists. However, *this* document has no section 16. section 2.2 The figures are inconsistent in how they label the "Tester" boxes as "EA" or not. Is this difference meaningful? Figures 9 and 10 show "SUT" embracing the entire test setup, including the "Tester" boxes, whereas RFC 2285 section 3.1.2 says that SUT does not include the tester components of the setup. section 3.1.1 The various components of a "session" (usually "dialog" in SIP terminology) are given quasi-mathematical names that look peculiar to me. Worse, they're not completely correct: since each RTP stream has a corresponding RTCP stream, "session[x].medc" should be "session[x].medc[y]". (Is there any benefit of introducing this symbolism?) section 3.1.5 This section defines "overload" and then says "The distinction between an overload condition and other failure scenarios is outside the scope of this document which is blackbox testing." If the distinction is outside the scope, why is there a definition here? section 3.1.6 The definition of "Session Attempt" seems to be incorrect. Of course, a session attempt is each sending of an INVITE/SUBSCRIBE/MESSAGE, whether or not it is ultimately successful. But the definition written makes "session attempt" a time-varying property, which is true only until a response is received by the EA. section 3.1.8 An IS is identified by the Call-ID, To-tag, and From-tag of the SIP message that establishes the session. As written, this is incorrect, as the to-tag is present only in the response(s) to the INVITE. 2. If a media session is described in the SDP body of the signaling message, then the media session is established by the end of Establishment Threshold Time (c.f. Section 3.3.3). This sentence is correct as far as it goes, but there is no clear description (that I can tell) of when a media session is "established". Indeed, it's not clear to me what a proper way to set up the media is -- in real SIP systems, a proxy or SBC can start receiving early media from a callee before it has received *any* SIP responses from the callee, and the middlebox can have some difficulty matching the RTP to a dialog being set up. So the exact details of when to start the media flows are needed to make the benchmarking process reproducible. section 3.2.3 This section defines "SIP-Aware Stateful Firewall" as=20 Device in test topology that provides Denial-of-Service (DoS) Protection to the Signaling and Media Planes for the EAs and Signaling Server But a device can be a SIP-Aware Stateful Firewall (in the ordinary sense of the words) without providing DoS protection. section 3.3.2 "IS Media Attempt Rate" is defined as Configuration on the EA for number of ISs with Associated Media to be established at the DUT per continuous one- second time intervals. However, "established" should be "attempted". section 3.3.3 Configuration of the EA for representing the amount of time that an EA will wait before declaring a Session Attempt Failure. The discussion makes clear that there may be different Establishment Threshold Times for IS and NS, but these times are written about in most places as if they were the same. draft-ietf-bmwg-sip-bench-meth-04 section 2 Refers to "Presence Rate", but draft-ietf-bmwg-sip-bench-term-04 says that presence is out of scope. section 4 What is the relationship between the data items described in this draft's "Benchmarking Considerations" and draft-ietf-bmwg-sip-bench-term-04's "Test Setup Parameters"? section 4.2 I'm having trouble understanding the various terms that include the word "server", including "Signaling Server", "The Server", "SIP Server". Are these intended to have the same meaning? Are they intended to cover the whole range of SIP "middleboxes" (including, e.g., proxies)? In section 2 is The DUT is a SIP Server, which may be any [RFC3261] conforming device. The SUT can be any device or group of devices containing RFC 3261 conforming functionality along with Firewall and/or NAT functionality. If read literally, that would *exclude* pure proxies, since they don't have firewall or NAT functionality. section 4.3 References "Figures 4 and 5", which don't exist. Does it mean to reference draft-ietf-bmwg-sip-bench-term-04? section 4.9 The formatting of the pseudocode is inconsistent. The variable "c" should be boolean rather than 0/1. section 6.6 1. If the DUT is being benchmarked as a proxy or B2BUA, and forking is supported in the DUT, then configure the DUT in the test topology shown in Figure 5 in [I-D.sip-bench-term]. If the DUT does not support forking, then this step can be skipped. 2. Configure a SUT according to the test topology shown in Figure 8 of [I-D.sip-bench-term]. It's not clear to me how one can configure the DUT/SUT according to both figures 5 and 8. And neither figure shows two callee EAs. The text suggests that DUTs that do not support forking can be tested, even though this is a test specifically of performance when the DUT is doing forking. Dale