From partr@cisco.com Fri Jun 3 17:54:41 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DB3E06C6 for ; Fri, 3 Jun 2011 17:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.826 X-Spam-Level: X-Spam-Status: No, score=-9.826 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctz69VuNXg5N for ; Fri, 3 Jun 2011 17:54:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 53708E0627 for ; Fri, 3 Jun 2011 17:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=19364; q=dns/txt; s=iport; t=1307148879; x=1308358479; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RYURTlMfYIvfVY5dV5/dxcVX7Q1G/1h476/U0tz9b/E=; b=Pl5wjmP3fKiXUCqK6QusPxIN73bUJuoLZBD90i9+FvIyypkbgjnb10v0 rLbipd0M+HKgm9deHcik2w65gUJ0BCQZ2pDpWOHQa05LXADGZy3vELojW Yd9aMPte2bEBukzdH0jv48kLwkFX4E4vBeNu8JXyESjxdJfe8gTO269dd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0BAHGB6U1Io8UR/2dsb2JhbABTl2aOYXeIcaNYnWKGIQSGbo5XinA X-IronPort-AV: E=Sophos;i="4.65,317,1304294400"; d="scan'208";a="33657581" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 04 Jun 2011 00:54:33 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p540sW6s016370; Sat, 4 Jun 2011 00:54:32 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 4 Jun 2011 06:24:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Jun 2011 06:24:28 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] extensionData in XML Thread-Index: Acv4X3wDgs8wZodKRU6y7lcfqyT99AGAQFEwCPvcqiA= References: <4D9CDFC0.9070300@cisco.com><48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> From: "Parthasarathi R (partr)" To: "Dan Burnett" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" , "Ken Rehor (krehor)" , "Rosen, Brian" , X-OriginalArrivalTime: 04 Jun 2011 00:54:32.0563 (UTC) FILETIME=[F76BBC30:01CC2251] Cc: siprec@ietf.org, "Peter Saint-Andre \(psaintan\)" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 00:54:41 -0000 =20 Hi all, Based on the discussion in last interim meeting and mail thread discussion on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and below mail thread, I have not seen anybody looking for separate extensiondata metadata XML tag. So, the authors of the draft plans to revise the next revision with "Extensiondata as an extension within metadata block" and example is as follows: =20 sip:alice@cisco.com In case anybody has difference of opinion, Please let us know by coming Thursday which helps us to update the next revision. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Tuesday, April 19, 2011 4:01 PM To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor (krehor) Cc: siprec@ietf.org Subject: Re: [siprec] extensionData in XML Dan & all, Sorry for the late reply. Thanks for sharing your XML experience. tag is provided as extensions to SIPREC metadata. The current approach allows to ignore the extension-data in case SRS does not understand.=20 I have added few extensiondata as a note of this mail which were discussed during earlier SIPREC interim meeting. The open question here is whether the extension-data has to be passed every time (during partial-update) within metadata XML tag (participant, session) update or it is enough to send only when extension-data changes. Partial update of any specific XML elements needs unique id. RFC 5261 recommends to use xml:id or type-id as unique attribute.=20 The following example illustrate three different mechanism for extensiondata: Extensiondata as separate metadata block: (Current format in the draft - works for partial update, URN UUID is used in all metadata block as of now) sip:alice@cisco.com Extensiondata as separate metadata block using xml:id:(Id reduction) sip:alice@cisco.com Extensiondata as an extension within metadata block: (Ignore the attribute but needs to be passed in each partial updated) Example: =20 sip:alice@cisco.com Please let me know which best suites SIPREC metadata. Including Leon & Ken explicitly because they provides lot of Extension data attributes during the discussion of metadata model. I'm fine with any of the above approach. Thanks Partha Note: End point information: ip/port, device id (MAC address), DN (used for the call, in case of multiline).=20 Device type: external, station, IVR, routing point, QUEUE, Gateway, MCU, Operator, etc Participant Role: caller, called, added, last_redirecting, redirecting, conferencing, queing, redirected AgentId, OSLogin -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Dan Burnett Sent: Monday, April 11, 2011 9:15 PM To: Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: Re: [siprec] extensionData in XML As someone who works quite a bit with XML, I'll point out that there is an important distinction between data for extensibility and expected application-specific data. As an example of the latter, EMMA [1] is an XML format for representing the input of a user (human being, commonly) to an automated system, by speech, gesture, pen, etc. Since the way an input is interpreted is dependent upon its intended use, there was a need for a designated application-specific section to represent the semantics (meaning) of the input. To make it easier for machine consumers of this format that may be seeking the semantics, there is a designated element "interpretation" =20 that holds this information. The contents of this element are arbitrary XML in an application-specific XML namespace. On the other hand, every XML specification I've worked on in W3C has =20 needed a way for implementers to innovate via extensions. =20 Traditionally this is handled via custom elements and attributes in an implementer-specific namespace to avoid name collision with the standard elements and attributes. Since these true innovation extensions can occur anywhere, there is no specific XML element established in most specifications for "extensions". Instead, the specification defines the expected behavior of a conformant processor upon encountering elements and attributes outside of the specification's standard namespace. The nice thing about this approach is that allows for innovation in a way that does not cause name collision but which could become part of the standard in the future (and be moved into the standard's namespace). For the specifications I worked on, we always required that a conformant processor had to do the behavior defined in the specification when it received a conformant document but that the behavior of the processor when it encountered non-standard elements and attributes was at its own discretion -- it could process the attributes, ignore them, or report an error, as it deemed appropriate. So the real question for us here is whether these extension elements are *extensions* (which do not require a custom element/location) or *expected application-specific information* (which can benefit from custom elements and prescribed locations in the XML tree). -- dan [1] http://www.w3.org/TR/emma/ On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: > > > On 4/6/2011 8:57 AM, Elwell, John wrote: >> Yes, I would be keen to hear Peter's or other opinions, but one other >> point. One of the properties of XML is that it is human- readable.=20 >> Having extension data as a child element of the element representing=20 >> the object to which it applies seems, in my opinion, to make it more=20 >> readable. Having extension data as a separate element, with a link to >> the element to which it applies, seems hard for a human reader,=20 >> particularly if the link is a long, random string. > > IMO human readability of the xml is a secondary/tertiary concern. > (SIP is in theory readable, but real sip on the wire tends to be=20 > difficult to read due to need to match up non-ergonomic numeric=20 > addresses and tags from one message to another.) > > I'm inclined to agree it would be better to embed extensions into the=20 > basic elements, but not primarily due to readability. IMO extensions=20 > should function as much like the predefined parts as possible. > (Today's extension may become common usage tomorrow.) > > I just don't know enough xml to define this "correctly". > > Thanks, > Paul > >> John (as individual) >> >> >>> -----Original Message----- >>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>> Sent: 06 April 2011 10:16 >>> To: Elwell, John; Hadriel Kaplan >>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >>> Subject: RE: [siprec] extensionData in XML >>> >>> John, >>> >>> Please read inline >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Wednesday, April 06, 2011 2:02 PM >>> To: Parthasarathi R (partr); Hadriel Kaplan >>> Cc: siprec@ietf.org; Jain, Rajnish >>> Subject: RE: [siprec] extensionData in XML >>> >>> I already posted on this topic on the other thread. Partha states=20 >>> below an additional motivation for handling extension data in the=20 >>> way specified in the current I-D. My counter argument is that anyone >>> specifying particular extension data could specify the expected=20 >>> behaviour when extension data is present in an object and then=20 >>> absent when that object is updated. For some types of metadata it=20 >>> could be that absence means it no longer applies, and for other=20 >>> types of metadata it could be that absence means it has not changed. >>> >>> Currently, metadata format draft XML element is written=20 >>> with the basics that "it is no longer applies" in case specific=20 >>> element is absent in the update. The question is how the information >>> of extensiondata absence means "it is no longer applies" or "it has=20 >>> not changed" has to be passed between SRC and SRS. Here, there is a=20 >>> need of common understanding between SRC and SRS or else the=20 >>> information will be misunderstand even though both parties=20 >>> understand the specific extension. >>> >>> The current extensiondata is taken the route of all other metadata=20 >>> block XML element definition. There may be better way to represent=20 >>> in extensiondata XML element apart from creating new metadata block=20 >>> with URN UUID. I'm including Peter for his advise on XML=20 >>> front. >>> >>> The latter approach would avoid the need for repeating large=20 >>> quantities of metadata each time there is a minor change to an=20 >>> object. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>> R (partr) >>>> Sent: 03 April 2011 19:46 >>>> To: Hadriel Kaplan >>>> Cc: siprec@ietf.org; Jain, Rajnish >>>> Subject: Re: [siprec] extensionData in XML >>>> >>>> Hadriel, >>>> >>>> I guess we have common understaning to the extend that the >>> intention >>>> is to send some extensiondata (Unknown) attribute by SRC >>> which may or >>>> may not understand by SRS and also for the usage of xs:any as the=20 >>>> solution. Few stuff are missing in yours proposal w.r.t >>> partial data >>>> passing of extensiondata: >>>> >>>> The question is whether there is a need to pass the extension data=20 >>>> during every time the corresponding metadata block is passed or=20 >>>> updated. For example, CS metadata block sends extension >>> data specific >>>> to call center data like Agent is remote or local, agent or >>> customer >>>> initiated call (direction) during the CS block creation >>> (INVITE) and >>>> these constant information in extensiondata is not required to be=20 >>>> passed in each update of CS metadata like adding video >>> stream in the >>>> mid-session. >>>> >>>> The current model allows to pass extensiondata only during >>> the initial >>> >>>> CS block creation and there is no need to update or resend while CS >>>> block is getting updated with other CS information. IMO, >>> The current >>>> extensiondata mechanism is required as SIPREC puts lot of >>> call centre >>>> specific attributes proposed during metadata model draft review as=20 >>>> outside the scope of SIPREC and most of the attributes >>> mentioned are >>>> constant within the scope of session. >>>> >>>> Also, it is possible to pass update only extension data within RS=20 >>>> session without impacting parent element. Please let me >>> know your and >>>> others opinion whethter it is fine to continue with the current=20 >>>> extension-data element or to move xs:any element to each of the=20 >>>> metadata block. >>>> >>>> Thanks >>>> Partha >>>> ________________________________ >>>> >>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>> Sent: Sat 4/2/2011 6:19 PM >>>> To: Parthasarathi R (partr) >>>> Cc: Jain, Rajnish; siprec@ietf.org >>>> Subject: Re: [siprec] extensionData in XML >>>> >>>> >>>> >>>> Hi Partha, >>>> I think you're missing my point (or I'm missing yours) - you can do >>>> all of that without specifying an "extensionData" XML element. >>>> Unknown XML elements are simply ignored by the other side, so Cisco >>>> can add a "ciscoPrivateData" XML element wherever it wants >>> and send it >>> >>>> to an Acme; and that private element will be ignored by Acme while=20 >>>> everything else will continue to work. Which I think is >>> the behavior >>>> you want, right? >>>> >>>> -hadriel >>>> >>>> >>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>> >>>>> Hadriel/Raj, >>>>> >>>>> Extensiondata XML is provided as per Metadata model >>>> extensiondata block. >>>>> During the initial discussion of metadata model draft, we >>>> realized that >>>>> lot of attributes specified for recording are call center >>>> specific or >>>>> specific domain related and it is outside the scope of IETF >>>> SIPREC but >>>>> it is required for those specific solution to work. >>>> Extensiondata XML >>>>> element helps to meet those requirement. >>>>> >>>>> Extensiondata is provided with URN UUID to pass or not pass=20 >>>>> independently in partial data. But it is open item whether >>>> extensiondata >>>>> has to be within specific metadatablock or not. >>>>> >>>>> Please read inline for more comments. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>> Of Jain, Rajnish >>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> There may be such motivation from how the CSTA standards >>>> are specified. >>>>> They have an element called privateData for each message. It is a=20 >>>>> placeholder for any non-standardized extensions. This could >>>> be legacy >>>>> and may not mean much for the modern text based protocols. >>>>> >>>>> I really didn't get the reason why is it not >>>> require for modern >>>>> text based protocols. This is more like generic param in >>>> SIP or xs:any >>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>> >>>>> >>>>> That said, I think you're right (this generally applies >>> to any text >>>>> based protocols and is the fundamental basis for forward/backward=20 >>>>> compatibility in such protocols). >>>>> >>>>> Raj >>>>> >>>>> >>>>> ----------------------------------------------------- >>>>> Please consider the environment before printing this email. >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of Hadriel Kaplan >>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>> To: siprec@ietf.org >>>>>> Subject: [siprec] extensionData in XML >>>>>> >>>>>> Howdy, >>>>>> With regards to the extensionData concept and XML, I have >>>> a few basic >>>>>> questions. I am by no means an XML expert so it could >>>> just be my lack >>>>> >>>>>> of knowledge which makes me confused. If so, just tell >>> me to RTFM. >>>>>> >>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>> A recording metadata object contains additional data not >>>> specified >>>>>> as >>>>>> part of siprec. This is intended to accommodate >>> future standards >>>>>> track extensions, as well as vendor and user specific >>> extensions. >>>>>> The mechanism MUST provide a means of unambiguously >>>> distinguishing >>>>>> such extension data. >>>>>> >>>>>> What confuses me is I didn't think XML had to do such >>>> machinations to >>>>>> accommodate this need. I thought we could just specify >>> in our RFCs >>> >>>>>> that unknown XML elements and attributes MUST be >>> ignored, so that >>>>>> future RFCs could add them without having to leave >>>> specific "blob" XML >>>>> >>>>>> elements to carry such data. Or at least that's what >>> we've done so >>> >>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>> namespace model that could be used to disambiguate proprietary=20 >>>>>> elements from standard ones. If both of those theories >>>> are correct, >>>>>> why do we need to define an extensionData element? >>>>>> >>>>>> -hadriel >>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>> DISCLAIMER: This e-mail may contain information that is >>>> confidential, >>>>> privileged or otherwise protected from disclosure. If you >>> are not an >>> >>>>> intended recipient of this e-mail, do not duplicate or >>>> redistribute it >>>>> by any means. Please delete it and any attachments and >>>> notify the sender >>>>> that you have received it in error. Unintended recipients >>>> are prohibited >>>>> from taking action on the basis of information in this >>> e-mail.E-mail >>> >>>>> messages may contain computer viruses or other defects, >>> may not be >>>>> accurately replicated on other systems, or may be >>>> intercepted, deleted >>>>> or interfered with without the knowledge of the sender or >>>> the intended >>>>> recipient. If you are not comfortable with the risks >>> associated with >>> >>>>> e-mail messages, you may decide not to use e-mail to >>>> communicate with >>>>> IPC. IPC reserves the right, to the extent and under >>> circumstances >>>>> permitted by applicable law, to retain, monitor and >>> intercept e-mail >>> >>>>> messages to and from its systems. >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> >>>> >>>> >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Mon Jun 6 01:19:28 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E1C11E808B for ; Mon, 6 Jun 2011 01:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTUGRsM8D9uc for ; Mon, 6 Jun 2011 01:19:27 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id B988F11E8083 for ; Mon, 6 Jun 2011 01:19:26 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 6 Jun 2011 11:19:24 +0300 From: Leon Portman To: "Parthasarathi R (partr)" , Dan Burnett , "Paul Kyzivat (pkyzivat)" , "Ken Rehor (krehor)" , "Rosen, Brian" , "HKaplan@acmepacket.com" Date: Mon, 6 Jun 2011 11:19:24 +0300 Thread-Topic: [siprec] extensionData in XML Thread-Index: Acv4X3wDgs8wZodKRU6y7lcfqyT99AGAQFEwCPvcqiAAdJ5tMA== Message-ID: <07465C1D981ABC41A344374066AE1A2C38AC31EB52@TLVMBX01.nice.com> References: <4D9CDFC0.9070300@cisco.com><48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> In-Reply-To: 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: "siprec@ietf.org" , "Peter Saint-Andre \(psaintan\)" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 08:19:28 -0000 I am ok with the proposal. Looking good Leon -----Original Message----- From: Parthasarathi R (partr) [mailto:partr@cisco.com] Sent: Saturday, June 04, 2011 3:54 AM To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor (krehor);= Rosen, Brian; HKaplan@acmepacket.com Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) Subject: RE: [siprec] extensionData in XML Hi all, Based on the discussion in last interim meeting and mail thread discussion = on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and be= low mail thread, I have not seen anybody looking for separate extensiondata= metadata XML tag. So, the authors of the draft plans to revise the next re= vision with "Extensiondata as an extension within metadata block" and examp= le is as follows: sip:alice@cisco.com In case anybody has difference of opinion, Please let us know by coming Thu= rsday which helps us to update the next revision. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Tuesday, April 19, 2011 4:01 PM To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor (krehor) Cc: siprec@ietf.org Subject: Re: [siprec] extensionData in XML Dan & all, Sorry for the late reply. Thanks for sharing your XML experience. tag is provided as extensions to SIPREC metadata. The curr= ent approach allows to ignore the extension-data in case SRS does not under= stand. I have added few extensiondata as a note of this mail which were discussed = during earlier SIPREC interim meeting. The open question here is whether th= e extension-data has to be passed every time (during partial-update) within metadata XML tag (participant, session) update or it= is enough to send only when extension-data changes. Partial update of any = specific XML elements needs unique id. RFC 5261 recommends to use xml:id o= r type-id as unique attribute. The following example illustrate three different mechanism for extensiondata: Extensiondata as separate metadata block: (Current format in the draft - wo= rks for partial update, URN UUID is used in all metadata block as of now) sip:alice@cisco.com Extensiondata as separate metadata block using xml:id:(Id reduction) sip:alice@cisco.com Extensiondata as an extension within metadata block: (Ignore the attribute = but needs to be passed in each partial updated) Example: sip:alice@cisco.com Please let me know which best suites SIPREC metadata. Including Leon & Ken = explicitly because they provides lot of Extension data attributes during th= e discussion of metadata model. I'm fine with any of the above approach. Thanks Partha Note: End point information: ip/port, device id (MAC address), DN (used for the c= all, in case of multiline). Device type: external, station, IVR, routing point, QUEUE, Gateway, MCU, Op= erator, etc Participant Role: caller, called, added, last_redirecting, redi= recting, conferencing, queing, redirected AgentId, OSLogin -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Dan Burnett Sent: Monday, April 11, 2011 9:15 PM To: Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: Re: [siprec] extensionData in XML As someone who works quite a bit with XML, I'll point out that there is an = important distinction between data for extensibility and expected applicati= on-specific data. As an example of the latter, EMMA [1] is an XML format f= or representing the input of a user (human being, commonly) to an automated= system, by speech, gesture, pen, etc. Since the way an input is interpret= ed is dependent upon its intended use, there was a need for a designated ap= plication-specific section to represent the semantics (meaning) of the inpu= t. To make it easier for machine consumers of this format that may be seeking = the semantics, there is a designated element "interpretation" that holds this information. The contents of this element are arbitrary XM= L in an application-specific XML namespace. On the other hand, every XML specification I've worked on in W3C has needed a way for implementers to innovate via extensions. Traditionally this is handled via custom elements and attributes in an impl= ementer-specific namespace to avoid name collision with the standard elemen= ts and attributes. Since these true innovation extensions can occur anywhe= re, there is no specific XML element established in most specifications for= "extensions". Instead, the specification defines the expected behavior of= a conformant processor upon encountering elements and attributes outside o= f the specification's standard namespace. The nice thing about this approa= ch is that allows for innovation in a way that does not cause name collisio= n but which could become part of the standard in the future (and be moved i= nto the standard's namespace). For the specifications I worked on, we always required that a conformant pr= ocessor had to do the behavior defined in the specification when it receive= d a conformant document but that the behavior of the processor when it enco= untered non-standard elements and attributes was at its own discretion -- i= t could process the attributes, ignore them, or report an error, as it deem= ed appropriate. So the real question for us here is whether these extension elements are *extensions* (which do not require a custom element/location) or *expected = application-specific information* (which can benefit from custom elements a= nd prescribed locations in the XML tree). -- dan [1] http://www.w3.org/TR/emma/ On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: > > > On 4/6/2011 8:57 AM, Elwell, John wrote: >> Yes, I would be keen to hear Peter's or other opinions, but one other >> point. One of the properties of XML is that it is human- readable. >> Having extension data as a child element of the element representing >> the object to which it applies seems, in my opinion, to make it more >> readable. Having extension data as a separate element, with a link to >> the element to which it applies, seems hard for a human reader, >> particularly if the link is a long, random string. > > IMO human readability of the xml is a secondary/tertiary concern. > (SIP is in theory readable, but real sip on the wire tends to be > difficult to read due to need to match up non-ergonomic numeric > addresses and tags from one message to another.) > > I'm inclined to agree it would be better to embed extensions into the > basic elements, but not primarily due to readability. IMO extensions > should function as much like the predefined parts as possible. > (Today's extension may become common usage tomorrow.) > > I just don't know enough xml to define this "correctly". > > Thanks, > Paul > >> John (as individual) >> >> >>> -----Original Message----- >>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>> Sent: 06 April 2011 10:16 >>> To: Elwell, John; Hadriel Kaplan >>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >>> Subject: RE: [siprec] extensionData in XML >>> >>> John, >>> >>> Please read inline >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Wednesday, April 06, 2011 2:02 PM >>> To: Parthasarathi R (partr); Hadriel Kaplan >>> Cc: siprec@ietf.org; Jain, Rajnish >>> Subject: RE: [siprec] extensionData in XML >>> >>> I already posted on this topic on the other thread. Partha states >>> below an additional motivation for handling extension data in the >>> way specified in the current I-D. My counter argument is that anyone >>> specifying particular extension data could specify the expected >>> behaviour when extension data is present in an object and then >>> absent when that object is updated. For some types of metadata it >>> could be that absence means it no longer applies, and for other >>> types of metadata it could be that absence means it has not changed. >>> >>> Currently, metadata format draft XML element is written >>> with the basics that "it is no longer applies" in case specific >>> element is absent in the update. The question is how the information >>> of extensiondata absence means "it is no longer applies" or "it has >>> not changed" has to be passed between SRC and SRS. Here, there is a >>> need of common understanding between SRC and SRS or else the >>> information will be misunderstand even though both parties >>> understand the specific extension. >>> >>> The current extensiondata is taken the route of all other metadata >>> block XML element definition. There may be better way to represent >>> in extensiondata XML element apart from creating new metadata block >>> with URN UUID. I'm including Peter for his advise on XML >>> front. >>> >>> The latter approach would avoid the need for repeating large >>> quantities of metadata each time there is a minor change to an >>> object. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>> R (partr) >>>> Sent: 03 April 2011 19:46 >>>> To: Hadriel Kaplan >>>> Cc: siprec@ietf.org; Jain, Rajnish >>>> Subject: Re: [siprec] extensionData in XML >>>> >>>> Hadriel, >>>> >>>> I guess we have common understaning to the extend that the >>> intention >>>> is to send some extensiondata (Unknown) attribute by SRC >>> which may or >>>> may not understand by SRS and also for the usage of xs:any as the >>>> solution. Few stuff are missing in yours proposal w.r.t >>> partial data >>>> passing of extensiondata: >>>> >>>> The question is whether there is a need to pass the extension data >>>> during every time the corresponding metadata block is passed or >>>> updated. For example, CS metadata block sends extension >>> data specific >>>> to call center data like Agent is remote or local, agent or >>> customer >>>> initiated call (direction) during the CS block creation >>> (INVITE) and >>>> these constant information in extensiondata is not required to be >>>> passed in each update of CS metadata like adding video >>> stream in the >>>> mid-session. >>>> >>>> The current model allows to pass extensiondata only during >>> the initial >>> >>>> CS block creation and there is no need to update or resend while CS >>>> block is getting updated with other CS information. IMO, >>> The current >>>> extensiondata mechanism is required as SIPREC puts lot of >>> call centre >>>> specific attributes proposed during metadata model draft review as >>>> outside the scope of SIPREC and most of the attributes >>> mentioned are >>>> constant within the scope of session. >>>> >>>> Also, it is possible to pass update only extension data within RS >>>> session without impacting parent element. Please let me >>> know your and >>>> others opinion whethter it is fine to continue with the current >>>> extension-data element or to move xs:any element to each of the >>>> metadata block. >>>> >>>> Thanks >>>> Partha >>>> ________________________________ >>>> >>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>> Sent: Sat 4/2/2011 6:19 PM >>>> To: Parthasarathi R (partr) >>>> Cc: Jain, Rajnish; siprec@ietf.org >>>> Subject: Re: [siprec] extensionData in XML >>>> >>>> >>>> >>>> Hi Partha, >>>> I think you're missing my point (or I'm missing yours) - you can do >>>> all of that without specifying an "extensionData" XML element. >>>> Unknown XML elements are simply ignored by the other side, so Cisco >>>> can add a "ciscoPrivateData" XML element wherever it wants >>> and send it >>> >>>> to an Acme; and that private element will be ignored by Acme while >>>> everything else will continue to work. Which I think is >>> the behavior >>>> you want, right? >>>> >>>> -hadriel >>>> >>>> >>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>> >>>>> Hadriel/Raj, >>>>> >>>>> Extensiondata XML is provided as per Metadata model >>>> extensiondata block. >>>>> During the initial discussion of metadata model draft, we >>>> realized that >>>>> lot of attributes specified for recording are call center >>>> specific or >>>>> specific domain related and it is outside the scope of IETF >>>> SIPREC but >>>>> it is required for those specific solution to work. >>>> Extensiondata XML >>>>> element helps to meet those requirement. >>>>> >>>>> Extensiondata is provided with URN UUID to pass or not pass >>>>> independently in partial data. But it is open item whether >>>> extensiondata >>>>> has to be within specific metadatablock or not. >>>>> >>>>> Please read inline for more comments. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>> Of Jain, Rajnish >>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> There may be such motivation from how the CSTA standards >>>> are specified. >>>>> They have an element called privateData for each message. It is a >>>>> placeholder for any non-standardized extensions. This could >>>> be legacy >>>>> and may not mean much for the modern text based protocols. >>>>> >>>>> I really didn't get the reason why is it not >>>> require for modern >>>>> text based protocols. This is more like generic param in >>>> SIP or xs:any >>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>> >>>>> >>>>> That said, I think you're right (this generally applies >>> to any text >>>>> based protocols and is the fundamental basis for forward/backward >>>>> compatibility in such protocols). >>>>> >>>>> Raj >>>>> >>>>> >>>>> ----------------------------------------------------- >>>>> Please consider the environment before printing this email. >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of Hadriel Kaplan >>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>> To: siprec@ietf.org >>>>>> Subject: [siprec] extensionData in XML >>>>>> >>>>>> Howdy, >>>>>> With regards to the extensionData concept and XML, I have >>>> a few basic >>>>>> questions. I am by no means an XML expert so it could >>>> just be my lack >>>>> >>>>>> of knowledge which makes me confused. If so, just tell >>> me to RTFM. >>>>>> >>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>> A recording metadata object contains additional data not >>>> specified >>>>>> as >>>>>> part of siprec. This is intended to accommodate >>> future standards >>>>>> track extensions, as well as vendor and user specific >>> extensions. >>>>>> The mechanism MUST provide a means of unambiguously >>>> distinguishing >>>>>> such extension data. >>>>>> >>>>>> What confuses me is I didn't think XML had to do such >>>> machinations to >>>>>> accommodate this need. I thought we could just specify >>> in our RFCs >>> >>>>>> that unknown XML elements and attributes MUST be >>> ignored, so that >>>>>> future RFCs could add them without having to leave >>>> specific "blob" XML >>>>> >>>>>> elements to carry such data. Or at least that's what >>> we've done so >>> >>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>> namespace model that could be used to disambiguate proprietary >>>>>> elements from standard ones. If both of those theories >>>> are correct, >>>>>> why do we need to define an extensionData element? >>>>>> >>>>>> -hadriel >>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>> DISCLAIMER: This e-mail may contain information that is >>>> confidential, >>>>> privileged or otherwise protected from disclosure. If you >>> are not an >>> >>>>> intended recipient of this e-mail, do not duplicate or >>>> redistribute it >>>>> by any means. Please delete it and any attachments and >>>> notify the sender >>>>> that you have received it in error. Unintended recipients >>>> are prohibited >>>>> from taking action on the basis of information in this >>> e-mail.E-mail >>> >>>>> messages may contain computer viruses or other defects, >>> may not be >>>>> accurately replicated on other systems, or may be >>>> intercepted, deleted >>>>> or interfered with without the knowledge of the sender or >>>> the intended >>>>> recipient. If you are not comfortable with the risks >>> associated with >>> >>>>> e-mail messages, you may decide not to use e-mail to >>>> communicate with >>>>> IPC. IPC reserves the right, to the extent and under >>> circumstances >>>>> permitted by applicable law, to retain, monitor and >>> intercept e-mail >>> >>>>> messages to and from its systems. >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> >>>> >>>> >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Mon Jun 6 06:21:00 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1D411E8146 for ; Mon, 6 Jun 2011 06:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOHcKmxlY5tw for ; Mon, 6 Jun 2011 06:20:58 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 8F79A11E8140 for ; Mon, 6 Jun 2011 06:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=20980; q=dns/txt; s=iport; t=1307366458; x=1308576058; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VFVZPmziKcgLsa0uYXxzksM8qL4VOk5OUJJsbC2TYmY=; b=hYnCrbbkI4dVhIdeIVk/Xkq3twQk7jgdmk+edLTWcRcplJx1oekrW54h Qk6TUUxcGlAsXivXAtuTMPinaF+omtGHL53tr2XU9pRk9hNELyPapal1+ 3ORTUDHEbS2AW7Vfc1ByuPtgS2YugFkhenS6wbPvKM9khvSfJntKfWKOb w=; X-IronPort-AV: E=Sophos;i="4.65,326,1304294400"; d="scan'208";a="286674611" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2011 13:20:55 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p56DKrHs018843; Mon, 6 Jun 2011 13:20:54 GMT Message-ID: <4DECD435.9050306@cisco.com> Date: Mon, 06 Jun 2011 09:20:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Leon Portman References: <4D9CDFC0.9070300@cisco.com><48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> <07465C1D981ABC41A344374066AE1A2C38AC31EB52@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AC31EB52@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Peter Saint-Andre \(psaintan\)" , "siprec@ietf.org" , "Rosen, Brian" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:21:00 -0000 I'd like to point out an implication of this approach: When you send an update to an entity (in the example its a session) and include extension data, that extension data applies to the session from that time forward until changed. If you later send another update to the same entity, regardless of your reason for sending that update, if you fail to include the extension data again you are saying that the extension data no longer applies to the session. If you want it to continue to apply you must transmit it again. That of course means you must remember what extension data you previously sent, so that you *can* send it again. That may be fine. I just don't want people saying they like this approach without having considered the implications. Thanks, Paul On 6/6/2011 4:19 AM, Leon Portman wrote: > I am ok with the proposal. Looking good > > Leon > > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Saturday, June 04, 2011 3:54 AM > To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor (krehor); Rosen, Brian; HKaplan@acmepacket.com > Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) > Subject: RE: [siprec] extensionData in XML > > > Hi all, > > Based on the discussion in last interim meeting and mail thread discussion on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and below mail thread, I have not seen anybody looking for separate extensiondata metadata XML tag. So, the authors of the draft plans to revise the next revision with "Extensiondata as an extension within metadata block" and example is as follows: > > group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> > > > sip:alice@cisco.com > > > > > In case anybody has difference of opinion, Please let us know by coming Thursday which helps us to update the next revision. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: Tuesday, April 19, 2011 4:01 PM > To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor > (krehor) > Cc: siprec@ietf.org > Subject: Re: [siprec] extensionData in XML > > Dan& all, > > Sorry for the late reply. Thanks for sharing your XML experience. > tag is provided as extensions to SIPREC metadata. The current approach allows to ignore the extension-data in case SRS does not understand. > > I have added few extensiondata as a note of this mail which were discussed during earlier SIPREC interim meeting. The open question here is whether the extension-data has to be passed every time (during > partial-update) within metadata XML tag (participant, session) update or it is enough to send only when extension-data changes. Partial update of any specific XML elements needs unique id. RFC 5261 recommends to use xml:id or type-id as unique attribute. > > The following example illustrate three different mechanism for > extensiondata: > > Extensiondata as separate metadata block: (Current format in the draft - works for partial update, URN UUID is used in all metadata block as of > now) > group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> > > id="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" > parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > sip:alice@cisco.com > > > > Extensiondata as separate metadata block using xml:id:(Id reduction) > group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> > > parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > sip:alice@cisco.com > > > > Extensiondata as an extension within metadata block: (Ignore the attribute but needs to be passed in each partial updated) > Example: > group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> > > > sip:alice@cisco.com > > > > > Please let me know which best suites SIPREC metadata. Including Leon& Ken explicitly because they provides lot of Extension data attributes during the discussion of metadata model. > > I'm fine with any of the above approach. > > Thanks > Partha > > Note: > End point information: ip/port, device id (MAC address), DN (used for the call, in case of multiline). > Device type: external, station, IVR, routing point, QUEUE, Gateway, MCU, Operator, etc Participant Role: caller, called, added, last_redirecting, redirecting, conferencing, queing, redirected AgentId, OSLogin > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Dan Burnett > Sent: Monday, April 11, 2011 9:15 PM > To: Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: Re: [siprec] extensionData in XML > > As someone who works quite a bit with XML, I'll point out that there is an important distinction between data for extensibility and expected application-specific data. As an example of the latter, EMMA [1] is an XML format for representing the input of a user (human being, commonly) to an automated system, by speech, gesture, pen, etc. Since the way an input is interpreted is dependent upon its intended use, there was a need for a designated application-specific section to represent the semantics (meaning) of the input. > To make it easier for machine consumers of this format that may be seeking the semantics, there is a designated element "interpretation" > that holds this information. The contents of this element are arbitrary XML in an application-specific XML namespace. > > On the other hand, every XML specification I've worked on in W3C has > needed a way for implementers to innovate via extensions. > Traditionally this is handled via custom elements and attributes in an implementer-specific namespace to avoid name collision with the standard elements and attributes. Since these true innovation extensions can occur anywhere, there is no specific XML element established in most specifications for "extensions". Instead, the specification defines the expected behavior of a conformant processor upon encountering elements and attributes outside of the specification's standard namespace. The nice thing about this approach is that allows for innovation in a way that does not cause name collision but which could become part of the standard in the future (and be moved into the standard's namespace). > For the specifications I worked on, we always required that a conformant processor had to do the behavior defined in the specification when it received a conformant document but that the behavior of the processor when it encountered non-standard elements and attributes was at its own discretion -- it could process the attributes, ignore them, or report an error, as it deemed appropriate. > > > So the real question for us here is whether these extension elements are > *extensions* (which do not require a custom element/location) or *expected application-specific information* (which can benefit from custom elements and prescribed locations in the XML tree). > > -- dan > > [1] http://www.w3.org/TR/emma/ > > On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: > >> >> >> On 4/6/2011 8:57 AM, Elwell, John wrote: >>> Yes, I would be keen to hear Peter's or other opinions, but one other > >>> point. One of the properties of XML is that it is human- readable. >>> Having extension data as a child element of the element representing >>> the object to which it applies seems, in my opinion, to make it more >>> readable. Having extension data as a separate element, with a link to > >>> the element to which it applies, seems hard for a human reader, >>> particularly if the link is a long, random string. >> >> IMO human readability of the xml is a secondary/tertiary concern. >> (SIP is in theory readable, but real sip on the wire tends to be >> difficult to read due to need to match up non-ergonomic numeric >> addresses and tags from one message to another.) >> >> I'm inclined to agree it would be better to embed extensions into the >> basic elements, but not primarily due to readability. IMO extensions >> should function as much like the predefined parts as possible. >> (Today's extension may become common usage tomorrow.) >> >> I just don't know enough xml to define this "correctly". >> >> Thanks, >> Paul >> >>> John (as individual) >>> >>> >>>> -----Original Message----- >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>> Sent: 06 April 2011 10:16 >>>> To: Elwell, John; Hadriel Kaplan >>>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >>>> Subject: RE: [siprec] extensionData in XML >>>> >>>> John, >>>> >>>> Please read inline >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Sent: Wednesday, April 06, 2011 2:02 PM >>>> To: Parthasarathi R (partr); Hadriel Kaplan >>>> Cc: siprec@ietf.org; Jain, Rajnish >>>> Subject: RE: [siprec] extensionData in XML >>>> >>>> I already posted on this topic on the other thread. Partha states >>>> below an additional motivation for handling extension data in the >>>> way specified in the current I-D. My counter argument is that anyone > >>>> specifying particular extension data could specify the expected >>>> behaviour when extension data is present in an object and then >>>> absent when that object is updated. For some types of metadata it >>>> could be that absence means it no longer applies, and for other >>>> types of metadata it could be that absence means it has not changed. >>>> >>>> Currently, metadata format draft XML element is written >>>> with the basics that "it is no longer applies" in case specific >>>> element is absent in the update. The question is how the information > >>>> of extensiondata absence means "it is no longer applies" or "it has >>>> not changed" has to be passed between SRC and SRS. Here, there is a >>>> need of common understanding between SRC and SRS or else the >>>> information will be misunderstand even though both parties >>>> understand the specific extension. >>>> >>>> The current extensiondata is taken the route of all other metadata >>>> block XML element definition. There may be better way to represent >>>> in extensiondata XML element apart from creating new metadata block >>>> with URN UUID. I'm including Peter for his advise on XML >>>> front. >>>> >>>> The latter approach would avoid the need for repeating large >>>> quantities of metadata each time there is a minor change to an >>>> object. >>>> >>>> John (as individual) >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>>> R (partr) >>>>> Sent: 03 April 2011 19:46 >>>>> To: Hadriel Kaplan >>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> Hadriel, >>>>> >>>>> I guess we have common understaning to the extend that the >>>> intention >>>>> is to send some extensiondata (Unknown) attribute by SRC >>>> which may or >>>>> may not understand by SRS and also for the usage of xs:any as the >>>>> solution. Few stuff are missing in yours proposal w.r.t >>>> partial data >>>>> passing of extensiondata: >>>>> >>>>> The question is whether there is a need to pass the extension data >>>>> during every time the corresponding metadata block is passed or >>>>> updated. For example, CS metadata block sends extension >>>> data specific >>>>> to call center data like Agent is remote or local, agent or >>>> customer >>>>> initiated call (direction) during the CS block creation >>>> (INVITE) and >>>>> these constant information in extensiondata is not required to be >>>>> passed in each update of CS metadata like adding video >>>> stream in the >>>>> mid-session. >>>>> >>>>> The current model allows to pass extensiondata only during >>>> the initial >>>> >>>>> CS block creation and there is no need to update or resend while CS > >>>>> block is getting updated with other CS information. IMO, >>>> The current >>>>> extensiondata mechanism is required as SIPREC puts lot of >>>> call centre >>>>> specific attributes proposed during metadata model draft review as >>>>> outside the scope of SIPREC and most of the attributes >>>> mentioned are >>>>> constant within the scope of session. >>>>> >>>>> Also, it is possible to pass update only extension data within RS >>>>> session without impacting parent element. Please let me >>>> know your and >>>>> others opinion whethter it is fine to continue with the current >>>>> extension-data element or to move xs:any element to each of the >>>>> metadata block. >>>>> >>>>> Thanks >>>>> Partha >>>>> ________________________________ >>>>> >>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>> Sent: Sat 4/2/2011 6:19 PM >>>>> To: Parthasarathi R (partr) >>>>> Cc: Jain, Rajnish; siprec@ietf.org >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> >>>>> >>>>> Hi Partha, >>>>> I think you're missing my point (or I'm missing yours) - you can do > >>>>> all of that without specifying an "extensionData" XML element. >>>>> Unknown XML elements are simply ignored by the other side, so Cisco > >>>>> can add a "ciscoPrivateData" XML element wherever it wants >>>> and send it >>>> >>>>> to an Acme; and that private element will be ignored by Acme while >>>>> everything else will continue to work. Which I think is >>>> the behavior >>>>> you want, right? >>>>> >>>>> -hadriel >>>>> >>>>> >>>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>>> >>>>>> Hadriel/Raj, >>>>>> >>>>>> Extensiondata XML is provided as per Metadata model >>>>> extensiondata block. >>>>>> During the initial discussion of metadata model draft, we >>>>> realized that >>>>>> lot of attributes specified for recording are call center >>>>> specific or >>>>>> specific domain related and it is outside the scope of IETF >>>>> SIPREC but >>>>>> it is required for those specific solution to work. >>>>> Extensiondata XML >>>>>> element helps to meet those requirement. >>>>>> >>>>>> Extensiondata is provided with URN UUID to pass or not pass >>>>>> independently in partial data. But it is open item whether >>>>> extensiondata >>>>>> has to be within specific metadatablock or not. >>>>>> >>>>>> Please read inline for more comments. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>> Of Jain, Rajnish >>>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>>> Subject: Re: [siprec] extensionData in XML >>>>>> >>>>>> There may be such motivation from how the CSTA standards >>>>> are specified. >>>>>> They have an element called privateData for each message. It is a >>>>>> placeholder for any non-standardized extensions. This could >>>>> be legacy >>>>>> and may not mean much for the modern text based protocols. >>>>>> >>>>>> I really didn't get the reason why is it not >>>>> require for modern >>>>>> text based protocols. This is more like generic param in >>>>> SIP or xs:any >>>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>>> >>>>>> >>>>>> That said, I think you're right (this generally applies >>>> to any text >>>>>> based protocols and is the fundamental basis for forward/backward >>>>>> compatibility in such protocols). >>>>>> >>>>>> Raj >>>>>> >>>>>> >>>>>> ----------------------------------------------------- >>>>>> Please consider the environment before printing this email. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On >>>>>>> Behalf Of Hadriel Kaplan >>>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>>> To: siprec@ietf.org >>>>>>> Subject: [siprec] extensionData in XML >>>>>>> >>>>>>> Howdy, >>>>>>> With regards to the extensionData concept and XML, I have >>>>> a few basic >>>>>>> questions. I am by no means an XML expert so it could >>>>> just be my lack >>>>>> >>>>>>> of knowledge which makes me confused. If so, just tell >>>> me to RTFM. >>>>>>> >>>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>>> A recording metadata object contains additional data not >>>>> specified >>>>>>> as >>>>>>> part of siprec. This is intended to accommodate >>>> future standards >>>>>>> track extensions, as well as vendor and user specific >>>> extensions. >>>>>>> The mechanism MUST provide a means of unambiguously >>>>> distinguishing >>>>>>> such extension data. >>>>>>> >>>>>>> What confuses me is I didn't think XML had to do such >>>>> machinations to >>>>>>> accommodate this need. I thought we could just specify >>>> in our RFCs >>>> >>>>>>> that unknown XML elements and attributes MUST be >>>> ignored, so that >>>>>>> future RFCs could add them without having to leave >>>>> specific "blob" XML >>>>>> >>>>>>> elements to carry such data. Or at least that's what >>>> we've done so >>>> >>>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>>> namespace model that could be used to disambiguate proprietary >>>>>>> elements from standard ones. If both of those theories >>>>> are correct, >>>>>>> why do we need to define an extensionData element? >>>>>>> >>>>>>> -hadriel >>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>>> DISCLAIMER: This e-mail may contain information that is >>>>> confidential, >>>>>> privileged or otherwise protected from disclosure. If you >>>> are not an >>>> >>>>>> intended recipient of this e-mail, do not duplicate or >>>>> redistribute it >>>>>> by any means. Please delete it and any attachments and >>>>> notify the sender >>>>>> that you have received it in error. Unintended recipients >>>>> are prohibited >>>>>> from taking action on the basis of information in this >>>> e-mail.E-mail >>>> >>>>>> messages may contain computer viruses or other defects, >>>> may not be >>>>>> accurately replicated on other systems, or may be >>>>> intercepted, deleted >>>>>> or interfered with without the knowledge of the sender or >>>>> the intended >>>>>> recipient. If you are not comfortable with the risks >>>> associated with >>>> >>>>>> e-mail messages, you may decide not to use e-mail to >>>>> communicate with >>>>>> IPC. IPC reserves the right, to the extent and under >>>> circumstances >>>>>> permitted by applicable law, to retain, monitor and >>>> intercept e-mail >>>> >>>>>> messages to and from its systems. >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From brian.rosen@neustar.biz Mon Jun 6 06:33:01 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1168D11E8149 for ; Mon, 6 Jun 2011 06:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCn6+rxTv33N for ; Mon, 6 Jun 2011 06:32:59 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id E4A0E11E813E for ; Mon, 6 Jun 2011 06:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1307367097; x=1622700350; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=v6QYTd2LwS/ZRiQaux8cW m1NPuBcg4Zmfuxuen8DmfM=; b=DkIKagZzhtZIG1qiscb7G+Re0W2DIxvHYQln6 u9v1vBZk0HOBISWkXqnyAcHpYZRG9mkarnndOiK78jfMFnvZg== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.38149769; Mon, 06 Jun 2011 09:31:36 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 6 Jun 2011 09:31:35 -0400 From: "Rosen, Brian" To: Paul Kyzivat Date: Mon, 6 Jun 2011 09:31:33 -0400 Thread-Topic: [siprec] extensionData in XML Thread-Index: AcwkTg6UAQ7R10IORJSGHH9Z2ypReA== Message-ID: <948BAC33-911A-426F-8E20-AA15F2DE8AC0@neustar.biz> References: <4D9CDFC0.9070300@cisco.com><48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> <07465C1D981ABC41A344374066AE1A2C38AC31EB52@TLVMBX01.nice.com> <4DECD435.9050306@cisco.com> In-Reply-To: <4DECD435.9050306@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: TcQwvNC4GjSnN0bPdROZ4Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 06 Jun 2011 06:38:26 -0700 Cc: "Peter Saint-Andre \(psaintan\)" , "siprec@ietf.org" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:33:01 -0000 I don't understand this. We can define it that way, but AFAIK, there isn't anything in XML standards= that would force that to be true. An extension point like this just allows you to add some new stuff, defined= in a new namespace. All it really does is allow a way for an older implem= entation to ignore what is in there if it doesn't understand it. Brian On Jun 6, 2011, at 9:20 AM, Paul Kyzivat wrote: > I'd like to point out an implication of this approach: > > When you send an update to an entity (in the example its a session) and > include extension data, that extension data applies to the session from > that time forward until changed. > > If you later send another update to the same entity, regardless of your > reason for sending that update, if you fail to include the extension > data again you are saying that the extension data no longer applies to > the session. If you want it to continue to apply you must transmit it > again. That of course means you must remember what extension data you > previously sent, so that you *can* send it again. > > That may be fine. I just don't want people saying they like this > approach without having considered the implications. > > Thanks, > Paul > > On 6/6/2011 4:19 AM, Leon Portman wrote: >> I am ok with the proposal. Looking good >> >> Leon >> >> -----Original Message----- >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >> Sent: Saturday, June 04, 2011 3:54 AM >> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor (kreho= r); Rosen, Brian; HKaplan@acmepacket.com >> Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) >> Subject: RE: [siprec] extensionData in XML >> >> >> Hi all, >> >> Based on the discussion in last interim meeting and mail thread discussi= on on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and= below mail thread, I have not seen anybody looking for separate extensiond= ata metadata XML tag. So, the authors of the draft plans to revise the next= revision with "Extensiondata as an extension within metadata block" and ex= ample is as follows: >> >> > group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >> >> >> sip:alice@cisco.com >> >> >> >> >> In case anybody has difference of opinion, Please let us know by coming = Thursday which helps us to update the next revision. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf= Of Parthasarathi R (partr) >> Sent: Tuesday, April 19, 2011 4:01 PM >> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor >> (krehor) >> Cc: siprec@ietf.org >> Subject: Re: [siprec] extensionData in XML >> >> Dan& all, >> >> Sorry for the late reply. Thanks for sharing your XML experience. >> tag is provided as extensions to SIPREC metadata. The = current approach allows to ignore the extension-data in case SRS does not u= nderstand. >> >> I have added few extensiondata as a note of this mail which were discuss= ed during earlier SIPREC interim meeting. The open question here is whether= the extension-data has to be passed every time (during >> partial-update) within metadata XML tag (participant, session) update or= it is enough to send only when extension-data changes. Partial update of a= ny specific XML elements needs unique id. RFC 5261 recommends to use xml:i= d or type-id as unique attribute. >> >> The following example illustrate three different mechanism for >> extensiondata: >> >> Extensiondata as separate metadata block: (Current format in the draft -= works for partial update, URN UUID is used in all metadata block as of >> now) >> > group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >> >> > id=3D"urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" >> parent=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >> >> sip:alice@cisco.com >> >> >> >> Extensiondata as separate metadata block using xml:id:(Id reduction) >> > group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >> >> > parent=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >> >> sip:alice@cisco.com >> >> >> >> Extensiondata as an extension within metadata block: (Ignore the attribu= te but needs to be passed in each partial updated) >> Example: >> > group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >> >> >> sip:alice@cisco.com >> >> >> >> >> Please let me know which best suites SIPREC metadata. Including Leon& K= en explicitly because they provides lot of Extension data attributes during= the discussion of metadata model. >> >> I'm fine with any of the above approach. >> >> Thanks >> Partha >> >> Note: >> End point information: ip/port, device id (MAC address), DN (used for th= e call, in case of multiline). >> Device type: external, station, IVR, routing point, QUEUE, Gateway, MCU,= Operator, etc Participant Role: caller, called, added, last_redirecting, r= edirecting, conferencing, queing, redirected AgentId, OSLogin >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf= Of Dan Burnett >> Sent: Monday, April 11, 2011 9:15 PM >> To: Paul Kyzivat (pkyzivat) >> Cc: siprec@ietf.org >> Subject: Re: [siprec] extensionData in XML >> >> As someone who works quite a bit with XML, I'll point out that there is = an important distinction between data for extensibility and expected applic= ation-specific data. As an example of the latter, EMMA [1] is an XML forma= t for representing the input of a user (human being, commonly) to an automa= ted system, by speech, gesture, pen, etc. Since the way an input is interp= reted is dependent upon its intended use, there was a need for a designated= application-specific section to represent the semantics (meaning) of the i= nput. >> To make it easier for machine consumers of this format that may be seeki= ng the semantics, there is a designated element "interpretation" >> that holds this information. The contents of this element are arbitrary= XML in an application-specific XML namespace. >> >> On the other hand, every XML specification I've worked on in W3C has >> needed a way for implementers to innovate via extensions. >> Traditionally this is handled via custom elements and attributes in an i= mplementer-specific namespace to avoid name collision with the standard ele= ments and attributes. Since these true innovation extensions can occur any= where, there is no specific XML element established in most specifications = for "extensions". Instead, the specification defines the expected behavior= of a conformant processor upon encountering elements and attributes outsid= e of the specification's standard namespace. The nice thing about this app= roach is that allows for innovation in a way that does not cause name colli= sion but which could become part of the standard in the future (and be move= d into the standard's namespace). >> For the specifications I worked on, we always required that a conformant= processor had to do the behavior defined in the specification when it rece= ived a conformant document but that the behavior of the processor when it e= ncountered non-standard elements and attributes was at its own discretion -= - it could process the attributes, ignore them, or report an error, as it d= eemed appropriate. >> >> >> So the real question for us here is whether these extension elements are >> *extensions* (which do not require a custom element/location) or *expect= ed application-specific information* (which can benefit from custom element= s and prescribed locations in the XML tree). >> >> -- dan >> >> [1] http://www.w3.org/TR/emma/ >> >> On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: >> >>> >>> >>> On 4/6/2011 8:57 AM, Elwell, John wrote: >>>> Yes, I would be keen to hear Peter's or other opinions, but one other >> >>>> point. One of the properties of XML is that it is human- readable. >>>> Having extension data as a child element of the element representing >>>> the object to which it applies seems, in my opinion, to make it more >>>> readable. Having extension data as a separate element, with a link to >> >>>> the element to which it applies, seems hard for a human reader, >>>> particularly if the link is a long, random string. >>> >>> IMO human readability of the xml is a secondary/tertiary concern. >>> (SIP is in theory readable, but real sip on the wire tends to be >>> difficult to read due to need to match up non-ergonomic numeric >>> addresses and tags from one message to another.) >>> >>> I'm inclined to agree it would be better to embed extensions into the >>> basic elements, but not primarily due to readability. IMO extensions >>> should function as much like the predefined parts as possible. >>> (Today's extension may become common usage tomorrow.) >>> >>> I just don't know enough xml to define this "correctly". >>> >>> Thanks, >>> Paul >>> >>>> John (as individual) >>>> >>>> >>>>> -----Original Message----- >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>> Sent: 06 April 2011 10:16 >>>>> To: Elwell, John; Hadriel Kaplan >>>>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >>>>> Subject: RE: [siprec] extensionData in XML >>>>> >>>>> John, >>>>> >>>>> Please read inline >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Wednesday, April 06, 2011 2:02 PM >>>>> To: Parthasarathi R (partr); Hadriel Kaplan >>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>> Subject: RE: [siprec] extensionData in XML >>>>> >>>>> I already posted on this topic on the other thread. Partha states >>>>> below an additional motivation for handling extension data in the >>>>> way specified in the current I-D. My counter argument is that anyone >> >>>>> specifying particular extension data could specify the expected >>>>> behaviour when extension data is present in an object and then >>>>> absent when that object is updated. For some types of metadata it >>>>> could be that absence means it no longer applies, and for other >>>>> types of metadata it could be that absence means it has not changed. >>>>> >>>>> Currently, metadata format draft XML element is written >>>>> with the basics that "it is no longer applies" in case specific >>>>> element is absent in the update. The question is how the information >> >>>>> of extensiondata absence means "it is no longer applies" or "it has >>>>> not changed" has to be passed between SRC and SRS. Here, there is a >>>>> need of common understanding between SRC and SRS or else the >>>>> information will be misunderstand even though both parties >>>>> understand the specific extension. >>>>> >>>>> The current extensiondata is taken the route of all other metadata >>>>> block XML element definition. There may be better way to represent >>>>> in extensiondata XML element apart from creating new metadata block >>>>> with URN UUID. I'm including Peter for his advise on XML >>>>> front. >>>>> >>>>> The latter approach would avoid the need for repeating large >>>>> quantities of metadata each time there is a minor change to an >>>>> object. >>>>> >>>>> John (as individual) >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>>>> R (partr) >>>>>> Sent: 03 April 2011 19:46 >>>>>> To: Hadriel Kaplan >>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>> Subject: Re: [siprec] extensionData in XML >>>>>> >>>>>> Hadriel, >>>>>> >>>>>> I guess we have common understaning to the extend that the >>>>> intention >>>>>> is to send some extensiondata (Unknown) attribute by SRC >>>>> which may or >>>>>> may not understand by SRS and also for the usage of xs:any as the >>>>>> solution. Few stuff are missing in yours proposal w.r.t >>>>> partial data >>>>>> passing of extensiondata: >>>>>> >>>>>> The question is whether there is a need to pass the extension data >>>>>> during every time the corresponding metadata block is passed or >>>>>> updated. For example, CS metadata block sends extension >>>>> data specific >>>>>> to call center data like Agent is remote or local, agent or >>>>> customer >>>>>> initiated call (direction) during the CS block creation >>>>> (INVITE) and >>>>>> these constant information in extensiondata is not required to be >>>>>> passed in each update of CS metadata like adding video >>>>> stream in the >>>>>> mid-session. >>>>>> >>>>>> The current model allows to pass extensiondata only during >>>>> the initial >>>>> >>>>>> CS block creation and there is no need to update or resend while CS >> >>>>>> block is getting updated with other CS information. IMO, >>>>> The current >>>>>> extensiondata mechanism is required as SIPREC puts lot of >>>>> call centre >>>>>> specific attributes proposed during metadata model draft review as >>>>>> outside the scope of SIPREC and most of the attributes >>>>> mentioned are >>>>>> constant within the scope of session. >>>>>> >>>>>> Also, it is possible to pass update only extension data within RS >>>>>> session without impacting parent element. Please let me >>>>> know your and >>>>>> others opinion whethter it is fine to continue with the current >>>>>> extension-data element or to move xs:any element to each of the >>>>>> metadata block. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> ________________________________ >>>>>> >>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>>> Sent: Sat 4/2/2011 6:19 PM >>>>>> To: Parthasarathi R (partr) >>>>>> Cc: Jain, Rajnish; siprec@ietf.org >>>>>> Subject: Re: [siprec] extensionData in XML >>>>>> >>>>>> >>>>>> >>>>>> Hi Partha, >>>>>> I think you're missing my point (or I'm missing yours) - you can do >> >>>>>> all of that without specifying an "extensionData" XML element. >>>>>> Unknown XML elements are simply ignored by the other side, so Cisco >> >>>>>> can add a "ciscoPrivateData" XML element wherever it wants >>>>> and send it >>>>> >>>>>> to an Acme; and that private element will be ignored by Acme while >>>>>> everything else will continue to work. Which I think is >>>>> the behavior >>>>>> you want, right? >>>>>> >>>>>> -hadriel >>>>>> >>>>>> >>>>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>>>> >>>>>>> Hadriel/Raj, >>>>>>> >>>>>>> Extensiondata XML is provided as per Metadata model >>>>>> extensiondata block. >>>>>>> During the initial discussion of metadata model draft, we >>>>>> realized that >>>>>>> lot of attributes specified for recording are call center >>>>>> specific or >>>>>>> specific domain related and it is outside the scope of IETF >>>>>> SIPREC but >>>>>>> it is required for those specific solution to work. >>>>>> Extensiondata XML >>>>>>> element helps to meet those requirement. >>>>>>> >>>>>>> Extensiondata is provided with URN UUID to pass or not pass >>>>>>> independently in partial data. But it is open item whether >>>>>> extensiondata >>>>>>> has to be within specific metadatablock or not. >>>>>>> >>>>>>> Please read inline for more comments. >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>> Of Jain, Rajnish >>>>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>> >>>>>>> There may be such motivation from how the CSTA standards >>>>>> are specified. >>>>>>> They have an element called privateData for each message. It is a >>>>>>> placeholder for any non-standardized extensions. This could >>>>>> be legacy >>>>>>> and may not mean much for the modern text based protocols. >>>>>>> >>>>>>> I really didn't get the reason why is it not >>>>>> require for modern >>>>>>> text based protocols. This is more like generic param in >>>>>> SIP or xs:any >>>>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>>>> >>>>>>> >>>>>>> That said, I think you're right (this generally applies >>>>> to any text >>>>>>> based protocols and is the fundamental basis for forward/backward >>>>>>> compatibility in such protocols). >>>>>>> >>>>>>> Raj >>>>>>> >>>>>>> >>>>>>> ----------------------------------------------------- >>>>>>> Please consider the environment before printing this email. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>> Behalf Of Hadriel Kaplan >>>>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>>>> To: siprec@ietf.org >>>>>>>> Subject: [siprec] extensionData in XML >>>>>>>> >>>>>>>> Howdy, >>>>>>>> With regards to the extensionData concept and XML, I have >>>>>> a few basic >>>>>>>> questions. I am by no means an XML expert so it could >>>>>> just be my lack >>>>>>> >>>>>>>> of knowledge which makes me confused. If so, just tell >>>>> me to RTFM. >>>>>>>> >>>>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>>>> A recording metadata object contains additional data not >>>>>> specified >>>>>>>> as >>>>>>>> part of siprec. This is intended to accommodate >>>>> future standards >>>>>>>> track extensions, as well as vendor and user specific >>>>> extensions. >>>>>>>> The mechanism MUST provide a means of unambiguously >>>>>> distinguishing >>>>>>>> such extension data. >>>>>>>> >>>>>>>> What confuses me is I didn't think XML had to do such >>>>>> machinations to >>>>>>>> accommodate this need. I thought we could just specify >>>>> in our RFCs >>>>> >>>>>>>> that unknown XML elements and attributes MUST be >>>>> ignored, so that >>>>>>>> future RFCs could add them without having to leave >>>>>> specific "blob" XML >>>>>>> >>>>>>>> elements to carry such data. Or at least that's what >>>>> we've done so >>>>> >>>>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>>>> namespace model that could be used to disambiguate proprietary >>>>>>>> elements from standard ones. If both of those theories >>>>>> are correct, >>>>>>>> why do we need to define an extensionData element? >>>>>>>> >>>>>>>> -hadriel >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>>> DISCLAIMER: This e-mail may contain information that is >>>>>> confidential, >>>>>>> privileged or otherwise protected from disclosure. If you >>>>> are not an >>>>> >>>>>>> intended recipient of this e-mail, do not duplicate or >>>>>> redistribute it >>>>>>> by any means. Please delete it and any attachments and >>>>>> notify the sender >>>>>>> that you have received it in error. Unintended recipients >>>>>> are prohibited >>>>>>> from taking action on the basis of information in this >>>>> e-mail.E-mail >>>>> >>>>>>> messages may contain computer viruses or other defects, >>>>> may not be >>>>>>> accurately replicated on other systems, or may be >>>>>> intercepted, deleted >>>>>>> or interfered with without the knowledge of the sender or >>>>>> the intended >>>>>>> recipient. If you are not comfortable with the risks >>>>> associated with >>>>> >>>>>>> e-mail messages, you may decide not to use e-mail to >>>>>> communicate with >>>>>>> IPC. IPC reserves the right, to the extent and under >>>>> circumstances >>>>>>> permitted by applicable law, to retain, monitor and >>>>> intercept e-mail >>>>> >>>>>>> messages to and from its systems. >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> From Leon.Portman@nice.com Mon Jun 6 06:39:23 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4F511E813C for ; Mon, 6 Jun 2011 06:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdx10WV9zAXS for ; Mon, 6 Jun 2011 06:39:21 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8E11E811E for ; Mon, 6 Jun 2011 06:39:20 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 6 Jun 2011 16:39:19 +0300 From: Leon Portman To: "Rosen, Brian" , Paul Kyzivat Date: Mon, 6 Jun 2011 16:39:18 +0300 Thread-Topic: [siprec] extensionData in XML Thread-Index: AcwkTg6UAQ7R10IORJSGHH9Z2ypReAAAOpeQ Message-ID: <07465C1D981ABC41A344374066AE1A2C38AC31EDBD@TLVMBX01.nice.com> References: <4D9CDFC0.9070300@cisco.com><48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> <07465C1D981ABC41A344374066AE1A2C38AC31EB52@TLVMBX01.nice.com> <4DECD435.9050306@cisco.com> <948BAC33-911A-426F-8E20-AA15F2DE8AC0@neustar.biz> In-Reply-To: <948BAC33-911A-426F-8E20-AA15F2DE8AC0@neustar.biz> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Peter Saint-Andre \(psaintan\)" , "siprec@ietf.org" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:39:23 -0000 Paul Hi The behavior that you have described below is consistent with any other par= tial updates. I do assume that in snapshot we will report the most update e= xtension data, correct? Regards Leon -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Monday, June 06, 2011 4:32 PM To: Paul Kyzivat Cc: Leon Portman; Parthasarathi R (partr); Dan Burnett; Ken Rehor (krehor);= HKaplan@acmepacket.com; siprec@ietf.org; Peter Saint-Andre (psaintan) Subject: Re: [siprec] extensionData in XML I don't understand this. We can define it that way, but AFAIK, there isn't anything in XML standards= that would force that to be true. An extension point like this just allows you to add some new stuff, defined= in a new namespace. All it really does is allow a way for an older implem= entation to ignore what is in there if it doesn't understand it. Brian On Jun 6, 2011, at 9:20 AM, Paul Kyzivat wrote: > I'd like to point out an implication of this approach: > > When you send an update to an entity (in the example its a session) > and include extension data, that extension data applies to the session > from that time forward until changed. > > If you later send another update to the same entity, regardless of > your reason for sending that update, if you fail to include the > extension data again you are saying that the extension data no longer > applies to the session. If you want it to continue to apply you must > transmit it again. That of course means you must remember what > extension data you previously sent, so that you *can* send it again. > > That may be fine. I just don't want people saying they like this > approach without having considered the implications. > > Thanks, > Paul > > On 6/6/2011 4:19 AM, Leon Portman wrote: >> I am ok with the proposal. Looking good >> >> Leon >> >> -----Original Message----- >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >> Sent: Saturday, June 04, 2011 3:54 AM >> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor >> (krehor); Rosen, Brian; HKaplan@acmepacket.com >> Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) >> Subject: RE: [siprec] extensionData in XML >> >> >> Hi all, >> >> Based on the discussion in last interim meeting and mail thread discussi= on on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and= below mail thread, I have not seen anybody looking for separate extensiond= ata metadata XML tag. So, the authors of the draft plans to revise the next= revision with "Extensiondata as an extension within metadata block" and ex= ample is as follows: >> >> > group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >> >> >> sip:alice@cisco.com >> >> >> >> >> In case anybody has difference of opinion, Please let us know by coming = Thursday which helps us to update the next revision. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Parthasarathi R (partr) >> Sent: Tuesday, April 19, 2011 4:01 PM >> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor >> (krehor) >> Cc: siprec@ietf.org >> Subject: Re: [siprec] extensionData in XML >> >> Dan& all, >> >> Sorry for the late reply. Thanks for sharing your XML experience. >> tag is provided as extensions to SIPREC metadata. The = current approach allows to ignore the extension-data in case SRS does not u= nderstand. >> >> I have added few extensiondata as a note of this mail which were >> discussed during earlier SIPREC interim meeting. The open question >> here is whether the extension-data has to be passed every time >> (during >> partial-update) within metadata XML tag (participant, session) update or= it is enough to send only when extension-data changes. Partial update of a= ny specific XML elements needs unique id. RFC 5261 recommends to use xml:i= d or type-id as unique attribute. >> >> The following example illustrate three different mechanism for >> extensiondata: >> >> Extensiondata as separate metadata block: (Current format in the >> draft - works for partial update, URN UUID is used in all metadata >> block as of >> now) >> > group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >> >> > id=3D"urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" >> parent=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >> >> sip:alice@cisco.com >> >> >> >> Extensiondata as separate metadata block using xml:id:(Id reduction) >> > group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >> >> > parent=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >> >> sip:alice@cisco.com >> >> >> >> Extensiondata as an extension within metadata block: (Ignore the >> attribute but needs to be passed in each partial updated) >> Example: >> > group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >> >> >> sip:alice@cisco.com >> >> >> >> >> Please let me know which best suites SIPREC metadata. Including Leon& K= en explicitly because they provides lot of Extension data attributes during= the discussion of metadata model. >> >> I'm fine with any of the above approach. >> >> Thanks >> Partha >> >> Note: >> End point information: ip/port, device id (MAC address), DN (used for th= e call, in case of multiline). >> Device type: external, station, IVR, routing point, QUEUE, Gateway, >> MCU, Operator, etc Participant Role: caller, called, added, >> last_redirecting, redirecting, conferencing, queing, redirected >> AgentId, OSLogin >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Dan Burnett >> Sent: Monday, April 11, 2011 9:15 PM >> To: Paul Kyzivat (pkyzivat) >> Cc: siprec@ietf.org >> Subject: Re: [siprec] extensionData in XML >> >> As someone who works quite a bit with XML, I'll point out that there is = an important distinction between data for extensibility and expected applic= ation-specific data. As an example of the latter, EMMA [1] is an XML forma= t for representing the input of a user (human being, commonly) to an automa= ted system, by speech, gesture, pen, etc. Since the way an input is interp= reted is dependent upon its intended use, there was a need for a designated= application-specific section to represent the semantics (meaning) of the i= nput. >> To make it easier for machine consumers of this format that may be seeki= ng the semantics, there is a designated element "interpretation" >> that holds this information. The contents of this element are arbitrary= XML in an application-specific XML namespace. >> >> On the other hand, every XML specification I've worked on in W3C has >> needed a way for implementers to innovate via extensions. >> Traditionally this is handled via custom elements and attributes in an i= mplementer-specific namespace to avoid name collision with the standard ele= ments and attributes. Since these true innovation extensions can occur any= where, there is no specific XML element established in most specifications = for "extensions". Instead, the specification defines the expected behavior= of a conformant processor upon encountering elements and attributes outsid= e of the specification's standard namespace. The nice thing about this app= roach is that allows for innovation in a way that does not cause name colli= sion but which could become part of the standard in the future (and be move= d into the standard's namespace). >> For the specifications I worked on, we always required that a conformant= processor had to do the behavior defined in the specification when it rece= ived a conformant document but that the behavior of the processor when it e= ncountered non-standard elements and attributes was at its own discretion -= - it could process the attributes, ignore them, or report an error, as it d= eemed appropriate. >> >> >> So the real question for us here is whether these extension elements >> are >> *extensions* (which do not require a custom element/location) or *expect= ed application-specific information* (which can benefit from custom element= s and prescribed locations in the XML tree). >> >> -- dan >> >> [1] http://www.w3.org/TR/emma/ >> >> On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: >> >>> >>> >>> On 4/6/2011 8:57 AM, Elwell, John wrote: >>>> Yes, I would be keen to hear Peter's or other opinions, but one >>>> other >> >>>> point. One of the properties of XML is that it is human- readable. >>>> Having extension data as a child element of the element >>>> representing the object to which it applies seems, in my opinion, >>>> to make it more readable. Having extension data as a separate >>>> element, with a link to >> >>>> the element to which it applies, seems hard for a human reader, >>>> particularly if the link is a long, random string. >>> >>> IMO human readability of the xml is a secondary/tertiary concern. >>> (SIP is in theory readable, but real sip on the wire tends to be >>> difficult to read due to need to match up non-ergonomic numeric >>> addresses and tags from one message to another.) >>> >>> I'm inclined to agree it would be better to embed extensions into >>> the basic elements, but not primarily due to readability. IMO >>> extensions should function as much like the predefined parts as possibl= e. >>> (Today's extension may become common usage tomorrow.) >>> >>> I just don't know enough xml to define this "correctly". >>> >>> Thanks, >>> Paul >>> >>>> John (as individual) >>>> >>>> >>>>> -----Original Message----- >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>> Sent: 06 April 2011 10:16 >>>>> To: Elwell, John; Hadriel Kaplan >>>>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >>>>> Subject: RE: [siprec] extensionData in XML >>>>> >>>>> John, >>>>> >>>>> Please read inline >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Wednesday, April 06, 2011 2:02 PM >>>>> To: Parthasarathi R (partr); Hadriel Kaplan >>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>> Subject: RE: [siprec] extensionData in XML >>>>> >>>>> I already posted on this topic on the other thread. Partha states >>>>> below an additional motivation for handling extension data in the >>>>> way specified in the current I-D. My counter argument is that >>>>> anyone >> >>>>> specifying particular extension data could specify the expected >>>>> behaviour when extension data is present in an object and then >>>>> absent when that object is updated. For some types of metadata it >>>>> could be that absence means it no longer applies, and for other >>>>> types of metadata it could be that absence means it has not changed. >>>>> >>>>> Currently, metadata format draft XML element is written >>>>> with the basics that "it is no longer applies" in case specific >>>>> element is absent in the update. The question is how the >>>>> information >> >>>>> of extensiondata absence means "it is no longer applies" or "it >>>>> has not changed" has to be passed between SRC and SRS. Here, there >>>>> is a need of common understanding between SRC and SRS or else the >>>>> information will be misunderstand even though both parties >>>>> understand the specific extension. >>>>> >>>>> The current extensiondata is taken the route of all other metadata >>>>> block XML element definition. There may be better way to represent >>>>> in extensiondata XML element apart from creating new metadata >>>>> block with URN UUID. I'm including Peter for his advise on XML >>>>> front. >>>>> >>>>> The latter approach would avoid the need for repeating large >>>>> quantities of metadata each time there is a minor change to an >>>>> object. >>>>> >>>>> John (as individual) >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>>>> R (partr) >>>>>> Sent: 03 April 2011 19:46 >>>>>> To: Hadriel Kaplan >>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>> Subject: Re: [siprec] extensionData in XML >>>>>> >>>>>> Hadriel, >>>>>> >>>>>> I guess we have common understaning to the extend that the >>>>> intention >>>>>> is to send some extensiondata (Unknown) attribute by SRC >>>>> which may or >>>>>> may not understand by SRS and also for the usage of xs:any as the >>>>>> solution. Few stuff are missing in yours proposal w.r.t >>>>> partial data >>>>>> passing of extensiondata: >>>>>> >>>>>> The question is whether there is a need to pass the extension >>>>>> data during every time the corresponding metadata block is passed >>>>>> or updated. For example, CS metadata block sends extension >>>>> data specific >>>>>> to call center data like Agent is remote or local, agent or >>>>> customer >>>>>> initiated call (direction) during the CS block creation >>>>> (INVITE) and >>>>>> these constant information in extensiondata is not required to be >>>>>> passed in each update of CS metadata like adding video >>>>> stream in the >>>>>> mid-session. >>>>>> >>>>>> The current model allows to pass extensiondata only during >>>>> the initial >>>>> >>>>>> CS block creation and there is no need to update or resend while >>>>>> CS >> >>>>>> block is getting updated with other CS information. IMO, >>>>> The current >>>>>> extensiondata mechanism is required as SIPREC puts lot of >>>>> call centre >>>>>> specific attributes proposed during metadata model draft review >>>>>> as outside the scope of SIPREC and most of the attributes >>>>> mentioned are >>>>>> constant within the scope of session. >>>>>> >>>>>> Also, it is possible to pass update only extension data within RS >>>>>> session without impacting parent element. Please let me >>>>> know your and >>>>>> others opinion whethter it is fine to continue with the current >>>>>> extension-data element or to move xs:any element to each of the >>>>>> metadata block. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> ________________________________ >>>>>> >>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>>> Sent: Sat 4/2/2011 6:19 PM >>>>>> To: Parthasarathi R (partr) >>>>>> Cc: Jain, Rajnish; siprec@ietf.org >>>>>> Subject: Re: [siprec] extensionData in XML >>>>>> >>>>>> >>>>>> >>>>>> Hi Partha, >>>>>> I think you're missing my point (or I'm missing yours) - you can >>>>>> do >> >>>>>> all of that without specifying an "extensionData" XML element. >>>>>> Unknown XML elements are simply ignored by the other side, so >>>>>> Cisco >> >>>>>> can add a "ciscoPrivateData" XML element wherever it wants >>>>> and send it >>>>> >>>>>> to an Acme; and that private element will be ignored by Acme >>>>>> while everything else will continue to work. Which I think is >>>>> the behavior >>>>>> you want, right? >>>>>> >>>>>> -hadriel >>>>>> >>>>>> >>>>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>>>> >>>>>>> Hadriel/Raj, >>>>>>> >>>>>>> Extensiondata XML is provided as per Metadata model >>>>>> extensiondata block. >>>>>>> During the initial discussion of metadata model draft, we >>>>>> realized that >>>>>>> lot of attributes specified for recording are call center >>>>>> specific or >>>>>>> specific domain related and it is outside the scope of IETF >>>>>> SIPREC but >>>>>>> it is required for those specific solution to work. >>>>>> Extensiondata XML >>>>>>> element helps to meet those requirement. >>>>>>> >>>>>>> Extensiondata is provided with URN UUID to pass or not pass >>>>>>> independently in partial data. But it is open item whether >>>>>> extensiondata >>>>>>> has to be within specific metadatablock or not. >>>>>>> >>>>>>> Please read inline for more comments. >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>> Of Jain, Rajnish >>>>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>> >>>>>>> There may be such motivation from how the CSTA standards >>>>>> are specified. >>>>>>> They have an element called privateData for each message. It is >>>>>>> a placeholder for any non-standardized extensions. This could >>>>>> be legacy >>>>>>> and may not mean much for the modern text based protocols. >>>>>>> >>>>>>> I really didn't get the reason why is it not >>>>>> require for modern >>>>>>> text based protocols. This is more like generic param in >>>>>> SIP or xs:any >>>>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>>>> >>>>>>> >>>>>>> That said, I think you're right (this generally applies >>>>> to any text >>>>>>> based protocols and is the fundamental basis for >>>>>>> forward/backward compatibility in such protocols). >>>>>>> >>>>>>> Raj >>>>>>> >>>>>>> >>>>>>> ----------------------------------------------------- >>>>>>> Please consider the environment before printing this email. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>> Behalf Of Hadriel Kaplan >>>>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>>>> To: siprec@ietf.org >>>>>>>> Subject: [siprec] extensionData in XML >>>>>>>> >>>>>>>> Howdy, >>>>>>>> With regards to the extensionData concept and XML, I have >>>>>> a few basic >>>>>>>> questions. I am by no means an XML expert so it could >>>>>> just be my lack >>>>>>> >>>>>>>> of knowledge which makes me confused. If so, just tell >>>>> me to RTFM. >>>>>>>> >>>>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>>>> A recording metadata object contains additional data not >>>>>> specified >>>>>>>> as >>>>>>>> part of siprec. This is intended to accommodate >>>>> future standards >>>>>>>> track extensions, as well as vendor and user specific >>>>> extensions. >>>>>>>> The mechanism MUST provide a means of unambiguously >>>>>> distinguishing >>>>>>>> such extension data. >>>>>>>> >>>>>>>> What confuses me is I didn't think XML had to do such >>>>>> machinations to >>>>>>>> accommodate this need. I thought we could just specify >>>>> in our RFCs >>>>> >>>>>>>> that unknown XML elements and attributes MUST be >>>>> ignored, so that >>>>>>>> future RFCs could add them without having to leave >>>>>> specific "blob" XML >>>>>>> >>>>>>>> elements to carry such data. Or at least that's what >>>>> we've done so >>>>> >>>>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>>>> namespace model that could be used to disambiguate proprietary >>>>>>>> elements from standard ones. If both of those theories >>>>>> are correct, >>>>>>>> why do we need to define an extensionData element? >>>>>>>> >>>>>>>> -hadriel >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>>> DISCLAIMER: This e-mail may contain information that is >>>>>> confidential, >>>>>>> privileged or otherwise protected from disclosure. If you >>>>> are not an >>>>> >>>>>>> intended recipient of this e-mail, do not duplicate or >>>>>> redistribute it >>>>>>> by any means. Please delete it and any attachments and >>>>>> notify the sender >>>>>>> that you have received it in error. Unintended recipients >>>>>> are prohibited >>>>>>> from taking action on the basis of information in this >>>>> e-mail.E-mail >>>>> >>>>>>> messages may contain computer viruses or other defects, >>>>> may not be >>>>>>> accurately replicated on other systems, or may be >>>>>> intercepted, deleted >>>>>>> or interfered with without the knowledge of the sender or >>>>>> the intended >>>>>>> recipient. If you are not comfortable with the risks >>>>> associated with >>>>> >>>>>>> e-mail messages, you may decide not to use e-mail to >>>>>> communicate with >>>>>>> IPC. IPC reserves the right, to the extent and under >>>>> circumstances >>>>>>> permitted by applicable law, to retain, monitor and >>>>> intercept e-mail >>>>> >>>>>>> messages to and from its systems. >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> From pkyzivat@cisco.com Mon Jun 6 06:52:21 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D51311E8145 for ; Mon, 6 Jun 2011 06:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.699 X-Spam-Level: X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuVtSg2OIGiN for ; Mon, 6 Jun 2011 06:52:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4000711E80F7 for ; Mon, 6 Jun 2011 06:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=22911; q=dns/txt; s=iport; t=1307368339; x=1308577939; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vpp4BeO319jd+G/svhJ1LWHPBkcPyH8KJxLAnUwqW2E=; b=mDAp4A/0QXpcqDqNCx1NalWTGyF2SkUgNAr1vFsdbIuKApxLHlZen6+u vpvXzhCB8kT8ORGl6FX56j6Cf9UyvBSyObmfgbkh2rs45fA/3sprqinZJ uViGs7DE58PfGCfxnf2rF93nw55oO+TJLiPhlAEzihtheTWDtDQu0B633 c=; X-IronPort-AV: E=Sophos;i="4.65,326,1304294400"; d="scan'208";a="708806304" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2011 13:52:18 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p56DqGSc026523; Mon, 6 Jun 2011 13:52:16 GMT Message-ID: <4DECDB90.5080704@cisco.com> Date: Mon, 06 Jun 2011 09:52:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Rosen, Brian" References: <4D9CDFC0.9070300@cisco.com><48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> <07465C1D981ABC41A344374066AE1A2C38AC31EB52@TLVMBX01.nice.com> <4DECD435.9050306@cisco.com> <948BAC33-911A-426F-8E20-AA15F2DE8AC0@neustar.biz> In-Reply-To: <948BAC33-911A-426F-8E20-AA15F2DE8AC0@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Peter Saint-Andre \(psaintan\)" , "siprec@ietf.org" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:52:21 -0000 Brian, Yeah, this isn't about xml itself, its about how we are using it. This is the approach taken for all the data in updates to elements. I guess we could define this as a one-off, or else we could define it as a sub-element by sub-element property. But that would seem to be confusing. Also, if you did this, then it gets hard to do the converse if you do want to remove the extension data for the remainder of a session. Thanks, Paul On 6/6/2011 9:31 AM, Rosen, Brian wrote: > I don't understand this. > > We can define it that way, but AFAIK, there isn't anything in XML standards that would force that to be true. > > An extension point like this just allows you to add some new stuff, defined in a new namespace. All it really does is allow a way for an older implementation to ignore what is in there if it doesn't understand it. > > Brian > > On Jun 6, 2011, at 9:20 AM, Paul Kyzivat wrote: > >> I'd like to point out an implication of this approach: >> >> When you send an update to an entity (in the example its a session) and >> include extension data, that extension data applies to the session from >> that time forward until changed. >> >> If you later send another update to the same entity, regardless of your >> reason for sending that update, if you fail to include the extension >> data again you are saying that the extension data no longer applies to >> the session. If you want it to continue to apply you must transmit it >> again. That of course means you must remember what extension data you >> previously sent, so that you *can* send it again. >> >> That may be fine. I just don't want people saying they like this >> approach without having considered the implications. >> >> Thanks, >> Paul >> >> On 6/6/2011 4:19 AM, Leon Portman wrote: >>> I am ok with the proposal. Looking good >>> >>> Leon >>> >>> -----Original Message----- >>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>> Sent: Saturday, June 04, 2011 3:54 AM >>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor (krehor); Rosen, Brian; HKaplan@acmepacket.com >>> Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) >>> Subject: RE: [siprec] extensionData in XML >>> >>> >>> Hi all, >>> >>> Based on the discussion in last interim meeting and mail thread discussion on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and below mail thread, I have not seen anybody looking for separate extensiondata metadata XML tag. So, the authors of the draft plans to revise the next revision with "Extensiondata as an extension within metadata block" and example is as follows: >>> >>> >> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>> >>> >>> sip:alice@cisco.com >>> >>> >>> >>> >>> In case anybody has difference of opinion, Please let us know by coming Thursday which helps us to update the next revision. >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) >>> Sent: Tuesday, April 19, 2011 4:01 PM >>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor >>> (krehor) >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] extensionData in XML >>> >>> Dan& all, >>> >>> Sorry for the late reply. Thanks for sharing your XML experience. >>> tag is provided as extensions to SIPREC metadata. The current approach allows to ignore the extension-data in case SRS does not understand. >>> >>> I have added few extensiondata as a note of this mail which were discussed during earlier SIPREC interim meeting. The open question here is whether the extension-data has to be passed every time (during >>> partial-update) within metadata XML tag (participant, session) update or it is enough to send only when extension-data changes. Partial update of any specific XML elements needs unique id. RFC 5261 recommends to use xml:id or type-id as unique attribute. >>> >>> The following example illustrate three different mechanism for >>> extensiondata: >>> >>> Extensiondata as separate metadata block: (Current format in the draft - works for partial update, URN UUID is used in all metadata block as of >>> now) >>> >> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>> >>> >> id="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" >>> parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>> >>> sip:alice@cisco.com >>> >>> >>> >>> Extensiondata as separate metadata block using xml:id:(Id reduction) >>> >> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>> >>> >> parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>> >>> sip:alice@cisco.com >>> >>> >>> >>> Extensiondata as an extension within metadata block: (Ignore the attribute but needs to be passed in each partial updated) >>> Example: >>> >> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>> >>> >>> sip:alice@cisco.com >>> >>> >>> >>> >>> Please let me know which best suites SIPREC metadata. Including Leon& Ken explicitly because they provides lot of Extension data attributes during the discussion of metadata model. >>> >>> I'm fine with any of the above approach. >>> >>> Thanks >>> Partha >>> >>> Note: >>> End point information: ip/port, device id (MAC address), DN (used for the call, in case of multiline). >>> Device type: external, station, IVR, routing point, QUEUE, Gateway, MCU, Operator, etc Participant Role: caller, called, added, last_redirecting, redirecting, conferencing, queing, redirected AgentId, OSLogin >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Dan Burnett >>> Sent: Monday, April 11, 2011 9:15 PM >>> To: Paul Kyzivat (pkyzivat) >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] extensionData in XML >>> >>> As someone who works quite a bit with XML, I'll point out that there is an important distinction between data for extensibility and expected application-specific data. As an example of the latter, EMMA [1] is an XML format for representing the input of a user (human being, commonly) to an automated system, by speech, gesture, pen, etc. Since the way an input is interpreted is dependent upon its intended use, there was a need for a designated application-specific section to represent the semantics (meaning) of the input. >>> To make it easier for machine consumers of this format that may be seeking the semantics, there is a designated element "interpretation" >>> that holds this information. The contents of this element are arbitrary XML in an application-specific XML namespace. >>> >>> On the other hand, every XML specification I've worked on in W3C has >>> needed a way for implementers to innovate via extensions. >>> Traditionally this is handled via custom elements and attributes in an implementer-specific namespace to avoid name collision with the standard elements and attributes. Since these true innovation extensions can occur anywhere, there is no specific XML element established in most specifications for "extensions". Instead, the specification defines the expected behavior of a conformant processor upon encountering elements and attributes outside of the specification's standard namespace. The nice thing about this approach is that allows for innovation in a way that does not cause name collision but which could become part of the standard in the future (and be moved into the standard's namespace). >>> For the specifications I worked on, we always required that a conformant processor had to do the behavior defined in the specification when it received a conformant document but that the behavior of the processor when it encountered non-standard elements and attributes was at its own discretion -- it could process the attributes, ignore them, or report an error, as it deemed appropriate. >>> >>> >>> So the real question for us here is whether these extension elements are >>> *extensions* (which do not require a custom element/location) or *expected application-specific information* (which can benefit from custom elements and prescribed locations in the XML tree). >>> >>> -- dan >>> >>> [1] http://www.w3.org/TR/emma/ >>> >>> On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: >>> >>>> >>>> >>>> On 4/6/2011 8:57 AM, Elwell, John wrote: >>>>> Yes, I would be keen to hear Peter's or other opinions, but one other >>> >>>>> point. One of the properties of XML is that it is human- readable. >>>>> Having extension data as a child element of the element representing >>>>> the object to which it applies seems, in my opinion, to make it more >>>>> readable. Having extension data as a separate element, with a link to >>> >>>>> the element to which it applies, seems hard for a human reader, >>>>> particularly if the link is a long, random string. >>>> >>>> IMO human readability of the xml is a secondary/tertiary concern. >>>> (SIP is in theory readable, but real sip on the wire tends to be >>>> difficult to read due to need to match up non-ergonomic numeric >>>> addresses and tags from one message to another.) >>>> >>>> I'm inclined to agree it would be better to embed extensions into the >>>> basic elements, but not primarily due to readability. IMO extensions >>>> should function as much like the predefined parts as possible. >>>> (Today's extension may become common usage tomorrow.) >>>> >>>> I just don't know enough xml to define this "correctly". >>>> >>>> Thanks, >>>> Paul >>>> >>>>> John (as individual) >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>> Sent: 06 April 2011 10:16 >>>>>> To: Elwell, John; Hadriel Kaplan >>>>>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >>>>>> Subject: RE: [siprec] extensionData in XML >>>>>> >>>>>> John, >>>>>> >>>>>> Please read inline >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>> Sent: Wednesday, April 06, 2011 2:02 PM >>>>>> To: Parthasarathi R (partr); Hadriel Kaplan >>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>> Subject: RE: [siprec] extensionData in XML >>>>>> >>>>>> I already posted on this topic on the other thread. Partha states >>>>>> below an additional motivation for handling extension data in the >>>>>> way specified in the current I-D. My counter argument is that anyone >>> >>>>>> specifying particular extension data could specify the expected >>>>>> behaviour when extension data is present in an object and then >>>>>> absent when that object is updated. For some types of metadata it >>>>>> could be that absence means it no longer applies, and for other >>>>>> types of metadata it could be that absence means it has not changed. >>>>>> >>>>>> Currently, metadata format draft XML element is written >>>>>> with the basics that "it is no longer applies" in case specific >>>>>> element is absent in the update. The question is how the information >>> >>>>>> of extensiondata absence means "it is no longer applies" or "it has >>>>>> not changed" has to be passed between SRC and SRS. Here, there is a >>>>>> need of common understanding between SRC and SRS or else the >>>>>> information will be misunderstand even though both parties >>>>>> understand the specific extension. >>>>>> >>>>>> The current extensiondata is taken the route of all other metadata >>>>>> block XML element definition. There may be better way to represent >>>>>> in extensiondata XML element apart from creating new metadata block >>>>>> with URN UUID. I'm including Peter for his advise on XML >>>>>> front. >>>>>> >>>>>> The latter approach would avoid the need for repeating large >>>>>> quantities of metadata each time there is a minor change to an >>>>>> object. >>>>>> >>>>>> John (as individual) >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>>>>> R (partr) >>>>>>> Sent: 03 April 2011 19:46 >>>>>>> To: Hadriel Kaplan >>>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>> >>>>>>> Hadriel, >>>>>>> >>>>>>> I guess we have common understaning to the extend that the >>>>>> intention >>>>>>> is to send some extensiondata (Unknown) attribute by SRC >>>>>> which may or >>>>>>> may not understand by SRS and also for the usage of xs:any as the >>>>>>> solution. Few stuff are missing in yours proposal w.r.t >>>>>> partial data >>>>>>> passing of extensiondata: >>>>>>> >>>>>>> The question is whether there is a need to pass the extension data >>>>>>> during every time the corresponding metadata block is passed or >>>>>>> updated. For example, CS metadata block sends extension >>>>>> data specific >>>>>>> to call center data like Agent is remote or local, agent or >>>>>> customer >>>>>>> initiated call (direction) during the CS block creation >>>>>> (INVITE) and >>>>>>> these constant information in extensiondata is not required to be >>>>>>> passed in each update of CS metadata like adding video >>>>>> stream in the >>>>>>> mid-session. >>>>>>> >>>>>>> The current model allows to pass extensiondata only during >>>>>> the initial >>>>>> >>>>>>> CS block creation and there is no need to update or resend while CS >>> >>>>>>> block is getting updated with other CS information. IMO, >>>>>> The current >>>>>>> extensiondata mechanism is required as SIPREC puts lot of >>>>>> call centre >>>>>>> specific attributes proposed during metadata model draft review as >>>>>>> outside the scope of SIPREC and most of the attributes >>>>>> mentioned are >>>>>>> constant within the scope of session. >>>>>>> >>>>>>> Also, it is possible to pass update only extension data within RS >>>>>>> session without impacting parent element. Please let me >>>>>> know your and >>>>>>> others opinion whethter it is fine to continue with the current >>>>>>> extension-data element or to move xs:any element to each of the >>>>>>> metadata block. >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> ________________________________ >>>>>>> >>>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>>>> Sent: Sat 4/2/2011 6:19 PM >>>>>>> To: Parthasarathi R (partr) >>>>>>> Cc: Jain, Rajnish; siprec@ietf.org >>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Partha, >>>>>>> I think you're missing my point (or I'm missing yours) - you can do >>> >>>>>>> all of that without specifying an "extensionData" XML element. >>>>>>> Unknown XML elements are simply ignored by the other side, so Cisco >>> >>>>>>> can add a "ciscoPrivateData" XML element wherever it wants >>>>>> and send it >>>>>> >>>>>>> to an Acme; and that private element will be ignored by Acme while >>>>>>> everything else will continue to work. Which I think is >>>>>> the behavior >>>>>>> you want, right? >>>>>>> >>>>>>> -hadriel >>>>>>> >>>>>>> >>>>>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>>>>> >>>>>>>> Hadriel/Raj, >>>>>>>> >>>>>>>> Extensiondata XML is provided as per Metadata model >>>>>>> extensiondata block. >>>>>>>> During the initial discussion of metadata model draft, we >>>>>>> realized that >>>>>>>> lot of attributes specified for recording are call center >>>>>>> specific or >>>>>>>> specific domain related and it is outside the scope of IETF >>>>>>> SIPREC but >>>>>>>> it is required for those specific solution to work. >>>>>>> Extensiondata XML >>>>>>>> element helps to meet those requirement. >>>>>>>> >>>>>>>> Extensiondata is provided with URN UUID to pass or not pass >>>>>>>> independently in partial data. But it is open item whether >>>>>>> extensiondata >>>>>>>> has to be within specific metadatablock or not. >>>>>>>> >>>>>>>> Please read inline for more comments. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>>> Of Jain, Rajnish >>>>>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>> >>>>>>>> There may be such motivation from how the CSTA standards >>>>>>> are specified. >>>>>>>> They have an element called privateData for each message. It is a >>>>>>>> placeholder for any non-standardized extensions. This could >>>>>>> be legacy >>>>>>>> and may not mean much for the modern text based protocols. >>>>>>>> >>>>>>>> I really didn't get the reason why is it not >>>>>>> require for modern >>>>>>>> text based protocols. This is more like generic param in >>>>>>> SIP or xs:any >>>>>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>>>>> >>>>>>>> >>>>>>>> That said, I think you're right (this generally applies >>>>>> to any text >>>>>>>> based protocols and is the fundamental basis for forward/backward >>>>>>>> compatibility in such protocols). >>>>>>>> >>>>>>>> Raj >>>>>>>> >>>>>>>> >>>>>>>> ----------------------------------------------------- >>>>>>>> Please consider the environment before printing this email. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>> Behalf Of Hadriel Kaplan >>>>>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: [siprec] extensionData in XML >>>>>>>>> >>>>>>>>> Howdy, >>>>>>>>> With regards to the extensionData concept and XML, I have >>>>>>> a few basic >>>>>>>>> questions. I am by no means an XML expert so it could >>>>>>> just be my lack >>>>>>>> >>>>>>>>> of knowledge which makes me confused. If so, just tell >>>>>> me to RTFM. >>>>>>>>> >>>>>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>>>>> A recording metadata object contains additional data not >>>>>>> specified >>>>>>>>> as >>>>>>>>> part of siprec. This is intended to accommodate >>>>>> future standards >>>>>>>>> track extensions, as well as vendor and user specific >>>>>> extensions. >>>>>>>>> The mechanism MUST provide a means of unambiguously >>>>>>> distinguishing >>>>>>>>> such extension data. >>>>>>>>> >>>>>>>>> What confuses me is I didn't think XML had to do such >>>>>>> machinations to >>>>>>>>> accommodate this need. I thought we could just specify >>>>>> in our RFCs >>>>>> >>>>>>>>> that unknown XML elements and attributes MUST be >>>>>> ignored, so that >>>>>>>>> future RFCs could add them without having to leave >>>>>>> specific "blob" XML >>>>>>>> >>>>>>>>> elements to carry such data. Or at least that's what >>>>>> we've done so >>>>>> >>>>>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>>>>> namespace model that could be used to disambiguate proprietary >>>>>>>>> elements from standard ones. If both of those theories >>>>>>> are correct, >>>>>>>>> why do we need to define an extensionData element? >>>>>>>>> >>>>>>>>> -hadriel >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> siprec mailing list >>>>>>>>> siprec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> >>>>>>>> DISCLAIMER: This e-mail may contain information that is >>>>>>> confidential, >>>>>>>> privileged or otherwise protected from disclosure. If you >>>>>> are not an >>>>>> >>>>>>>> intended recipient of this e-mail, do not duplicate or >>>>>>> redistribute it >>>>>>>> by any means. Please delete it and any attachments and >>>>>>> notify the sender >>>>>>>> that you have received it in error. Unintended recipients >>>>>>> are prohibited >>>>>>>> from taking action on the basis of information in this >>>>>> e-mail.E-mail >>>>>> >>>>>>>> messages may contain computer viruses or other defects, >>>>>> may not be >>>>>>>> accurately replicated on other systems, or may be >>>>>>> intercepted, deleted >>>>>>>> or interfered with without the knowledge of the sender or >>>>>>> the intended >>>>>>>> recipient. If you are not comfortable with the risks >>>>>> associated with >>>>>> >>>>>>>> e-mail messages, you may decide not to use e-mail to >>>>>>> communicate with >>>>>>>> IPC. IPC reserves the right, to the extent and under >>>>>> circumstances >>>>>>>> permitted by applicable law, to retain, monitor and >>>>>> intercept e-mail >>>>>> >>>>>>>> messages to and from its systems. >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> > > From pkyzivat@cisco.com Mon Jun 6 06:54:29 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02C811E80F7 for ; Mon, 6 Jun 2011 06:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.599 X-Spam-Level: X-Spam-Status: No, score=-109.599 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsFYBXyQpBJV for ; Mon, 6 Jun 2011 06:54:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5D05A11E813E for ; Mon, 6 Jun 2011 06:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=23236; q=dns/txt; s=iport; t=1307368462; x=1308578062; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hgMPuFggQ+lcFrt3bIhgbQRmfwbV6HoTl52ehH0LilI=; b=jMWCsIkHwyr2YsDeG7gWprRM9dHRCfBC8K5l9TJ1asd+kRNdgeaWg3w4 cfTttwzL7n6y0yElgPrqp3MvrlGb8ZmluP4Cm4RyQ2w4Y4m/cUe8FUlrY 0dWBtN9FkeLRWci31NqEUrsDa8BrJUPyrBskws9xoUQQzW7wNxlsE6324 U=; X-IronPort-AV: E=Sophos;i="4.65,326,1304294400"; d="scan'208";a="460386639" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 06 Jun 2011 13:54:21 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p56DsJc5028573; Mon, 6 Jun 2011 13:54:20 GMT Message-ID: <4DECDC0B.1080301@cisco.com> Date: Mon, 06 Jun 2011 09:54:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Leon Portman References: <4D9CDFC0.9070300@cisco.com><48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> <07465C1D981ABC41A344374066AE1A2C38AC31EB52@TLVMBX01.nice.com> <4DECD435.9050306@cisco.com> <948BAC33-911A-426F-8E20-AA15F2DE8AC0@neustar.biz> <07465C1D981ABC41A344374066AE1A2C38AC31EDBD@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AC31EDBD@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Peter Saint-Andre \(psaintan\)" , "siprec@ietf.org" , "Rosen, Brian" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:54:29 -0000 On 6/6/2011 9:39 AM, Leon Portman wrote: > Paul Hi > > The behavior that you have described below is consistent with any other partial updates. I do assume that in snapshot we will report the most update extension data, correct? Presumably. This becomes part of the *state* that an SRC needs to maintain. Thanks, Paul > Regards > > Leon > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Monday, June 06, 2011 4:32 PM > To: Paul Kyzivat > Cc: Leon Portman; Parthasarathi R (partr); Dan Burnett; Ken Rehor (krehor); HKaplan@acmepacket.com; siprec@ietf.org; Peter Saint-Andre (psaintan) > Subject: Re: [siprec] extensionData in XML > > I don't understand this. > > We can define it that way, but AFAIK, there isn't anything in XML standards that would force that to be true. > > An extension point like this just allows you to add some new stuff, defined in a new namespace. All it really does is allow a way for an older implementation to ignore what is in there if it doesn't understand it. > > Brian > > On Jun 6, 2011, at 9:20 AM, Paul Kyzivat wrote: > >> I'd like to point out an implication of this approach: >> >> When you send an update to an entity (in the example its a session) >> and include extension data, that extension data applies to the session >> from that time forward until changed. >> >> If you later send another update to the same entity, regardless of >> your reason for sending that update, if you fail to include the >> extension data again you are saying that the extension data no longer >> applies to the session. If you want it to continue to apply you must >> transmit it again. That of course means you must remember what >> extension data you previously sent, so that you *can* send it again. >> >> That may be fine. I just don't want people saying they like this >> approach without having considered the implications. >> >> Thanks, >> Paul >> >> On 6/6/2011 4:19 AM, Leon Portman wrote: >>> I am ok with the proposal. Looking good >>> >>> Leon >>> >>> -----Original Message----- >>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>> Sent: Saturday, June 04, 2011 3:54 AM >>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor >>> (krehor); Rosen, Brian; HKaplan@acmepacket.com >>> Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) >>> Subject: RE: [siprec] extensionData in XML >>> >>> >>> Hi all, >>> >>> Based on the discussion in last interim meeting and mail thread discussion on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and below mail thread, I have not seen anybody looking for separate extensiondata metadata XML tag. So, the authors of the draft plans to revise the next revision with "Extensiondata as an extension within metadata block" and example is as follows: >>> >>> >> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>> >>> >>> sip:alice@cisco.com >>> >>> >>> >>> >>> In case anybody has difference of opinion, Please let us know by coming Thursday which helps us to update the next revision. >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Parthasarathi R (partr) >>> Sent: Tuesday, April 19, 2011 4:01 PM >>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor >>> (krehor) >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] extensionData in XML >>> >>> Dan& all, >>> >>> Sorry for the late reply. Thanks for sharing your XML experience. >>> tag is provided as extensions to SIPREC metadata. The current approach allows to ignore the extension-data in case SRS does not understand. >>> >>> I have added few extensiondata as a note of this mail which were >>> discussed during earlier SIPREC interim meeting. The open question >>> here is whether the extension-data has to be passed every time >>> (during >>> partial-update) within metadata XML tag (participant, session) update or it is enough to send only when extension-data changes. Partial update of any specific XML elements needs unique id. RFC 5261 recommends to use xml:id or type-id as unique attribute. >>> >>> The following example illustrate three different mechanism for >>> extensiondata: >>> >>> Extensiondata as separate metadata block: (Current format in the >>> draft - works for partial update, URN UUID is used in all metadata >>> block as of >>> now) >>> >> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>> >>> >> id="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" >>> parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>> >>> sip:alice@cisco.com >>> >>> >>> >>> Extensiondata as separate metadata block using xml:id:(Id reduction) >>> >> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>> >>> >> parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>> >>> sip:alice@cisco.com >>> >>> >>> >>> Extensiondata as an extension within metadata block: (Ignore the >>> attribute but needs to be passed in each partial updated) >>> Example: >>> >> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>> >>> >>> sip:alice@cisco.com >>> >>> >>> >>> >>> Please let me know which best suites SIPREC metadata. Including Leon& Ken explicitly because they provides lot of Extension data attributes during the discussion of metadata model. >>> >>> I'm fine with any of the above approach. >>> >>> Thanks >>> Partha >>> >>> Note: >>> End point information: ip/port, device id (MAC address), DN (used for the call, in case of multiline). >>> Device type: external, station, IVR, routing point, QUEUE, Gateway, >>> MCU, Operator, etc Participant Role: caller, called, added, >>> last_redirecting, redirecting, conferencing, queing, redirected >>> AgentId, OSLogin >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Dan Burnett >>> Sent: Monday, April 11, 2011 9:15 PM >>> To: Paul Kyzivat (pkyzivat) >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] extensionData in XML >>> >>> As someone who works quite a bit with XML, I'll point out that there is an important distinction between data for extensibility and expected application-specific data. As an example of the latter, EMMA [1] is an XML format for representing the input of a user (human being, commonly) to an automated system, by speech, gesture, pen, etc. Since the way an input is interpreted is dependent upon its intended use, there was a need for a designated application-specific section to represent the semantics (meaning) of the input. >>> To make it easier for machine consumers of this format that may be seeking the semantics, there is a designated element "interpretation" >>> that holds this information. The contents of this element are arbitrary XML in an application-specific XML namespace. >>> >>> On the other hand, every XML specification I've worked on in W3C has >>> needed a way for implementers to innovate via extensions. >>> Traditionally this is handled via custom elements and attributes in an implementer-specific namespace to avoid name collision with the standard elements and attributes. Since these true innovation extensions can occur anywhere, there is no specific XML element established in most specifications for "extensions". Instead, the specification defines the expected behavior of a conformant processor upon encountering elements and attributes outside of the specification's standard namespace. The nice thing about this approach is that allows for innovation in a way that does not cause name collision but which could become part of the standard in the future (and be moved into the standard's namespace). >>> For the specifications I worked on, we always required that a conformant processor had to do the behavior defined in the specification when it received a conformant document but that the behavior of the processor when it encountered non-standard elements and attributes was at its own discretion -- it could process the attributes, ignore them, or report an error, as it deemed appropriate. >>> >>> >>> So the real question for us here is whether these extension elements >>> are >>> *extensions* (which do not require a custom element/location) or *expected application-specific information* (which can benefit from custom elements and prescribed locations in the XML tree). >>> >>> -- dan >>> >>> [1] http://www.w3.org/TR/emma/ >>> >>> On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: >>> >>>> >>>> >>>> On 4/6/2011 8:57 AM, Elwell, John wrote: >>>>> Yes, I would be keen to hear Peter's or other opinions, but one >>>>> other >>> >>>>> point. One of the properties of XML is that it is human- readable. >>>>> Having extension data as a child element of the element >>>>> representing the object to which it applies seems, in my opinion, >>>>> to make it more readable. Having extension data as a separate >>>>> element, with a link to >>> >>>>> the element to which it applies, seems hard for a human reader, >>>>> particularly if the link is a long, random string. >>>> >>>> IMO human readability of the xml is a secondary/tertiary concern. >>>> (SIP is in theory readable, but real sip on the wire tends to be >>>> difficult to read due to need to match up non-ergonomic numeric >>>> addresses and tags from one message to another.) >>>> >>>> I'm inclined to agree it would be better to embed extensions into >>>> the basic elements, but not primarily due to readability. IMO >>>> extensions should function as much like the predefined parts as possible. >>>> (Today's extension may become common usage tomorrow.) >>>> >>>> I just don't know enough xml to define this "correctly". >>>> >>>> Thanks, >>>> Paul >>>> >>>>> John (as individual) >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>> Sent: 06 April 2011 10:16 >>>>>> To: Elwell, John; Hadriel Kaplan >>>>>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >>>>>> Subject: RE: [siprec] extensionData in XML >>>>>> >>>>>> John, >>>>>> >>>>>> Please read inline >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>> Sent: Wednesday, April 06, 2011 2:02 PM >>>>>> To: Parthasarathi R (partr); Hadriel Kaplan >>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>> Subject: RE: [siprec] extensionData in XML >>>>>> >>>>>> I already posted on this topic on the other thread. Partha states >>>>>> below an additional motivation for handling extension data in the >>>>>> way specified in the current I-D. My counter argument is that >>>>>> anyone >>> >>>>>> specifying particular extension data could specify the expected >>>>>> behaviour when extension data is present in an object and then >>>>>> absent when that object is updated. For some types of metadata it >>>>>> could be that absence means it no longer applies, and for other >>>>>> types of metadata it could be that absence means it has not changed. >>>>>> >>>>>> Currently, metadata format draft XML element is written >>>>>> with the basics that "it is no longer applies" in case specific >>>>>> element is absent in the update. The question is how the >>>>>> information >>> >>>>>> of extensiondata absence means "it is no longer applies" or "it >>>>>> has not changed" has to be passed between SRC and SRS. Here, there >>>>>> is a need of common understanding between SRC and SRS or else the >>>>>> information will be misunderstand even though both parties >>>>>> understand the specific extension. >>>>>> >>>>>> The current extensiondata is taken the route of all other metadata >>>>>> block XML element definition. There may be better way to represent >>>>>> in extensiondata XML element apart from creating new metadata >>>>>> block with URN UUID. I'm including Peter for his advise on XML >>>>>> front. >>>>>> >>>>>> The latter approach would avoid the need for repeating large >>>>>> quantities of metadata each time there is a minor change to an >>>>>> object. >>>>>> >>>>>> John (as individual) >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>>>>> R (partr) >>>>>>> Sent: 03 April 2011 19:46 >>>>>>> To: Hadriel Kaplan >>>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>> >>>>>>> Hadriel, >>>>>>> >>>>>>> I guess we have common understaning to the extend that the >>>>>> intention >>>>>>> is to send some extensiondata (Unknown) attribute by SRC >>>>>> which may or >>>>>>> may not understand by SRS and also for the usage of xs:any as the >>>>>>> solution. Few stuff are missing in yours proposal w.r.t >>>>>> partial data >>>>>>> passing of extensiondata: >>>>>>> >>>>>>> The question is whether there is a need to pass the extension >>>>>>> data during every time the corresponding metadata block is passed >>>>>>> or updated. For example, CS metadata block sends extension >>>>>> data specific >>>>>>> to call center data like Agent is remote or local, agent or >>>>>> customer >>>>>>> initiated call (direction) during the CS block creation >>>>>> (INVITE) and >>>>>>> these constant information in extensiondata is not required to be >>>>>>> passed in each update of CS metadata like adding video >>>>>> stream in the >>>>>>> mid-session. >>>>>>> >>>>>>> The current model allows to pass extensiondata only during >>>>>> the initial >>>>>> >>>>>>> CS block creation and there is no need to update or resend while >>>>>>> CS >>> >>>>>>> block is getting updated with other CS information. IMO, >>>>>> The current >>>>>>> extensiondata mechanism is required as SIPREC puts lot of >>>>>> call centre >>>>>>> specific attributes proposed during metadata model draft review >>>>>>> as outside the scope of SIPREC and most of the attributes >>>>>> mentioned are >>>>>>> constant within the scope of session. >>>>>>> >>>>>>> Also, it is possible to pass update only extension data within RS >>>>>>> session without impacting parent element. Please let me >>>>>> know your and >>>>>>> others opinion whethter it is fine to continue with the current >>>>>>> extension-data element or to move xs:any element to each of the >>>>>>> metadata block. >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> ________________________________ >>>>>>> >>>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>>>> Sent: Sat 4/2/2011 6:19 PM >>>>>>> To: Parthasarathi R (partr) >>>>>>> Cc: Jain, Rajnish; siprec@ietf.org >>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Partha, >>>>>>> I think you're missing my point (or I'm missing yours) - you can >>>>>>> do >>> >>>>>>> all of that without specifying an "extensionData" XML element. >>>>>>> Unknown XML elements are simply ignored by the other side, so >>>>>>> Cisco >>> >>>>>>> can add a "ciscoPrivateData" XML element wherever it wants >>>>>> and send it >>>>>> >>>>>>> to an Acme; and that private element will be ignored by Acme >>>>>>> while everything else will continue to work. Which I think is >>>>>> the behavior >>>>>>> you want, right? >>>>>>> >>>>>>> -hadriel >>>>>>> >>>>>>> >>>>>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>>>>> >>>>>>>> Hadriel/Raj, >>>>>>>> >>>>>>>> Extensiondata XML is provided as per Metadata model >>>>>>> extensiondata block. >>>>>>>> During the initial discussion of metadata model draft, we >>>>>>> realized that >>>>>>>> lot of attributes specified for recording are call center >>>>>>> specific or >>>>>>>> specific domain related and it is outside the scope of IETF >>>>>>> SIPREC but >>>>>>>> it is required for those specific solution to work. >>>>>>> Extensiondata XML >>>>>>>> element helps to meet those requirement. >>>>>>>> >>>>>>>> Extensiondata is provided with URN UUID to pass or not pass >>>>>>>> independently in partial data. But it is open item whether >>>>>>> extensiondata >>>>>>>> has to be within specific metadatablock or not. >>>>>>>> >>>>>>>> Please read inline for more comments. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>>> Of Jain, Rajnish >>>>>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>> >>>>>>>> There may be such motivation from how the CSTA standards >>>>>>> are specified. >>>>>>>> They have an element called privateData for each message. It is >>>>>>>> a placeholder for any non-standardized extensions. This could >>>>>>> be legacy >>>>>>>> and may not mean much for the modern text based protocols. >>>>>>>> >>>>>>>> I really didn't get the reason why is it not >>>>>>> require for modern >>>>>>>> text based protocols. This is more like generic param in >>>>>>> SIP or xs:any >>>>>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>>>>> >>>>>>>> >>>>>>>> That said, I think you're right (this generally applies >>>>>> to any text >>>>>>>> based protocols and is the fundamental basis for >>>>>>>> forward/backward compatibility in such protocols). >>>>>>>> >>>>>>>> Raj >>>>>>>> >>>>>>>> >>>>>>>> ----------------------------------------------------- >>>>>>>> Please consider the environment before printing this email. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>> Behalf Of Hadriel Kaplan >>>>>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: [siprec] extensionData in XML >>>>>>>>> >>>>>>>>> Howdy, >>>>>>>>> With regards to the extensionData concept and XML, I have >>>>>>> a few basic >>>>>>>>> questions. I am by no means an XML expert so it could >>>>>>> just be my lack >>>>>>>> >>>>>>>>> of knowledge which makes me confused. If so, just tell >>>>>> me to RTFM. >>>>>>>>> >>>>>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>>>>> A recording metadata object contains additional data not >>>>>>> specified >>>>>>>>> as >>>>>>>>> part of siprec. This is intended to accommodate >>>>>> future standards >>>>>>>>> track extensions, as well as vendor and user specific >>>>>> extensions. >>>>>>>>> The mechanism MUST provide a means of unambiguously >>>>>>> distinguishing >>>>>>>>> such extension data. >>>>>>>>> >>>>>>>>> What confuses me is I didn't think XML had to do such >>>>>>> machinations to >>>>>>>>> accommodate this need. I thought we could just specify >>>>>> in our RFCs >>>>>> >>>>>>>>> that unknown XML elements and attributes MUST be >>>>>> ignored, so that >>>>>>>>> future RFCs could add them without having to leave >>>>>>> specific "blob" XML >>>>>>>> >>>>>>>>> elements to carry such data. Or at least that's what >>>>>> we've done so >>>>>> >>>>>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>>>>> namespace model that could be used to disambiguate proprietary >>>>>>>>> elements from standard ones. If both of those theories >>>>>>> are correct, >>>>>>>>> why do we need to define an extensionData element? >>>>>>>>> >>>>>>>>> -hadriel >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> siprec mailing list >>>>>>>>> siprec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> >>>>>>>> DISCLAIMER: This e-mail may contain information that is >>>>>>> confidential, >>>>>>>> privileged or otherwise protected from disclosure. If you >>>>>> are not an >>>>>> >>>>>>>> intended recipient of this e-mail, do not duplicate or >>>>>>> redistribute it >>>>>>>> by any means. Please delete it and any attachments and >>>>>>> notify the sender >>>>>>>> that you have received it in error. Unintended recipients >>>>>>> are prohibited >>>>>>>> from taking action on the basis of information in this >>>>>> e-mail.E-mail >>>>>> >>>>>>>> messages may contain computer viruses or other defects, >>>>>> may not be >>>>>>>> accurately replicated on other systems, or may be >>>>>>> intercepted, deleted >>>>>>>> or interfered with without the knowledge of the sender or >>>>>>> the intended >>>>>>>> recipient. If you are not comfortable with the risks >>>>>> associated with >>>>>> >>>>>>>> e-mail messages, you may decide not to use e-mail to >>>>>>> communicate with >>>>>>>> IPC. IPC reserves the right, to the extent and under >>>>>> circumstances >>>>>>>> permitted by applicable law, to retain, monitor and >>>>>> intercept e-mail >>>>>> >>>>>>>> messages to and from its systems. >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> > > From brian.rosen@neustar.biz Mon Jun 6 06:57:39 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F11A11E8140 for ; Mon, 6 Jun 2011 06:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeQqxasMiNEq for ; Mon, 6 Jun 2011 06:57:37 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFB111E80F7 for ; Mon, 6 Jun 2011 06:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1307368652; x=1622720155; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=fB9odUfcyomq4EZjSzd92 NtvO6dNfFGgQK2vnT7XwCQ=; b=fJrsafYsMHAoMufxl1yEKEebMFARCMwpuxUYi hz10ddkyFiCK2GZq9NH9RyV1Waj/DIMA2FwSUq7C0ftuB2iEQ== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.46050269; Mon, 06 Jun 2011 09:57:31 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Mon, 6 Jun 2011 09:57:31 -0400 From: "Rosen, Brian" To: Paul Kyzivat Date: Mon, 6 Jun 2011 09:57:26 -0400 Thread-Topic: [siprec] extensionData in XML Thread-Index: AcwkUazgMGp9Kz+VSlayrOe/wLmkWQ== Message-ID: <08D51778-55E4-44D6-87E1-45DE2FA23725@neustar.biz> References: <4D9CDFC0.9070300@cisco.com><48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> <07465C1D981ABC41A344374066AE1A2C38AC31EB52@TLVMBX01.nice.com> <4DECD435.9050306@cisco.com> <948BAC33-911A-426F-8E20-AA15F2DE8AC0@neustar.biz> <4DECDB90.5080704@cisco.com> In-Reply-To: <4DECDB90.5080704@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Ihty+stGGs/c/Z0Wp94u7w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" , "Peter Saint-Andre \(psaintan\)" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:57:39 -0000 If the rule is "no change if not mentioned" for partial updates, then that = would be the same here, right? That's always how partial updates work. Why= can't we define extensions the same way, even if their are multiple of the= m? If you need to remove something, then you have to define semantics for = that (like assign a null value). Brian On Jun 6, 2011, at 9:52 AM, Paul Kyzivat wrote: > Brian, > > Yeah, this isn't about xml itself, its about how we are using it. > This is the approach taken for all the data in updates to elements. > I guess we could define this as a one-off, or else we could define it as = a sub-element by sub-element property. But that would seem to be confusing.= Also, if you did this, then it gets hard to do the converse if you do want= to remove the extension data for the remainder of a session. > > Thanks, > Paul > > On 6/6/2011 9:31 AM, Rosen, Brian wrote: >> I don't understand this. >> >> We can define it that way, but AFAIK, there isn't anything in XML standa= rds that would force that to be true. >> >> An extension point like this just allows you to add some new stuff, defi= ned in a new namespace. All it really does is allow a way for an older imp= lementation to ignore what is in there if it doesn't understand it. >> >> Brian >> >> On Jun 6, 2011, at 9:20 AM, Paul Kyzivat wrote: >> >>> I'd like to point out an implication of this approach: >>> >>> When you send an update to an entity (in the example its a session) and >>> include extension data, that extension data applies to the session from >>> that time forward until changed. >>> >>> If you later send another update to the same entity, regardless of your >>> reason for sending that update, if you fail to include the extension >>> data again you are saying that the extension data no longer applies to >>> the session. If you want it to continue to apply you must transmit it >>> again. That of course means you must remember what extension data you >>> previously sent, so that you *can* send it again. >>> >>> That may be fine. I just don't want people saying they like this >>> approach without having considered the implications. >>> >>> Thanks, >>> Paul >>> >>> On 6/6/2011 4:19 AM, Leon Portman wrote: >>>> I am ok with the proposal. Looking good >>>> >>>> Leon >>>> >>>> -----Original Message----- >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>> Sent: Saturday, June 04, 2011 3:54 AM >>>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor (kre= hor); Rosen, Brian; HKaplan@acmepacket.com >>>> Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) >>>> Subject: RE: [siprec] extensionData in XML >>>> >>>> >>>> Hi all, >>>> >>>> Based on the discussion in last interim meeting and mail thread discus= sion on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html a= nd below mail thread, I have not seen anybody looking for separate extensio= ndata metadata XML tag. So, the authors of the draft plans to revise the ne= xt revision with "Extensiondata as an extension within metadata block" and = example is as follows: >>>> >>>> >>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>> >>>> >>>> sip:alice@cisco.com >>>> >>>> >>>> >>>> >>>> In case anybody has difference of opinion, Please let us know by comin= g Thursday which helps us to update the next revision. >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Beha= lf Of Parthasarathi R (partr) >>>> Sent: Tuesday, April 19, 2011 4:01 PM >>>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor >>>> (krehor) >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] extensionData in XML >>>> >>>> Dan& all, >>>> >>>> Sorry for the late reply. Thanks for sharing your XML experience. >>>> tag is provided as extensions to SIPREC metadata. T= he current approach allows to ignore the extension-data in case SRS does no= t understand. >>>> >>>> I have added few extensiondata as a note of this mail which were discu= ssed during earlier SIPREC interim meeting. The open question here is wheth= er the extension-data has to be passed every time (during >>>> partial-update) within metadata XML tag (participant, session) update = or it is enough to send only when extension-data changes. Partial update of= any specific XML elements needs unique id. RFC 5261 recommends to use xml= :id or type-id as unique attribute. >>>> >>>> The following example illustrate three different mechanism for >>>> extensiondata: >>>> >>>> Extensiondata as separate metadata block: (Current format in the draft= - works for partial update, URN UUID is used in all metadata block as of >>>> now) >>>> >>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>> >>>> >>> id=3D"urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" >>>> parent=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>> >>>> sip:alice@cisco.com >>>> >>>> >>>> >>>> Extensiondata as separate metadata block using xml:id:(Id reduction) >>>> >>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>> >>>> >>> parent=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>> >>>> sip:alice@cisco.com >>>> >>>> >>>> >>>> Extensiondata as an extension within metadata block: (Ignore the attri= bute but needs to be passed in each partial updated) >>>> Example: >>>> >>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>> >>>> >>>> sip:alice@cisco.com >>>> >>>> >>>> >>>> >>>> Please let me know which best suites SIPREC metadata. Including Leon& = Ken explicitly because they provides lot of Extension data attributes dur= ing the discussion of metadata model. >>>> >>>> I'm fine with any of the above approach. >>>> >>>> Thanks >>>> Partha >>>> >>>> Note: >>>> End point information: ip/port, device id (MAC address), DN (used for = the call, in case of multiline). >>>> Device type: external, station, IVR, routing point, QUEUE, Gateway, MC= U, Operator, etc Participant Role: caller, called, added, last_redirecting,= redirecting, conferencing, queing, redirected AgentId, OSLogin >>>> >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Beha= lf Of Dan Burnett >>>> Sent: Monday, April 11, 2011 9:15 PM >>>> To: Paul Kyzivat (pkyzivat) >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] extensionData in XML >>>> >>>> As someone who works quite a bit with XML, I'll point out that there i= s an important distinction between data for extensibility and expected appl= ication-specific data. As an example of the latter, EMMA [1] is an XML for= mat for representing the input of a user (human being, commonly) to an auto= mated system, by speech, gesture, pen, etc. Since the way an input is inte= rpreted is dependent upon its intended use, there was a need for a designat= ed application-specific section to represent the semantics (meaning) of the= input. >>>> To make it easier for machine consumers of this format that may be see= king the semantics, there is a designated element "interpretation" >>>> that holds this information. The contents of this element are arbitra= ry XML in an application-specific XML namespace. >>>> >>>> On the other hand, every XML specification I've worked on in W3C has >>>> needed a way for implementers to innovate via extensions. >>>> Traditionally this is handled via custom elements and attributes in an= implementer-specific namespace to avoid name collision with the standard e= lements and attributes. Since these true innovation extensions can occur a= nywhere, there is no specific XML element established in most specification= s for "extensions". Instead, the specification defines the expected behavi= or of a conformant processor upon encountering elements and attributes outs= ide of the specification's standard namespace. The nice thing about this a= pproach is that allows for innovation in a way that does not cause name col= lision but which could become part of the standard in the future (and be mo= ved into the standard's namespace). >>>> For the specifications I worked on, we always required that a conforma= nt processor had to do the behavior defined in the specification when it re= ceived a conformant document but that the behavior of the processor when it= encountered non-standard elements and attributes was at its own discretion= -- it could process the attributes, ignore them, or report an error, as it= deemed appropriate. >>>> >>>> >>>> So the real question for us here is whether these extension elements a= re >>>> *extensions* (which do not require a custom element/location) or *expe= cted application-specific information* (which can benefit from custom eleme= nts and prescribed locations in the XML tree). >>>> >>>> -- dan >>>> >>>> [1] http://www.w3.org/TR/emma/ >>>> >>>> On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: >>>> >>>>> >>>>> >>>>> On 4/6/2011 8:57 AM, Elwell, John wrote: >>>>>> Yes, I would be keen to hear Peter's or other opinions, but one othe= r >>>> >>>>>> point. One of the properties of XML is that it is human- readable. >>>>>> Having extension data as a child element of the element representing >>>>>> the object to which it applies seems, in my opinion, to make it more >>>>>> readable. Having extension data as a separate element, with a link t= o >>>> >>>>>> the element to which it applies, seems hard for a human reader, >>>>>> particularly if the link is a long, random string. >>>>> >>>>> IMO human readability of the xml is a secondary/tertiary concern. >>>>> (SIP is in theory readable, but real sip on the wire tends to be >>>>> difficult to read due to need to match up non-ergonomic numeric >>>>> addresses and tags from one message to another.) >>>>> >>>>> I'm inclined to agree it would be better to embed extensions into the >>>>> basic elements, but not primarily due to readability. IMO extensions >>>>> should function as much like the predefined parts as possible. >>>>> (Today's extension may become common usage tomorrow.) >>>>> >>>>> I just don't know enough xml to define this "correctly". >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> John (as individual) >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>> Sent: 06 April 2011 10:16 >>>>>>> To: Elwell, John; Hadriel Kaplan >>>>>>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >>>>>>> Subject: RE: [siprec] extensionData in XML >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> Please read inline >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>> Sent: Wednesday, April 06, 2011 2:02 PM >>>>>>> To: Parthasarathi R (partr); Hadriel Kaplan >>>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>>> Subject: RE: [siprec] extensionData in XML >>>>>>> >>>>>>> I already posted on this topic on the other thread. Partha states >>>>>>> below an additional motivation for handling extension data in the >>>>>>> way specified in the current I-D. My counter argument is that anyon= e >>>> >>>>>>> specifying particular extension data could specify the expected >>>>>>> behaviour when extension data is present in an object and then >>>>>>> absent when that object is updated. For some types of metadata it >>>>>>> could be that absence means it no longer applies, and for other >>>>>>> types of metadata it could be that absence means it has not changed= . >>>>>>> >>>>>>> Currently, metadata format draft XML element is written >>>>>>> with the basics that "it is no longer applies" in case specific >>>>>>> element is absent in the update. The question is how the informatio= n >>>> >>>>>>> of extensiondata absence means "it is no longer applies" or "it has >>>>>>> not changed" has to be passed between SRC and SRS. Here, there is a >>>>>>> need of common understanding between SRC and SRS or else the >>>>>>> information will be misunderstand even though both parties >>>>>>> understand the specific extension. >>>>>>> >>>>>>> The current extensiondata is taken the route of all other metadata >>>>>>> block XML element definition. There may be better way to represent >>>>>>> in extensiondata XML element apart from creating new metadata block >>>>>>> with URN UUID. I'm including Peter for his advise on XML >>>>>>> front. >>>>>>> >>>>>>> The latter approach would avoid the need for repeating large >>>>>>> quantities of metadata each time there is a minor change to an >>>>>>> object. >>>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>>>>>> R (partr) >>>>>>>> Sent: 03 April 2011 19:46 >>>>>>>> To: Hadriel Kaplan >>>>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>> >>>>>>>> Hadriel, >>>>>>>> >>>>>>>> I guess we have common understaning to the extend that the >>>>>>> intention >>>>>>>> is to send some extensiondata (Unknown) attribute by SRC >>>>>>> which may or >>>>>>>> may not understand by SRS and also for the usage of xs:any as the >>>>>>>> solution. Few stuff are missing in yours proposal w.r.t >>>>>>> partial data >>>>>>>> passing of extensiondata: >>>>>>>> >>>>>>>> The question is whether there is a need to pass the extension data >>>>>>>> during every time the corresponding metadata block is passed or >>>>>>>> updated. For example, CS metadata block sends extension >>>>>>> data specific >>>>>>>> to call center data like Agent is remote or local, agent or >>>>>>> customer >>>>>>>> initiated call (direction) during the CS block creation >>>>>>> (INVITE) and >>>>>>>> these constant information in extensiondata is not required to be >>>>>>>> passed in each update of CS metadata like adding video >>>>>>> stream in the >>>>>>>> mid-session. >>>>>>>> >>>>>>>> The current model allows to pass extensiondata only during >>>>>>> the initial >>>>>>> >>>>>>>> CS block creation and there is no need to update or resend while C= S >>>> >>>>>>>> block is getting updated with other CS information. IMO, >>>>>>> The current >>>>>>>> extensiondata mechanism is required as SIPREC puts lot of >>>>>>> call centre >>>>>>>> specific attributes proposed during metadata model draft review as >>>>>>>> outside the scope of SIPREC and most of the attributes >>>>>>> mentioned are >>>>>>>> constant within the scope of session. >>>>>>>> >>>>>>>> Also, it is possible to pass update only extension data within RS >>>>>>>> session without impacting parent element. Please let me >>>>>>> know your and >>>>>>>> others opinion whethter it is fine to continue with the current >>>>>>>> extension-data element or to move xs:any element to each of the >>>>>>>> metadata block. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> ________________________________ >>>>>>>> >>>>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>>>>> Sent: Sat 4/2/2011 6:19 PM >>>>>>>> To: Parthasarathi R (partr) >>>>>>>> Cc: Jain, Rajnish; siprec@ietf.org >>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Partha, >>>>>>>> I think you're missing my point (or I'm missing yours) - you can d= o >>>> >>>>>>>> all of that without specifying an "extensionData" XML element. >>>>>>>> Unknown XML elements are simply ignored by the other side, so Cisc= o >>>> >>>>>>>> can add a "ciscoPrivateData" XML element wherever it wants >>>>>>> and send it >>>>>>> >>>>>>>> to an Acme; and that private element will be ignored by Acme while >>>>>>>> everything else will continue to work. Which I think is >>>>>>> the behavior >>>>>>>> you want, right? >>>>>>>> >>>>>>>> -hadriel >>>>>>>> >>>>>>>> >>>>>>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>>>>>> >>>>>>>>> Hadriel/Raj, >>>>>>>>> >>>>>>>>> Extensiondata XML is provided as per Metadata model >>>>>>>> extensiondata block. >>>>>>>>> During the initial discussion of metadata model draft, we >>>>>>>> realized that >>>>>>>>> lot of attributes specified for recording are call center >>>>>>>> specific or >>>>>>>>> specific domain related and it is outside the scope of IETF >>>>>>>> SIPREC but >>>>>>>>> it is required for those specific solution to work. >>>>>>>> Extensiondata XML >>>>>>>>> element helps to meet those requirement. >>>>>>>>> >>>>>>>>> Extensiondata is provided with URN UUID to pass or not pass >>>>>>>>> independently in partial data. But it is open item whether >>>>>>>> extensiondata >>>>>>>>> has to be within specific metadatablock or not. >>>>>>>>> >>>>>>>>> Please read inline for more comments. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>>>> Of Jain, Rajnish >>>>>>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>>>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>>> >>>>>>>>> There may be such motivation from how the CSTA standards >>>>>>>> are specified. >>>>>>>>> They have an element called privateData for each message. It is a >>>>>>>>> placeholder for any non-standardized extensions. This could >>>>>>>> be legacy >>>>>>>>> and may not mean much for the modern text based protocols. >>>>>>>>> >>>>>>>>> I really didn't get the reason why is it not >>>>>>>> require for modern >>>>>>>>> text based protocols. This is more like generic param in >>>>>>>> SIP or xs:any >>>>>>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>>>>>> >>>>>>>>> >>>>>>>>> That said, I think you're right (this generally applies >>>>>>> to any text >>>>>>>>> based protocols and is the fundamental basis for forward/backward >>>>>>>>> compatibility in such protocols). >>>>>>>>> >>>>>>>>> Raj >>>>>>>>> >>>>>>>>> >>>>>>>>> ----------------------------------------------------- >>>>>>>>> Please consider the environment before printing this email. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>> Behalf Of Hadriel Kaplan >>>>>>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>>>>>> To: siprec@ietf.org >>>>>>>>>> Subject: [siprec] extensionData in XML >>>>>>>>>> >>>>>>>>>> Howdy, >>>>>>>>>> With regards to the extensionData concept and XML, I have >>>>>>>> a few basic >>>>>>>>>> questions. I am by no means an XML expert so it could >>>>>>>> just be my lack >>>>>>>>> >>>>>>>>>> of knowledge which makes me confused. If so, just tell >>>>>>> me to RTFM. >>>>>>>>>> >>>>>>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>>>>>> A recording metadata object contains additional data not >>>>>>>> specified >>>>>>>>>> as >>>>>>>>>> part of siprec. This is intended to accommodate >>>>>>> future standards >>>>>>>>>> track extensions, as well as vendor and user specific >>>>>>> extensions. >>>>>>>>>> The mechanism MUST provide a means of unambiguously >>>>>>>> distinguishing >>>>>>>>>> such extension data. >>>>>>>>>> >>>>>>>>>> What confuses me is I didn't think XML had to do such >>>>>>>> machinations to >>>>>>>>>> accommodate this need. I thought we could just specify >>>>>>> in our RFCs >>>>>>> >>>>>>>>>> that unknown XML elements and attributes MUST be >>>>>>> ignored, so that >>>>>>>>>> future RFCs could add them without having to leave >>>>>>>> specific "blob" XML >>>>>>>>> >>>>>>>>>> elements to carry such data. Or at least that's what >>>>>>> we've done so >>>>>>> >>>>>>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>>>>>> namespace model that could be used to disambiguate proprietary >>>>>>>>>> elements from standard ones. If both of those theories >>>>>>>> are correct, >>>>>>>>>> why do we need to define an extensionData element? >>>>>>>>>> >>>>>>>>>> -hadriel >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> siprec mailing list >>>>>>>>>> siprec@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>> >>>>>>>>> DISCLAIMER: This e-mail may contain information that is >>>>>>>> confidential, >>>>>>>>> privileged or otherwise protected from disclosure. If you >>>>>>> are not an >>>>>>> >>>>>>>>> intended recipient of this e-mail, do not duplicate or >>>>>>>> redistribute it >>>>>>>>> by any means. Please delete it and any attachments and >>>>>>>> notify the sender >>>>>>>>> that you have received it in error. Unintended recipients >>>>>>>> are prohibited >>>>>>>>> from taking action on the basis of information in this >>>>>>> e-mail.E-mail >>>>>>> >>>>>>>>> messages may contain computer viruses or other defects, >>>>>>> may not be >>>>>>>>> accurately replicated on other systems, or may be >>>>>>>> intercepted, deleted >>>>>>>>> or interfered with without the knowledge of the sender or >>>>>>>> the intended >>>>>>>>> recipient. If you are not comfortable with the risks >>>>>>> associated with >>>>>>> >>>>>>>>> e-mail messages, you may decide not to use e-mail to >>>>>>>> communicate with >>>>>>>>> IPC. IPC reserves the right, to the extent and under >>>>>>> circumstances >>>>>>>>> permitted by applicable law, to retain, monitor and >>>>>>> intercept e-mail >>>>>>> >>>>>>>>> messages to and from its systems. >>>>>>>>> _______________________________________________ >>>>>>>>> siprec mailing list >>>>>>>>> siprec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >> >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Mon Jun 6 07:10:42 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C2F11E8135 for ; Mon, 6 Jun 2011 07:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.549 X-Spam-Level: X-Spam-Status: No, score=-109.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZh8bUw+ypfy for ; Mon, 6 Jun 2011 07:10:40 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 21E0811E8145 for ; Mon, 6 Jun 2011 07:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=25008; q=dns/txt; s=iport; t=1307369440; x=1308579040; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PH1Ol9fyHh+y92agXqbRYVHoHxx8IVHQSueuaYRDbcQ=; b=B7jUfOGK1vj1KnIcXLu/tw6T3l6tfx39S5dmZhyuN1ohsbbB9NkPWH8M grA53yoaCnMt0DLguundemWrvuGjcej7ZZ1vDyz8gQcNn7j+jLoxxytqD FK0L870TVcbUGfPj8M0fOvrk5N421m7HtH6ntn2EuC54lEhtf5RtyoAYt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4BAFrf7E2tJV2d/2dsb2JhbABTl1uOYXeIcaNCnUaGIQSQeYRIiw4 X-IronPort-AV: E=Sophos;i="4.65,326,1304294400"; d="scan'208";a="357767720" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2011 14:10:07 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p56EA6da018139; Mon, 6 Jun 2011 14:10:06 GMT Message-ID: <4DECDFBE.9020000@cisco.com> Date: Mon, 06 Jun 2011 10:10:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Rosen, Brian" References: <4D9CDFC0.9070300@cisco.com><48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> <07465C1D981ABC41A344374066AE1A2C38AC31EB52@TLVMBX01.nice.com> <4DECD435.9050306@cisco.com> <948BAC33-911A-426F-8E20-AA15F2DE8AC0@neustar.biz> <4DECDB90.5080704@cisco.com> <08D51778-55E4-44D6-87E1-45DE2FA23725@neustar.biz> In-Reply-To: <08D51778-55E4-44D6-87E1-45DE2FA23725@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" , "Peter Saint-Andre \(psaintan\)" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 14:10:42 -0000 On 6/6/2011 9:57 AM, Rosen, Brian wrote: > If the rule is "no change if not mentioned" for partial updates, then that would be the same here, right? That's always how partial updates work. Why can't we define extensions the same way, even if their are multiple of them? If you need to remove something, then you have to define semantics for that (like assign a null value). Anything is possible - all it requires is the right definitions. :-) Each approach has its own consequences. The consequences I mentioned are for the current approach as it has been conceived to date. What you suggest is possible, but then it would require a syntax to distinguish between adding/replacing/removing a sub-element. (Or maybe just replacing/removing.) I'll let Partha/Ram comment on that, since they are defining the format. Thanks, Paul > Brian > On Jun 6, 2011, at 9:52 AM, Paul Kyzivat wrote: > >> Brian, >> >> Yeah, this isn't about xml itself, its about how we are using it. >> This is the approach taken for all the data in updates to elements. >> I guess we could define this as a one-off, or else we could define it as a sub-element by sub-element property. But that would seem to be confusing. Also, if you did this, then it gets hard to do the converse if you do want to remove the extension data for the remainder of a session. >> >> Thanks, >> Paul >> >> On 6/6/2011 9:31 AM, Rosen, Brian wrote: >>> I don't understand this. >>> >>> We can define it that way, but AFAIK, there isn't anything in XML standards that would force that to be true. >>> >>> An extension point like this just allows you to add some new stuff, defined in a new namespace. All it really does is allow a way for an older implementation to ignore what is in there if it doesn't understand it. >>> >>> Brian >>> >>> On Jun 6, 2011, at 9:20 AM, Paul Kyzivat wrote: >>> >>>> I'd like to point out an implication of this approach: >>>> >>>> When you send an update to an entity (in the example its a session) and >>>> include extension data, that extension data applies to the session from >>>> that time forward until changed. >>>> >>>> If you later send another update to the same entity, regardless of your >>>> reason for sending that update, if you fail to include the extension >>>> data again you are saying that the extension data no longer applies to >>>> the session. If you want it to continue to apply you must transmit it >>>> again. That of course means you must remember what extension data you >>>> previously sent, so that you *can* send it again. >>>> >>>> That may be fine. I just don't want people saying they like this >>>> approach without having considered the implications. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 6/6/2011 4:19 AM, Leon Portman wrote: >>>>> I am ok with the proposal. Looking good >>>>> >>>>> Leon >>>>> >>>>> -----Original Message----- >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>> Sent: Saturday, June 04, 2011 3:54 AM >>>>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor (krehor); Rosen, Brian; HKaplan@acmepacket.com >>>>> Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) >>>>> Subject: RE: [siprec] extensionData in XML >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> Based on the discussion in last interim meeting and mail thread discussion on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and below mail thread, I have not seen anybody looking for separate extensiondata metadata XML tag. So, the authors of the draft plans to revise the next revision with "Extensiondata as an extension within metadata block" and example is as follows: >>>>> >>>>> >>>> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> >>>>> In case anybody has difference of opinion, Please let us know by coming Thursday which helps us to update the next revision. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) >>>>> Sent: Tuesday, April 19, 2011 4:01 PM >>>>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor >>>>> (krehor) >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> Dan& all, >>>>> >>>>> Sorry for the late reply. Thanks for sharing your XML experience. >>>>> tag is provided as extensions to SIPREC metadata. The current approach allows to ignore the extension-data in case SRS does not understand. >>>>> >>>>> I have added few extensiondata as a note of this mail which were discussed during earlier SIPREC interim meeting. The open question here is whether the extension-data has to be passed every time (during >>>>> partial-update) within metadata XML tag (participant, session) update or it is enough to send only when extension-data changes. Partial update of any specific XML elements needs unique id. RFC 5261 recommends to use xml:id or type-id as unique attribute. >>>>> >>>>> The following example illustrate three different mechanism for >>>>> extensiondata: >>>>> >>>>> Extensiondata as separate metadata block: (Current format in the draft - works for partial update, URN UUID is used in all metadata block as of >>>>> now) >>>>> >>>> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>> id="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" >>>>> parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> Extensiondata as separate metadata block using xml:id:(Id reduction) >>>>> >>>> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>> parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> Extensiondata as an extension within metadata block: (Ignore the attribute but needs to be passed in each partial updated) >>>>> Example: >>>>> >>>> group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> >>>>> Please let me know which best suites SIPREC metadata. Including Leon& Ken explicitly because they provides lot of Extension data attributes during the discussion of metadata model. >>>>> >>>>> I'm fine with any of the above approach. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> Note: >>>>> End point information: ip/port, device id (MAC address), DN (used for the call, in case of multiline). >>>>> Device type: external, station, IVR, routing point, QUEUE, Gateway, MCU, Operator, etc Participant Role: caller, called, added, last_redirecting, redirecting, conferencing, queing, redirected AgentId, OSLogin >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Dan Burnett >>>>> Sent: Monday, April 11, 2011 9:15 PM >>>>> To: Paul Kyzivat (pkyzivat) >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> As someone who works quite a bit with XML, I'll point out that there is an important distinction between data for extensibility and expected application-specific data. As an example of the latter, EMMA [1] is an XML format for representing the input of a user (human being, commonly) to an automated system, by speech, gesture, pen, etc. Since the way an input is interpreted is dependent upon its intended use, there was a need for a designated application-specific section to represent the semantics (meaning) of the input. >>>>> To make it easier for machine consumers of this format that may be seeking the semantics, there is a designated element "interpretation" >>>>> that holds this information. The contents of this element are arbitrary XML in an application-specific XML namespace. >>>>> >>>>> On the other hand, every XML specification I've worked on in W3C has >>>>> needed a way for implementers to innovate via extensions. >>>>> Traditionally this is handled via custom elements and attributes in an implementer-specific namespace to avoid name collision with the standard elements and attributes. Since these true innovation extensions can occur anywhere, there is no specific XML element established in most specifications for "extensions". Instead, the specification defines the expected behavior of a conformant processor upon encountering elements and attributes outside of the specification's standard namespace. The nice thing about this approach is that allows for innovation in a way that does not cause name collision but which could become part of the standard in the future (and be moved into the standard's namespace). >>>>> For the specifications I worked on, we always required that a conformant processor had to do the behavior defined in the specification when it received a conformant document but that the behavior of the processor when it encountered non-standard elements and attributes was at its own discretion -- it could process the attributes, ignore them, or report an error, as it deemed appropriate. >>>>> >>>>> >>>>> So the real question for us here is whether these extension elements are >>>>> *extensions* (which do not require a custom element/location) or *expected application-specific information* (which can benefit from custom elements and prescribed locations in the XML tree). >>>>> >>>>> -- dan >>>>> >>>>> [1] http://www.w3.org/TR/emma/ >>>>> >>>>> On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: >>>>> >>>>>> >>>>>> >>>>>> On 4/6/2011 8:57 AM, Elwell, John wrote: >>>>>>> Yes, I would be keen to hear Peter's or other opinions, but one other >>>>> >>>>>>> point. One of the properties of XML is that it is human- readable. >>>>>>> Having extension data as a child element of the element representing >>>>>>> the object to which it applies seems, in my opinion, to make it more >>>>>>> readable. Having extension data as a separate element, with a link to >>>>> >>>>>>> the element to which it applies, seems hard for a human reader, >>>>>>> particularly if the link is a long, random string. >>>>>> >>>>>> IMO human readability of the xml is a secondary/tertiary concern. >>>>>> (SIP is in theory readable, but real sip on the wire tends to be >>>>>> difficult to read due to need to match up non-ergonomic numeric >>>>>> addresses and tags from one message to another.) >>>>>> >>>>>> I'm inclined to agree it would be better to embed extensions into the >>>>>> basic elements, but not primarily due to readability. IMO extensions >>>>>> should function as much like the predefined parts as possible. >>>>>> (Today's extension may become common usage tomorrow.) >>>>>> >>>>>> I just don't know enough xml to define this "correctly". >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>>> Sent: 06 April 2011 10:16 >>>>>>>> To: Elwell, John; Hadriel Kaplan >>>>>>>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >>>>>>>> Subject: RE: [siprec] extensionData in XML >>>>>>>> >>>>>>>> John, >>>>>>>> >>>>>>>> Please read inline >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>>> Sent: Wednesday, April 06, 2011 2:02 PM >>>>>>>> To: Parthasarathi R (partr); Hadriel Kaplan >>>>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>>>> Subject: RE: [siprec] extensionData in XML >>>>>>>> >>>>>>>> I already posted on this topic on the other thread. Partha states >>>>>>>> below an additional motivation for handling extension data in the >>>>>>>> way specified in the current I-D. My counter argument is that anyone >>>>> >>>>>>>> specifying particular extension data could specify the expected >>>>>>>> behaviour when extension data is present in an object and then >>>>>>>> absent when that object is updated. For some types of metadata it >>>>>>>> could be that absence means it no longer applies, and for other >>>>>>>> types of metadata it could be that absence means it has not changed. >>>>>>>> >>>>>>>> Currently, metadata format draft XML element is written >>>>>>>> with the basics that "it is no longer applies" in case specific >>>>>>>> element is absent in the update. The question is how the information >>>>> >>>>>>>> of extensiondata absence means "it is no longer applies" or "it has >>>>>>>> not changed" has to be passed between SRC and SRS. Here, there is a >>>>>>>> need of common understanding between SRC and SRS or else the >>>>>>>> information will be misunderstand even though both parties >>>>>>>> understand the specific extension. >>>>>>>> >>>>>>>> The current extensiondata is taken the route of all other metadata >>>>>>>> block XML element definition. There may be better way to represent >>>>>>>> in extensiondata XML element apart from creating new metadata block >>>>>>>> with URN UUID. I'm including Peter for his advise on XML >>>>>>>> front. >>>>>>>> >>>>>>>> The latter approach would avoid the need for repeating large >>>>>>>> quantities of metadata each time there is a minor change to an >>>>>>>> object. >>>>>>>> >>>>>>>> John (as individual) >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>>>>>>> R (partr) >>>>>>>>> Sent: 03 April 2011 19:46 >>>>>>>>> To: Hadriel Kaplan >>>>>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>>> >>>>>>>>> Hadriel, >>>>>>>>> >>>>>>>>> I guess we have common understaning to the extend that the >>>>>>>> intention >>>>>>>>> is to send some extensiondata (Unknown) attribute by SRC >>>>>>>> which may or >>>>>>>>> may not understand by SRS and also for the usage of xs:any as the >>>>>>>>> solution. Few stuff are missing in yours proposal w.r.t >>>>>>>> partial data >>>>>>>>> passing of extensiondata: >>>>>>>>> >>>>>>>>> The question is whether there is a need to pass the extension data >>>>>>>>> during every time the corresponding metadata block is passed or >>>>>>>>> updated. For example, CS metadata block sends extension >>>>>>>> data specific >>>>>>>>> to call center data like Agent is remote or local, agent or >>>>>>>> customer >>>>>>>>> initiated call (direction) during the CS block creation >>>>>>>> (INVITE) and >>>>>>>>> these constant information in extensiondata is not required to be >>>>>>>>> passed in each update of CS metadata like adding video >>>>>>>> stream in the >>>>>>>>> mid-session. >>>>>>>>> >>>>>>>>> The current model allows to pass extensiondata only during >>>>>>>> the initial >>>>>>>> >>>>>>>>> CS block creation and there is no need to update or resend while CS >>>>> >>>>>>>>> block is getting updated with other CS information. IMO, >>>>>>>> The current >>>>>>>>> extensiondata mechanism is required as SIPREC puts lot of >>>>>>>> call centre >>>>>>>>> specific attributes proposed during metadata model draft review as >>>>>>>>> outside the scope of SIPREC and most of the attributes >>>>>>>> mentioned are >>>>>>>>> constant within the scope of session. >>>>>>>>> >>>>>>>>> Also, it is possible to pass update only extension data within RS >>>>>>>>> session without impacting parent element. Please let me >>>>>>>> know your and >>>>>>>>> others opinion whethter it is fine to continue with the current >>>>>>>>> extension-data element or to move xs:any element to each of the >>>>>>>>> metadata block. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>> ________________________________ >>>>>>>>> >>>>>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>>>>>> Sent: Sat 4/2/2011 6:19 PM >>>>>>>>> To: Parthasarathi R (partr) >>>>>>>>> Cc: Jain, Rajnish; siprec@ietf.org >>>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Partha, >>>>>>>>> I think you're missing my point (or I'm missing yours) - you can do >>>>> >>>>>>>>> all of that without specifying an "extensionData" XML element. >>>>>>>>> Unknown XML elements are simply ignored by the other side, so Cisco >>>>> >>>>>>>>> can add a "ciscoPrivateData" XML element wherever it wants >>>>>>>> and send it >>>>>>>> >>>>>>>>> to an Acme; and that private element will be ignored by Acme while >>>>>>>>> everything else will continue to work. Which I think is >>>>>>>> the behavior >>>>>>>>> you want, right? >>>>>>>>> >>>>>>>>> -hadriel >>>>>>>>> >>>>>>>>> >>>>>>>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>>>>>>> >>>>>>>>>> Hadriel/Raj, >>>>>>>>>> >>>>>>>>>> Extensiondata XML is provided as per Metadata model >>>>>>>>> extensiondata block. >>>>>>>>>> During the initial discussion of metadata model draft, we >>>>>>>>> realized that >>>>>>>>>> lot of attributes specified for recording are call center >>>>>>>>> specific or >>>>>>>>>> specific domain related and it is outside the scope of IETF >>>>>>>>> SIPREC but >>>>>>>>>> it is required for those specific solution to work. >>>>>>>>> Extensiondata XML >>>>>>>>>> element helps to meet those requirement. >>>>>>>>>> >>>>>>>>>> Extensiondata is provided with URN UUID to pass or not pass >>>>>>>>>> independently in partial data. But it is open item whether >>>>>>>>> extensiondata >>>>>>>>>> has to be within specific metadatablock or not. >>>>>>>>>> >>>>>>>>>> Please read inline for more comments. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Partha >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>>>>> Of Jain, Rajnish >>>>>>>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>>>>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>>>> >>>>>>>>>> There may be such motivation from how the CSTA standards >>>>>>>>> are specified. >>>>>>>>>> They have an element called privateData for each message. It is a >>>>>>>>>> placeholder for any non-standardized extensions. This could >>>>>>>>> be legacy >>>>>>>>>> and may not mean much for the modern text based protocols. >>>>>>>>>> >>>>>>>>>> I really didn't get the reason why is it not >>>>>>>>> require for modern >>>>>>>>>> text based protocols. This is more like generic param in >>>>>>>>> SIP or xs:any >>>>>>>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That said, I think you're right (this generally applies >>>>>>>> to any text >>>>>>>>>> based protocols and is the fundamental basis for forward/backward >>>>>>>>>> compatibility in such protocols). >>>>>>>>>> >>>>>>>>>> Raj >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----------------------------------------------------- >>>>>>>>>> Please consider the environment before printing this email. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>>> Behalf Of Hadriel Kaplan >>>>>>>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>>>>>>> To: siprec@ietf.org >>>>>>>>>>> Subject: [siprec] extensionData in XML >>>>>>>>>>> >>>>>>>>>>> Howdy, >>>>>>>>>>> With regards to the extensionData concept and XML, I have >>>>>>>>> a few basic >>>>>>>>>>> questions. I am by no means an XML expert so it could >>>>>>>>> just be my lack >>>>>>>>>> >>>>>>>>>>> of knowledge which makes me confused. If so, just tell >>>>>>>> me to RTFM. >>>>>>>>>>> >>>>>>>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>>>>>>> A recording metadata object contains additional data not >>>>>>>>> specified >>>>>>>>>>> as >>>>>>>>>>> part of siprec. This is intended to accommodate >>>>>>>> future standards >>>>>>>>>>> track extensions, as well as vendor and user specific >>>>>>>> extensions. >>>>>>>>>>> The mechanism MUST provide a means of unambiguously >>>>>>>>> distinguishing >>>>>>>>>>> such extension data. >>>>>>>>>>> >>>>>>>>>>> What confuses me is I didn't think XML had to do such >>>>>>>>> machinations to >>>>>>>>>>> accommodate this need. I thought we could just specify >>>>>>>> in our RFCs >>>>>>>> >>>>>>>>>>> that unknown XML elements and attributes MUST be >>>>>>>> ignored, so that >>>>>>>>>>> future RFCs could add them without having to leave >>>>>>>>> specific "blob" XML >>>>>>>>>> >>>>>>>>>>> elements to carry such data. Or at least that's what >>>>>>>> we've done so >>>>>>>> >>>>>>>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>>>>>>> namespace model that could be used to disambiguate proprietary >>>>>>>>>>> elements from standard ones. If both of those theories >>>>>>>>> are correct, >>>>>>>>>>> why do we need to define an extensionData element? >>>>>>>>>>> >>>>>>>>>>> -hadriel >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>> >>>>>>>>>> DISCLAIMER: This e-mail may contain information that is >>>>>>>>> confidential, >>>>>>>>>> privileged or otherwise protected from disclosure. If you >>>>>>>> are not an >>>>>>>> >>>>>>>>>> intended recipient of this e-mail, do not duplicate or >>>>>>>>> redistribute it >>>>>>>>>> by any means. Please delete it and any attachments and >>>>>>>>> notify the sender >>>>>>>>>> that you have received it in error. Unintended recipients >>>>>>>>> are prohibited >>>>>>>>>> from taking action on the basis of information in this >>>>>>>> e-mail.E-mail >>>>>>>> >>>>>>>>>> messages may contain computer viruses or other defects, >>>>>>>> may not be >>>>>>>>>> accurately replicated on other systems, or may be >>>>>>>>> intercepted, deleted >>>>>>>>>> or interfered with without the knowledge of the sender or >>>>>>>>> the intended >>>>>>>>>> recipient. If you are not comfortable with the risks >>>>>>>> associated with >>>>>>>> >>>>>>>>>> e-mail messages, you may decide not to use e-mail to >>>>>>>>> communicate with >>>>>>>>>> IPC. IPC reserves the right, to the extent and under >>>>>>>> circumstances >>>>>>>>>> permitted by applicable law, to retain, monitor and >>>>>>>> intercept e-mail >>>>>>>> >>>>>>>>>> messages to and from its systems. >>>>>>>>>> _______________________________________________ >>>>>>>>>> siprec mailing list >>>>>>>>>> siprec@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>> >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > From rmohanr@cisco.com Mon Jun 6 09:47:51 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C23B11E818E for ; Mon, 6 Jun 2011 09:47:51 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ma2bw27+az0Y for ; Mon, 6 Jun 2011 09:47:50 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 12A1311E8186 for ; Mon, 6 Jun 2011 09:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=10000; q=dns/txt; s=iport; t=1307378870; x=1308588470; h=mime-version:subject:date:message-id:from:to; bh=ANAL4MSfr9hpOe5eeS9MVQkp3t1dmOM2/umBSW89gj4=; b=kTVNRcdhwj0PAFa6dveapL7tCHe7npH/JClRdFegeKUXCLRPXM3g16vC lVToqXO4PIZragMvAB7SvB5fpEaDZ5lz8fh3QZ7BkhPtl7hNsodP+jQvo 1Q8JNOtXcT/jyDtFJo5XW7Y1+x3BWwtVJh2jksNEPYN7N5IeCOiNl53I0 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIIACEE7U1Io8UQ/2dsb2JhbABTglKVMY4hd6pUgR2dZIYhBIZyjliKcQ X-IronPort-AV: E=Sophos;i="4.65,327,1304294400"; d="scan'208,217";a="33901780" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 06 Jun 2011 16:47:39 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p56GldXR019480 for ; Mon, 6 Jun 2011 16:47:39 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 22:17:38 +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_01CC2469.71DDC914" Date: Mon, 6 Jun 2011 22:17:35 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06A0ADB1@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ticket #68 Start/stop time for Recording Session Thread-Index: AcwkaW+kbQfeg9WIQ4yC6nltw6gnUQ== From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 06 Jun 2011 16:47:38.0784 (UTC) FILETIME=[71E41200:01CC2469] Subject: [siprec] Ticket #68 Start/stop time for Recording Session X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 16:47:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2469.71DDC914 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A ticket was raised after IETF80 on the need for a optional attribute to indicate start/stop time of RS in metadata. =20 After the discussions in last interim meeting (2011-05-09) and after that, we agreed that in the Metadata model we will continue to have RS block. However in the format there is no need for a separate element (XML) for RS. Instead the Recording Session SIP dialog will itself serve for this purpose ( and thus maps to RS block in the model).=20 Refer mail thread for details - http://www.ietf.org/mail-archive/web/siprec/current/msg01998.html =20 Since there is no separate XML representation for RS block in the schema, there is no need for any attributes. Hence we can close this ticket. =20 An SRS interested in knowing the start / stop time may derive from: * Date/Time header ( if present in SIP message ) * OR From the time at which SRS receives SIP messages.=20 =20 Let me know your thoughts on this. =20 =20 Regards, Ram ------_=_NextPart_001_01CC2469.71DDC914 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A ticket = was raised after IETF80 on the need for a optional attribute to indicate = start/stop time of RS in metadata.

 

After the = discussions in last interim meeting (2011-05-09) and after that, we = agreed  that  in the Metadata  model we will continue to = have RS block. However in the format there is no need for a separate = element (XML) for RS. Instead the Recording Session SIP dialog will = itself serve for this purpose ( and thus maps to RS block in the model). =

Refer mail thread for details - http://www.ietf.org/mail-archive/web/siprec/current/msg01998.html

 

Since there is no separate XML representation for RS =  block in the schema, there is no need for any attributes. Hence = we can close this ticket.

 

An SRS = interested in knowing the  start / stop time may  derive = from:

·         = Date/Time header ( if present in SIP = message )

·         = OR From the time at which SRS receives = SIP messages.

 

Let me know = your thoughts on this. 

 

Regards,

Ram

------_=_NextPart_001_01CC2469.71DDC914-- From rmohanr@cisco.com Mon Jun 6 09:49:28 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9581F11E8186 for ; Mon, 6 Jun 2011 09:49:28 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4xHOoVUAjFE for ; Mon, 6 Jun 2011 09:49:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 72D9E11E8177 for ; Mon, 6 Jun 2011 09:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=6058; q=dns/txt; s=iport; t=1307378967; x=1308588567; h=mime-version:subject:date:message-id:from:to; bh=FHcapZA/G9yeaavihnIVNrtcn07dMdE1SKnnHOW7+ps=; b=SD17F2pUYh2rMZm8//sdtyoyi0ImgOAwzU+Et6fBg8xLcZjH1KaLL8YH FcpHihr0b6G/Yf+zJRNaetX3/p5CQ+AvIjT1t7o4vk8/2Zr5Hu7s10K/r VU/5o1EitpSZIY11H6cSm/JOJwFg+5xtkMhEtDy9cBLPRSMjKrL6L0N9J o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIIAJsE7U1Io8UR/2dsb2JhbABTglKVMY4hd6pVgR2dZIYhBIZyjliKcQ X-IronPort-AV: E=Sophos;i="4.65,327,1304294400"; d="scan'208,217";a="92482735" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 06 Jun 2011 16:49:25 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p56GnPQI018085 for ; Mon, 6 Jun 2011 16:49:25 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 22:19: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_01CC2469.B128EB64" Date: Mon, 6 Jun 2011 22:19:23 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06A0ADB3@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ticket #71 Media Stream / codec params Thread-Index: AcwkabATlF0t0iv+SxmU06VtQSQGOA== From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 06 Jun 2011 16:49:24.0988 (UTC) FILETIME=[B13183C0:01CC2469] Subject: [siprec] Ticket #71 Media Stream / codec params X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 16:49:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2469.B128EB64 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable from ticket #71 description: =20 >From Prague minutes: "Slide 9: Open item: Media stream: Codec params text change. Although there=20 wasn't any objection to changing codec params text to refer to RS SDP (as=20 opposed to CS SDP), it was not clear to everyone why this was needed at all.=20 Therefore it will be taken to the mailing list." =20 =20 The codec parameters on the MS have been there since the first cut at the metadata model. The intent at that time was to see if there was any need to carry some of the CS parameters as metadata in RS dialog.=20 =20 However after several discussions we had on the mailer where we have not seen any use cases we agreed that there is no need to carry CS SDP params Please refer to mail thread http://www.ietf.org/mail-archive/web/siprec/current/msg01600.html =20 So I intend to remove this attribute from the MS block of the metadata model and close this ticket. =20 Please get back before 6/ 13 ( Monday) if any one has any concerns. =20 Regards, Ram ------_=_NextPart_001_01CC2469.B128EB64 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<snip> from ticket #71 = description:

 

From Prague minutes: "Slide = 9: Open item: Media stream: Codec params text change. Although = there 
wasn't any objection to changing codec params = text to refer to RS SDP (as 
opposed to CS SDP), it was not clear to = everyone why this was needed at all. 
Therefore it will be taken to the mailing = list."

 

</snip>

 

The codec parameters on the MS have been there = since the first cut at the metadata model. The intent at that time was = to see if there was any need to carry some of the CS parameters as = metadata in  RS dialog.

 

However = after several discussions we had on the mailer where we have not seen = any use cases we agreed that there is no need to carry CS SDP = params

Please refer to mail thread http://www.ietf.org/mail-archive/web/siprec/current/msg01600.html

 

So I intend to remove this attribute from the MS block = of the metadata model and close this ticket.

 

Please get = back before 6/ 13 ( Monday) if any one has any = concerns.

 

Regards,

Ram

------_=_NextPart_001_01CC2469.B128EB64-- From partr@cisco.com Thu Jun 9 06:43:54 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831EB21F8470 for ; Thu, 9 Jun 2011 06:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzkoM3TIJ4zF for ; Thu, 9 Jun 2011 06:43:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 825A721F846E for ; Thu, 9 Jun 2011 06:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=27143; q=dns/txt; s=iport; t=1307627031; x=1308836631; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=NMOhAEukkxuhA8esrHGrIeuvLMi1ZkKC+zkJk0hmCC8=; b=Wc1blhjtxrJjaA7Wj0vXvrFcDUFJQsSDi5tuHkwI52n1ah3eZg2vM6Fw +NLn3cu/i4+8PmwezoLc8fpia2H9IKR5dHTZZWmS5dU2n3CHYPxWkX9yW fGbIU22FH94qawoWB1PVI5UjG5H8uwM5aAb+kdHJf5atXU2+bbSVyfwLk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwBAL3N8E1Io8UR/2dsb2JhbABTl0eOc3eIcaA/niKGIwSHBo56iwQ X-IronPort-AV: E=Sophos;i="4.65,341,1304294400"; d="scan'208";a="93143173" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2011 13:43:48 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p59DhmGx020302; Thu, 9 Jun 2011 13:43:48 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 19:13:30 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jun 2011 19:13:29 +0530 Message-ID: In-Reply-To: <4DECDFBE.9020000@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] extensionData in XML Thread-Index: AcwkU4vxkcoCYMQgTLePgkN1FWnjGwCU0Uzg References: <4D9CDFC0.9070300@cisco.com><48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com><07465C1D981ABC41A344374066AE1A2C38AC31EB52@TLVMBX01.nice.com><4DECD435.9050306@cisco.com><948BAC33-911A-426F-8E20-AA15F2DE8AC0@neustar.biz><4DECDB90.5080704@cisco.com><08D51778-55E4-44D6-87E1-45DE2FA23725@neustar.biz> <4DECDFBE.9020000@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , "Rosen, Brian" X-OriginalArrivalTime: 09 Jun 2011 13:43:30.0654 (UTC) FILETIME=[37EE77E0:01CC26AB] Cc: siprec@ietf.org, "Peter Saint-Andre \(psaintan\)" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 13:43:54 -0000 Brian, Please read inline. Thanks Partha=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Monday, June 06, 2011 7:40 PM To: Rosen, Brian Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) Subject: Re: [siprec] extensionData in XML On 6/6/2011 9:57 AM, Rosen, Brian wrote: > If the rule is "no change if not mentioned" for partial updates, then that would be the same here, right? That's always how partial updates work. =20 Even the current mechanism in metadata format draft is same as you expect which uses URN UUID. Here, extensiondata is considered as separate element which has the property of "no change if not mentioned". The minor optimization is possible to achieve by using xml:id as mentioned in the below mail and the minor limitation in the optimization is that xml:id scope MUST be span across single CSG in different CS in the model.=20 Also, any partial update mechanism of an XML element requires some sort of unique id. Please look into RFC 5261 for x-path based partial update which is more complex compare to the current mechanism in the draft. But the issue raised is to optimize in a way that no unique id is required to track this extension data element. So, we proposed extensiondata without any unique-id which has Paul mentioned caveats. Why can't we define extensions the same way, even if their are multiple of them?=20 The current proposal is inline with your expectation If you need to remove something, then you have to define semantics for that (like assign a null value). Agreed, the authors will come up "null" value in case we get the consensus for the current mechanism in the format draft. =20 Thanks Partha =20 Anything is possible - all it requires is the right definitions. :-) Each approach has its own consequences. The consequences I mentioned are for the current approach as it has been conceived to date. What you suggest is possible, but then it would require a syntax to distinguish between adding/replacing/removing a sub-element. (Or maybe just replacing/removing.) I'll let Partha/Ram comment on that, since they are defining the format. Thanks, Paul > Brian > On Jun 6, 2011, at 9:52 AM, Paul Kyzivat wrote: > >> Brian, >> >> Yeah, this isn't about xml itself, its about how we are using it. >> This is the approach taken for all the data in updates to elements. >> I guess we could define this as a one-off, or else we could define it as a sub-element by sub-element property. But that would seem to be confusing. Also, if you did this, then it gets hard to do the converse if you do want to remove the extension data for the remainder of a session. >> >> Thanks, >> Paul >> >> On 6/6/2011 9:31 AM, Rosen, Brian wrote: >>> I don't understand this. >>> >>> We can define it that way, but AFAIK, there isn't anything in XML standards that would force that to be true. >>> >>> An extension point like this just allows you to add some new stuff, defined in a new namespace. All it really does is allow a way for an older implementation to ignore what is in there if it doesn't understand it. >>> >>> Brian >>> >>> On Jun 6, 2011, at 9:20 AM, Paul Kyzivat wrote: >>> >>>> I'd like to point out an implication of this approach: >>>> >>>> When you send an update to an entity (in the example its a session) >>>> and include extension data, that extension data applies to the=20 >>>> session from that time forward until changed. >>>> >>>> If you later send another update to the same entity, regardless of=20 >>>> your reason for sending that update, if you fail to include the=20 >>>> extension data again you are saying that the extension data no=20 >>>> longer applies to the session. If you want it to continue to apply=20 >>>> you must transmit it again. That of course means you must remember=20 >>>> what extension data you previously sent, so that you *can* send it again. >>>> >>>> That may be fine. I just don't want people saying they like this=20 >>>> approach without having considered the implications. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 6/6/2011 4:19 AM, Leon Portman wrote: >>>>> I am ok with the proposal. Looking good >>>>> >>>>> Leon >>>>> >>>>> -----Original Message----- >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>> Sent: Saturday, June 04, 2011 3:54 AM >>>>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor=20 >>>>> (krehor); Rosen, Brian; HKaplan@acmepacket.com >>>>> Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) >>>>> Subject: RE: [siprec] extensionData in XML >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> Based on the discussion in last interim meeting and mail thread discussion on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and below mail thread, I have not seen anybody looking for separate extensiondata metadata XML tag. So, the authors of the draft plans to revise the next revision with "Extensiondata as an extension within metadata block" and example is as follows: >>>>> >>>>> >>>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> >>>>> In case anybody has difference of opinion, Please let us know by coming Thursday which helps us to update the next revision. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>>>> Behalf Of Parthasarathi R (partr) >>>>> Sent: Tuesday, April 19, 2011 4:01 PM >>>>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor >>>>> (krehor) >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> Dan& all, >>>>> >>>>> Sorry for the late reply. Thanks for sharing your XML experience. >>>>> tag is provided as extensions to SIPREC metadata. The current approach allows to ignore the extension-data in case SRS does not understand. >>>>> >>>>> I have added few extensiondata as a note of this mail which were=20 >>>>> discussed during earlier SIPREC interim meeting. The open question >>>>> here is whether the extension-data has to be passed every time=20 >>>>> (during >>>>> partial-update) within metadata XML tag (participant, session) update or it is enough to send only when extension-data changes. Partial update of any specific XML elements needs unique id. RFC 5261 recommends to use xml:id or type-id as unique attribute. >>>>> >>>>> The following example illustrate three different mechanism for >>>>> extensiondata: >>>>> >>>>> Extensiondata as separate metadata block: (Current format in the=20 >>>>> draft - works for partial update, URN UUID is used in all metadata >>>>> block as of >>>>> now) >>>>> >>>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>> id=3D"urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" >>>>> = parent=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> Extensiondata as separate metadata block using xml:id:(Id reduction) >>>>> >>>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>> = parent=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> Extensiondata as an extension within metadata block: (Ignore the=20 >>>>> attribute but needs to be passed in each partial updated) >>>>> Example: >>>>> >>>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> >>>>> Please let me know which best suites SIPREC metadata. Including Leon& Ken explicitly because they provides lot of Extension data attributes during the discussion of metadata model. >>>>> >>>>> I'm fine with any of the above approach. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> Note: >>>>> End point information: ip/port, device id (MAC address), DN (used for the call, in case of multiline). >>>>> Device type: external, station, IVR, routing point, QUEUE,=20 >>>>> Gateway, MCU, Operator, etc Participant Role: caller, called,=20 >>>>> added, last_redirecting, redirecting, conferencing, queing,=20 >>>>> redirected AgentId, OSLogin >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>>>> Behalf Of Dan Burnett >>>>> Sent: Monday, April 11, 2011 9:15 PM >>>>> To: Paul Kyzivat (pkyzivat) >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> As someone who works quite a bit with XML, I'll point out that there is an important distinction between data for extensibility and expected application-specific data. As an example of the latter, EMMA [1] is an XML format for representing the input of a user (human being, commonly) to an automated system, by speech, gesture, pen, etc. Since the way an input is interpreted is dependent upon its intended use, there was a need for a designated application-specific section to represent the semantics (meaning) of the input. >>>>> To make it easier for machine consumers of this format that may be seeking the semantics, there is a designated element "interpretation" >>>>> that holds this information. The contents of this element are arbitrary XML in an application-specific XML namespace. >>>>> >>>>> On the other hand, every XML specification I've worked on in W3C=20 >>>>> has needed a way for implementers to innovate via extensions. >>>>> Traditionally this is handled via custom elements and attributes in an implementer-specific namespace to avoid name collision with the standard elements and attributes. Since these true innovation extensions can occur anywhere, there is no specific XML element established in most specifications for "extensions". Instead, the specification defines the expected behavior of a conformant processor upon encountering elements and attributes outside of the specification's standard namespace. The nice thing about this approach is that allows for innovation in a way that does not cause name collision but which could become part of the standard in the future (and be moved into the standard's namespace). >>>>> For the specifications I worked on, we always required that a conformant processor had to do the behavior defined in the specification when it received a conformant document but that the behavior of the processor when it encountered non-standard elements and attributes was at its own discretion -- it could process the attributes, ignore them, or report an error, as it deemed appropriate. >>>>> >>>>> >>>>> So the real question for us here is whether these extension=20 >>>>> elements are >>>>> *extensions* (which do not require a custom element/location) or *expected application-specific information* (which can benefit from custom elements and prescribed locations in the XML tree). >>>>> >>>>> -- dan >>>>> >>>>> [1] http://www.w3.org/TR/emma/ >>>>> >>>>> On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: >>>>> >>>>>> >>>>>> >>>>>> On 4/6/2011 8:57 AM, Elwell, John wrote: >>>>>>> Yes, I would be keen to hear Peter's or other opinions, but one=20 >>>>>>> other >>>>> >>>>>>> point. One of the properties of XML is that it is human- readable. >>>>>>> Having extension data as a child element of the element=20 >>>>>>> representing the object to which it applies seems, in my=20 >>>>>>> opinion, to make it more readable. Having extension data as a=20 >>>>>>> separate element, with a link to >>>>> >>>>>>> the element to which it applies, seems hard for a human reader,=20 >>>>>>> particularly if the link is a long, random string. >>>>>> >>>>>> IMO human readability of the xml is a secondary/tertiary concern. >>>>>> (SIP is in theory readable, but real sip on the wire tends to be=20 >>>>>> difficult to read due to need to match up non-ergonomic numeric=20 >>>>>> addresses and tags from one message to another.) >>>>>> >>>>>> I'm inclined to agree it would be better to embed extensions into >>>>>> the basic elements, but not primarily due to readability. IMO=20 >>>>>> extensions should function as much like the predefined parts as possible. >>>>>> (Today's extension may become common usage tomorrow.) >>>>>> >>>>>> I just don't know enough xml to define this "correctly". >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>>> Sent: 06 April 2011 10:16 >>>>>>>> To: Elwell, John; Hadriel Kaplan >>>>>>>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre=20 >>>>>>>> (psaintan) >>>>>>>> Subject: RE: [siprec] extensionData in XML >>>>>>>> >>>>>>>> John, >>>>>>>> >>>>>>>> Please read inline >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>>> Sent: Wednesday, April 06, 2011 2:02 PM >>>>>>>> To: Parthasarathi R (partr); Hadriel Kaplan >>>>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>>>> Subject: RE: [siprec] extensionData in XML >>>>>>>> >>>>>>>> I already posted on this topic on the other thread. Partha=20 >>>>>>>> states below an additional motivation for handling extension=20 >>>>>>>> data in the way specified in the current I-D. My counter=20 >>>>>>>> argument is that anyone >>>>> >>>>>>>> specifying particular extension data could specify the expected >>>>>>>> behaviour when extension data is present in an object and then=20 >>>>>>>> absent when that object is updated. For some types of metadata=20 >>>>>>>> it could be that absence means it no longer applies, and for=20 >>>>>>>> other types of metadata it could be that absence means it has not changed. >>>>>>>> >>>>>>>> Currently, metadata format draft XML element is written >>>>>>>> with the basics that "it is no longer applies" in case specific >>>>>>>> element is absent in the update. The question is how the=20 >>>>>>>> information >>>>> >>>>>>>> of extensiondata absence means "it is no longer applies" or "it >>>>>>>> has not changed" has to be passed between SRC and SRS. Here,=20 >>>>>>>> there is a need of common understanding between SRC and SRS or=20 >>>>>>>> else the information will be misunderstand even though both=20 >>>>>>>> parties understand the specific extension. >>>>>>>> >>>>>>>> The current extensiondata is taken the route of all other=20 >>>>>>>> metadata block XML element definition. There may be better way=20 >>>>>>>> to represent in extensiondata XML element apart from creating=20 >>>>>>>> new metadata block with URN UUID. I'm including Peter for his=20 >>>>>>>> advise on XML front. >>>>>>>> >>>>>>>> The latter approach would avoid the need for repeating large=20 >>>>>>>> quantities of metadata each time there is a minor change to an=20 >>>>>>>> object. >>>>>>>> >>>>>>>> John (as individual) >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>>>>>>> R (partr) >>>>>>>>> Sent: 03 April 2011 19:46 >>>>>>>>> To: Hadriel Kaplan >>>>>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>>> >>>>>>>>> Hadriel, >>>>>>>>> >>>>>>>>> I guess we have common understaning to the extend that the >>>>>>>> intention >>>>>>>>> is to send some extensiondata (Unknown) attribute by SRC >>>>>>>> which may or >>>>>>>>> may not understand by SRS and also for the usage of xs:any as=20 >>>>>>>>> the solution. Few stuff are missing in yours proposal w.r.t >>>>>>>> partial data >>>>>>>>> passing of extensiondata: >>>>>>>>> >>>>>>>>> The question is whether there is a need to pass the extension=20 >>>>>>>>> data during every time the corresponding metadata block is=20 >>>>>>>>> passed or updated. For example, CS metadata block sends=20 >>>>>>>>> extension >>>>>>>> data specific >>>>>>>>> to call center data like Agent is remote or local, agent or >>>>>>>> customer >>>>>>>>> initiated call (direction) during the CS block creation >>>>>>>> (INVITE) and >>>>>>>>> these constant information in extensiondata is not required to >>>>>>>>> be passed in each update of CS metadata like adding video >>>>>>>> stream in the >>>>>>>>> mid-session. >>>>>>>>> >>>>>>>>> The current model allows to pass extensiondata only during >>>>>>>> the initial >>>>>>>> >>>>>>>>> CS block creation and there is no need to update or resend=20 >>>>>>>>> while CS >>>>> >>>>>>>>> block is getting updated with other CS information. IMO, >>>>>>>> The current >>>>>>>>> extensiondata mechanism is required as SIPREC puts lot of >>>>>>>> call centre >>>>>>>>> specific attributes proposed during metadata model draft=20 >>>>>>>>> review as outside the scope of SIPREC and most of the=20 >>>>>>>>> attributes >>>>>>>> mentioned are >>>>>>>>> constant within the scope of session. >>>>>>>>> >>>>>>>>> Also, it is possible to pass update only extension data within >>>>>>>>> RS session without impacting parent element. Please let me >>>>>>>> know your and >>>>>>>>> others opinion whethter it is fine to continue with the=20 >>>>>>>>> current extension-data element or to move xs:any element to=20 >>>>>>>>> each of the metadata block. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>> ________________________________ >>>>>>>>> >>>>>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>>>>>> Sent: Sat 4/2/2011 6:19 PM >>>>>>>>> To: Parthasarathi R (partr) >>>>>>>>> Cc: Jain, Rajnish; siprec@ietf.org >>>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Partha, >>>>>>>>> I think you're missing my point (or I'm missing yours) - you=20 >>>>>>>>> can do >>>>> >>>>>>>>> all of that without specifying an "extensionData" XML element. >>>>>>>>> Unknown XML elements are simply ignored by the other side, so=20 >>>>>>>>> Cisco >>>>> >>>>>>>>> can add a "ciscoPrivateData" XML element wherever it wants >>>>>>>> and send it >>>>>>>> >>>>>>>>> to an Acme; and that private element will be ignored by Acme=20 >>>>>>>>> while everything else will continue to work. Which I think is >>>>>>>> the behavior >>>>>>>>> you want, right? >>>>>>>>> >>>>>>>>> -hadriel >>>>>>>>> >>>>>>>>> >>>>>>>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>>>>>>> >>>>>>>>>> Hadriel/Raj, >>>>>>>>>> >>>>>>>>>> Extensiondata XML is provided as per Metadata model >>>>>>>>> extensiondata block. >>>>>>>>>> During the initial discussion of metadata model draft, we >>>>>>>>> realized that >>>>>>>>>> lot of attributes specified for recording are call center >>>>>>>>> specific or >>>>>>>>>> specific domain related and it is outside the scope of IETF >>>>>>>>> SIPREC but >>>>>>>>>> it is required for those specific solution to work. >>>>>>>>> Extensiondata XML >>>>>>>>>> element helps to meet those requirement. >>>>>>>>>> >>>>>>>>>> Extensiondata is provided with URN UUID to pass or not pass=20 >>>>>>>>>> independently in partial data. But it is open item whether >>>>>>>>> extensiondata >>>>>>>>>> has to be within specific metadatablock or not. >>>>>>>>>> >>>>>>>>>> Please read inline for more comments. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Partha >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>>>>> Of Jain, Rajnish >>>>>>>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>>>>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>>>> >>>>>>>>>> There may be such motivation from how the CSTA standards >>>>>>>>> are specified. >>>>>>>>>> They have an element called privateData for each message. It=20 >>>>>>>>>> is a placeholder for any non-standardized extensions. This=20 >>>>>>>>>> could >>>>>>>>> be legacy >>>>>>>>>> and may not mean much for the modern text based protocols. >>>>>>>>>> >>>>>>>>>> I really didn't get the reason why is it not >>>>>>>>> require for modern >>>>>>>>>> text based protocols. This is more like generic param in >>>>>>>>> SIP or xs:any >>>>>>>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That said, I think you're right (this generally applies >>>>>>>> to any text >>>>>>>>>> based protocols and is the fundamental basis for=20 >>>>>>>>>> forward/backward compatibility in such protocols). >>>>>>>>>> >>>>>>>>>> Raj >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----------------------------------------------------- >>>>>>>>>> Please consider the environment before printing this email. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>>> Behalf Of Hadriel Kaplan >>>>>>>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>>>>>>> To: siprec@ietf.org >>>>>>>>>>> Subject: [siprec] extensionData in XML >>>>>>>>>>> >>>>>>>>>>> Howdy, >>>>>>>>>>> With regards to the extensionData concept and XML, I have >>>>>>>>> a few basic >>>>>>>>>>> questions. I am by no means an XML expert so it could >>>>>>>>> just be my lack >>>>>>>>>> >>>>>>>>>>> of knowledge which makes me confused. If so, just tell >>>>>>>> me to RTFM. >>>>>>>>>>> >>>>>>>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>>>>>>> A recording metadata object contains additional data not >>>>>>>>> specified >>>>>>>>>>> as >>>>>>>>>>> part of siprec. This is intended to accommodate >>>>>>>> future standards >>>>>>>>>>> track extensions, as well as vendor and user specific >>>>>>>> extensions. >>>>>>>>>>> The mechanism MUST provide a means of unambiguously >>>>>>>>> distinguishing >>>>>>>>>>> such extension data. >>>>>>>>>>> >>>>>>>>>>> What confuses me is I didn't think XML had to do such >>>>>>>>> machinations to >>>>>>>>>>> accommodate this need. I thought we could just specify >>>>>>>> in our RFCs >>>>>>>> >>>>>>>>>>> that unknown XML elements and attributes MUST be >>>>>>>> ignored, so that >>>>>>>>>>> future RFCs could add them without having to leave >>>>>>>>> specific "blob" XML >>>>>>>>>> >>>>>>>>>>> elements to carry such data. Or at least that's what >>>>>>>> we've done so >>>>>>>> >>>>>>>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>>>>>>> namespace model that could be used to disambiguate=20 >>>>>>>>>>> proprietary elements from standard ones. If both of those=20 >>>>>>>>>>> theories >>>>>>>>> are correct, >>>>>>>>>>> why do we need to define an extensionData element? >>>>>>>>>>> >>>>>>>>>>> -hadriel >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>> >>>>>>>>>> DISCLAIMER: This e-mail may contain information that is >>>>>>>>> confidential, >>>>>>>>>> privileged or otherwise protected from disclosure. If you >>>>>>>> are not an >>>>>>>> >>>>>>>>>> intended recipient of this e-mail, do not duplicate or >>>>>>>>> redistribute it >>>>>>>>>> by any means. Please delete it and any attachments and >>>>>>>>> notify the sender >>>>>>>>>> that you have received it in error. Unintended recipients >>>>>>>>> are prohibited >>>>>>>>>> from taking action on the basis of information in this >>>>>>>> e-mail.E-mail >>>>>>>> >>>>>>>>>> messages may contain computer viruses or other defects, >>>>>>>> may not be >>>>>>>>>> accurately replicated on other systems, or may be >>>>>>>>> intercepted, deleted >>>>>>>>>> or interfered with without the knowledge of the sender or >>>>>>>>> the intended >>>>>>>>>> recipient. If you are not comfortable with the risks >>>>>>>> associated with >>>>>>>> >>>>>>>>>> e-mail messages, you may decide not to use e-mail to >>>>>>>>> communicate with >>>>>>>>>> IPC. IPC reserves the right, to the extent and under >>>>>>>> circumstances >>>>>>>>>> permitted by applicable law, to retain, monitor and >>>>>>>> intercept e-mail >>>>>>>> >>>>>>>>>> messages to and from its systems. >>>>>>>>>> _______________________________________________ >>>>>>>>>> siprec mailing list >>>>>>>>>> siprec@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>> >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Thu Jun 9 11:35:24 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1436111E8122 for ; Thu, 9 Jun 2011 11:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXdtwYlFDdnw for ; Thu, 9 Jun 2011 11:35:23 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9358211E80F3 for ; Thu, 9 Jun 2011 11:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=11197; q=dns/txt; s=iport; t=1307644522; x=1308854122; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=EVTM/cpEq7px/yF9p7CZUKJYOqoz//aHfF7Wrt1sSuo=; b=jftWy7JwGPfONJVnCoLEJZfYpINSr4ZHd+EZgJu4zvXawIfabYFYon4G 1B3F78a+unGNSE8A4Mkv3vf115xy0WNEJUbrWv6aGgp34cOnrWeOlBwlr OyvkvEAMxRekGn96SIRNbqfOtLERQTcyxCa/UWTGS4ZTODjvibcZi1jl4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABALYR8U1Io8UR/2dsb2JhbABTglGUe450d6oPnhaGIwSHBo56iwQ X-IronPort-AV: E=Sophos;i="4.65,342,1304294400"; d="scan'208,217";a="34528813" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 09 Jun 2011 18:35:20 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p59IZ3mH024622 for ; Thu, 9 Jun 2011 18:35:20 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Jun 2011 00:05:04 +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_01CC26D3.F3011692" Date: Fri, 10 Jun 2011 00:05:05 +0530 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06A0ADB1@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Ticket #68 Start/stop time for Recording Session Thread-Index: AcwkaW+kbQfeg9WIQ4yC6nltw6gnUQCajBOw References: <35BCE99A477D6A4986FB2216D8CF2CFD06A0ADB1@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Ram Mohan R (rmohanr)" , X-OriginalArrivalTime: 09 Jun 2011 18:35:04.0528 (UTC) FILETIME=[F317CD00:01CC26D3] Subject: Re: [siprec] Ticket #68 Start/stop time for Recording Session X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 18:35:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC26D3.F3011692 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable IMO, let the attribute be represented in the metadata model and its value (metadata format) shall be derived from Date header in RS. This will facilitate for better interoperability between SRC and SRS rather than keep it as open. =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Monday, June 06, 2011 10:18 PM To: siprec@ietf.org Subject: [siprec] Ticket #68 Start/stop time for Recording Session A ticket was raised after IETF80 on the need for a optional attribute to indicate start/stop time of RS in metadata. =20 After the discussions in last interim meeting (2011-05-09) and after that, we agreed that in the Metadata model we will continue to have RS block. However in the format there is no need for a separate element (XML) for RS. Instead the Recording Session SIP dialog will itself serve for this purpose ( and thus maps to RS block in the model).=20 Refer mail thread for details - http://www.ietf.org/mail-archive/web/siprec/current/msg01998.html =20 Since there is no separate XML representation for RS block in the schema, there is no need for any attributes. Hence we can close this ticket. =20 An SRS interested in knowing the start / stop time may derive from: * Date/Time header ( if present in SIP message ) * OR From the time at which SRS receives SIP messages.=20 =20 Let me know your thoughts on this. =20 =20 Regards, Ram ------_=_NextPart_001_01CC26D3.F3011692 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
IMO, let the attribute be represented in the = metadata model=20 and its value (metadata format) shall be derived from Date header = in RS.=20 This will facilitate for better interoperability between SRC and SRS = rather than=20 keep it as open.
 
Thanks
Partha

From: siprec-bounces@ietf.org=20 [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R=20 (rmohanr)
Sent: Monday, June 06, 2011 10:18 PM
To:=20 siprec@ietf.org
Subject: [siprec] Ticket #68 Start/stop time = for=20 Recording Session

A ticket was raised after IETF80 on the need for a = optional=20 attribute to indicate start/stop time of RS in metadata.

 

After the discussions in last interim meeting = (2011-05-09)=20 and after that, we agreed  that  in the Metadata  model = we will=20 continue to have RS block. However in the format there is no need for a = separate=20 element (XML) for RS. Instead the Recording Session SIP dialog will = itself serve=20 for this purpose ( and thus maps to RS block in the model). =

Refer mail thread for details - http://www.ietf.org/mail-archive/web/siprec/current/msg01998.html

 

Since there is no separate XML representation for = RS=20  block in the schema, there is no need for any attributes. Hence = we can=20 close this ticket.

 

An SRS interested in knowing the  start / stop = time may=20  derive from:

·        =20 Date/Time header ( if present in SIP = message=20 )

·        =20 OR From the time at which SRS receives = SIP=20 messages.

 

Let me know your thoughts on this.  =

 

Regards,

Ram

------_=_NextPart_001_01CC26D3.F3011692-- From rmohanr@cisco.com Thu Jun 9 22:12:59 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF2911E80A1 for ; Thu, 9 Jun 2011 22:12:59 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tXugex2dZ5m for ; Thu, 9 Jun 2011 22:12:58 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFD511E8078 for ; Thu, 9 Jun 2011 22:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=13834; q=dns/txt; s=iport; t=1307682778; x=1308892378; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=UWkdR5CNfMJBWelbJzpd1PTyXel6VtxaTXMO9lyQcCU=; b=Dtod4iRQUWPUN4cNds058HAQKZdbYjZKmB6uL0Pxp8C5VgklMEDbJzs8 MUYd0OkHkdwnbakhylZk9wyri8KsOUv6kgRq/a6CcTLB8zymf8WcGezWb OBC9MfmszZHmyRbqM6bt4RmCys1A/CPH7oKibFbFqznM2lUUZRN/lK2Rl A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcBAI2m8U1Io8UR/2dsb2JhbABTglGUfY50d6gcnhyGIwSHBo58iwg X-IronPort-AV: E=Sophos;i="4.65,345,1304294400"; d="scan'208,217";a="34581656" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 10 Jun 2011 05:12:55 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5A5Ct29003820 for ; Fri, 10 Jun 2011 05:12:55 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Jun 2011 10:42:55 +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_01CC272D.0E3554BC" Date: Fri, 10 Jun 2011 10:42:53 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06A0BA41@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Ticket #68 Start/stop time for Recording Session Thread-Index: AcwkaW+kbQfeg9WIQ4yC6nltw6gnUQCajBOwABZBAXA= References: <35BCE99A477D6A4986FB2216D8CF2CFD06A0ADB1@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Parthasarathi R (partr)" , X-OriginalArrivalTime: 10 Jun 2011 05:12:55.0263 (UTC) FILETIME=[0E3A86F0:01CC272D] Subject: Re: [siprec] Ticket #68 Start/stop time for Recording Session X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 05:12:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC272D.0E3554BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds fine to me. However we may not able to mandate having Date header in SIP messages between SRC and SRS. So we may have to say that the attribute value could be derived from=20 Date header ( if present in SIP message) OR >From the time at which SRS receive the SIP message to setup RS / disconnect RS ( this is not efficient though) =20 I would like to hear if there is any better way to derive the Start / Stop time of RS. =20 Ram =20 From: Parthasarathi R (partr)=20 Sent: Friday, June 10, 2011 12:05 AM To: Ram Mohan R (rmohanr); siprec@ietf.org Subject: RE: [siprec] Ticket #68 Start/stop time for Recording Session =20 IMO, let the attribute be represented in the metadata model and its value (metadata format) shall be derived from Date header in RS. This will facilitate for better interoperability between SRC and SRS rather than keep it as open. =20 Thanks Partha =20 ________________________________ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Monday, June 06, 2011 10:18 PM To: siprec@ietf.org Subject: [siprec] Ticket #68 Start/stop time for Recording Session A ticket was raised after IETF80 on the need for a optional attribute to indicate start/stop time of RS in metadata. =20 After the discussions in last interim meeting (2011-05-09) and after that, we agreed that in the Metadata model we will continue to have RS block. However in the format there is no need for a separate element (XML) for RS. Instead the Recording Session SIP dialog will itself serve for this purpose ( and thus maps to RS block in the model).=20 Refer mail thread for details - http://www.ietf.org/mail-archive/web/siprec/current/msg01998.html =20 Since there is no separate XML representation for RS block in the schema, there is no need for any attributes. Hence we can close this ticket. =20 An SRS interested in knowing the start / stop time may derive from: * Date/Time header ( if present in SIP message ) * OR From the time at which SRS receives SIP messages.=20 =20 Let me know your thoughts on this. =20 =20 Regards, Ram ------_=_NextPart_001_01CC272D.0E3554BC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sounds fine to me.  However we may not able = to mandate having Date header in SIP messages between SRC and SRS. So we = may have to say that the attribute value could be derived from =

Date header ( if present in SIP message) = OR

From the time at which SRS receive the SIP = message to setup RS / disconnect RS  ( this is not efficient = though)

 

I would like to hear if = there is any better way to derive the  Start / Stop time of = RS.

 

Ram

 

From:= = Parthasarathi R (partr)
Sent: Friday, June 10, 2011 12:05 = AM
To: Ram Mohan R (rmohanr); = siprec@ietf.org
Subject: RE: [siprec] Ticket #68 Start/stop = time for Recording Session

 

IM= O, let the attribute be represented in the metadata model and its value = (metadata format) shall be derived from Date header in RS. This = will facilitate for better interoperability between SRC and SRS rather = than keep it as open.

 

Th= anks

Pa= rtha

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ram Mohan R (rmohanr)
Sent: Monday, June 06, 2011 10:18 = PM
To: siprec@ietf.org
Subject: [siprec] Ticket #68 = Start/stop time for Recording Session

A ticket was = raised after IETF80 on the need for a optional attribute to indicate = start/stop time of RS in metadata.

 

After the = discussions in last interim meeting (2011-05-09) and after that, we = agreed  that  in the Metadata  model we will continue to = have RS block. However in the format there is no need for a separate = element (XML) for RS. Instead the Recording Session SIP dialog will = itself serve for this purpose ( and thus maps to RS block in the model). =

Refer mail thread for details - http://www.ietf.org/mail-archive/web/siprec/current/msg01998.html

 

Since there is no separate XML representation for RS =  block in the schema, there is no need for any attributes. Hence = we can close this ticket.

 

An SRS = interested in knowing the  start / stop time may  derive = from:

·         = Date/Time header ( if present in SIP message )

·         = OR From the time at which SRS receives SIP messages. =

 

Let me know your thoughts on this.  =

 

Regards,

Ram

------_=_NextPart_001_01CC272D.0E3554BC-- From eckelcu@cisco.com Fri Jun 10 10:26:43 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A4711E80D4 for ; Fri, 10 Jun 2011 10:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rkXpdSRjSu0 for ; Fri, 10 Jun 2011 10:26:42 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 75FDE11E80CC for ; Fri, 10 Jun 2011 10:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=15719; q=dns/txt; s=iport; t=1307726802; x=1308936402; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=fNQOswqy2ng1aGV2cwyrZLPwaDTmfFBkCxt18iutkas=; b=IQFFUcZhMeUMDL1OuLqBUXkR5wEshdVAeNA1V3kV+0LYa0xeQjxqmcWS rOL3qEZO12lGjWrymhCgZQRXJd0FmkkMR0HmMCM5RiqWmfPwrvbjvpSmb RUmIFOfZwWB0TDkxXQ4OGO/VbKLZ3yVbquLKovVtifVSlBZyeKixb+BfO w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgBABxS8k2rRDoJ/2dsb2JhbABSl1KOeHenLp4NhiMEhwiOeosg X-IronPort-AV: E=Sophos;i="4.65,348,1304294400"; d="scan'208";a="334515700" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2011 17:26:41 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5AHQf2W006728; Fri, 10 Jun 2011 17:26:41 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Jun 2011 10:26:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jun 2011 10:26:39 -0700 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [siprec] Can an MS object span several CSs in a CSG? thread-index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEAAHiqxwAARuZ7AAEv0wYAAASlPQAA0tNiAAM/kssAAEs2agAPRFMhAB/2vD0A== References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> From: "Charles Eckel (eckelcu)" To: "Leon Portman" , "Elwell, John" , "Parthasarathi R (partr)" , "Ram Mohan R (rmohanr)" , X-OriginalArrivalTime: 10 Jun 2011 17:26:41.0745 (UTC) FILETIME=[900E8C10:01CC2793] Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:26:44 -0000 Please excuse the delay. I am catching up after having been away on vacation. In light of this better understanding of the use case, I also prefer the option favored by John and Leon to model as a separate MS. In this specific case, I would expect the properties of the MS to change when A is transferred to C, so I expect the overhead in creating a new MS vs. reusing the same MS to be minimal and not worth the added complexity to the model. Cheers, Charles > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Tuesday, May 31, 2011 6:19 AM > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > Hello >=20 > I also having a problem even without a quantification of number of update messages that CS MS is > remains same between different CS. So I do prefer to keep it simple and keep it per CS. >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, May 27, 2011 12:26 PM > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 26 May 2011 15:55 > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > > siprec@ietf.org > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > John, > > > > The callflow mentioned by me is the basic primitive in the call center > > scenario wherein customer (participant) is same throughout the session > > and agents are changed using transfer service and B2BUA acts as SRC. > > IMO, it is one of key requirement to be considered in case we support > > for partial-update. > [JRE] Agreed the Participant remains the same, but we are discussing MS. >=20 > > This may not be the only callflow where MS partial-update is required > > in this fashion. During -00 format draft, I thought that the > > partial-update is not required but lot of folks raised the concern > > that partial update is important. Current, -01 format draft is > > designed to support partial-update. Now, You propose to restrict MS > > partial-update across CS. IMO, it is a not good idea to restrict in > > the protocol level. Anyway, I think that we need others opinion before > > conclude here. > [JRE] I am not opposed to partial update, but I would like to avoid distorting the model just to gain > some efficiency improvements in certain cases. To me it is not intuitive that a MS on one CS and an MS > on another CS are the same object, just because one of the Participants is common to both CSs. In the > transfer-between-agents example, although one of the Participants is common to the two CSs, this is > not true for the other Participants. >=20 > Let's try to quantify the efficiency improvement. In the blind transfer case, the partial updates > would at least have to include: > - the removal of P1 from CS1 (where P1 is the first agent and CS1 is the first CS); > - the removal of P2 from CS1 (where P2 is the transferred participant); > - the termination of CS1; > - the removal of CS1 from CSG1; > - the creation of CS2 (the CS that results from transfer); > - the addition to of CS2 to CSG1; > - the addition of P2 to CSG1; > - the addition of P3 to CS2 (where P3 is the second agent); > - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); > - the removal of P2 as a recipient of MS1; > - the termination of MS1; > - the creation of MS3; > - the addition of P3 as a sender of MS3; > - the addition of P2 as a recipient of MS3. >=20 > So all we are arguing about is whether we also include in the partial updates EITHER (this I think is > your proposal): > - the removal of P1 as a recipient of MS2; > - the addition of P3 as a recipient of MS2; >=20 > OR > - the removal of P1 as recipient of MS2; > - the removal of P2 as a sender of MS2; > - the termination MS2; > - the creation of MS4; > - the addition of P3 as a recipient of MS4; > - the addition of P2 as a sender of MS4. >=20 > So with the first option the total number of deltas is 14+2=3D16. > For the second option the total number of deltas is 14+6=3D20. >=20 > Some of the details might be wrong, but I hope you can see the point I am getting at. Looked at this > way, the efficiency saving by recycling MS2 for use in consecutive CSs is relatively small. Or perhaps > your intention is also to recycle MS1 (this time, the recipient remaining the same but the sender > changing). That would reduce the number of deltas slightly further. The impact on XML size might not > be quite in proportion to the reduction in the number of deltas, since by recycling MS2 it has to have > a global identifier, not an identifier local to a CS. Or perhaps it could have an identifier local to > a CSG. >=20 > I also see that with your proposal it doesn't force the MS to be recycled - an SRC could still choose > to model it as separate MSs. However, in that case it would still need to use global identifiers for > MSs. >=20 > I am not necessarily opposed to your proposal for recycling MS objects outside the context of a single > CS - I can see advantages and disadvantages. I just want to make sure the group makes an informed > decision. >=20 > John (as individual) >=20 >=20 > > > > Enhancing label attribute across the multiple SIP message to tie > > between Metadata XML and RS SDP m-line is possible. SRC has to ensure > > that label for the given RS SDP m-line should have same label > > throughout single CSG even though it span across multiple CS and > > multiple RS. Even then, it will not meet partial-update requirement as > > mentioned below in this mail thread. At this moment, I'm favoring URN > > UUID and not label attribute > > enhancement. > > > > Please read inline > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, May 25, 2011 7:17 PM > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R > > (rmohanr); siprec@ietf.org > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 25 May 2011 08:48 > > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > > > siprec@ietf.org > > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > > > John, > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > 3) B transfer the call of A & B to C using REFER, B2BUA > > > converts REFER > > > > > > > to RE-INVITE towards A & C and A & C are connected. B2BUA > > > updates RS > > > > with CS2, Participant1 as A & participant2 as C, MS1(A's media > > > > stream), MS2(C's media stream). There is no update on RS1, > > > CSG1, MS1, > > > > MS2. MS2 will become MS2 with the new association and in terms of > > > > format, it will associate with tag > > > [JRE] What harm is done (what do we lose) if, following > > transfer, A's > > > media stream is called MS3 and C's media stream is called MS4? > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > To indicate MS1 as MS3, MS1 media block has to be > > stopped in > > > the partial-update and start MS3 separate which is not required in > > > case there is a means to have common MS1. > > [JRE] It seems this distorts the model in order to give some minor > > efficiency improvement during metadata updates. I doubt that this > > alone is sufficient justification for having the MS persist from one > > CS to another CS. > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > MS3 can reference the same SDP m-line (through a=3Dlabel) as MS1, and > > > likewise MS4 could reference the same SDP m-line as MS2, if we are > > > concerned about recycling media descriptions in RS SDP. > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > As you mentioned, we will lose recycling of media > > description > > > in RS SDP without common value in media stream object for this > > > scenario. > > [JRE] I don't understand your point. With my proposal we can still > > recycle RS SDP m-lines. > > > > Agreed that Recycle is possible with your proposal. > > I indicated > > the need for unique-id in this requirement > > > > > AFAIK, Your proposal needs enhancement in RFC 4574 as label > > attribute > > > scope is within single SIP message and not required to be unique in > > > all SIP messages of a given dialog. > > [JRE] But I think we could nail that down as a requirement of the > > SIPREC protocol. > > > > John (as individual) > > > > > > > > Thanks > > > Partha > > > > > > John (as individual) > > > > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) > > > > Sent: Wednesday, May 25, 2011 1:39 AM > > > > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); > > 'Elwell, John'; > > > > 'siprec@ietf.org' > > > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > Hi Ram, > > > > > > > > I think that is many cases, they will be treated as separate MSs > > > > due to the complexities you mention. However, I am trying to > > understand if > > > > Partha feels allowing an SRC to treat them as a single MS is still > > > > required. If not, then what is a use case? A concrete example > > > > would help me, and potentially others, to better understand the > > > motivation behind > > > > Partha's requirement for modeling media from multiple CSs > > > as a single > > > > MS. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: Ram Mohan R (rmohanr) > > > > > Sent: Tuesday, May 24, 2011 9:36 AM > > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > > Elwell, John; > > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] Can an MS object span several CSs > > in a CSG? > > > > > > > > > > Charles, > > > > > > > > > > I did bring about this specific usecase of MMOH/MOH > > stream being > > > > > played to different participants earlier and suggested that > > > > they have > > > > > to treated as a same MS across multiple CSs > > (potentially recorded > > > > using multiple RSs). > > > > > Refer > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > > > > > > > > > > We had several discussions on it and it and several > > folks were in > > > > > favor of treating it as separate MS as there would be > > > > complexity in DB > > > > design. > > > > > > > > > > Regards, > > > > > Ram > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > > Sent: Tuesday, May 24, 2011 9:11 PM > > > > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > > > > Subject: Re: [siprec] Can an MS object span several CSs > > > in a CSG? > > > > > > > > > > > > Hi Partha, > > > > > > > > > > > > Is an example of this the same music on hold audio stream > > > > existing > > > > > > as the same MS within multiple CSs? If so, then I > > > understand your > > > > > > requirement to be that the SRC be able to indicate multiple > > > > > > instances of this audio stream within several CSs as > > > > being the same > > > > > > MS. Is that correct? > > > > > > > > > > > > Thanks, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Parthasarathi R (partr) > > > > > > > Sent: Tuesday, May 24, 2011 4:26 AM > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > Subject: Re: [siprec] Can an MS object span several CSs > > > > in a CSG? > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > I agree that it is not mandatory to consider recorded > > > > stream of a > > > > > > > specific participant in several CS within the same > > CSG as one > > > > > > recorded > > > > > > > stream but SIPREC protocol design MUST NOT restrict a > > > > SRC in case > > > > > > > it wishes to design in such a way. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf > > > > > > > Of Elwell, John > > > > > > > Sent: Tuesday, May 24, 2011 1:06 PM > > > > > > > To: siprec@ietf.org > > > > > > > Subject: [siprec] Can an MS object span several CSs > > in a CSG? > > > > > > > > > > > > > > We seem to have consensus that a Media Stream object > > > > represents a > > > > > > > recorded media stream, contributed to by one, > > several or all > > > > > > > Participants. However, Partha also wrote: > > > > > > > > > > > > > > "2) Each MS lifetime related to CSG because participant > > > > may move > > > > > > > from one CS to another CS within single CSG and also > > > > CSG will span > > > > > > > > > > > across multiple RS." > > > > > > > > > > > > > > I am not sure we had resolved this during earlier > > > > discussions on > > > > > > > the scope of an MS object. Although the same > > Participant can > > > > > > > participate > > > > > > in > > > > > > > several CSs within the same CSG, I don't think the > > > > recorded media > > > > > > > streams need to be considered the same. Any other views? > > > > > > > > > > > > > > John (as individual) > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Fri Jun 10 10:36:20 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E5811E80B1 for ; Fri, 10 Jun 2011 10:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3pk00oHazMM for ; Fri, 10 Jun 2011 10:36:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCDA11E815E for ; Fri, 10 Jun 2011 10:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3221; q=dns/txt; s=iport; t=1307727378; x=1308936978; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=D1Ma7Gvl+Ybd9Ch8ig34d54pZZM8LR1J9CpxEsdj7tE=; b=d8aJmxLTVW5xrcDc9wx6NTMu9muqsDQvkz/jLUK0HFxmzXQCWDbfK/fe LKEqanJ7nmp+8VQ7tEVjT3txQqji7mN1jH8Q/pQa0dK4S0vZssqMFSHqZ C54WCVxiwojrb452PV97/LFtFB5DR0/zbrwN8GwP4dFjvW7lVUSNYMmrL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgBAGVV8k1Io8UR/2dsb2JhbABSl1KOeHenH54LhiMEhwiOeosg X-IronPort-AV: E=Sophos;i="4.65,348,1304294400"; d="scan'208";a="93415859" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 10 Jun 2011 17:36:13 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5AHZkl1023196; Fri, 10 Jun 2011 17:36:12 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Jun 2011 10:36:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jun 2011 10:36:07 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? thread-index: AcwaNRNd5Kpg41TSSeWFPJywVvLejAAbXOUAAzxf8DA= References: <4DDA89F2.50706@cisco.com><4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com><4DDBE5D1.7030704@cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" , "Ram Mohan R (rmohanr)" X-OriginalArrivalTime: 10 Jun 2011 17:36:08.0565 (UTC) FILETIME=[E1E86A50:01CC2794] Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:36:20 -0000 Hi John, Given that the syntax for the content attribute in RFC 4796 allows for the assignment of additional extension values: content-attribute =3D "a=3Dcontent:" mediacnt-tag mediacnt-tag =3D mediacnt *("," mediacnt) mediacnt =3D "slides" / "speaker" / "sl" / "main" / "alt" / mediacnt-ext mediacnt-ext =3D token do you still think it is not rich enough? It seems to be that given the content and label attributes plus the grouping framework, we can express pretty complex and detailed relationships. That said, it may be simpler to express in metadata than in SDP. Is that the motivation? Cheers, Charles=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Tuesday, May 24, 2011 11:15 PM > To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) > Cc: siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? >=20 > Given that SDP's a=3Dcontent might not be rich enough, I think we need to define something new for > metadata, independent of a=3Dcontent. The SRC could choose to derive = the metadata content attribute from > the a=3Dcontent attributes of the contributing CS streams (that is an SRC decision), but should not use > the a=3Dcontent label in the RS SDP. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 24 May 2011 18:07 > > To: Ram Mohan R (rmohanr) > > Cc: Elwell, John; siprec@ietf.org > > Subject: Re: [siprec] What does an MS object represent? Can > > we pick one of theseoptions? > > > > > > > > On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: > > > Paul/ John, > > > > > > I am ok to add attribute "content" in MS block of the model. > > > > > > The question is do we want to map this attribute in the model to > > > 1) The Session Description Protocol (SDP) Content Attribute > > defined in > > > RFC 4796 OR > > > 2)define our own content in the metadata XML which can take > > values as > > > "audio" / "main video" / "presentation video" / "current > > speaker video" > > > as suggested by John. > > > > Well... > > > > ISTM that if there is already an a=3Dcontent in the CS SDP, > > then we would > > want to report that in the metadata. > > > > If there is a pair (one from offer, one from answer, same > > m-line offset) > > and there is *not* an a=3Dcontent that pairs them, then we > > would want to > > report it anyway. > > > > But if we do that we have a problem with names and conflicts. rfc4796 > > doesn't define a lot of names, nor does it say whether corresponding > > streams in offer & answer must have the same names. > > > > So I think we have something similar but not quite the same, > > and we need > > to define something new. It must permit identifying streams > > even though > > we know nothing of their purpose. > > > > Thanks, > > Paul > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From internet-drafts@ietf.org Sat Jun 11 21:04:19 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991E311E80D1; Sat, 11 Jun 2011 21:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdQ+gBp54gsP; Sat, 11 Jun 2011 21:04:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375FC11E808D; Sat, 11 Jun 2011 21:04:19 -0700 (PDT) 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.55 Message-ID: <20110612040419.16938.52325.idtracker@ietfa.amsl.com> Date: Sat, 11 Jun 2011 21:04:19 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-req-12.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 04:04:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : Use Cases and Requirements for SIP-based Media Recording= (SIPREC) Author(s) : Ken Rehor Leon Portman Andrew Hutton Rajnish Jain Filename : draft-ietf-siprec-req-12.txt Pages : 16 Date : 2011-06-11 Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics. Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-12.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-siprec-req-12.txt From partr@cisco.com Mon Jun 13 00:07:49 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CF111E8096 for ; Mon, 13 Jun 2011 00:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-7802eFRnwF for ; Mon, 13 Jun 2011 00:07:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 73A0611E808D for ; Mon, 13 Jun 2011 00:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=2044; q=dns/txt; s=iport; t=1307948868; x=1309158468; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=rzM3g6I38L/FhaI8nG6o6+fofOjB3dcsd2mVQDbJ+yc=; b=OQ83V1XWAJK9mi2UzSPirGJncTn/ddwUhQ/lgwijBWdcaufM0xX3cSQZ 6muWjSEf9EWuiDlV6TLDmlRQFZ0/YA7D2r0gVIjpN7m58XN+NQWDw1snP NOvMwp/Sh3XdmafKK3xvWYlE2h/Sj0+wxYFLV4OQBS1x9N1NF0KNq+e1T 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMBAFS29U1Io8UT/2dsb2JhbABSl1BBjjd3qXidJoYkBIcLjwGLDQ X-IronPort-AV: E=Sophos;i="4.65,356,1304294400"; d="scan'208";a="93615231" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 13 Jun 2011 07:07:46 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5D77ksv030509 for ; Mon, 13 Jun 2011 07:07:46 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 12:37:46 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jun 2011 12:37:47 +0530 Message-ID: In-Reply-To: <20110612040419.16938.52325.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-req-12.txt Thread-Index: Acwotf8u3Ga6GjnISmGI++2E/QxzaQA4Xr4g References: <20110612040419.16938.52325.idtracker@ietfa.amsl.com> From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 13 Jun 2011 07:07:46.0182 (UTC) FILETIME=[98C69260:01CC2998] Subject: Re: [siprec] I-D Action: draft-ietf-siprec-req-12.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 07:07:49 -0000 The draft looks good, covered all the requirements for SIPREC. It may be preferred to change "must" to "MUST" in "REQ-014" in consistent with other requirements. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Sunday, June 12, 2011 9:34 AM To: i-d-announce@ietf.org Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-req-12.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Recording Working Group of the IETF. Title : Use Cases and Requirements for SIP-based Media Recording (SIPREC) Author(s) : Ken Rehor Leon Portman Andrew Hutton Rajnish Jain Filename : draft-ietf-siprec-req-12.txt Pages : 16 Date : 2011-06-11 Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics. Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-12.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-siprec-req-12.txt _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Mon Jun 13 02:28:14 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFD311E80B0 for ; Mon, 13 Jun 2011 02:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTiUfe+wVmea for ; Mon, 13 Jun 2011 02:28:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CF21411E80AF for ; Mon, 13 Jun 2011 02:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2258; q=dns/txt; s=iport; t=1307957294; x=1309166894; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=wyH0W+2rMy67p5JjcY/j/mcwNYmRn4sG8b6zoHR6TF4=; b=XpZDlZvLHn9LWaucnl7zH4/6KahTuq4CvvgDT3xQv0eSLK9z9UOX3oeL jZJPMh1LADNiDJjMpBKaEmjt9YTBTSowGWpLCVd1GCPdO04W+sA/e5/3n b3nXFcCawkzvF94GIzA1W+Q0lEEgBcFJadJK/GiTpxCciaUFGvrJuA98f w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMBAOTW9U1Io8UT/2dsb2JhbABSl1BBji13qkidJYYkBIcLjwGLDQ X-IronPort-AV: E=Sophos;i="4.65,357,1304294400"; d="scan'208";a="34933020" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 13 Jun 2011 09:28:11 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5D9SBMZ024436 for ; Mon, 13 Jun 2011 09:28:11 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 14:58:11 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jun 2011 14:58:09 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06B1AFFC@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-req-12.txt Thread-Index: Acwotf8u3Ga6GjnISmGI++2E/QxzaQA4Xr4gAATyS6A= References: <20110612040419.16938.52325.idtracker@ietfa.amsl.com> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 13 Jun 2011 09:28:11.0622 (UTC) FILETIME=[36BAB060:01CC29AC] Subject: Re: [siprec] I-D Action: draft-ietf-siprec-req-12.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 09:28:14 -0000 The draft looks very good.=20 One minor comment REQ-14 - change "must" to "MUST" in compliance with rfc 2119 Regards, Ram >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > Of internet-drafts@ietf.org > Sent: Sunday, June 12, 2011 9:34 AM > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action: draft-ietf-siprec-req-12.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SIP Recording Working > Group of the IETF. >=20 > Title : Use Cases and Requirements for SIP-based Media > Recording (SIPREC) > Author(s) : Ken Rehor > Leon Portman > Andrew Hutton > Rajnish Jain > Filename : draft-ietf-siprec-req-12.txt > Pages : 16 > Date : 2011-06-11 >=20 > Session recording is a critical requirement in many business > communications environments such as call centers and financial > trading floors. In some of these environments, all calls must be > recorded for regulatory and compliance reasons. In others, calls > may > be recorded for quality control or business analytics. >=20 > Recording is typically performed by sending a copy of the session > media to the recording devices. This document specifies > requirements > for extensions to SIP that will manage delivery of RTP media to a > recording device. This is being referred to as SIP-based Media > Recording. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-12.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-req-12.txt > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From iesg-secretary@ietf.org Mon Jun 13 09:24:09 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B476F21F84D3; Mon, 13 Jun 2011 09:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUVrrm3n0u9b; Mon, 13 Jun 2011 09:24:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4004521F84C8; Mon, 13 Jun 2011 09:24:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110613162409.18409.34916.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2011 09:24:09 -0700 Cc: siprec mailing list , siprec chair , RFC Editor Subject: [siprec] Document Action: 'Use Cases and Requirements for SIP-based Media Recording (SIPREC)' to Informational RFC (draft-ietf-siprec-req-12.txt) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 16:24:09 -0000 The IESG has approved the following document: - 'Use Cases and Requirements for SIP-based Media Recording (SIPREC)' (draft-ietf-siprec-req-12.txt) as an Informational RFC This document is the product of the SIP Recording Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ Technical Summary This document summarizes the requirements for a SIP-based mechanism for controlling a session (media) recorder, taking into account any special security or privacy considerations as well as the distinction between the session that is being recorded and the session established for the purpose of recording. Working Group Summary There were no particularly controversial issues, although significant time was spent working on requirements relating to privacy and notifications. Document Quality The document has been reviewed by participants within the IETF SIPREC WG, including representatives from traditional SIP vendors as well as from session recording vendors. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' John Elwell is the document shepherd. Gonzalo Camarillo is the responsible AD. From eckelcu@cisco.com Mon Jun 13 12:56:53 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C52E11E807D for ; Mon, 13 Jun 2011 12:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO++biQRJx2z for ; Mon, 13 Jun 2011 12:56:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 65AB121F84E3 for ; Mon, 13 Jun 2011 12:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1872; q=dns/txt; s=iport; t=1307995012; x=1309204612; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=ljjDd04x2fb8VN9TOrP4CHvDG2hxugnQ0zIMCPWItYU=; b=Q9yRIudCalKZ8z8xHZcqlXvk571aAsClnzKNTu/HEya5E80XVRRev9IH mGrfaIx4A/2w/OsknsUPMHZZOhj59uWDU3Sxt58RQK3nnJGIn4iEbIAHd 3gk53LQfZw5EqWt46arv6x5rX8r0CXiABc06GPZ4aCHZP52aP77RMBbCd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkBAL9q9k2rRDoI/2dsb2JhbABShEmTAEGNPGp3qS2BH40nkEiBK4NvgQoEhw2Of4sl X-IronPort-AV: E=Sophos;i="4.65,360,1304294400"; d="scan'208";a="375790286" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 13 Jun 2011 19:56:51 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5DJup2F009881 for ; Mon, 13 Jun 2011 19:56:51 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 12:56:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 13 Jun 2011 12:56:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-eckel-siprec-rtp-rec-00.txt Thread-Index: AcwqAnZVGLiKbskDRFaW1Y2k4Cx3EgAAQxVA From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 13 Jun 2011 19:56:51.0407 (UTC) FILETIME=[09791DF0:01CC2A04] Subject: [siprec] FW: New Version Notification for draft-eckel-siprec-rtp-rec-00.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 19:56:53 -0000 SSBoYXZlIHBvc3RlZCB0aGUgaW5pdGlhbCByZXYgb2YgdGhlIFJUUCByZWNvbW1lbmRhdGlvbnMg Zm9yIFNJUFJFQyBkcmFmdC4gSXQgaXMgYXZhaWxhYmxlIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZWNrZWwtc2lwcmVjLXJ0cC1yZWMvLg0KUGxlYXNlIGhhdmUgYSBs b29rIGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzLg0KDQpDaGVlcnMsDQpDaGFybGVzDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKdW5lIDEzLCAy MDExIDEyOjQ1IFBNDQpUbzogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkNCkNjOiBDaGFybGVzIEVj a2VsIChlY2tlbGN1KQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1lY2tlbC1zaXByZWMtcnRwLXJlYy0wMC50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWVja2VsLXNpcHJlYy1ydHAtcmVjLTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IENoYXJsZXMgRWNrZWwgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5 Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWVja2VsLXNpcHJlYy1ydHAtcmVjDQpSZXZpc2lvbjoJIDAw DQpUaXRsZToJCSBSZWFsLXRpbWUgVHJhbnNwb3J0IFByb3RvY29sIChSVFApIFJlY29tbWVuZGF0 aW9ucyBmb3IgU0lQUkVDDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0wNi0xMw0KV0cgSUQ6CQkgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDExDQoNCkFic3RyYWN0Og0KICAg VGhpcyBkb2N1bWVudCBwcm92aWRlcyByZWNvbW1lbmRhdGlvbnMgYW5kIGd1aWRlbGluZXMgZm9y IFJUUCBhbmQNCiAgIFJUQ1AgaW4gdGhlIGNvbnRleHQgb2YgU0lQUkVDLiAgVGhpcyBkb2N1bWVu dCBleGlzdHMgYXMgYSBzdGFuZGFsb25lDQogICBkb2N1bWVudCB0byBmYWNpbGlhdGUgZGljdXNz aW9uIG9mIHRoZSBSVFAgcmVjb21tZW5kYXRpb25zLCBhbmQgaXQgaXMNCiAgIGFudGljaXBhdGVk IHRoYXQgcG9ydGlvbnMgb2YgdGhpcyBkb2N1bWVudCB3aWxsIGJlIGluY29ycG9yYXRlZCBpbnRv DQogICBbSS1ELnBvcnRtYW4tc2lwcmVjLXByb3RvY29sXSByYXRoZXIgdGhhbiB0aGlzIGRvY3Vt ZW50IGl0c2VsZiBiZWluZw0KICAgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From partr@cisco.com Tue Jun 14 05:15:40 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3380911E811B for ; Tue, 14 Jun 2011 05:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbynX4krp5dp for ; Tue, 14 Jun 2011 05:15:38 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AAEA411E80F8 for ; Tue, 14 Jun 2011 05:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=36589; q=dns/txt; s=iport; t=1308053736; x=1309263336; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=ATqJp+BUU2x+GxjAHmKNjCUW/l/RRa9V/J3BLVh+034=; b=Hb253ZYH/HtHcRuiyc9TzkdOdG9qF2ZIfUAsX2abOBOSRgHaOFw/cHOA OGVd3lLUgG70CgH3N+IEJ5pp2eOILs0KGInUksgENAzMw0nB+Kqsx+2wa aO/WoFetJy72rhXZe74rBHF49I8+QmzoHJRuK34HmwIefCQ9JzvahhU8l c=; X-Files: MS across CS.txt, MS within CS.txt : 7011, 7075 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBAC5Q901Io8UQ/2dsb2JhbABSl0yOdXeIc6IankKGJASHE4VtiSiLDw X-IronPort-AV: E=Sophos;i="4.65,364,1304294400"; d="txt'?scan'208";a="35152930" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 14 Jun 2011 12:15:31 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5ECDhHJ032277; Tue, 14 Jun 2011 12:15:29 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 17:45:17 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC2A8C.B8911572" Date: Tue, 14 Jun 2011 17:45:15 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEAAHiqxwAARuZ7AAEv0wYAAASlPQAA0tNiAAM/kssAAEs2agAPRFMhAB/2vD0AC9wGnQ References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , "Leon Portman" , "Elwell, John" , "Ram Mohan R (rmohanr)" , X-OriginalArrivalTime: 14 Jun 2011 12:15:17.0182 (UTC) FILETIME=[B8D77DE0:01CC2A8C] Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 12:15:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2A8C.B8911572 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, Sorry for the delay. Just to double confirm everybody understanding with SIP message example, I added the example with creating new MS and reusing the same MS as an attachment with this mail.=20 Please note that creating new MS is putting SRS implementers to guess how old MS and new MS are related. Also, few scenario like Even after looking into the example, the intention is to use local variable, I'm ok. Thanks Partha -----Original Message----- From: Charles Eckel (eckelcu)=20 Sent: Friday, June 10, 2011 10:57 PM To: Leon Portman; Elwell, John; Parthasarathi R (partr); Ram Mohan R (rmohanr); siprec@ietf.org Subject: RE: [siprec] Can an MS object span several CSs in a CSG? Please excuse the delay. I am catching up after having been away on vacation. In light of this better understanding of the use case, I also prefer the option favored by John and Leon to model as a separate MS. In this specific case, I would expect the properties of the MS to change when A is transferred to C, so I expect the overhead in creating a new MS vs. reusing the same MS to be minimal and not worth the added complexity to the model. Cheers, Charles > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Tuesday, May 31, 2011 6:19 AM > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu);=20 > Ram Mohan R (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > Hello >=20 > I also having a problem even without a quantification of number of=20 > update messages that CS MS is remains same between different CS. So I do prefer to keep it simple and keep it per CS. >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: Friday, May 27, 2011 12:26 PM > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R=20 > (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 26 May 2011 15:55 > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 > > siprec@ietf.org > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > John, > > > > The callflow mentioned by me is the basic primitive in the call=20 > > center scenario wherein customer (participant) is same throughout=20 > > the session and agents are changed using transfer service and B2BUA acts as SRC. > > IMO, it is one of key requirement to be considered in case we=20 > > support for partial-update. > [JRE] Agreed the Participant remains the same, but we are discussing MS. >=20 > > This may not be the only callflow where MS partial-update is=20 > > required in this fashion. During -00 format draft, I thought that=20 > > the partial-update is not required but lot of folks raised the=20 > > concern that partial update is important. Current, -01 format draft=20 > > is designed to support partial-update. Now, You propose to restrict=20 > > MS partial-update across CS. IMO, it is a not good idea to restrict=20 > > in the protocol level. Anyway, I think that we need others opinion=20 > > before conclude here. > [JRE] I am not opposed to partial update, but I would like to avoid=20 > distorting the model just to gain some efficiency improvements in=20 > certain cases. To me it is not intuitive that a MS on one CS and an MS > on another CS are the same object, just because one of the=20 > Participants is common to both CSs. In the transfer-between-agents example, although one of the Participants is common to the two CSs, this is not true for the other Participants. >=20 > Let's try to quantify the efficiency improvement. In the blind=20 > transfer case, the partial updates would at least have to include: > - the removal of P1 from CS1 (where P1 is the first agent and CS1 is=20 > the first CS); > - the removal of P2 from CS1 (where P2 is the transferred=20 > participant); > - the termination of CS1; > - the removal of CS1 from CSG1; > - the creation of CS2 (the CS that results from transfer); > - the addition to of CS2 to CSG1; > - the addition of P2 to CSG1; > - the addition of P3 to CS2 (where P3 is the second agent); > - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); > - the removal of P2 as a recipient of MS1; > - the termination of MS1; > - the creation of MS3; > - the addition of P3 as a sender of MS3; > - the addition of P2 as a recipient of MS3. >=20 > So all we are arguing about is whether we also include in the partial=20 > updates EITHER (this I think is your proposal): > - the removal of P1 as a recipient of MS2; > - the addition of P3 as a recipient of MS2; >=20 > OR > - the removal of P1 as recipient of MS2; > - the removal of P2 as a sender of MS2; > - the termination MS2; > - the creation of MS4; > - the addition of P3 as a recipient of MS4; > - the addition of P2 as a sender of MS4. >=20 > So with the first option the total number of deltas is 14+2=3D16. > For the second option the total number of deltas is 14+6=3D20. >=20 > Some of the details might be wrong, but I hope you can see the point I > am getting at. Looked at this way, the efficiency saving by recycling=20 > MS2 for use in consecutive CSs is relatively small. Or perhaps your=20 > intention is also to recycle MS1 (this time, the recipient remaining=20 > the same but the sender changing). That would reduce the number of=20 > deltas slightly further. The impact on XML size might not be quite in=20 > proportion to the reduction in the number of deltas, since by recycling MS2 it has to have a global identifier, not an identifier local to a CS. Or perhaps it could have an identifier local to a CSG. >=20 > I also see that with your proposal it doesn't force the MS to be=20 > recycled - an SRC could still choose to model it as separate MSs.=20 > However, in that case it would still need to use global identifiers for MSs. >=20 > I am not necessarily opposed to your proposal for recycling MS objects > outside the context of a single CS - I can see advantages and=20 > disadvantages. I just want to make sure the group makes an informed decision. >=20 > John (as individual) >=20 >=20 > > > > Enhancing label attribute across the multiple SIP message to tie=20 > > between Metadata XML and RS SDP m-line is possible. SRC has to=20 > > ensure that label for the given RS SDP m-line should have same label > > throughout single CSG even though it span across multiple CS and=20 > > multiple RS. Even then, it will not meet partial-update requirement=20 > > as mentioned below in this mail thread. At this moment, I'm favoring > > URN UUID and not label attribute enhancement. > > > > Please read inline > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, May 25, 2011 7:17 PM > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R=20 > > (rmohanr); siprec@ietf.org > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 25 May 2011 08:48 > > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 > > > siprec@ietf.org > > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > > > John, > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D > > > > 3) B transfer the call of A & B to C using REFER, B2BUA > > > converts REFER > > > > > > > to RE-INVITE towards A & C and A & C are connected. B2BUA > > > updates RS > > > > with CS2, Participant1 as A & participant2 as C, MS1(A's media=20 > > > > stream), MS2(C's media stream). There is no update on RS1, > > > CSG1, MS1, > > > > MS2. MS2 will become MS2 with the new association and in terms=20 > > > > of format, it will associate with tag > > > [JRE] What harm is done (what do we lose) if, following > > transfer, A's > > > media stream is called MS3 and C's media stream is called MS4? > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D > > > To indicate MS1 as MS3, MS1 media block has to be > > stopped in > > > the partial-update and start MS3 separate which is not required in > > > case there is a means to have common MS1. > > [JRE] It seems this distorts the model in order to give some minor=20 > > efficiency improvement during metadata updates. I doubt that this=20 > > alone is sufficient justification for having the MS persist from one > > CS to another CS. > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > MS3 can reference the same SDP m-line (through a=3Dlabel) as MS1,=20 > > > and likewise MS4 could reference the same SDP m-line as MS2, if we > > > are concerned about recycling media descriptions in RS SDP. > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > As you mentioned, we will lose recycling of media > > description > > > in RS SDP without common value in media stream object for this=20 > > > scenario. > > [JRE] I don't understand your point. With my proposal we can still=20 > > recycle RS SDP m-lines. > > > > Agreed that Recycle is possible with your proposal. > > I indicated > > the need for unique-id in this requirement > > > > > AFAIK, Your proposal needs enhancement in RFC 4574 as label > > attribute > > > scope is within single SIP message and not required to be unique=20 > > > in all SIP messages of a given dialog. > > [JRE] But I think we could nail that down as a requirement of the=20 > > SIPREC protocol. > > > > John (as individual) > > > > > > > > Thanks > > > Partha > > > > > > John (as individual) > > > > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) > > > > Sent: Wednesday, May 25, 2011 1:39 AM > > > > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); > > 'Elwell, John'; > > > > 'siprec@ietf.org' > > > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > Hi Ram, > > > > > > > > I think that is many cases, they will be treated as separate MSs > > > > due to the complexities you mention. However, I am trying to > > understand if > > > > Partha feels allowing an SRC to treat them as a single MS is=20 > > > > still required. If not, then what is a use case? A concrete=20 > > > > example would help me, and potentially others, to better=20 > > > > understand the > > > motivation behind > > > > Partha's requirement for modeling media from multiple CSs > > > as a single > > > > MS. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: Ram Mohan R (rmohanr) > > > > > Sent: Tuesday, May 24, 2011 9:36 AM > > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > > Elwell, John; > > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] Can an MS object span several CSs > > in a CSG? > > > > > > > > > > Charles, > > > > > > > > > > I did bring about this specific usecase of MMOH/MOH > > stream being > > > > > played to different participants earlier and suggested that > > > > they have > > > > > to treated as a same MS across multiple CSs > > (potentially recorded > > > > using multiple RSs). > > > > > Refer > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > > > > > > > > > > We had several discussions on it and it and several > > folks were in > > > > > favor of treating it as separate MS as there would be > > > > complexity in DB > > > > design. > > > > > > > > > > Regards, > > > > > Ram > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > > Sent: Tuesday, May 24, 2011 9:11 PM > > > > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > > > > Subject: Re: [siprec] Can an MS object span several CSs > > > in a CSG? > > > > > > > > > > > > Hi Partha, > > > > > > > > > > > > Is an example of this the same music on hold audio stream > > > > existing > > > > > > as the same MS within multiple CSs? If so, then I > > > understand your > > > > > > requirement to be that the SRC be able to indicate multiple=20 > > > > > > instances of this audio stream within several CSs as > > > > being the same > > > > > > MS. Is that correct? > > > > > > > > > > > > Thanks, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Parthasarathi R (partr) > > > > > > > Sent: Tuesday, May 24, 2011 4:26 AM > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > Subject: Re: [siprec] Can an MS object span several CSs > > > > in a CSG? > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > I agree that it is not mandatory to consider recorded > > > > stream of a > > > > > > > specific participant in several CS within the same > > CSG as one > > > > > > recorded > > > > > > > stream but SIPREC protocol design MUST NOT restrict a > > > > SRC in case > > > > > > > it wishes to design in such a way. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf > > > > > > > Of Elwell, John > > > > > > > Sent: Tuesday, May 24, 2011 1:06 PM > > > > > > > To: siprec@ietf.org > > > > > > > Subject: [siprec] Can an MS object span several CSs > > in a CSG? > > > > > > > > > > > > > > We seem to have consensus that a Media Stream object > > > > represents a > > > > > > > recorded media stream, contributed to by one, > > several or all > > > > > > > Participants. However, Partha also wrote: > > > > > > > > > > > > > > "2) Each MS lifetime related to CSG because participant > > > > may move > > > > > > > from one CS to another CS within single CSG and also > > > > CSG will span > > > > > > > > > > > across multiple RS." > > > > > > > > > > > > > > I am not sure we had resolved this during earlier > > > > discussions on > > > > > > > the scope of an MS object. Although the same > > Participant can > > > > > > > participate > > > > > > in > > > > > > > several CSs within the same CSG, I don't think the > > > > recorded media > > > > > > > streams need to be considered the same. Any other views? > > > > > > > > > > > > > > John (as individual) > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CC2A8C.B8911572 Content-Type: text/plain; name="MS across CS.txt" Content-Transfer-Encoding: base64 Content-Description: MS across CS.txt Content-Disposition: attachment; filename="MS across CS.txt" U2NlbmFyaW86DQoNCjEpIEEgY2FsbHMgQiB0aHJvdWdoIEIyQlVBLiBCMkJVQSBjcmVhdGVzIFJT IHRvd2FyZHMgU1JTIHdpdGggQ1NHMSwgQ1MxLA0KTVMxIChBJ3MgbWVkaWEgc3RyZWFtKSwgTVMy IChCJ3MgbWVkaWEgc3RyZWFtKSwgUGFydGljaXBhbnQxIGFzIEEgJg0KUGFydGljaXBhbnQyIGFz IEIuDQoyKSBCIHRyYW5zZmVyIHRoZSBjYWxsIG9mIEEgJiBCIHRvIEMgdXNpbmcgUkVGRVIsIEIy QlVBIGNvbnZlcnRzIFJFRkVSIHRvIFJFLUlOVklURSB0b3dhcmRzIEEgJiBDIGFuZCBBICYgQyBh cmUgY29ubmVjdGVkLiBCMkJVQSB1cGRhdGVzIFJTIHdpdGggQ1MyLCBQYXJ0aWNpcGFudDEgYXMg QSAmIHBhcnRpY2lwYW50MiBhcyBDLCBNUzEoQSdzIG1lZGlhIHN0cmVhbSksIE1TMihDJ3MgbWVk aWEgc3RyZWFtKS4gVGhlcmUgaXMgbm8gdXBkYXRlIG9uIFJTMSwgQ1NHMSwgTVMxLCBNUzIuIE1T MiB3aWxsIGJlY29tZSBNUzIgd2l0aCB0aGUgbmV3IGFzc29jaWF0aW9uIGFuZCBpbiB0ZXJtcyBv ZiBmb3JtYXQsIGl0IHdpbGwgYXNzb2NpYXRlIHdpdGggPHNlbmQ+IHRhZw0KDQpSUyBTSVAgbWVz c2FnZXMgd2l0aCBtZXRhZGF0YToNCg0KSW5pdGlhbCBJbnZpdGU6DQoNCklOVklURSBzaXA6MTA0 MUByZWNvcmRpbmdzZXJ2ZXIuY2lzY28uY29tOjUwNjA7dHJhbnNwb3J0PXRjcCBTSVAvMi4wDQpW aWE6IFNJUC8yLjAvVENQIDEwLjIxLjgzLjU4O2JyYW5jaD16OWhHNGJLLTE5OTM1LTEtNw0KTWF4 LUZvcndhcmRzOiA3MA0KVG86IDxzaXA6MTA0MUByZWNvcmRpbmdzZXJ2ZXIuY2lzY28uY29tPg0K RnJvbTogUmVjcmRpbmdDbGllbnQgPHNpcDoxMC4yMS44My41OD47dGFnPWRzNDNkNzYyNjMNCkNh bGwtSUQ6IDEyNTQ4MDg2OTcwMjYxQDE5Mi4xNjguMS42Nw0KQ1NlcTogMTAwIElOVklURQ0KQ29u dGVudC1MZW5ndGg6IHh4eA0KQ29udGFjdDogPHNpcDoxMC4yMS44My41ODo1MDYwO3RyYW5zcG9y dD10Y3A+O2F1ZGlvOw0KRGF0ZTogVHVlLCAxNiBEZWMgMjAxMCAyMzo0NTowNyBHTVQNCkNvbnRl bnQtVHlwZTogbXVsdGlwYXJ0L21peGVkO2JvdW5kYXJ5PXVuaXF1ZS1ib3VuZGFyeS0xDQpNSU1F LVZlcnNpb246IDEuMA0KDQotLXVuaXF1ZS1ib3VuZGFyeS0xDQpDb250ZW50LVR5cGU6IGFwcGxp Y2F0aW9uL1NEUA0KLi4uDQptPWF1ZGlvIDQ5MTcwIFJUUC9BVlAgMCAgICAgICAgICANCmE9cnRw bWFwOjAgUENNVS84MDAwDQphPWxhYmVsOjk2DQphPXNlbmRvbmx5DQouLi4NCm09dmlkZW8gNDkx NzQgUlRQL0FWUEYgOTYgICAgDQphPXJ0cG1hcDo5NiBILjI2NC85MDAwMA0KYT1sYWJlbDo5Nw0K YT1zZW5kb25seQ0KLi4uDQptPWF1ZGlvIDUxMzcyIFJUUC9BVlAgMCAgICAgICAgICANCmE9cnRw bWFwOjAgUENNVS84MDAwDQphPWxhYmVsOjk4DQphPXNlbmRvbmx5DQouLi4NCm09dmlkZW8gNDkx NzYgUlRQL0FWUEYgOTYgICAgICAgICANCmE9cnRwbWFwOjk2IEguMjY0LzkwMDAwDQphPWxhYmVs Ojk5DQphPXNlbmRvbmx5DQouLi4uDQoNCi0tdW5pcXVlLWJvdW5kYXJ5LTENCkNvbnRlbnQtdHlw ZTphcHBsaWNhdGlvbi9ycy1tZXRhZGF0YSt4bWwNCg0KPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNv ZGluZz0iVVRGLTgiPz4NCiAgPHJlY29yZGluZyB4bWxucz0ndXJuOmlldGY6cGFyYW1zOnhtbDpu czpyZWNvcmRpbmcnPg0KICAgICA8Z3JvdXAgaWQ9InVybjp1dWlkOmVmZTM5MzBiLTJhMzEtNGU2 YS1hNmFiLTIwM2ZkNzA3ODMwMiI+ICAgDQogICAgIDwvZ3JvdXA+DQogICAgIDxzZXNzaW9uIGlk PSJ1cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcwZi02ZGExZWVhZWI0MjUiPg0KICAgICAg IDxncm91cC1yZWY+dXJuOnV1aWQ6ZWZlMzkzMGItMmEzMS00ZTZhLWE2YWItMjAzZmQ3MDc4MzAy DQogICAgICAgPC9ncm91cC1yZWY+DQogICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQyMzo0 MTowN1o8L3N0YXJ0LXRpbWU+DQogICAgIDwvc2Vzc2lvbj4NCiAgICAgPHBhcnRpY2lwYW50IA0K ICAgICAgICBpZD0idXJuOnV1aWQ6YjJiN2MxMTItNTk4Mi00NjlkLTkwMDctNmRkYmVjY2E2NGQz Ig0KICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcwZi02ZGEx ZWVhZWI0MjUiPg0KICAgICAgICA8YW9yPnNpcDpwYXJ0aGFAYmxyLmNpc2NvLmNvbTwvYW9yPg0K ICAgICAgICA8c2VuZD51cm46dXVpZDo4YjUzZjNkZS1kYTM5LTQ4NDYtOTNjNy1lZTVlNWY4ZjZm MGI8L3NlbmQ+DQogICAgICAgIDxzZW5kPnVybjp1dWlkOjUwMDAwYzliLTkxOTEtNDBhNC04MjMx LTViY2JjYTVlMmIxNzwvc2VuZD4NCiAgICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQyMzo0 MTowN1o8L3N0YXJ0LXRpbWU+DQogICAgIDwvcGFydGljaXBhbnQ+DQogICAgIDxwYXJ0aWNpcGFu dCANCiAgICAgICAgIGlkPSJ1cm46dXVpZDpjZDI3Y2ZhMS0yYmRkLTQ4MzAtYTY1My03MDM3NGQx MGYxMDMiDQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcw Zi02ZGExZWVhZWI0MjUiPg0KICAgICAgICAgPGFvcj5zaXA6cGF1bEBib3guY2lzY28uY29tPC9h b3I+DQogICAgICAgICA8c2VuZD51cm46dXVpZDo1MDAwMGM5Yi05MTkxLTQwYTQtODIzMS01YmNi Y2E1ZTJiMTc8L3NlbmQ+DQogICAgICAgICA8c2VuZD51cm46dXVpZDo4YjUzZjNkZS1kYTM5LTQ4 NDYtOTNjNy1lZTVlNWY4ZjZmMGI8L3NlbmQ+DQogICAgICAgICA8c3RhcnQtdGltZT4yMDEwLTEy LTE2VDIzOjQxOjA3Wjwvc3RhcnQtdGltZT4NCiAgICAgPC9wYXJ0aWNpcGFudD4NCiAgICAgPHN0 cmVhbSBpZD0idXJuOnV1aWQ6NTAwMDBjOWItOTE5MS00MGE0LTgyMzEtNWJjYmNhNWUyYjE3Ig0K ICAgICAgICAgc2Vzc2lvbj0idXJuOnV1aWQ6ODU1YTVkZWQtODQyMC00NTZkLWE3MGYtNmRhMWVl YWViNDI1Ij4NCiAgICAgICAgIDxzdGFydC10aW1lPjIwMTAtMTItMTZUMjM6NDE6MDdaPC9zdGFy dC10aW1lPg0KICAgICAgICAgPGxhYmVsPjk2PC9sYWJlbD4NCiAgICAgPC9zdHJlYW0+DQogICAg IDxzdHJlYW0gaWQ9InVybjp1dWlkOjhiNTNmM2RlLWRhMzktNDg0Ni05M2M3LWVlNWU1ZjhmNmYw YiINCiAgICAgICAgIHNlc3Npb249InVybjp1dWlkOjg1NWE1ZGVkLTg0MjAtNDU2ZC1hNzBmLTZk YTFlZWFlYjQyNSI+DQogICAgICAgICA8c3RhcnQtdGltZT4yMDEwLTEyLTE2VDIzOjQxOjA3Wjwv c3RhcnQtdGltZT4NCiAgICAgICAgIDxsYWJlbD45NzwvbGFiZWw+DQogICAgIDwvc3RyZWFtPg0K ICAgICA8c3RyZWFtIGlkPSJ1cm46dXVpZDpmMzM3M2E3Yi00OTU4LTRlNTUtODgyMC1kMDNhMTkx ZmI3NmEiDQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDpjZDI3Y2ZhMS0yYmRkLTQ4MzAtYTY1 My03MDM3NGQxMGYxMDMiPg0KICAgICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQyMzo0MTow N1o8L3N0YXJ0LXRpbWU+DQogICAgICAgICA8bGFiZWw+OTg8L2xhYmVsPg0KICAgICA8L3N0cmVh bT4NCiAgICAgPHN0cmVhbSBpZD0idXJuOnV1aWQ6MTIyNWM2OTUtY2ZiOC00ZWJiLWFhYWEtODBk YTM0NGVmYTZhIg0KICAgICAgICAgc2Vzc2lvbj0idXJuOnV1aWQ6Y2QyN2NmYTEtMmJkZC00ODMw LWE2NTMtNzAzNzRkMTBmMTAzIj4NCiAgICAgICAgIDxzdGFydC10aW1lPjIwMTAtMTItMTZUMjM6 NDE6MDdaPC9zdGFydC10aW1lPg0KICAgICAgICAgPGxhYmVsPjk5PC9sYWJlbD4NCiAgICAgPC9z dHJlYW0+DQo8L3JlY29yZGluZz4NCg0KLS11bmlxdWUtYm91bmRhcnktMS0tDQoNClBhcnRpY2lw YW50IGNoYW5nZSB1c2luZyBSZS1JTlZJVEUgd2l0aG91dCBNUywgQ1NHIGNoYW5nZToNCg0KSU5W SVRFIHNpcDoxMDQxQHJlY29yZGluZ3NlcnZlci5jaXNjby5jb206NTA2MDt0cmFuc3BvcnQ9dGNw IFNJUC8yLjANClZpYTogU0lQLzIuMC9UQ1AgMTAuMjEuODMuNTg7YnJhbmNoPXo5aEc0YkstMTk5 MzUtMS05DQpNYXgtRm9yd2FyZHM6IDcwDQpUbzogPHNpcDoxMDQxQHJlY29yZGluZ3NlcnZlci5j aXNjby5jb20+O3RhZz01MjYyQkEwLTEzRDQNCkZyb206IFJlY3JkaW5nQ2xpZW50IDxzaXA6MTAu MjEuODMuNTg+O3RhZz1kczQzZDc2MjYzDQpDYWxsLUlEOiAxMjU0ODA4Njk3MDI2MUAxOTIuMTY4 LjEuNjcNCkNTZXE6IDEwMSBJTlZJVEUNCkNvbnRlbnQtTGVuZ3RoOiB4eHgNCkNvbnRhY3Q6IDxz aXA6MTAuMjEuODMuNTg6NTA2MDt0cmFuc3BvcnQ9dGNwPjthdWRpbzsNCkRhdGU6IFR1ZSwgMTYg RGVjIDIwMTAgMjM6NDU6MDcgR01UDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDtib3Vu ZGFyeT11bmlxdWUtYm91bmRhcnktMQ0KTUlNRS1WZXJzaW9uOiAxLjANCg0KLS11bmlxdWUtYm91 bmRhcnktMQ0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9TRFANCi4uLg0KbT1hdWRpbyA0OTE3 MCBSVFAvQVZQIDAgICAgICAgICAgDQphPXJ0cG1hcDowIFBDTVUvODAwMA0KYT1sYWJlbDo5Ng0K YT1zZW5kb25seQ0KLi4uDQptPXZpZGVvIDQ5MTc0IFJUUC9BVlBGIDk2ICAgIA0KYT1ydHBtYXA6 OTYgSC4yNjQvOTAwMDANCmE9bGFiZWw6OTcNCmE9c2VuZG9ubHkNCi4uLg0KbT1hdWRpbyA1MTM3 MiBSVFAvQVZQIDAgICAgICAgICAgDQphPXJ0cG1hcDowIFBDTVUvODAwMA0KYT1sYWJlbDo5OA0K YT1zZW5kb25seQ0KLi4uDQptPXZpZGVvIDQ5MTc2IFJUUC9BVlBGIDk2ICAgICAgICAgDQphPXJ0 cG1hcDo5NiBILjI2NC85MDAwMA0KYT1sYWJlbDo5OQ0KYT1zZW5kb25seQ0KLi4uLg0KDQotLXVu aXF1ZS1ib3VuZGFyeS0xDQpDb250ZW50LXR5cGU6YXBwbGljYXRpb24vcnMtbWV0YWRhdGEreG1s DQoNCjw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DQogIDxyZWNvcmRpbmcg eG1sbnM9J3VybjppZXRmOnBhcmFtczp4bWw6bnM6cmVjb3JkaW5nJz4NCiAgICAgPGRhdGFNb2Rl PnBhcnRpYWw8L2RhdGFNb2RlPiAgDQogICAgIDxzZXNzaW9uIGlkPSJ1cm46dXVpZDoxOGJiYTRm ZjItOTY2My0xMWUwLTk1MTYtNWI5YjQ4MjQwMTliIj4NCiAgICAgICA8Z3JvdXAtcmVmPnVybjp1 dWlkOmVmZTM5MzBiLTJhMzEtNGU2YS1hNmFiLTIwM2ZkNzA3ODMwMg0KICAgICAgIDwvZ3JvdXAt cmVmPg0KICAgICAgIDxzdGFydC10aW1lPjIwMTAtMTItMTZUMjM6NDU6MDdaPC9zdGFydC10aW1l Pg0KICAgICA8L3Nlc3Npb24+DQogICAgIDxzZXNzaW9uIGlkPSJ1cm46dXVpZDo4NTVhNWRlZC04 NDIwLTQ1NmQtYTcwZi02ZGExZWVhZWI0MjUiPg0KICAgICAgIDxzdG9wLXRpbWU+MjAxMC0xMi0x NlQyMzo0NTowN1o8L3N0b3AtdGltZT4NCiAgICAgPC9zZXNzaW9uPg0KICAgICA8cGFydGljaXBh bnQgDQogICAgICAgIGlkPSJ1cm46dXVpZDpiMmI3YzExMi01OTgyLTQ2OWQtOTAwNy02ZGRiZWNj YTY0ZDMiDQogICAgICAgIHNlc3Npb249InVybjp1dWlkOjE4YmJhNGZmMi05NjYzLTExZTAtOTUx Ni01YjliNDgyNDAxOWIiPg0KICAgICAgICA8YW9yPnNpcDpwYXJ0aGFAYmxyLmNpc2NvLmNvbTwv YW9yPg0KICAgICAgICA8c2VuZD51cm46dXVpZDo4YjUzZjNkZS1kYTM5LTQ4NDYtOTNjNy1lZTVl NWY4ZjZmMGI8L3NlbmQ+DQogICAgICAgIDxzZW5kPnVybjp1dWlkOjUwMDAwYzliLTkxOTEtNDBh NC04MjMxLTViY2JjYTVlMmIxNzwvc2VuZD4NCiAgICAgPC9wYXJ0aWNpcGFudD4NCiAgICAgPHBh cnRpY2lwYW50IA0KICAgICAgICAgaWQ9InVybjp1dWlkOmNkMjdjZmExLTJiZGQtNDgzMC1hNjUz LTcwMzc0ZDEwZjEwMyINCiAgICAgICAgIHNlc3Npb249InVybjp1dWlkOjg1NWE1ZGVkLTg0MjAt NDU2ZC1hNzBmLTZkYTFlZWFlYjQyNSI+DQogICAgICAgICA8c3RvcC10aW1lPjIwMTAtMTItMTZU MjM6NDU6MDdaPC9zdG9wLXRpbWU+DQogICAgIDwvcGFydGljaXBhbnQ+DQogICAgIDxwYXJ0aWNp cGFudCANCiAgICAgICAgIGlkPSJ1cm46dXVpZDpjZDI3Y2ZhMS0yYmRkLTQ4MzAtYTY1My03MDM3 NGQxMGYxMDMiDQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDoxOGJiYTRmZjItOTY2My0xMWUw LTk1MTYtNWI5YjQ4MjQwMTliIj4NCiAgICAgICAgIDxzdGFydC10aW1lPjIwMTAtMTItMTZUMjM6 NDU6MDdaPC9zdG9wLXRpbWU+DQogICAgICAgICA8YW9yPnNpcDpyYW1AYmxyLmNpc2NvLmNvbTwv YW9yPg0KICAgICAgICAgPHNlbmQ+dXJuOnV1aWQ6NTAwMDBjOWItOTE5MS00MGE0LTgyMzEtNWJj YmNhNWUyYjE3PC9zZW5kPg0KICAgICAgICAgPHNlbmQ+dXJuOnV1aWQ6OGI1M2YzZGUtZGEzOS00 ODQ2LTkzYzctZWU1ZTVmOGY2ZjBiPC9zZW5kPg0KICAgICA8L3BhcnRpY2lwYW50Pg0KICAgICA8 c3RyZWFtIGlkPSJ1cm46dXVpZDo1MDAwMGM5Yi05MTkxLTQwYTQtODIzMS01YmNiY2E1ZTJiMTci DQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDoxOGJiYTRmZjItOTY2My0xMWUwLTk1MTYtNWI5 YjQ4MjQwMTliIj4NCiAgICAgICAgIDxsYWJlbD45NjwvbGFiZWw+DQogICAgIDwvc3RyZWFtPg0K ICAgICA8c3RyZWFtIGlkPSJ1cm46dXVpZDo4YjUzZjNkZS1kYTM5LTQ4NDYtOTNjNy1lZTVlNWY4 ZjZmMGIiDQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDoxOGJiYTRmZjItOTY2My0xMWUwLTk1 MTYtNWI5YjQ4MjQwMTliIj4NCiAgICAgICAgIDxsYWJlbD45NzwvbGFiZWw+DQogICAgIDwvc3Ry ZWFtPg0KICAgICA8c3RyZWFtIGlkPSJ1cm46dXVpZDpmMzM3M2E3Yi00OTU4LTRlNTUtODgyMC1k MDNhMTkxZmI3NmEiDQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDoxOGJiYTRmZjItOTY2My0x MWUwLTk1MTYtNWI5YjQ4MjQwMTliIj4NCiAgICAgICAgIDxsYWJlbD45ODwvbGFiZWw+DQogICAg IDwvc3RyZWFtPg0KICAgICA8c3RyZWFtIGlkPSJ1cm46dXVpZDoxMjI1YzY5NS1jZmI4LTRlYmIt YWFhYS04MGRhMzQ0ZWZhNmEiDQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDoxOGJiYTRmZjIt OTY2My0xMWUwLTk1MTYtNWI5YjQ4MjQwMTliIj4NCiAgICAgICAgIDxsYWJlbD45OTwvbGFiZWw+ DQogICAgIDwvc3RyZWFtPg0KPC9yZWNvcmRpbmc+DQoNCi0tdW5pcXVlLWJvdW5kYXJ5LTEtLQ0K ------_=_NextPart_001_01CC2A8C.B8911572 Content-Type: text/plain; name="MS within CS.txt" Content-Transfer-Encoding: base64 Content-Description: MS within CS.txt Content-Disposition: attachment; filename="MS within CS.txt" U2NlbmFyaW86DQoNCjEpIEEgY2FsbHMgQiB0aHJvdWdoIEIyQlVBLiBCMkJVQSBjcmVhdGVzIFJT IHRvd2FyZHMgU1JTIHdpdGggQ1NHMSwgQ1MxLA0KTVMxIChBJ3MgbWVkaWEgc3RyZWFtKSwgTVMy IChCJ3MgbWVkaWEgc3RyZWFtKSwgUGFydGljaXBhbnQxIGFzIEEgJg0KUGFydGljaXBhbnQyIGFz IEIuDQoyKSBCIHRyYW5zZmVyIHRoZSBjYWxsIG9mIEEgJiBCIHRvIEMgdXNpbmcgUkVGRVIsIEIy QlVBIGNvbnZlcnRzIFJFRkVSIHRvIFJFLUlOVklURSB0b3dhcmRzIEEgJiBDIGFuZCBBICYgQyBh cmUgY29ubmVjdGVkLiBCMkJVQSB1cGRhdGVzIFJTIHdpdGggQ1MyLCBQYXJ0aWNpcGFudDEgYXMg QSAmIHBhcnRpY2lwYW50MiBhcyBDLCBNUzEoQSdzIG1lZGlhIHN0cmVhbSksIE1TMihDJ3MgbWVk aWEgc3RyZWFtKS4gVGhlcmUgaXMgbm8gdXBkYXRlIG9uIFJTMSwgQ1NHMSwgTVMxLCBNUzIuIE1T MiB3aWxsIGJlY29tZSBNUzIgd2l0aCB0aGUgbmV3IGFzc29jaWF0aW9uIGFuZCBpbiB0ZXJtcyBv ZiBmb3JtYXQsIGl0IHdpbGwgYXNzb2NpYXRlIHdpdGggPHNlbmQ+IHRhZw0KDQpSUyBTSVAgbWVz c2FnZXMgd2l0aCBtZXRhZGF0YToNCg0KSW5pdGlhbCBJbnZpdGU6DQoNCklOVklURSBzaXA6MTA0 MUByZWNvcmRpbmdzZXJ2ZXIuY2lzY28uY29tOjUwNjA7dHJhbnNwb3J0PXRjcCBTSVAvMi4wDQpW aWE6IFNJUC8yLjAvVENQIDEwLjIxLjgzLjU4O2JyYW5jaD16OWhHNGJLLTE5OTM1LTEtNw0KTWF4 LUZvcndhcmRzOiA3MA0KVG86IDxzaXA6MTA0MUByZWNvcmRpbmdzZXJ2ZXIuY2lzY28uY29tPg0K RnJvbTogUmVjcmRpbmdDbGllbnQgPHNpcDoxMC4yMS44My41OD47dGFnPWRzNDNkNzYyNjMNCkNh bGwtSUQ6IDEyNTQ4MDg2OTcwMjYxQDE5Mi4xNjguMS42Nw0KQ1NlcTogMTAwIElOVklURQ0KQ29u dGVudC1MZW5ndGg6IHh4eA0KQ29udGFjdDogPHNpcDoxMC4yMS44My41ODo1MDYwO3RyYW5zcG9y dD10Y3A+O2F1ZGlvOw0KRGF0ZTogVHVlLCAxNiBEZWMgMjAxMCAyMzo0MTowNyBHTVQNCkNvbnRl bnQtVHlwZTogbXVsdGlwYXJ0L21peGVkO2JvdW5kYXJ5PXVuaXF1ZS1ib3VuZGFyeS0xDQpNSU1F LVZlcnNpb246IDEuMA0KDQotLXVuaXF1ZS1ib3VuZGFyeS0xDQpDb250ZW50LVR5cGU6IGFwcGxp Y2F0aW9uL1NEUA0KLi4uDQptPWF1ZGlvIDQ5MTcwIFJUUC9BVlAgMCAgICAgICAgICANCmE9cnRw bWFwOjAgUENNVS84MDAwDQphPWxhYmVsOjk2DQphPXNlbmRvbmx5DQouLi4NCm09dmlkZW8gNDkx NzQgUlRQL0FWUEYgOTYgICAgDQphPXJ0cG1hcDo5NiBILjI2NC85MDAwMA0KYT1sYWJlbDo5Nw0K YT1zZW5kb25seQ0KLi4uDQptPWF1ZGlvIDUxMzcyIFJUUC9BVlAgMCAgICAgICAgICANCmE9cnRw bWFwOjAgUENNVS84MDAwDQphPWxhYmVsOjk4DQphPXNlbmRvbmx5DQouLi4NCm09dmlkZW8gNDkx NzYgUlRQL0FWUEYgOTYgICAgICAgICANCmE9cnRwbWFwOjk2IEguMjY0LzkwMDAwDQphPWxhYmVs Ojk5DQphPXNlbmRvbmx5DQouLi4uDQoNCi0tdW5pcXVlLWJvdW5kYXJ5LTENCkNvbnRlbnQtdHlw ZTphcHBsaWNhdGlvbi9ycy1tZXRhZGF0YSt4bWwNCg0KPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNv ZGluZz0iVVRGLTgiPz4NCiAgPHJlY29yZGluZyB4bWxucz0ndXJuOmlldGY6cGFyYW1zOnhtbDpu czpyZWNvcmRpbmcnPg0KICAgICA8Z3JvdXAgaWQ9InVybjp1dWlkOmVmZTM5MzBiLTJhMzEtNGU2 YS1hNmFiLTIwM2ZkNzA3ODMwMiI+ICAgDQogICAgIDwvZ3JvdXA+DQogICAgIDxzZXNzaW9uIGlk PSJ1cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcwZi02ZGExZWVhZWI0MjUiPg0KICAgICAg IDxncm91cC1yZWY+dXJuOnV1aWQ6ZWZlMzkzMGItMmEzMS00ZTZhLWE2YWItMjAzZmQ3MDc4MzAy DQogICAgICAgPC9ncm91cC1yZWY+DQogICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQyMzo0 MTowN1o8L3N0YXJ0LXRpbWU+DQogICAgIDwvc2Vzc2lvbj4NCiAgICAgPHBhcnRpY2lwYW50IA0K ICAgICAgICBpZD0idXJuOnV1aWQ6YjJiN2MxMTItNTk4Mi00NjlkLTkwMDctNmRkYmVjY2E2NGQz Ig0KICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcwZi02ZGEx ZWVhZWI0MjUiPg0KICAgICAgICA8YW9yPnNpcDpwYXJ0aGFAYmxyLmNpc2NvLmNvbTwvYW9yPg0K ICAgICAgICA8c2VuZD4xPC9zZW5kPg0KICAgICAgICA8c2VuZD4yPC9zZW5kPg0KICAgICAgICA8 c3RhcnQtdGltZT4yMDEwLTEyLTE2VDIzOjQxOjA3Wjwvc3RhcnQtdGltZT4NCiAgICAgPC9wYXJ0 aWNpcGFudD4NCiAgICAgPHBhcnRpY2lwYW50IA0KICAgICAgICAgaWQ9InVybjp1dWlkOmNkMjdj ZmExLTJiZGQtNDgzMC1hNjUzLTcwMzc0ZDEwZjEwMyINCiAgICAgICAgIHNlc3Npb249InVybjp1 dWlkOjg1NWE1ZGVkLTg0MjAtNDU2ZC1hNzBmLTZkYTFlZWFlYjQyNSI+DQogICAgICAgICA8YW9y PnNpcDpwYXVsQGJveC5jaXNjby5jb208L2Fvcj4NCiAgICAgICAgIDxzZW5kPjM8L3NlbmQ+DQog ICAgICAgICA8c2VuZD40PC9zZW5kPg0KICAgICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQy Mzo0MTowN1o8L3N0YXJ0LXRpbWU+DQogICAgIDwvcGFydGljaXBhbnQ+DQogICAgIDxzdHJlYW0g aWQ9IjEiDQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcw Zi02ZGExZWVhZWI0MjUiPg0KICAgICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQyMzo0MTow N1o8L3N0YXJ0LXRpbWU+DQogICAgICAgICA8bGFiZWw+OTY8L2xhYmVsPg0KICAgICA8L3N0cmVh bT4NCiAgICAgPHN0cmVhbSBpZD0iMiINCiAgICAgICAgIHNlc3Npb249InVybjp1dWlkOjg1NWE1 ZGVkLTg0MjAtNDU2ZC1hNzBmLTZkYTFlZWFlYjQyNSI+DQogICAgICAgICA8c3RhcnQtdGltZT4y MDEwLTEyLTE2VDIzOjQxOjA3Wjwvc3RhcnQtdGltZT4NCiAgICAgICAgIDxsYWJlbD45NzwvbGFi ZWw+DQogICAgIDwvc3RyZWFtPg0KICAgICA8c3RyZWFtIGlkPSIzIg0KICAgICAgICAgc2Vzc2lv bj0idXJuOnV1aWQ6ODU1YTVkZWQtODQyMC00NTZkLWE3MGYtNmRhMWVlYWViNDI1Ij4NCiAgICAg ICAgIDxzdGFydC10aW1lPjIwMTAtMTItMTZUMjM6NDE6MDdaPC9zdGFydC10aW1lPg0KICAgICAg ICAgPGxhYmVsPjk4PC9sYWJlbD4NCiAgICAgPC9zdHJlYW0+DQogICAgIDxzdHJlYW0gaWQ9IjQi DQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcwZi02ZGEx ZWVhZWI0MjUiPg0KICAgICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQyMzo0MTowN1o8L3N0 YXJ0LXRpbWU+DQogICAgICAgICA8bGFiZWw+OTk8L2xhYmVsPg0KICAgICA8L3N0cmVhbT4NCjwv cmVjb3JkaW5nPg0KDQotLXVuaXF1ZS1ib3VuZGFyeS0xLS0NCg0KUGFydGljaXBhbnQgY2hhbmdl IHVzaW5nIFJlLUlOVklURSB3aXRob3V0IE1TLCBDU0cgY2hhbmdlOg0KDQpJTlZJVEUgc2lwOjEw NDFAcmVjb3JkaW5nc2VydmVyLmNpc2NvLmNvbTo1MDYwO3RyYW5zcG9ydD10Y3AgU0lQLzIuMA0K VmlhOiBTSVAvMi4wL1RDUCAxMC4yMS44My41ODticmFuY2g9ejloRzRiSy0xOTkzNS0xLTkNCk1h eC1Gb3J3YXJkczogNzANClRvOiA8c2lwOjEwNDFAcmVjb3JkaW5nc2VydmVyLmNpc2NvLmNvbT47 dGFnPTUyNjJCQTAtMTNENA0KRnJvbTogUmVjcmRpbmdDbGllbnQgPHNpcDoxMC4yMS44My41OD47 dGFnPWRzNDNkNzYyNjMNCkNhbGwtSUQ6IDEyNTQ4MDg2OTcwMjYxQDE5Mi4xNjguMS42Nw0KQ1Nl cTogMTAxIElOVklURQ0KQ29udGVudC1MZW5ndGg6IHh4eA0KQ29udGFjdDogPHNpcDoxMC4yMS44 My41ODo1MDYwO3RyYW5zcG9ydD10Y3A+O2F1ZGlvOw0KRGF0ZTogVHVlLCAxNiBEZWMgMjAxMCAy Mzo0NTowNyBHTVQNCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkO2JvdW5kYXJ5PXVuaXF1 ZS1ib3VuZGFyeS0xDQpNSU1FLVZlcnNpb246IDEuMA0KDQotLXVuaXF1ZS1ib3VuZGFyeS0xDQpD b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL1NEUA0KLi4uDQptPWF1ZGlvIDQ5MTcwIFJUUC9BVlAg MCAgICAgICAgICANCmE9cnRwbWFwOjAgUENNVS84MDAwDQphPWxhYmVsOjk2DQphPXNlbmRvbmx5 DQouLi4NCm09dmlkZW8gNDkxNzQgUlRQL0FWUEYgOTYgICAgDQphPXJ0cG1hcDo5NiBILjI2NC85 MDAwMA0KYT1sYWJlbDo5Nw0KYT1zZW5kb25seQ0KLi4uDQptPWF1ZGlvIDUxMzcyIFJUUC9BVlAg MCAgICAgICAgICANCmE9cnRwbWFwOjAgUENNVS84MDAwDQphPWxhYmVsOjk4DQphPXNlbmRvbmx5 DQouLi4NCm09dmlkZW8gNDkxNzYgUlRQL0FWUEYgOTYgICAgICAgICANCmE9cnRwbWFwOjk2IEgu MjY0LzkwMDAwDQphPWxhYmVsOjk5DQphPXNlbmRvbmx5DQouLi4uDQoNCi0tdW5pcXVlLWJvdW5k YXJ5LTENCkNvbnRlbnQtdHlwZTphcHBsaWNhdGlvbi9ycy1tZXRhZGF0YSt4bWwNCg0KPD94bWwg dmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCiAgPHJlY29yZGluZyB4bWxucz0ndXJu OmlldGY6cGFyYW1zOnhtbDpuczpyZWNvcmRpbmcnPg0KICAgICA8ZGF0YU1vZGU+cGFydGlhbDwv ZGF0YU1vZGU+ICANCiAgICAgPHNlc3Npb24gaWQ9InVybjp1dWlkOjE4YmJhNGZmMi05NjYzLTEx ZTAtOTUxNi01YjliNDgyNDAxOWIiPg0KICAgICAgIDxzdGFydC10aW1lPjIwMTAtMTItMTZUMjM6 NDU6MDdaPC9zdGFydC10aW1lPg0KICAgICA8L3Nlc3Npb24+DQogICAgIDxzZXNzaW9uIGlkPSJ1 cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcwZi02ZGExZWVhZWI0MjUiPg0KICAgICAgIDxz dG9wLXRpbWU+MjAxMC0xMi0xNlQyMzo0NTowN1o8L3N0b3AtdGltZT4NCiAgICAgPC9zZXNzaW9u Pg0KICAgICA8cGFydGljaXBhbnQgDQogICAgICAgIGlkPSJ1cm46dXVpZDpiMmI3YzExMi01OTgy LTQ2OWQtOTAwNy02ZGRiZWNjYTY0ZDMiDQogICAgICAgIHNlc3Npb249InVybjp1dWlkOjE4YmJh NGZmMi05NjYzLTExZTAtOTUxNi01YjliNDgyNDAxOWIiPg0KICAgICAgICA8YW9yPnNpcDpwYXJ0 aGFAYmxyLmNpc2NvLmNvbTwvYW9yPg0KICAgICAgICA8c2VuZD41PC9zZW5kPg0KICAgICAgICA8 c2VuZD42PC9zZW5kPg0KICAgICA8L3BhcnRpY2lwYW50Pg0KICAgICA8cGFydGljaXBhbnQgDQog ICAgICAgICBpZD0idXJuOnV1aWQ6Y2QyN2NmYTEtMmJkZC00ODMwLWE2NTMtNzAzNzRkMTBmMTAz Ig0KICAgICAgICAgc2Vzc2lvbj0idXJuOnV1aWQ6ODU1YTVkZWQtODQyMC00NTZkLWE3MGYtNmRh MWVlYWViNDI1Ij4NCiAgICAgICAgIDxzdG9wLXRpbWU+MjAxMC0xMi0xNlQyMzo0NTowN1o8L3N0 b3AtdGltZT4NCiAgICAgPC9wYXJ0aWNpcGFudD4NCiAgICAgPHBhcnRpY2lwYW50IA0KICAgICAg ICAgaWQ9InVybjp1dWlkOmNkMjdjZmExLTJiZGQtNDgzMC1hNjUzLTcwMzc0ZDEwZjEwMyINCiAg ICAgICAgIHNlc3Npb249InVybjp1dWlkOjE4YmJhNGZmMi05NjYzLTExZTAtOTUxNi01YjliNDgy NDAxOWIiPg0KICAgICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQyMzo0NTowN1o8L3N0b3At dGltZT4NCiAgICAgICAgIDxhb3I+c2lwOnJhbUBibHIuY2lzY28uY29tPC9hb3I+DQogICAgICAg ICA8c2VuZD43PC9zZW5kPg0KICAgICAgICAgPHNlbmQ+ODwvc2VuZD4NCiAgICAgPC9wYXJ0aWNp cGFudD4NCiAgICAgPHN0cmVhbSBpZD0iMSINCiAgICAgICAgIHNlc3Npb249InVybjp1dWlkOjg1 NWE1ZGVkLTg0MjAtNDU2ZC1hNzBmLTZkYTFlZWFlYjQyNSI+DQogICAgICAgICA8c3RvcC10aW1l PjIwMTAtMTItMTZUMjM6NDU6MDdaPC9zdG9wLXRpbWU+DQogICAgIDwvc3RyZWFtPg0KICAgICA8 c3RyZWFtIGlkPSIyIg0KICAgICAgICAgc2Vzc2lvbj0idXJuOnV1aWQ6ODU1YTVkZWQtODQyMC00 NTZkLWE3MGYtNmRhMWVlYWViNDI1Ij4NCiAgICAgICAgIDxzdG9wLXRpbWU+MjAxMC0xMi0xNlQy Mzo0NTowN1o8L3N0b3AtdGltZT4NCiAgICAgPC9zdHJlYW0+DQogICAgIDxzdHJlYW0gaWQ9IjMi DQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcwZi02ZGEx ZWVhZWI0MjUiPg0KICAgICAgICAgPHN0b3AtdGltZT4yMDEwLTEyLTE2VDIzOjQ1OjA3Wjwvc3Rv cC10aW1lPg0KICAgICA8L3N0cmVhbT4NCiAgICAgPHN0cmVhbSBpZD0iNCINCiAgICAgICAgIHNl c3Npb249InVybjp1dWlkOjg1NWE1ZGVkLTg0MjAtNDU2ZC1hNzBmLTZkYTFlZWFlYjQyNSI+DQog ICAgICAgICA8c3RvcC10aW1lPjIwMTAtMTItMTZUMjM6NDU6MDdaPC9zdG9wLXRpbWU+DQogICAg IDwvc3RyZWFtPg0KICAgICA8c3RyZWFtIGlkPSI1Ig0KICAgICAgICAgc2Vzc2lvbj0idXJuOnV1 aWQ6MThiYmE0ZmYyLTk2NjMtMTFlMC05NTE2LTViOWI0ODI0MDE5YiI+DQogICAgICAgICA8c3Rh cnQtdGltZT4yMDEwLTEyLTE2VDIzOjQ1OjA3Wjwvc3RhcnQtdGltZT4NCiAgICAgICAgIDxsYWJl bD45NjwvbGFiZWw+DQogICAgIDwvc3RyZWFtPg0KICAgICA8c3RyZWFtIGlkPSI2Ig0KICAgICAg ICAgc2Vzc2lvbj0idXJuOnV1aWQ6MThiYmE0ZmYyLTk2NjMtMTFlMC05NTE2LTViOWI0ODI0MDE5 YiI+DQogICAgICAgICA8c3RhcnQtdGltZT4yMDEwLTEyLTE2VDIzOjQ1OjA3Wjwvc3RhcnQtdGlt ZT4NCiAgICAgICAgIDxsYWJlbD45NzwvbGFiZWw+DQogICAgIDwvc3RyZWFtPg0KICAgICA8c3Ry ZWFtIGlkPSI3Ig0KICAgICAgICAgc2Vzc2lvbj0idXJuOnV1aWQ6MThiYmE0ZmYyLTk2NjMtMTFl MC05NTE2LTViOWI0ODI0MDE5YiI+DQogICAgICAgICA8c3RhcnQtdGltZT4yMDEwLTEyLTE2VDIz OjQ1OjA3Wjwvc3RhcnQtdGltZT4NCiAgICAgICAgIDxsYWJlbD45ODwvbGFiZWw+DQogICAgIDwv c3RyZWFtPg0KICAgICA8c3RyZWFtIGlkPSI4Ig0KICAgICAgICAgc2Vzc2lvbj0idXJuOnV1aWQ6 MThiYmE0ZmYyLTk2NjMtMTFlMC05NTE2LTViOWI0ODI0MDE5YiI+DQogICAgICAgICA8c3RhcnQt dGltZT4yMDEwLTEyLTE2VDIzOjQ1OjA3Wjwvc3RhcnQtdGltZT4NCiAgICAgICAgIDxsYWJlbD45 OTwvbGFiZWw+DQogICAgIDwvc3RyZWFtPg0KPC9yZWNvcmRpbmc+DQoNCi0tdW5pcXVlLWJvdW5k YXJ5LTEtLQ== ------_=_NextPart_001_01CC2A8C.B8911572-- From john.elwell@siemens-enterprise.com Tue Jun 14 07:28:12 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C0A9E801E for ; Tue, 14 Jun 2011 07:28:12 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnMDMqETaCBA for ; Tue, 14 Jun 2011 07:28:12 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id D3D419E8028 for ; Tue, 14 Jun 2011 07:28:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1308061682!31655051!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 19363 invoked from network); 14 Jun 2011 14:28:02 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-4.tower-27.messagelabs.com with SMTP; 14 Jun 2011 14:28:02 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 5C78123F03E9; Tue, 14 Jun 2011 16:28:10 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 14 Jun 2011 16:28:10 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Tue, 14 Jun 2011 16:28:09 +0200 Thread-Topic: [siprec] FW: New Version Notification for draft-eckel-siprec-rtp-rec-00.txt Thread-Index: AcwqAnZVGLiKbskDRFaW1Y2k4Cx3EgAAQxVAACa5n/A= Message-ID: References: In-Reply-To: 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: [siprec] FW: New Version Notification for draft-eckel-siprec-rtp-rec-00.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 14:28:12 -0000 Thanks, Charles, for posting this. Much of the material has been posted bef= ore, but having it in an I-D makes it easier to discuss. The I-D makes a nu= mber of recommendations, with the intention that these be incorporated into= the protocol draft at some stage. So folks should review these and see whi= ch ones they are happy with and which need more discussion. It would be goo= d to do this before the next interim call on 23rd June. One minor point I noted. Section 13 talks about symmetric RTP/RTCP, but in = the case of the RS, RTP is one-way, so does symmetry apply in practice only= to RTCP? Perhaps next section needs some slight elaboration. John (as chair) =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > Sent: 13 June 2011 20:57 > To: siprec@ietf.org > Subject: [siprec] FW: New Version Notification for=20 > draft-eckel-siprec-rtp-rec-00.txt >=20 > I have posted the initial rev of the RTP recommendations for=20 > SIPREC draft. It is available at=20 > http://datatracker.ietf.org/doc/draft-eckel-siprec-rtp-rec/. > Please have a look and share your comments. >=20 > Cheers, > Charles >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Monday, June 13, 2011 12:45 PM > To: Charles Eckel (eckelcu) > Cc: Charles Eckel (eckelcu) > Subject: New Version Notification for=20 > draft-eckel-siprec-rtp-rec-00.txt >=20 > A new version of I-D, draft-eckel-siprec-rtp-rec-00.txt has=20 > been successfully submitted by Charles Eckel and posted to=20 > the IETF repository. >=20 > Filename: draft-eckel-siprec-rtp-rec > Revision: 00 > Title: Real-time Transport Protocol (RTP)=20 > Recommendations for SIPREC > Creation date: 2011-06-13 > WG ID: Individual Submission > Number of pages: 11 >=20 > Abstract: > This document provides recommendations and guidelines for RTP and > RTCP in the context of SIPREC. This document exists as a=20 > standalone > document to faciliate dicussion of the RTP=20 > recommendations, and it is > anticipated that portions of this document will be=20 > incorporated into > [I-D.portman-siprec-protocol] rather than this document=20 > itself being > adopted as a working group document. >=20 > =20 > =20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Tue Jun 14 07:44:00 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEABD9E8026 for ; Tue, 14 Jun 2011 07:44:00 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk9MRI3nahJv for ; Tue, 14 Jun 2011 07:44:00 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id E3C0C9E801C for ; Tue, 14 Jun 2011 07:43:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1308062630!40554442!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 1115 invoked from network); 14 Jun 2011 14:43:50 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-11.tower-21.messagelabs.com with SMTP; 14 Jun 2011 14:43:50 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 786DE1EB83D3 for ; Tue, 14 Jun 2011 16:43:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 14 Jun 2011 16:43:58 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 14 Jun 2011 16:43:57 +0200 Thread-Topic: Agenda interim 2011-06-23, 13.00-15.00 UTC/GMT Thread-Index: AcwqoX3ahA9Cv1J4Tei1s2mbYHjidw== 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: [siprec] Agenda interim 2011-06-23, 13.00-15.00 UTC/GMT X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 14:44:00 -0000 As agreed at the last interim, priority to be given to the protocol documen= t. Any other agenda requests? John ################################# Administrivia, 10 minutes, Chairs - Note takers - Participant list - Start recording - Note well - Agenda bash Protocol, 30 minutes, Leon Portman - https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Wrap-up, hums, next steps, 10 minutes, Chairs From john.elwell@siemens-enterprise.com Tue Jun 14 08:03:58 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFC511E80C7 for ; Tue, 14 Jun 2011 08:03:58 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cG7uaQCAKhB for ; Tue, 14 Jun 2011 08:03:56 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id D1B6F11E80C0 for ; Tue, 14 Jun 2011 08:03:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1308063826!31660260!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 29009 invoked from network); 14 Jun 2011 15:03:46 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-4.tower-27.messagelabs.com with SMTP; 14 Jun 2011 15:03:46 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 7F29223F03E8; Tue, 14 Jun 2011 17:03:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 14 Jun 2011 17:03:54 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , Leon Portman , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Tue, 14 Jun 2011 17:03:53 +0200 Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEAAHiqxwAARuZ7AAEv0wYAAASlPQAA0tNiAAM/kssAAEs2agAPRFMhAB/2vD0AC9wGnQAAZv8PA= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> In-Reply-To: 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: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:03:58 -0000 Partha, Thanks for the examples. The character count for the delta is about 2500 wh= en a new MS is created compared to about 2100 when the MS is retained. This= seems to be in line with my previous gut feeling. Concerning the need for "SRS implementers to guess how old MS and new MS ar= e related", I don't think they are related, except by having other things i= n common like a common participant or a common CSG. John (as individual) > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 14 June 2011 13:15 > To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; Ram > Mohan R (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > Hi all, > > Sorry for the delay. Just to double confirm everybody > understanding with > SIP message example, I added the example with creating new MS and > reusing the same MS as an attachment with this mail. > > Please note that creating new MS is putting SRS implementers to guess > how old MS and new MS are related. Also, few scenario like Even after > looking into the example, the intention is to use local variable, I'm > ok. > > Thanks > Partha > > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Friday, June 10, 2011 10:57 PM > To: Leon Portman; Elwell, John; Parthasarathi R (partr); Ram Mohan R > (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > Please excuse the delay. I am catching up after having been away on > vacation. > In light of this better understanding of the use case, I also > prefer the > option favored by John and Leon to model as a separate MS. In this > specific case, I would expect the properties of the MS to > change when A > is transferred to C, so I expect the overhead in creating a new MS vs. > reusing the same MS to be minimal and not worth the added > complexity to > the model. > > Cheers, > Charles > > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: Tuesday, May 31, 2011 6:19 AM > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); > > Ram Mohan R (rmohanr); siprec@ietf.org > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > Hello > > > > I also having a problem even without a quantification of number of > > update messages that CS MS is remains same between > different CS. So I > do prefer to keep it simple and keep it per CS. > > > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Friday, May 27, 2011 12:26 PM > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R > > (rmohanr); siprec@ietf.org > > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 26 May 2011 15:55 > > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > > > siprec@ietf.org > > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > > > John, > > > > > > The callflow mentioned by me is the basic primitive in the call > > > center scenario wherein customer (participant) is same throughout > > > the session and agents are changed using transfer service > and B2BUA > acts as SRC. > > > IMO, it is one of key requirement to be considered in case we > > > support for partial-update. > > [JRE] Agreed the Participant remains the same, but we are discussing > MS. > > > > > This may not be the only callflow where MS partial-update is > > > required in this fashion. During -00 format draft, I thought that > > > the partial-update is not required but lot of folks raised the > > > concern that partial update is important. Current, -01 > format draft > > > is designed to support partial-update. Now, You propose > to restrict > > > MS partial-update across CS. IMO, it is a not good idea > to restrict > > > in the protocol level. Anyway, I think that we need > others opinion > > > before conclude here. > > [JRE] I am not opposed to partial update, but I would like to avoid > > distorting the model just to gain some efficiency improvements in > > certain cases. To me it is not intuitive that a MS on one > CS and an MS > > > on another CS are the same object, just because one of the > > Participants is common to both CSs. In the transfer-between-agents > example, although one of the Participants is common to the > two CSs, this > is not true for the other Participants. > > > > Let's try to quantify the efficiency improvement. In the blind > > transfer case, the partial updates would at least have to include: > > - the removal of P1 from CS1 (where P1 is the first agent > and CS1 is > > the first CS); > > - the removal of P2 from CS1 (where P2 is the transferred > > participant); > > - the termination of CS1; > > - the removal of CS1 from CSG1; > > - the creation of CS2 (the CS that results from transfer); > > - the addition to of CS2 to CSG1; > > - the addition of P2 to CSG1; > > - the addition of P3 to CS2 (where P3 is the second agent); > > - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); > > - the removal of P2 as a recipient of MS1; > > - the termination of MS1; > > - the creation of MS3; > > - the addition of P3 as a sender of MS3; > > - the addition of P2 as a recipient of MS3. > > > > So all we are arguing about is whether we also include in > the partial > > updates EITHER (this I think is your proposal): > > - the removal of P1 as a recipient of MS2; > > - the addition of P3 as a recipient of MS2; > > > > OR > > - the removal of P1 as recipient of MS2; > > - the removal of P2 as a sender of MS2; > > - the termination MS2; > > - the creation of MS4; > > - the addition of P3 as a recipient of MS4; > > - the addition of P2 as a sender of MS4. > > > > So with the first option the total number of deltas is 14+2=3D16. > > For the second option the total number of deltas is 14+6=3D20. > > > > Some of the details might be wrong, but I hope you can see > the point I > > > am getting at. Looked at this way, the efficiency saving by > recycling > > MS2 for use in consecutive CSs is relatively small. Or perhaps your > > intention is also to recycle MS1 (this time, the recipient > remaining > > the same but the sender changing). That would reduce the number of > > deltas slightly further. The impact on XML size might not > be quite in > > proportion to the reduction in the number of deltas, since by > recycling MS2 it has to have a global identifier, not an identifier > local to a CS. Or perhaps it could have an identifier local to a CSG. > > > > I also see that with your proposal it doesn't force the MS to be > > recycled - an SRC could still choose to model it as separate MSs. > > However, in that case it would still need to use global identifiers > for MSs. > > > > I am not necessarily opposed to your proposal for recycling > MS objects > > > outside the context of a single CS - I can see advantages and > > disadvantages. I just want to make sure the group makes an informed > decision. > > > > John (as individual) > > > > > > > > > > Enhancing label attribute across the multiple SIP message to tie > > > between Metadata XML and RS SDP m-line is possible. SRC has to > > > ensure that label for the given RS SDP m-line should have > same label > > > > throughout single CSG even though it span across multiple CS and > > > multiple RS. Even then, it will not meet partial-update > requirement > > > as mentioned below in this mail thread. At this moment, > I'm favoring > > > > URN UUID and not label attribute enhancement. > > > > > > Please read inline > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Wednesday, May 25, 2011 7:17 PM > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R > > > (rmohanr); siprec@ietf.org > > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 25 May 2011 08:48 > > > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > (rmohanr); > > > > siprec@ietf.org > > > > Subject: RE: [siprec] Can an MS object span several CSs > in a CSG? > > > > > > > > John, > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D > > > > > 3) B transfer the call of A & B to C using REFER, B2BUA > > > > converts REFER > > > > > > > > > to RE-INVITE towards A & C and A & C are connected. B2BUA > > > > updates RS > > > > > with CS2, Participant1 as A & participant2 as C, > MS1(A's media > > > > > stream), MS2(C's media stream). There is no update on RS1, > > > > CSG1, MS1, > > > > > MS2. MS2 will become MS2 with the new association and > in terms > > > > > of format, it will associate with tag > > > > [JRE] What harm is done (what do we lose) if, following > > > transfer, A's > > > > media stream is called MS3 and C's media stream is called MS4? > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D > > > > To indicate MS1 as MS3, MS1 media block has to be > > > stopped in > > > > the partial-update and start MS3 separate which is not > required in > > > > > case there is a means to have common MS1. > > > [JRE] It seems this distorts the model in order to give > some minor > > > efficiency improvement during metadata updates. I doubt that this > > > alone is sufficient justification for having the MS > persist from one > > > > CS to another CS. > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > MS3 can reference the same SDP m-line (through a=3Dlabel) as MS1, > > > > and likewise MS4 could reference the same SDP m-line as > MS2, if we > > > > > are concerned about recycling media descriptions in RS SDP. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > As you mentioned, we will lose recycling of media > > > description > > > > in RS SDP without common value in media stream object for this > > > > scenario. > > > [JRE] I don't understand your point. With my proposal we > can still > > > recycle RS SDP m-lines. > > > > > > Agreed that Recycle is possible with your proposal. > > > I indicated > > > the need for unique-id in this requirement > > > > > > > AFAIK, Your proposal needs enhancement in RFC 4574 as label > > > attribute > > > > scope is within single SIP message and not required to > be unique > > > > in all SIP messages of a given dialog. > > > [JRE] But I think we could nail that down as a requirement of the > > > SIPREC protocol. > > > > > > John (as individual) > > > > > > > > > > > Thanks > > > > Partha > > > > > > > > John (as individual) > > > > > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) > > > > > Sent: Wednesday, May 25, 2011 1:39 AM > > > > > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); > > > 'Elwell, John'; > > > > > 'siprec@ietf.org' > > > > > Subject: RE: [siprec] Can an MS object span several CSs in a > CSG? > > > > > > > > > > Hi Ram, > > > > > > > > > > I think that is many cases, they will be treated as > separate MSs > > > > > > due to the complexities you mention. However, I am trying to > > > understand if > > > > > Partha feels allowing an SRC to treat them as a single MS is > > > > > still required. If not, then what is a use case? A concrete > > > > > example would help me, and potentially others, to better > > > > > understand the > > > > motivation behind > > > > > Partha's requirement for modeling media from multiple CSs > > > > as a single > > > > > MS. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: Ram Mohan R (rmohanr) > > > > > > Sent: Tuesday, May 24, 2011 9:36 AM > > > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > > > Elwell, John; > > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] Can an MS object span several CSs > > > in a CSG? > > > > > > > > > > > > Charles, > > > > > > > > > > > > I did bring about this specific usecase of MMOH/MOH > > > stream being > > > > > > played to different participants earlier and suggested that > > > > > they have > > > > > > to treated as a same MS across multiple CSs > > > (potentially recorded > > > > > using multiple RSs). > > > > > > Refer > > > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > > > > > > > > > > > > We had several discussions on it and it and several > > > folks were in > > > > > > favor of treating it as separate MS as there would be > > > > > complexity in DB > > > > > design. > > > > > > > > > > > > Regards, > > > > > > Ram > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > > > Sent: Tuesday, May 24, 2011 9:11 PM > > > > > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > > > > > Subject: Re: [siprec] Can an MS object span several CSs > > > > in a CSG? > > > > > > > > > > > > > > Hi Partha, > > > > > > > > > > > > > > Is an example of this the same music on hold audio stream > > > > > existing > > > > > > > as the same MS within multiple CSs? If so, then I > > > > understand your > > > > > > > requirement to be that the SRC be able to > indicate multiple > > > > > > > instances of this audio stream within several CSs as > > > > > being the same > > > > > > > MS. Is that correct? > > > > > > > > > > > > > > Thanks, > > > > > > > Charles > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf Of Parthasarathi R (partr) > > > > > > > > Sent: Tuesday, May 24, 2011 4:26 AM > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Can an MS object span several CSs > > > > > in a CSG? > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > I agree that it is not mandatory to consider recorded > > > > > stream of a > > > > > > > > specific participant in several CS within the same > > > CSG as one > > > > > > > recorded > > > > > > > > stream but SIPREC protocol design MUST NOT restrict a > > > > > SRC in case > > > > > > > > it wishes to design in such a way. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf > > > > > > > > Of Elwell, John > > > > > > > > Sent: Tuesday, May 24, 2011 1:06 PM > > > > > > > > To: siprec@ietf.org > > > > > > > > Subject: [siprec] Can an MS object span several CSs > > > in a CSG? > > > > > > > > > > > > > > > > We seem to have consensus that a Media Stream object > > > > > represents a > > > > > > > > recorded media stream, contributed to by one, > > > several or all > > > > > > > > Participants. However, Partha also wrote: > > > > > > > > > > > > > > > > "2) Each MS lifetime related to CSG because participant > > > > > may move > > > > > > > > from one CS to another CS within single CSG and also > > > > > CSG will span > > > > > > > > > > > > > across multiple RS." > > > > > > > > > > > > > > > > I am not sure we had resolved this during earlier > > > > > discussions on > > > > > > > > the scope of an MS object. Although the same > > > Participant can > > > > > > > > participate > > > > > > > in > > > > > > > > several CSs within the same CSG, I don't think the > > > > > recorded media > > > > > > > > streams need to be considered the same. Any other views? > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing list > > > > > > > > siprec@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing list > > > > > > > > siprec@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Tue Jun 14 08:24:06 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2E911E80AD for ; Tue, 14 Jun 2011 08:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZNlHeiGnijF for ; Tue, 14 Jun 2011 08:24:05 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id AED5011E808D for ; Tue, 14 Jun 2011 08:24:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1308065042!9042269!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 14059 invoked from network); 14 Jun 2011 15:24:02 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-13.tower-182.messagelabs.com with SMTP; 14 Jun 2011 15:24:02 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 1C29A1EB83D3; Tue, 14 Jun 2011 17:24:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 14 Jun 2011 17:24:02 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "Paul Kyzivat (pkyzivat)" , "Ram Mohan R (rmohanr)" Date: Tue, 14 Jun 2011 17:24:01 +0200 Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwaNRNd5Kpg41TSSeWFPJywVvLejAAbXOUAAzxf8DAAxLmSUA== Message-ID: References: <4DDA89F2.50706@cisco.com><4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com><4DDBE5D1.7030704@cisco.com> In-Reply-To: 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: "siprec@ietf.org" Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:24:06 -0000 Charles, I think it was Paul who first suggested that a=3Dcontent might not be rich = enough, and I was just discussing the consequences. So perhaps Paul should = respond. John > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 10 June 2011 18:36 > To: Elwell, John; Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) > Cc: siprec@ietf.org > Subject: RE: [siprec] What does an MS object represent? Can=20 > we pick one of theseoptions? >=20 > Hi John, >=20 > Given that the syntax for the content attribute in RFC 4796 allows for > the assignment of additional extension values: >=20 > content-attribute =3D "a=3Dcontent:" mediacnt-tag > mediacnt-tag =3D mediacnt *("," mediacnt) > mediacnt =3D "slides" / "speaker" / "sl" / "main" > / "alt" / mediacnt-ext > mediacnt-ext =3D token >=20 > do you still think it is not rich enough? It seems to be that=20 > given the > content and label attributes plus the grouping framework, we=20 > can express > pretty complex and detailed relationships. That said, it may=20 > be simpler > to express in metadata than in SDP. Is that the motivation? >=20 > Cheers, > Charles=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Tuesday, May 24, 2011 11:15 PM > > To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] What does an MS object represent? Can we pick > one of theseoptions? > >=20 > > Given that SDP's a=3Dcontent might not be rich enough, I think we need > to define something new for > > metadata, independent of a=3Dcontent. The SRC could choose to=20 > derive the > metadata content attribute from > > the a=3Dcontent attributes of the contributing CS streams (that is an > SRC decision), but should not use > > the a=3Dcontent label in the RS SDP. > >=20 > > John (as individual) > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: 24 May 2011 18:07 > > > To: Ram Mohan R (rmohanr) > > > Cc: Elwell, John; siprec@ietf.org > > > Subject: Re: [siprec] What does an MS object represent? Can > > > we pick one of theseoptions? > > > > > > > > > > > > On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: > > > > Paul/ John, > > > > > > > > I am ok to add attribute "content" in MS block of the model. > > > > > > > > The question is do we want to map this attribute in the model to > > > > 1) The Session Description Protocol (SDP) Content Attribute > > > defined in > > > > RFC 4796 OR > > > > 2)define our own content in the metadata XML which can take > > > values as > > > > "audio" / "main video" / "presentation video" / "current > > > speaker video" > > > > as suggested by John. > > > > > > Well... > > > > > > ISTM that if there is already an a=3Dcontent in the CS SDP, > > > then we would > > > want to report that in the metadata. > > > > > > If there is a pair (one from offer, one from answer, same > > > m-line offset) > > > and there is *not* an a=3Dcontent that pairs them, then we > > > would want to > > > report it anyway. > > > > > > But if we do that we have a problem with names and conflicts. > rfc4796 > > > doesn't define a lot of names, nor does it say whether=20 > corresponding > > > streams in offer & answer must have the same names. > > > > > > So I think we have something similar but not quite the same, > > > and we need > > > to define something new. It must permit identifying streams > > > even though > > > we know nothing of their purpose. > > > > > > Thanks, > > > Paul > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From pkyzivat@cisco.com Tue Jun 14 08:31:05 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2D711E8098 for ; Tue, 14 Jun 2011 08:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.404 X-Spam-Level: X-Spam-Status: No, score=-110.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF2ahql8-nnG for ; Tue, 14 Jun 2011 08:31:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 700FA11E80B0 for ; Tue, 14 Jun 2011 08:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=17355; q=dns/txt; s=iport; t=1308065463; x=1309275063; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=yMfleFVQACKBQQ0vcqBoCRpXHa6JBGTKl/l2+tF6tBw=; b=M3XbPzBUndVvxVHXLDdiXbxY8XzoEFB9+SzyUVUjhrCav/VfqsXPpq8p 1N+fBb2dyA2POhFP2e6eMw/xoHosnH2iFGCkDJP9qfe5ouY4szn5IAcnd q5j9e9lzIfGizRkon+Ab8/qxMuV9oOqZhVCTwPMYcXi3QLiKyZ6jzOZ1D E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBAOd9902Q/khR/2dsb2JhbABSl0yOdXerSJ5IhiQEkUiEV4ss X-IronPort-AV: E=Sophos;i="4.65,365,1304294400"; d="scan'208";a="35184809" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 14 Jun 2011 15:31:02 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5EFV12I021306 for ; Tue, 14 Jun 2011 15:31:01 GMT Message-ID: <4DF77EB5.9060009@cisco.com> Date: Tue, 14 Jun 2011 11:31:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: siprec@ietf.org References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:31:05 -0000 John, Consider another case: two SRCs in the same CS (perhaps one at each "end".) They are both sending metadata about the same CS and MSs. Suppose they want to cooperate with each other. They have the potential to use the same ID to reference the CS, so that the SRS will know they are talking about the same one. But with RS-specific MS ids there is no way for them to indicate that they are talking about the same MSs. With global MS ids, they could accomplish this. Thanks, Paul On 6/14/2011 11:03 AM, Elwell, John wrote: > Partha, > > Thanks for the examples. The character count for the delta is about 2500 when a new MS is created compared to about 2100 when the MS is retained. This seems to be in line with my previous gut feeling. > > Concerning the need for "SRS implementers to guess how old MS and new MS are related", I don't think they are related, except by having other things in common like a common participant or a common CSG. > > John (as individual) > >> -----Original Message----- >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >> Sent: 14 June 2011 13:15 >> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; Ram >> Mohan R (rmohanr); siprec@ietf.org >> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >> >> Hi all, >> >> Sorry for the delay. Just to double confirm everybody >> understanding with >> SIP message example, I added the example with creating new MS and >> reusing the same MS as an attachment with this mail. >> >> Please note that creating new MS is putting SRS implementers to guess >> how old MS and new MS are related. Also, few scenario like Even after >> looking into the example, the intention is to use local variable, I'm >> ok. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: Charles Eckel (eckelcu) >> Sent: Friday, June 10, 2011 10:57 PM >> To: Leon Portman; Elwell, John; Parthasarathi R (partr); Ram Mohan R >> (rmohanr); siprec@ietf.org >> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >> >> Please excuse the delay. I am catching up after having been away on >> vacation. >> In light of this better understanding of the use case, I also >> prefer the >> option favored by John and Leon to model as a separate MS. In this >> specific case, I would expect the properties of the MS to >> change when A >> is transferred to C, so I expect the overhead in creating a new MS vs. >> reusing the same MS to be minimal and not worth the added >> complexity to >> the model. >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>> Sent: Tuesday, May 31, 2011 6:19 AM >>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); >>> Ram Mohan R (rmohanr); siprec@ietf.org >>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>> >>> Hello >>> >>> I also having a problem even without a quantification of number of >>> update messages that CS MS is remains same between >> different CS. So I >> do prefer to keep it simple and keep it per CS. >>> >>> Leon >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Elwell, John >>> Sent: Friday, May 27, 2011 12:26 PM >>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R >>> (rmohanr); siprec@ietf.org >>> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>> Sent: 26 May 2011 15:55 >>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); >>>> siprec@ietf.org >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>> >>>> John, >>>> >>>> The callflow mentioned by me is the basic primitive in the call >>>> center scenario wherein customer (participant) is same throughout >>>> the session and agents are changed using transfer service >> and B2BUA >> acts as SRC. >>>> IMO, it is one of key requirement to be considered in case we >>>> support for partial-update. >>> [JRE] Agreed the Participant remains the same, but we are discussing >> MS. >>> >>>> This may not be the only callflow where MS partial-update is >>>> required in this fashion. During -00 format draft, I thought that >>>> the partial-update is not required but lot of folks raised the >>>> concern that partial update is important. Current, -01 >> format draft >>>> is designed to support partial-update. Now, You propose >> to restrict >>>> MS partial-update across CS. IMO, it is a not good idea >> to restrict >>>> in the protocol level. Anyway, I think that we need >> others opinion >>>> before conclude here. >>> [JRE] I am not opposed to partial update, but I would like to avoid >>> distorting the model just to gain some efficiency improvements in >>> certain cases. To me it is not intuitive that a MS on one >> CS and an MS >> >>> on another CS are the same object, just because one of the >>> Participants is common to both CSs. In the transfer-between-agents >> example, although one of the Participants is common to the >> two CSs, this >> is not true for the other Participants. >>> >>> Let's try to quantify the efficiency improvement. In the blind >>> transfer case, the partial updates would at least have to include: >>> - the removal of P1 from CS1 (where P1 is the first agent >> and CS1 is >>> the first CS); >>> - the removal of P2 from CS1 (where P2 is the transferred >>> participant); >>> - the termination of CS1; >>> - the removal of CS1 from CSG1; >>> - the creation of CS2 (the CS that results from transfer); >>> - the addition to of CS2 to CSG1; >>> - the addition of P2 to CSG1; >>> - the addition of P3 to CS2 (where P3 is the second agent); >>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); >>> - the removal of P2 as a recipient of MS1; >>> - the termination of MS1; >>> - the creation of MS3; >>> - the addition of P3 as a sender of MS3; >>> - the addition of P2 as a recipient of MS3. >>> >>> So all we are arguing about is whether we also include in >> the partial >>> updates EITHER (this I think is your proposal): >>> - the removal of P1 as a recipient of MS2; >>> - the addition of P3 as a recipient of MS2; >>> >>> OR >>> - the removal of P1 as recipient of MS2; >>> - the removal of P2 as a sender of MS2; >>> - the termination MS2; >>> - the creation of MS4; >>> - the addition of P3 as a recipient of MS4; >>> - the addition of P2 as a sender of MS4. >>> >>> So with the first option the total number of deltas is 14+2=16. >>> For the second option the total number of deltas is 14+6=20. >>> >>> Some of the details might be wrong, but I hope you can see >> the point I >> >>> am getting at. Looked at this way, the efficiency saving by >> recycling >>> MS2 for use in consecutive CSs is relatively small. Or perhaps your >>> intention is also to recycle MS1 (this time, the recipient >> remaining >>> the same but the sender changing). That would reduce the number of >>> deltas slightly further. The impact on XML size might not >> be quite in >>> proportion to the reduction in the number of deltas, since by >> recycling MS2 it has to have a global identifier, not an identifier >> local to a CS. Or perhaps it could have an identifier local to a CSG. >>> >>> I also see that with your proposal it doesn't force the MS to be >>> recycled - an SRC could still choose to model it as separate MSs. >>> However, in that case it would still need to use global identifiers >> for MSs. >>> >>> I am not necessarily opposed to your proposal for recycling >> MS objects >> >>> outside the context of a single CS - I can see advantages and >>> disadvantages. I just want to make sure the group makes an informed >> decision. >>> >>> John (as individual) >>> >>> >>>> >>>> Enhancing label attribute across the multiple SIP message to tie >>>> between Metadata XML and RS SDP m-line is possible. SRC has to >>>> ensure that label for the given RS SDP m-line should have >> same label >> >>>> throughout single CSG even though it span across multiple CS and >>>> multiple RS. Even then, it will not meet partial-update >> requirement >>>> as mentioned below in this mail thread. At this moment, >> I'm favoring >> >>>> URN UUID and not label attribute enhancement. >>>> >>>> Please read inline >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Sent: Wednesday, May 25, 2011 7:17 PM >>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R >>>> (rmohanr); siprec@ietf.org >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>> Sent: 25 May 2011 08:48 >>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R >> (rmohanr); >>>>> siprec@ietf.org >>>>> Subject: RE: [siprec] Can an MS object span several CSs >> in a CSG? >>>>> >>>>> John, >>>>> >>>>> >> ================================================================== >>>>> = >>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA >>>>> converts REFER >>>>> >>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA >>>>> updates RS >>>>>> with CS2, Participant1 as A& participant2 as C, >> MS1(A's media >>>>>> stream), MS2(C's media stream). There is no update on RS1, >>>>> CSG1, MS1, >>>>>> MS2. MS2 will become MS2 with the new association and >> in terms >>>>>> of format, it will associate with tag >>>>> [JRE] What harm is done (what do we lose) if, following >>>> transfer, A's >>>>> media stream is called MS3 and C's media stream is called MS4? >>>>> >>>> >> ==================================================================== >>>> = >>>>> To indicate MS1 as MS3, MS1 media block has to be >>>> stopped in >>>>> the partial-update and start MS3 separate which is not >> required in >> >>>>> case there is a means to have common MS1. >>>> [JRE] It seems this distorts the model in order to give >> some minor >>>> efficiency improvement during metadata updates. I doubt that this >>>> alone is sufficient justification for having the MS >> persist from one >> >>>> CS to another CS. >>>> >>>>> >>>>> ============================================================== >>>>> ========== >>>>> ======================= >>>>> MS3 can reference the same SDP m-line (through a=label) as MS1, >>>>> and likewise MS4 could reference the same SDP m-line as >> MS2, if we >> >>>>> are concerned about recycling media descriptions in RS SDP. >>>>> ============================================================== >>>>> ========== >>>>> ================== >>>>> As you mentioned, we will lose recycling of media >>>> description >>>>> in RS SDP without common value in media stream object for this >>>>> scenario. >>>> [JRE] I don't understand your point. With my proposal we >> can still >>>> recycle RS SDP m-lines. >>>> >>>> Agreed that Recycle is possible with your proposal. >>>> I indicated >>>> the need for unique-id in this requirement >>>> >>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label >>>> attribute >>>>> scope is within single SIP message and not required to >> be unique >>>>> in all SIP messages of a given dialog. >>>> [JRE] But I think we could nail that down as a requirement of the >>>> SIPREC protocol. >>>> >>>> John (as individual) >>>> >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> John (as individual) >>>>> >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) >>>>>> Sent: Wednesday, May 25, 2011 1:39 AM >>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); >>>> 'Elwell, John'; >>>>>> 'siprec@ietf.org' >>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a >> CSG? >>>>>> >>>>>> Hi Ram, >>>>>> >>>>>> I think that is many cases, they will be treated as >> separate MSs >> >>>>>> due to the complexities you mention. However, I am trying to >>>> understand if >>>>>> Partha feels allowing an SRC to treat them as a single MS is >>>>>> still required. If not, then what is a use case? A concrete >>>>>> example would help me, and potentially others, to better >>>>>> understand the >>>>> motivation behind >>>>>> Partha's requirement for modeling media from multiple CSs >>>>> as a single >>>>>> MS. >>>>>> >>>>>> Cheers, >>>>>> Charles >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ram Mohan R (rmohanr) >>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM >>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >>>>> Elwell, John; >>>>>>> siprec@ietf.org >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >>>> in a CSG? >>>>>>> >>>>>>> Charles, >>>>>>> >>>>>>> I did bring about this specific usecase of MMOH/MOH >>>> stream being >>>>>>> played to different participants earlier and suggested that >>>>>> they have >>>>>>> to treated as a same MS across multiple CSs >>>> (potentially recorded >>>>>> using multiple RSs). >>>>>>> Refer >>>>>>> >>>> http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html >>>>>>> >>>>>>> We had several discussions on it and it and several >>>> folks were in >>>>>>> favor of treating it as separate MS as there would be >>>>>> complexity in DB >>>>>> design. >>>>>>> >>>>>>> Regards, >>>>>>> Ram >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>> Behalf Of Charles Eckel (eckelcu) >>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM >>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org >>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>> in a CSG? >>>>>>>> >>>>>>>> Hi Partha, >>>>>>>> >>>>>>>> Is an example of this the same music on hold audio stream >>>>>> existing >>>>>>>> as the same MS within multiple CSs? If so, then I >>>>> understand your >>>>>>>> requirement to be that the SRC be able to >> indicate multiple >>>>>>>> instances of this audio stream within several CSs as >>>>>> being the same >>>>>>>> MS. Is that correct? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Charles >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>> Behalf Of Parthasarathi R (partr) >>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM >>>>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>>> in a CSG? >>>>>>>>> >>>>>>>>> John, >>>>>>>>> >>>>>>>>> I agree that it is not mandatory to consider recorded >>>>>> stream of a >>>>>>>>> specific participant in several CS within the same >>>> CSG as one >>>>>>>> recorded >>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a >>>>>> SRC in case >>>>>>>>> it wishes to design in such a way. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>> Behalf >>>>>>>>> Of Elwell, John >>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: [siprec] Can an MS object span several CSs >>>> in a CSG? >>>>>>>>> >>>>>>>>> We seem to have consensus that a Media Stream object >>>>>> represents a >>>>>>>>> recorded media stream, contributed to by one, >>>> several or all >>>>>>>>> Participants. However, Partha also wrote: >>>>>>>>> >>>>>>>>> "2) Each MS lifetime related to CSG because participant >>>>>> may move >>>>>>>>> from one CS to another CS within single CSG and also >>>>>> CSG will span >>>>>> >>>>>>>>> across multiple RS." >>>>>>>>> >>>>>>>>> I am not sure we had resolved this during earlier >>>>>> discussions on >>>>>>>>> the scope of an MS object. Although the same >>>> Participant can >>>>>>>>> participate >>>>>>>> in >>>>>>>>> several CSs within the same CSG, I don't think the >>>>>> recorded media >>>>>>>>> streams need to be considered the same. Any other views? >>>>>>>>> >>>>>>>>> John (as individual) >>>>>>>>> _______________________________________________ >>>>>>>>> siprec mailing list >>>>>>>>> siprec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>> _______________________________________________ >>>>>>>>> siprec mailing list >>>>>>>>> siprec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>> >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@cisco.com Tue Jun 14 08:46:19 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6922811E80CF for ; Tue, 14 Jun 2011 08:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.116 X-Spam-Level: X-Spam-Status: No, score=-110.116 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2J9tZfUhnsT for ; Tue, 14 Jun 2011 08:46:18 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAAD11E809A for ; Tue, 14 Jun 2011 08:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4422; q=dns/txt; s=iport; t=1308066371; x=1309275971; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OSON6MudpRlTAaYeWZEpOzNqxGA1xUrsVJsh6h6hqQU=; b=nH38B34OXrjy1yAhHb7RspjClvza9Ii7XCNoq9iVYKhfyVGLG6SdiCwy euW6pU1HWmazxOLJDypTI+5eC16X4LjbvfClEklEpuSDQ8mhtb18ZmjNe 8iSbka0eL3OYOOqDM87MIiZ9FEBFawm8FwkY2I460ujcg+k8/sWQTh9J4 Q=; X-IronPort-AV: E=Sophos;i="4.65,365,1304294400"; d="scan'208";a="358384316" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 14 Jun 2011 15:46:10 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p5EFk9Fe010781; Tue, 14 Jun 2011 15:46:09 GMT Message-ID: <4DF78241.6050204@cisco.com> Date: Tue, 14 Jun 2011 11:46:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Elwell, John" References: <4DDA89F2.50706@cisco.com><4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com><4DDBE5D1.7030704@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:46:19 -0000 On 6/14/2011 11:24 AM, Elwell, John wrote: > Charles, > > I think it was Paul who first suggested that a=content might not be rich enough, and I was just discussing the consequences. So perhaps Paul should respond. Its all about namespaces, and being able to distinquish annotations supplied by the SRC from those already present in the CS. For instance, if the MS in the RS is a mix of multiple CS media streams that have differing a=content values, it would be difficult to represent that using a=content in the RS SDP using a=content. There are probably lots of ways to skin that cat. We are just hand waving right now. I don't know how deep we want to go with that in the metamodel. Thanks, Paul > John > > >> -----Original Message----- >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> Sent: 10 June 2011 18:36 >> To: Elwell, John; Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) >> Cc: siprec@ietf.org >> Subject: RE: [siprec] What does an MS object represent? Can >> we pick one of theseoptions? >> >> Hi John, >> >> Given that the syntax for the content attribute in RFC 4796 allows for >> the assignment of additional extension values: >> >> content-attribute = "a=content:" mediacnt-tag >> mediacnt-tag = mediacnt *("," mediacnt) >> mediacnt = "slides" / "speaker" / "sl" / "main" >> / "alt" / mediacnt-ext >> mediacnt-ext = token >> >> do you still think it is not rich enough? It seems to be that >> given the >> content and label attributes plus the grouping framework, we >> can express >> pretty complex and detailed relationships. That said, it may >> be simpler >> to express in metadata than in SDP. Is that the motivation? >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Elwell, John >>> Sent: Tuesday, May 24, 2011 11:15 PM >>> To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] What does an MS object represent? Can we pick >> one of theseoptions? >>> >>> Given that SDP's a=content might not be rich enough, I think we need >> to define something new for >>> metadata, independent of a=content. The SRC could choose to >> derive the >> metadata content attribute from >>> the a=content attributes of the contributing CS streams (that is an >> SRC decision), but should not use >>> the a=content label in the RS SDP. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: 24 May 2011 18:07 >>>> To: Ram Mohan R (rmohanr) >>>> Cc: Elwell, John; siprec@ietf.org >>>> Subject: Re: [siprec] What does an MS object represent? Can >>>> we pick one of theseoptions? >>>> >>>> >>>> >>>> On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: >>>>> Paul/ John, >>>>> >>>>> I am ok to add attribute "content" in MS block of the model. >>>>> >>>>> The question is do we want to map this attribute in the model to >>>>> 1) The Session Description Protocol (SDP) Content Attribute >>>> defined in >>>>> RFC 4796 OR >>>>> 2)define our own content in the metadata XML which can take >>>> values as >>>>> "audio" / "main video" / "presentation video" / "current >>>> speaker video" >>>>> as suggested by John. >>>> >>>> Well... >>>> >>>> ISTM that if there is already an a=content in the CS SDP, >>>> then we would >>>> want to report that in the metadata. >>>> >>>> If there is a pair (one from offer, one from answer, same >>>> m-line offset) >>>> and there is *not* an a=content that pairs them, then we >>>> would want to >>>> report it anyway. >>>> >>>> But if we do that we have a problem with names and conflicts. >> rfc4796 >>>> doesn't define a lot of names, nor does it say whether >> corresponding >>>> streams in offer& answer must have the same names. >>>> >>>> So I think we have something similar but not quite the same, >>>> and we need >>>> to define something new. It must permit identifying streams >>>> even though >>>> we know nothing of their purpose. >>>> >>>> Thanks, >>>> Paul >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> From rmohanr@cisco.com Tue Jun 14 08:53:14 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3497511E80C8 for ; Tue, 14 Jun 2011 08:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0WS6gvQBeE5 for ; Tue, 14 Jun 2011 08:53:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7880E11E808B for ; Tue, 14 Jun 2011 08:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1101; q=dns/txt; s=iport; t=1308066786; x=1309276386; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=AG3FqdTWbhjZ0Nd7VNYyGDZ0NBksVFxDFscjW9CtUEw=; b=LcVTqSZ2I8/RDohSeUENR+K++UU7B19QUI+HdCOI46OyurBz+/i8v2Ia RgiaI1nJvSRCk4B6BPvPaYVmetslc0EdGnBvdkAFft0DS9qRDrvnJU401 oZWfZWGPOHWQIvUUwXDYPMq1Kz29qJhj8jkeFVDwOtJ8nFc+lfxMVdibQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBAJWC901Io8US/2dsb2JhbABSl0yOdXerO55ShiQEhxOPFYsP X-IronPort-AV: E=Sophos;i="4.65,365,1304294400"; d="scan'208";a="35187532" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 14 Jun 2011 15:53:03 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5EFr2Js022186; Tue, 14 Jun 2011 15:53:02 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 21:23:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jun 2011 21:23:01 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06B1B4D1@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Agenda interim 2011-06-23, 13.00-15.00 UTC/GMT Thread-Index: AcwqoX3ahA9Cv1J4Tei1s2mbYHjidwACOsCA References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 14 Jun 2011 15:53:02.0946 (UTC) FILETIME=[24A4DC20:01CC2AAB] Subject: Re: [siprec] Agenda interim 2011-06-23, 13.00-15.00 UTC/GMT X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:53:14 -0000 Hi John, We would like to have at least 20 mins for metamodel and 30 mins for metadata format to conclude / close the major open items ( some of which we are actively discussing in mailer). Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Tuesday, June 14, 2011 8:14 PM > To: siprec@ietf.org > Subject: [siprec] Agenda interim 2011-06-23, 13.00-15.00 UTC/GMT >=20 > As agreed at the last interim, priority to be given to the protocol > document. Any other agenda requests? >=20 > John >=20 > ################################# >=20 >=20 > Administrivia, 10 minutes, Chairs > - Note takers > - Participant list > - Start recording > - Note well > - Agenda bash >=20 > Protocol, 30 minutes, Leon Portman > - https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ >=20 > Wrap-up, hums, next steps, 10 minutes, Chairs >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Tue Jun 14 08:58:12 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E786711E8090 for ; Tue, 14 Jun 2011 08:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7a+IuRwAxfFQ for ; Tue, 14 Jun 2011 08:58:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7522A11E808B for ; Tue, 14 Jun 2011 08:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5494; q=dns/txt; s=iport; t=1308067089; x=1309276689; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=r94G4Sf1WDqxIAPcFzvVhj67hfEwop+rYg+xxBlyo3o=; b=kj++qK6fC7CKt46uEpM91erGABihIhn7gttTKN/f8v3e0lrDG/wjafMO 03Uf6SqG8psfpf8ZSO4TBkzITkGn/qNCeJu+iNmP2ZfIesFqS+Is88BCI esV0zE7fBjM0yeWmoMszKXqanNDtGnGqkvdOf453KMER15FbAanWC1JR0 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBAPaD902Q/khN/2dsb2JhbABSl0yOdXerJp5UhiQEhxWPE4sn X-IronPort-AV: E=Sophos;i="4.65,365,1304294400"; d="scan'208";a="93919496" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2011 15:58:06 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5EFvx2t026497; Tue, 14 Jun 2011 15:58:06 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 08:58:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jun 2011 08:58:03 -0700 Message-ID: In-Reply-To: <4DF78241.6050204@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwqqjG8uQW1yL2vRV+jdU/xxOUvQwAAMfOg References: <4DDA89F2.50706@cisco.com><4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com><4DDBE5D1.7030704@cisco.com> <4DF78241.6050204@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 14 Jun 2011 15:58:04.0350 (UTC) FILETIME=[D84B75E0:01CC2AAB] Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:58:13 -0000 Hi Paul, My first thought is that mixing CS MSs with different a=3Dcontent values into a single RS MS is something that should probably be avoided. I do not think reusing the a=3Dcontent attribute for the RS MS complicates this. If you wanted to mix CS1 MS1 and CS1 MS2 with different content attributes into a single RS MS, you could include the following: a:content=3DCS1-MS1-content-attribute-value CS1-MS2-content-attribute-value Cheers, Charles > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Tuesday, June 14, 2011 8:46 AM > To: Elwell, John > Cc: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? >=20 >=20 >=20 > On 6/14/2011 11:24 AM, Elwell, John wrote: > > Charles, > > > > I think it was Paul who first suggested that a=3Dcontent might not = be rich enough, and I was just > discussing the consequences. So perhaps Paul should respond. >=20 > Its all about namespaces, and being able to distinquish annotations > supplied by the SRC from those already present in the CS. For instance, > if the MS in the RS is a mix of multiple CS media streams that have > differing a=3Dcontent values, it would be difficult to represent that > using a=3Dcontent in the RS SDP using a=3Dcontent. >=20 > There are probably lots of ways to skin that cat. We are just hand > waving right now. I don't know how deep we want to go with that in the > metamodel. >=20 > Thanks, > Paul >=20 > > John > > > > > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >> Sent: 10 June 2011 18:36 > >> To: Elwell, John; Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) > >> Cc: siprec@ietf.org > >> Subject: RE: [siprec] What does an MS object represent? Can > >> we pick one of theseoptions? > >> > >> Hi John, > >> > >> Given that the syntax for the content attribute in RFC 4796 allows for > >> the assignment of additional extension values: > >> > >> content-attribute =3D "a=3Dcontent:" mediacnt-tag > >> mediacnt-tag =3D mediacnt *("," mediacnt) > >> mediacnt =3D "slides" / "speaker" / "sl" / = "main" > >> / "alt" / mediacnt-ext > >> mediacnt-ext =3D token > >> > >> do you still think it is not rich enough? It seems to be that > >> given the > >> content and label attributes plus the grouping framework, we > >> can express > >> pretty complex and detailed relationships. That said, it may > >> be simpler > >> to express in metadata than in SDP. Is that the motivation? > >> > >> Cheers, > >> Charles > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Elwell, John > >>> Sent: Tuesday, May 24, 2011 11:15 PM > >>> To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) > >>> Cc: siprec@ietf.org > >>> Subject: Re: [siprec] What does an MS object represent? Can we pick > >> one of theseoptions? > >>> > >>> Given that SDP's a=3Dcontent might not be rich enough, I think we need > >> to define something new for > >>> metadata, independent of a=3Dcontent. The SRC could choose to > >> derive the > >> metadata content attribute from > >>> the a=3Dcontent attributes of the contributing CS streams (that is an > >> SRC decision), but should not use > >>> the a=3Dcontent label in the RS SDP. > >>> > >>> John (as individual) > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: 24 May 2011 18:07 > >>>> To: Ram Mohan R (rmohanr) > >>>> Cc: Elwell, John; siprec@ietf.org > >>>> Subject: Re: [siprec] What does an MS object represent? Can > >>>> we pick one of theseoptions? > >>>> > >>>> > >>>> > >>>> On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: > >>>>> Paul/ John, > >>>>> > >>>>> I am ok to add attribute "content" in MS block of the model. > >>>>> > >>>>> The question is do we want to map this attribute in the model to > >>>>> 1) The Session Description Protocol (SDP) Content Attribute > >>>> defined in > >>>>> RFC 4796 OR > >>>>> 2)define our own content in the metadata XML which can take > >>>> values as > >>>>> "audio" / "main video" / "presentation video" / "current > >>>> speaker video" > >>>>> as suggested by John. > >>>> > >>>> Well... > >>>> > >>>> ISTM that if there is already an a=3Dcontent in the CS SDP, > >>>> then we would > >>>> want to report that in the metadata. > >>>> > >>>> If there is a pair (one from offer, one from answer, same > >>>> m-line offset) > >>>> and there is *not* an a=3Dcontent that pairs them, then we > >>>> would want to > >>>> report it anyway. > >>>> > >>>> But if we do that we have a problem with names and conflicts. > >> rfc4796 > >>>> doesn't define a lot of names, nor does it say whether > >> corresponding > >>>> streams in offer& answer must have the same names. > >>>> > >>>> So I think we have something similar but not quite the same, > >>>> and we need > >>>> to define something new. It must permit identifying streams > >>>> even though > >>>> we know nothing of their purpose. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >> From pkyzivat@cisco.com Tue Jun 14 09:18:32 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566C11F0C42 for ; Tue, 14 Jun 2011 09:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.109 X-Spam-Level: X-Spam-Status: No, score=-110.109 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ot9EM8-gp2qN for ; Tue, 14 Jun 2011 09:18:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 373BF1F0C3B for ; Tue, 14 Jun 2011 09:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6050; q=dns/txt; s=iport; t=1308068310; x=1309277910; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0wF6bZfLYB5p0Y/cp6/VE8lMbm3sxyUfJOeopRd+cTE=; b=dA6K3GWRdE9D15gbHf/wqHj2eHXjgT8QKglUfFiuXUhiTry7ToaDT6We cHpgyGnDqDz2rlytZrxK2YqwNUWvsxM6h5N2L0d9GDGz/WgHm8+lpNWwI aLdPZ6DKmY5SfLDGvhEoYCv9Da8U32tvs+tDDd9b/sf1w5eB8QE5oKYRJ Q=; X-IronPort-AV: E=Sophos;i="4.65,365,1304294400"; d="scan'208";a="93922501" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2011 16:18:28 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5EGIR0O032437; Tue, 14 Jun 2011 16:18:28 GMT Message-ID: <4DF789D3.4050101@cisco.com> Date: Tue, 14 Jun 2011 12:18:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <4DDA89F2.50706@cisco.com><4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com><4DDBE5D1.7030704@cisco.com> <4DF78241.6050204@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:18:32 -0000 On 6/14/2011 11:58 AM, Charles Eckel (eckelcu) wrote: > Hi Paul, > > My first thought is that mixing CS MSs with different a=content values > into a single RS MS is something that should probably be avoided. Yeah, certainly in cases of conflict. Not so clear if there is an a=content in one direction and none in the other. We may eventually need some sort of BCP or informational document with guidelines on how to use all this stuff. > I do > not think reusing the a=content attribute for the RS MS complicates > this. If you wanted to mix CS1 MS1 and CS1 MS2 with different content > attributes into a single RS MS, you could include the following: > > a:content=CS1-MS1-content-attribute-value > CS1-MS2-content-attribute-value Do we then know (or care) which came from which participant? Yes, I know I am getting really picky here, and it probably doesn't matter. Maybe we can somehow just leave the details of how to do this to the mechanism. Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Tuesday, June 14, 2011 8:46 AM >> To: Elwell, John >> Cc: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); siprec@ietf.org >> Subject: Re: [siprec] What does an MS object represent? Can we pick > one of theseoptions? >> >> >> >> On 6/14/2011 11:24 AM, Elwell, John wrote: >>> Charles, >>> >>> I think it was Paul who first suggested that a=content might not be > rich enough, and I was just >> discussing the consequences. So perhaps Paul should respond. >> >> Its all about namespaces, and being able to distinquish annotations >> supplied by the SRC from those already present in the CS. For > instance, >> if the MS in the RS is a mix of multiple CS media streams that have >> differing a=content values, it would be difficult to represent that >> using a=content in the RS SDP using a=content. >> >> There are probably lots of ways to skin that cat. We are just hand >> waving right now. I don't know how deep we want to go with that in the >> metamodel. >> >> Thanks, >> Paul >> >>> John >>> >>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>> Sent: 10 June 2011 18:36 >>>> To: Elwell, John; Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) >>>> Cc: siprec@ietf.org >>>> Subject: RE: [siprec] What does an MS object represent? Can >>>> we pick one of theseoptions? >>>> >>>> Hi John, >>>> >>>> Given that the syntax for the content attribute in RFC 4796 allows > for >>>> the assignment of additional extension values: >>>> >>>> content-attribute = "a=content:" mediacnt-tag >>>> mediacnt-tag = mediacnt *("," mediacnt) >>>> mediacnt = "slides" / "speaker" / "sl" / "main" >>>> / "alt" / mediacnt-ext >>>> mediacnt-ext = token >>>> >>>> do you still think it is not rich enough? It seems to be that >>>> given the >>>> content and label attributes plus the grouping framework, we >>>> can express >>>> pretty complex and detailed relationships. That said, it may >>>> be simpler >>>> to express in metadata than in SDP. Is that the motivation? >>>> >>>> Cheers, >>>> Charles >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Elwell, John >>>>> Sent: Tuesday, May 24, 2011 11:15 PM >>>>> To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] What does an MS object represent? Can we > pick >>>> one of theseoptions? >>>>> >>>>> Given that SDP's a=content might not be rich enough, I think we > need >>>> to define something new for >>>>> metadata, independent of a=content. The SRC could choose to >>>> derive the >>>> metadata content attribute from >>>>> the a=content attributes of the contributing CS streams (that is > an >>>> SRC decision), but should not use >>>>> the a=content label in the RS SDP. >>>>> >>>>> John (as individual) >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: 24 May 2011 18:07 >>>>>> To: Ram Mohan R (rmohanr) >>>>>> Cc: Elwell, John; siprec@ietf.org >>>>>> Subject: Re: [siprec] What does an MS object represent? Can >>>>>> we pick one of theseoptions? >>>>>> >>>>>> >>>>>> >>>>>> On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: >>>>>>> Paul/ John, >>>>>>> >>>>>>> I am ok to add attribute "content" in MS block of the model. >>>>>>> >>>>>>> The question is do we want to map this attribute in the model to >>>>>>> 1) The Session Description Protocol (SDP) Content Attribute >>>>>> defined in >>>>>>> RFC 4796 OR >>>>>>> 2)define our own content in the metadata XML which can take >>>>>> values as >>>>>>> "audio" / "main video" / "presentation video" / "current >>>>>> speaker video" >>>>>>> as suggested by John. >>>>>> >>>>>> Well... >>>>>> >>>>>> ISTM that if there is already an a=content in the CS SDP, >>>>>> then we would >>>>>> want to report that in the metadata. >>>>>> >>>>>> If there is a pair (one from offer, one from answer, same >>>>>> m-line offset) >>>>>> and there is *not* an a=content that pairs them, then we >>>>>> would want to >>>>>> report it anyway. >>>>>> >>>>>> But if we do that we have a problem with names and conflicts. >>>> rfc4796 >>>>>> doesn't define a lot of names, nor does it say whether >>>> corresponding >>>>>> streams in offer& answer must have the same names. >>>>>> >>>>>> So I think we have something similar but not quite the same, >>>>>> and we need >>>>>> to define something new. It must permit identifying streams >>>>>> even though >>>>>> we know nothing of their purpose. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> > From john.elwell@siemens-enterprise.com Tue Jun 14 09:25:23 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3869E8029 for ; Tue, 14 Jun 2011 09:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFn7ew038x1n for ; Tue, 14 Jun 2011 09:25:22 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 5CB219E8005 for ; Tue, 14 Jun 2011 09:25:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1308068692!43411009!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 769 invoked from network); 14 Jun 2011 16:24:52 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-10.tower-21.messagelabs.com with SMTP; 14 Jun 2011 16:24:52 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 722C423F03E8 for ; Tue, 14 Jun 2011 18:25:00 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 14 Jun 2011 18:25:00 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 14 Jun 2011 18:24:58 +0200 Thread-Topic: Agenda interim 2011-06-23, 13.00-15.00 UTC/GMT Thread-Index: AcwqoX3ahA9Cv1J4Tei1s2mbYHjidw== 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: [siprec] Agenda interim 2011-06-23, 13.00-15.00 UTC/GMT X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:25:23 -0000 Revised - items added on request from Ram ################################# Administrivia, 10 minutes, Chairs - Note takers - Participant list - Start recording - Note well - Agenda bash Protocol, 30 minutes, Leon Portman - https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Metadata model, 20 minutes, Ram Mohan - https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ Metadata format, 30 minutes, Parthasarasi R - https://datatracker.ietf.org/doc/draft-ram-siprec-metadata-format/ Wrap-up, hums, next steps, 10 minutes, Chairs From eckelcu@cisco.com Tue Jun 14 14:09:19 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9533411E80D8 for ; Tue, 14 Jun 2011 14:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.213 X-Spam-Level: X-Spam-Status: No, score=-10.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd2EY+tAf5qN for ; Tue, 14 Jun 2011 14:09:18 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7F59511E80DA for ; Tue, 14 Jun 2011 14:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=6980; q=dns/txt; s=iport; t=1308085758; x=1309295358; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=pAkclr/ho/0o7s0It8BUs8jDGiKoQsERe+Emj4YJ9Hg=; b=NNjUFdAzMwTNutU7DxFNat2zBzKTt0seir+oI4n0qN4XOUaPoQN/zbBj dnFw6MuYnTxOYlOK6eIPmi2Wazt5dvPB3t/0JKh4YKXuvUfS7jVq47FTk a2oP+LmrLVLlNynLF/mBM1dRP2SclvIr6cCeZNfeS7JneX1egIsPo6NId k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAKzM902rRDoJ/2dsb2JhbABSl0yPCHeqR54+hiQEhxWPE4sn X-IronPort-AV: E=Sophos;i="4.65,366,1304294400"; d="scan'208";a="376609062" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 14 Jun 2011 21:09:15 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5EL9FU8019169; Tue, 14 Jun 2011 21:09:15 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 14:09:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jun 2011 14:09:12 -0700 Message-ID: In-Reply-To: <4DF789D3.4050101@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: Acwqrrz34mgw1dfaRkWGEibCzkkdVAAAjSfg References: <4DDA89F2.50706@cisco.com><4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com><4DDBE5D1.7030704@cisco.com> <4DF78241.6050204@cisco.com> <4DF789D3.4050101@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 14 Jun 2011 21:09:15.0056 (UTC) FILETIME=[50E71B00:01CC2AD7] Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 21:09:19 -0000 I was thinking that in the metadata you would have the SDP for both CS1 MS1 and CS2 MS2, and then in the RS you would include the content attribute in the example provided below. Cheers, Charles > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Tuesday, June 14, 2011 9:18 AM > To: Charles Eckel (eckelcu) > Cc: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? >=20 >=20 >=20 > On 6/14/2011 11:58 AM, Charles Eckel (eckelcu) wrote: > > Hi Paul, > > > > My first thought is that mixing CS MSs with different a=3Dcontent values > > into a single RS MS is something that should probably be avoided. >=20 > Yeah, certainly in cases of conflict. Not so clear if there is an > a=3Dcontent in one direction and none in the other. >=20 > We may eventually need some sort of BCP or informational document with > guidelines on how to use all this stuff. >=20 > > I do > > not think reusing the a=3Dcontent attribute for the RS MS = complicates > > this. If you wanted to mix CS1 MS1 and CS1 MS2 with different content > > attributes into a single RS MS, you could include the following: > > > > a:content=3DCS1-MS1-content-attribute-value > > CS1-MS2-content-attribute-value >=20 > Do we then know (or care) which came from which participant? >=20 > Yes, I know I am getting really picky here, and it probably doesn't > matter. Maybe we can somehow just leave the details of how to do this to > the mechanism. >=20 > Thanks, > Paul >=20 > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: Paul Kyzivat (pkyzivat) > >> Sent: Tuesday, June 14, 2011 8:46 AM > >> To: Elwell, John > >> Cc: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); siprec@ietf.org > >> Subject: Re: [siprec] What does an MS object represent? Can we pick > > one of theseoptions? > >> > >> > >> > >> On 6/14/2011 11:24 AM, Elwell, John wrote: > >>> Charles, > >>> > >>> I think it was Paul who first suggested that a=3Dcontent might not be > > rich enough, and I was just > >> discussing the consequences. So perhaps Paul should respond. > >> > >> Its all about namespaces, and being able to distinquish annotations > >> supplied by the SRC from those already present in the CS. For > > instance, > >> if the MS in the RS is a mix of multiple CS media streams that have > >> differing a=3Dcontent values, it would be difficult to represent = that > >> using a=3Dcontent in the RS SDP using a=3Dcontent. > >> > >> There are probably lots of ways to skin that cat. We are just hand > >> waving right now. I don't know how deep we want to go with that in the > >> metamodel. > >> > >> Thanks, > >> Paul > >> > >>> John > >>> > >>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>> Sent: 10 June 2011 18:36 > >>>> To: Elwell, John; Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) > >>>> Cc: siprec@ietf.org > >>>> Subject: RE: [siprec] What does an MS object represent? Can > >>>> we pick one of theseoptions? > >>>> > >>>> Hi John, > >>>> > >>>> Given that the syntax for the content attribute in RFC 4796 allows > > for > >>>> the assignment of additional extension values: > >>>> > >>>> content-attribute =3D "a=3Dcontent:" mediacnt-tag > >>>> mediacnt-tag =3D mediacnt *("," mediacnt) > >>>> mediacnt =3D "slides" / "speaker" / "sl" / "main" > >>>> / "alt" / mediacnt-ext > >>>> mediacnt-ext =3D token > >>>> > >>>> do you still think it is not rich enough? It seems to be that > >>>> given the > >>>> content and label attributes plus the grouping framework, we > >>>> can express > >>>> pretty complex and detailed relationships. That said, it may > >>>> be simpler > >>>> to express in metadata than in SDP. Is that the motivation? > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf Of Elwell, John > >>>>> Sent: Tuesday, May 24, 2011 11:15 PM > >>>>> To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) > >>>>> Cc: siprec@ietf.org > >>>>> Subject: Re: [siprec] What does an MS object represent? Can we > > pick > >>>> one of theseoptions? > >>>>> > >>>>> Given that SDP's a=3Dcontent might not be rich enough, I think = we > > need > >>>> to define something new for > >>>>> metadata, independent of a=3Dcontent. The SRC could choose to > >>>> derive the > >>>> metadata content attribute from > >>>>> the a=3Dcontent attributes of the contributing CS streams (that = is > > an > >>>> SRC decision), but should not use > >>>>> the a=3Dcontent label in the RS SDP. > >>>>> > >>>>> John (as individual) > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>> Sent: 24 May 2011 18:07 > >>>>>> To: Ram Mohan R (rmohanr) > >>>>>> Cc: Elwell, John; siprec@ietf.org > >>>>>> Subject: Re: [siprec] What does an MS object represent? Can > >>>>>> we pick one of theseoptions? > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: > >>>>>>> Paul/ John, > >>>>>>> > >>>>>>> I am ok to add attribute "content" in MS block of the model. > >>>>>>> > >>>>>>> The question is do we want to map this attribute in the model to > >>>>>>> 1) The Session Description Protocol (SDP) Content Attribute > >>>>>> defined in > >>>>>>> RFC 4796 OR > >>>>>>> 2)define our own content in the metadata XML which can take > >>>>>> values as > >>>>>>> "audio" / "main video" / "presentation video" / "current > >>>>>> speaker video" > >>>>>>> as suggested by John. > >>>>>> > >>>>>> Well... > >>>>>> > >>>>>> ISTM that if there is already an a=3Dcontent in the CS SDP, > >>>>>> then we would > >>>>>> want to report that in the metadata. > >>>>>> > >>>>>> If there is a pair (one from offer, one from answer, same > >>>>>> m-line offset) > >>>>>> and there is *not* an a=3Dcontent that pairs them, then we > >>>>>> would want to > >>>>>> report it anyway. > >>>>>> > >>>>>> But if we do that we have a problem with names and conflicts. > >>>> rfc4796 > >>>>>> doesn't define a lot of names, nor does it say whether > >>>> corresponding > >>>>>> streams in offer& answer must have the same names. > >>>>>> > >>>>>> So I think we have something similar but not quite the same, > >>>>>> and we need > >>>>>> to define something new. It must permit identifying streams > >>>>>> even though > >>>>>> we know nothing of their purpose. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>> _______________________________________________ > >>>>> siprec mailing list > >>>>> siprec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> > > From eckelcu@cisco.com Tue Jun 14 14:12:10 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E789D1F0C3D for ; Tue, 14 Jun 2011 14:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQdyeHQDDUYU for ; Tue, 14 Jun 2011 14:12:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id BD3881F0C35 for ; Tue, 14 Jun 2011 14:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3345; q=dns/txt; s=iport; t=1308085925; x=1309295525; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=WNpmyN8sIPy9txdRtlDzWwdEAtdDOl2+iXIoGiRa+zo=; b=h/DHkEuGKMDB5uFoEb7Fep2uP+hrm+OvHhB346lbS7l2SI7d6nom9cmk 5B2U5b95oykDsS50j9N9DvWx7NZXDRAHnZSM8+wHqASEiRjCfYDk7YuBn OBZgjiinA+/aridcjd5CYaq2AazDFlIucGM2PUxP9Pv33VcuAgZSsCdwK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAPzN902rRDoG/2dsb2JhbABSl0yPCHeqRp4+hiQEhxWPE4sn X-IronPort-AV: E=Sophos;i="4.65,366,1304294400"; d="scan'208";a="713487181" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 14 Jun 2011 21:12:05 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5ELC5Jt022235; Tue, 14 Jun 2011 21:12:05 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 14:12:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jun 2011 14:12:03 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] FW: New Version Notification fordraft-eckel-siprec-rtp-rec-00.txt Thread-Index: AcwqAnZVGLiKbskDRFaW1Y2k4Cx3EgAAQxVAACa5n/AADj7CEA== References: From: "Charles Eckel (eckelcu)" To: "Elwell, John" , X-OriginalArrivalTime: 14 Jun 2011 21:12:05.0241 (UTC) FILETIME=[B6574690:01CC2AD7] Subject: Re: [siprec] FW: New Version Notification fordraft-eckel-siprec-rtp-rec-00.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 21:12:10 -0000 Hi John, Thanks for having a look for the proposed improvement. I will update Section 13 accordingly. I also realized I forgot to run the draft through a spell checker - my apologies for that. I will take care of that as well. Depending on the amount of review and comments in the next few days, it may be worthwhile to add a time slot to discuss this draft as part of the interim meeting. Cheers, Charles > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, June 14, 2011 7:28 AM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] FW: New Version Notification fordraft-eckel-siprec-rtp-rec-00.txt >=20 > Thanks, Charles, for posting this. Much of the material has been posted before, but having it in an I- > D makes it easier to discuss. The I-D makes a number of recommendations, with the intention that these > be incorporated into the protocol draft at some stage. So folks should review these and see which ones > they are happy with and which need more discussion. It would be good to do this before the next > interim call on 23rd June. >=20 > One minor point I noted. Section 13 talks about symmetric RTP/RTCP, but in the case of the RS, RTP is > one-way, so does symmetry apply in practice only to RTCP? Perhaps next section needs some slight > elaboration. >=20 > John (as chair) >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > > Sent: 13 June 2011 20:57 > > To: siprec@ietf.org > > Subject: [siprec] FW: New Version Notification for > > draft-eckel-siprec-rtp-rec-00.txt > > > > I have posted the initial rev of the RTP recommendations for > > SIPREC draft. It is available at > > http://datatracker.ietf.org/doc/draft-eckel-siprec-rtp-rec/. > > Please have a look and share your comments. > > > > Cheers, > > Charles > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, June 13, 2011 12:45 PM > > To: Charles Eckel (eckelcu) > > Cc: Charles Eckel (eckelcu) > > Subject: New Version Notification for > > draft-eckel-siprec-rtp-rec-00.txt > > > > A new version of I-D, draft-eckel-siprec-rtp-rec-00.txt has > > been successfully submitted by Charles Eckel and posted to > > the IETF repository. > > > > Filename: draft-eckel-siprec-rtp-rec > > Revision: 00 > > Title: Real-time Transport Protocol (RTP) > > Recommendations for SIPREC > > Creation date: 2011-06-13 > > WG ID: Individual Submission > > Number of pages: 11 > > > > Abstract: > > This document provides recommendations and guidelines for RTP and > > RTCP in the context of SIPREC. This document exists as a > > standalone > > document to faciliate dicussion of the RTP > > recommendations, and it is > > anticipated that portions of this document will be > > incorporated into > > [I-D.portman-siprec-protocol] rather than this document > > itself being > > adopted as a working group document. > > > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > From pkyzivat@cisco.com Tue Jun 14 14:17:41 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2038C11E809E for ; Tue, 14 Jun 2011 14:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.113 X-Spam-Level: X-Spam-Status: No, score=-110.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUTzkZ3BpQCx for ; Tue, 14 Jun 2011 14:17:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 39B6A11E807D for ; Tue, 14 Jun 2011 14:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=7296; q=dns/txt; s=iport; t=1308086259; x=1309295859; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=en4kmi4pDXBzWI20O7NcXkpKxLONLqr7La6q+iT+IYg=; b=bJmvfDkIzsFlIb5Wkp3iGL4tg0WvdbbsTsv6WT4IjOeAFAzQcbA5a+Z9 MgRyWPG9wz0zn9WBB+dIQdIgAU1KFei+tiH/s6NUpJMSNtXysFxF5HRGT Noysyon629Ex4ERgRGQGxcyAmQ5tI+Xz6hTwXDos1XT1HgYFIvwpLegOg 8=; X-IronPort-AV: E=Sophos;i="4.65,366,1304294400"; d="scan'208";a="376613760" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 14 Jun 2011 21:17:38 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5ELHb6O000880; Tue, 14 Jun 2011 21:17:37 GMT Message-ID: <4DF7CFF1.4010502@cisco.com> Date: Tue, 14 Jun 2011 17:17:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <4DDA89F2.50706@cisco.com><4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com><4DDBE5D1.7030704@cisco.com> <4DF78241.6050204@cisco.com> <4DF789D3.4050101@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 21:17:41 -0000 On 6/14/2011 5:09 PM, Charles Eckel (eckelcu) wrote: > I was thinking that in the metadata you would have the SDP for both CS1 > MS1 and CS2 MS2, and then in the RS you would include the content > attribute in the example provided below. IIRC there was once some discussion in passing of whether we should include all the CS sdp in the metadata, and the decision was "no" - we would call out in the metamodel all the stuff that we wanted to carry. Can somebody confirm/deny that? Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Tuesday, June 14, 2011 9:18 AM >> To: Charles Eckel (eckelcu) >> Cc: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org >> Subject: Re: [siprec] What does an MS object represent? Can we pick > one of theseoptions? >> >> >> >> On 6/14/2011 11:58 AM, Charles Eckel (eckelcu) wrote: >>> Hi Paul, >>> >>> My first thought is that mixing CS MSs with different a=content > values >>> into a single RS MS is something that should probably be avoided. >> >> Yeah, certainly in cases of conflict. Not so clear if there is an >> a=content in one direction and none in the other. >> >> We may eventually need some sort of BCP or informational document with >> guidelines on how to use all this stuff. >> >>> I do >>> not think reusing the a=content attribute for the RS MS complicates >>> this. If you wanted to mix CS1 MS1 and CS1 MS2 with different > content >>> attributes into a single RS MS, you could include the following: >>> >>> a:content=CS1-MS1-content-attribute-value >>> CS1-MS2-content-attribute-value >> >> Do we then know (or care) which came from which participant? >> >> Yes, I know I am getting really picky here, and it probably doesn't >> matter. Maybe we can somehow just leave the details of how to do this > to >> the mechanism. >> >> Thanks, >> Paul >> >>> Cheers, >>> Charles >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat (pkyzivat) >>>> Sent: Tuesday, June 14, 2011 8:46 AM >>>> To: Elwell, John >>>> Cc: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); siprec@ietf.org >>>> Subject: Re: [siprec] What does an MS object represent? Can we pick >>> one of theseoptions? >>>> >>>> >>>> >>>> On 6/14/2011 11:24 AM, Elwell, John wrote: >>>>> Charles, >>>>> >>>>> I think it was Paul who first suggested that a=content might not > be >>> rich enough, and I was just >>>> discussing the consequences. So perhaps Paul should respond. >>>> >>>> Its all about namespaces, and being able to distinquish annotations >>>> supplied by the SRC from those already present in the CS. For >>> instance, >>>> if the MS in the RS is a mix of multiple CS media streams that have >>>> differing a=content values, it would be difficult to represent that >>>> using a=content in the RS SDP using a=content. >>>> >>>> There are probably lots of ways to skin that cat. We are just hand >>>> waving right now. I don't know how deep we want to go with that in > the >>>> metamodel. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> John >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>>> Sent: 10 June 2011 18:36 >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) >>>>>> Cc: siprec@ietf.org >>>>>> Subject: RE: [siprec] What does an MS object represent? Can >>>>>> we pick one of theseoptions? >>>>>> >>>>>> Hi John, >>>>>> >>>>>> Given that the syntax for the content attribute in RFC 4796 > allows >>> for >>>>>> the assignment of additional extension values: >>>>>> >>>>>> content-attribute = "a=content:" mediacnt-tag >>>>>> mediacnt-tag = mediacnt *("," mediacnt) >>>>>> mediacnt = "slides" / "speaker" / "sl" / > "main" >>>>>> / "alt" / mediacnt-ext >>>>>> mediacnt-ext = token >>>>>> >>>>>> do you still think it is not rich enough? It seems to be that >>>>>> given the >>>>>> content and label attributes plus the grouping framework, we >>>>>> can express >>>>>> pretty complex and detailed relationships. That said, it may >>>>>> be simpler >>>>>> to express in metadata than in SDP. Is that the motivation? >>>>>> >>>>>> Cheers, >>>>>> Charles >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On >>>>>> Behalf Of Elwell, John >>>>>>> Sent: Tuesday, May 24, 2011 11:15 PM >>>>>>> To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) >>>>>>> Cc: siprec@ietf.org >>>>>>> Subject: Re: [siprec] What does an MS object represent? Can we >>> pick >>>>>> one of theseoptions? >>>>>>> >>>>>>> Given that SDP's a=content might not be rich enough, I think we >>> need >>>>>> to define something new for >>>>>>> metadata, independent of a=content. The SRC could choose to >>>>>> derive the >>>>>> metadata content attribute from >>>>>>> the a=content attributes of the contributing CS streams (that is >>> an >>>>>> SRC decision), but should not use >>>>>>> the a=content label in the RS SDP. >>>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>> Sent: 24 May 2011 18:07 >>>>>>>> To: Ram Mohan R (rmohanr) >>>>>>>> Cc: Elwell, John; siprec@ietf.org >>>>>>>> Subject: Re: [siprec] What does an MS object represent? Can >>>>>>>> we pick one of theseoptions? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: >>>>>>>>> Paul/ John, >>>>>>>>> >>>>>>>>> I am ok to add attribute "content" in MS block of the model. >>>>>>>>> >>>>>>>>> The question is do we want to map this attribute in the model > to >>>>>>>>> 1) The Session Description Protocol (SDP) Content Attribute >>>>>>>> defined in >>>>>>>>> RFC 4796 OR >>>>>>>>> 2)define our own content in the metadata XML which can take >>>>>>>> values as >>>>>>>>> "audio" / "main video" / "presentation video" / "current >>>>>>>> speaker video" >>>>>>>>> as suggested by John. >>>>>>>> >>>>>>>> Well... >>>>>>>> >>>>>>>> ISTM that if there is already an a=content in the CS SDP, >>>>>>>> then we would >>>>>>>> want to report that in the metadata. >>>>>>>> >>>>>>>> If there is a pair (one from offer, one from answer, same >>>>>>>> m-line offset) >>>>>>>> and there is *not* an a=content that pairs them, then we >>>>>>>> would want to >>>>>>>> report it anyway. >>>>>>>> >>>>>>>> But if we do that we have a problem with names and conflicts. >>>>>> rfc4796 >>>>>>>> doesn't define a lot of names, nor does it say whether >>>>>> corresponding >>>>>>>> streams in offer& answer must have the same names. >>>>>>>> >>>>>>>> So I think we have something similar but not quite the same, >>>>>>>> and we need >>>>>>>> to define something new. It must permit identifying streams >>>>>>>> even though >>>>>>>> we know nothing of their purpose. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>> > From rmohanr@cisco.com Tue Jun 14 20:25:37 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9A6228005 for ; Tue, 14 Jun 2011 20:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjnTFnQS-1cV for ; Tue, 14 Jun 2011 20:25:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 44F36228004 for ; Tue, 14 Jun 2011 20:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=8345; q=dns/txt; s=iport; t=1308108335; x=1309317935; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=PBDGMrLDLB2EXwyXtEcKtmH2KCjImuRRFGD+vwB1eDc=; b=HuVmfI24cjwwMEbzS0JbHL8r1FIh5HYu2yBLruQw0bhmfH4M4acPkkXW u2yEQe+swLWu7lnux9z0UHOyjOg8Cm1tX1qp1uuuQow6UtEtUcUMTlycY 95R6mOOZwax71ku39W/TPJ84LItiEhIUEYAV/sWOkT+jduGeOGI84Ws1d U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEBAG8l+E1Io8UQ/2dsb2JhbABSl0uPBneIc6BdnkGGJgSHE48YixQ X-IronPort-AV: E=Sophos;i="4.65,368,1304294400"; d="scan'208";a="93987934" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2011 03:25:27 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5F3PQb2004189; Wed, 15 Jun 2011 03:25:26 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 08:55:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jun 2011 08:55:24 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06B1B5BF@XMB-BGL-417.cisco.com> In-Reply-To: <4DF7CFF1.4010502@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: Acwq2IWxqmtzXd2qS5moVCrFJRxT5wAMg5QQ References: <4DDA89F2.50706@cisco.com><4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com><4DDBE5D1.7030704@cisco.com> <4DF78241.6050204@cisco.com> <4DF789D3.4050101@cisco.com> <4DF7CFF1.4010502@cisco.com> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat (pkyzivat)" , "Charles Eckel (eckelcu)" X-OriginalArrivalTime: 15 Jun 2011 03:25:26.0344 (UTC) FILETIME=[DE705480:01CC2B0B] Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 03:25:37 -0000 > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Wednesday, June 15, 2011 2:48 AM > To: Charles Eckel (eckelcu) > Cc: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can we pick one > of theseoptions? >=20 >=20 >=20 > On 6/14/2011 5:09 PM, Charles Eckel (eckelcu) wrote: > > I was thinking that in the metadata you would have the SDP for both > CS1 > > MS1 and CS2 MS2, and then in the RS you would include the content > > attribute in the example provided below. >=20 > IIRC there was once some discussion in passing of whether we should > include all the CS sdp in the metadata, and the decision was "no" - we > would call out in the metamodel all the stuff that we wanted to carry. >=20 > Can somebody confirm/deny that? Yes we agreed that there is no need/requirement to pass the entire CS SDP in metadata. Here is one of the mail thread for the same from archives http://www.ietf.org/mail-archive/web/siprec/current/msg01581.html Ram >=20 > Thanks, > Paul >=20 > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: Paul Kyzivat (pkyzivat) > >> Sent: Tuesday, June 14, 2011 9:18 AM > >> To: Charles Eckel (eckelcu) > >> Cc: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org > >> Subject: Re: [siprec] What does an MS object represent? Can we pick > > one of theseoptions? > >> > >> > >> > >> On 6/14/2011 11:58 AM, Charles Eckel (eckelcu) wrote: > >>> Hi Paul, > >>> > >>> My first thought is that mixing CS MSs with different a=3Dcontent > > values > >>> into a single RS MS is something that should probably be avoided. > >> > >> Yeah, certainly in cases of conflict. Not so clear if there is an > >> a=3Dcontent in one direction and none in the other. > >> > >> We may eventually need some sort of BCP or informational document > with > >> guidelines on how to use all this stuff. > >> > >>> I do > >>> not think reusing the a=3Dcontent attribute for the RS MS complicates > >>> this. If you wanted to mix CS1 MS1 and CS1 MS2 with different > > content > >>> attributes into a single RS MS, you could include the following: > >>> > >>> a:content=3DCS1-MS1-content-attribute-value > >>> CS1-MS2-content-attribute-value > >> > >> Do we then know (or care) which came from which participant? > >> > >> Yes, I know I am getting really picky here, and it probably doesn't > >> matter. Maybe we can somehow just leave the details of how to do > this > > to > >> the mechanism. > >> > >> Thanks, > >> Paul > >> > >>> Cheers, > >>> Charles > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat (pkyzivat) > >>>> Sent: Tuesday, June 14, 2011 8:46 AM > >>>> To: Elwell, John > >>>> Cc: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > siprec@ietf.org > >>>> Subject: Re: [siprec] What does an MS object represent? Can we > pick > >>> one of theseoptions? > >>>> > >>>> > >>>> > >>>> On 6/14/2011 11:24 AM, Elwell, John wrote: > >>>>> Charles, > >>>>> > >>>>> I think it was Paul who first suggested that a=3Dcontent might = not > > be > >>> rich enough, and I was just > >>>> discussing the consequences. So perhaps Paul should respond. > >>>> > >>>> Its all about namespaces, and being able to distinquish > annotations > >>>> supplied by the SRC from those already present in the CS. For > >>> instance, > >>>> if the MS in the RS is a mix of multiple CS media streams that > have > >>>> differing a=3Dcontent values, it would be difficult to represent > that > >>>> using a=3Dcontent in the RS SDP using a=3Dcontent. > >>>> > >>>> There are probably lots of ways to skin that cat. We are just hand > >>>> waving right now. I don't know how deep we want to go with that in > > the > >>>> metamodel. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> John > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>>>> Sent: 10 June 2011 18:36 > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) > >>>>>> Cc: siprec@ietf.org > >>>>>> Subject: RE: [siprec] What does an MS object represent? Can > >>>>>> we pick one of theseoptions? > >>>>>> > >>>>>> Hi John, > >>>>>> > >>>>>> Given that the syntax for the content attribute in RFC 4796 > > allows > >>> for > >>>>>> the assignment of additional extension values: > >>>>>> > >>>>>> content-attribute =3D "a=3Dcontent:" mediacnt-tag > >>>>>> mediacnt-tag =3D mediacnt *("," mediacnt) > >>>>>> mediacnt =3D "slides" / "speaker" / "sl" / > > "main" > >>>>>> / "alt" / mediacnt-ext > >>>>>> mediacnt-ext =3D token > >>>>>> > >>>>>> do you still think it is not rich enough? It seems to be that > >>>>>> given the > >>>>>> content and label attributes plus the grouping framework, we > >>>>>> can express > >>>>>> pretty complex and detailed relationships. That said, it may > >>>>>> be simpler > >>>>>> to express in metadata than in SDP. Is that the motivation? > >>>>>> > >>>>>> Cheers, > >>>>>> Charles > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > > On > >>>>>> Behalf Of Elwell, John > >>>>>>> Sent: Tuesday, May 24, 2011 11:15 PM > >>>>>>> To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) > >>>>>>> Cc: siprec@ietf.org > >>>>>>> Subject: Re: [siprec] What does an MS object represent? Can we > >>> pick > >>>>>> one of theseoptions? > >>>>>>> > >>>>>>> Given that SDP's a=3Dcontent might not be rich enough, I think we > >>> need > >>>>>> to define something new for > >>>>>>> metadata, independent of a=3Dcontent. The SRC could choose to > >>>>>> derive the > >>>>>> metadata content attribute from > >>>>>>> the a=3Dcontent attributes of the contributing CS streams = (that > is > >>> an > >>>>>> SRC decision), but should not use > >>>>>>> the a=3Dcontent label in the RS SDP. > >>>>>>> > >>>>>>> John (as individual) > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>>>> Sent: 24 May 2011 18:07 > >>>>>>>> To: Ram Mohan R (rmohanr) > >>>>>>>> Cc: Elwell, John; siprec@ietf.org > >>>>>>>> Subject: Re: [siprec] What does an MS object represent? Can > >>>>>>>> we pick one of theseoptions? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: > >>>>>>>>> Paul/ John, > >>>>>>>>> > >>>>>>>>> I am ok to add attribute "content" in MS block of the model. > >>>>>>>>> > >>>>>>>>> The question is do we want to map this attribute in the model > > to > >>>>>>>>> 1) The Session Description Protocol (SDP) Content Attribute > >>>>>>>> defined in > >>>>>>>>> RFC 4796 OR > >>>>>>>>> 2)define our own content in the metadata XML which can take > >>>>>>>> values as > >>>>>>>>> "audio" / "main video" / "presentation video" / "current > >>>>>>>> speaker video" > >>>>>>>>> as suggested by John. > >>>>>>>> > >>>>>>>> Well... > >>>>>>>> > >>>>>>>> ISTM that if there is already an a=3Dcontent in the CS SDP, > >>>>>>>> then we would > >>>>>>>> want to report that in the metadata. > >>>>>>>> > >>>>>>>> If there is a pair (one from offer, one from answer, same > >>>>>>>> m-line offset) > >>>>>>>> and there is *not* an a=3Dcontent that pairs them, then we > >>>>>>>> would want to > >>>>>>>> report it anyway. > >>>>>>>> > >>>>>>>> But if we do that we have a problem with names and conflicts. > >>>>>> rfc4796 > >>>>>>>> doesn't define a lot of names, nor does it say whether > >>>>>> corresponding > >>>>>>>> streams in offer& answer must have the same names. > >>>>>>>> > >>>>>>>> So I think we have something similar but not quite the same, > >>>>>>>> and we need > >>>>>>>> to define something new. It must permit identifying streams > >>>>>>>> even though > >>>>>>>> we know nothing of their purpose. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Paul > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> siprec mailing list > >>>>>>> siprec@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>> > >>> > > From rmohanr@cisco.com Tue Jun 14 23:13:22 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417A511E8086 for ; Tue, 14 Jun 2011 23:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6rqKpI4h5ay for ; Tue, 14 Jun 2011 23:13:21 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DE57F11E8076 for ; Tue, 14 Jun 2011 23:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=7876; q=dns/txt; s=iport; t=1308118401; x=1309328001; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=6qm7zv407ZMXzy6fdi6TER03z5Sfeq0sRbMoqRHRHKU=; b=JHFfrYUHthpURrsobV6tlKhEhWWSGXc8F4FJTBkH7ytjNWRGz85IcCvn JivpSgmenU273cH+0Gn56kAagOqA+knZzot5fdAi8HST3MbzpqG8p1Mov OPwBABnZ328rMjWkIwoAjwKZFCEqGED0Nr3VDgJYKgGpL75aoGyf5gVPM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsBAFJM+E1Io8UQ/2dsb2JhbABSglGUekGORXepVp5IhiYEhxOPGIsU X-IronPort-AV: E=Sophos;i="4.65,368,1304294400"; d="scan'208,217";a="94008297" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2011 06:13:12 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5F6DCcu002553 for ; Wed, 15 Jun 2011 06:13:12 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 11:43:12 +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_01CC2B23.4E411DB4" Date: Wed, 15 Jun 2011 11:43:09 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06B1B69E@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06A0ADB3@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Ticket #71 Media Stream / codec params Thread-Index: AcwkabATlF0t0iv+SxmU06VtQSQGOAGuP1Yw References: <35BCE99A477D6A4986FB2216D8CF2CFD06A0ADB3@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 15 Jun 2011 06:13:12.0403 (UTC) FILETIME=[4E470A30:01CC2B23] Subject: Re: [siprec] Ticket #71 Media Stream / codec params X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 06:13:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2B23.4E411DB4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have not heard of any motivations for having Codec-params in media stream block of the model. So will remove the same in the next version. =20 Regards, Ram From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Monday, June 06, 2011 10:19 PM To: siprec@ietf.org Subject: [siprec] Ticket #71 Media Stream / codec params =20 from ticket #71 description: =20 >From Prague minutes: "Slide 9: Open item: Media stream: Codec params text change. Although there=20 wasn't any objection to changing codec params text to refer to RS SDP (as=20 opposed to CS SDP), it was not clear to everyone why this was needed at all.=20 Therefore it will be taken to the mailing list." =20 =20 The codec parameters on the MS have been there since the first cut at the metadata model. The intent at that time was to see if there was any need to carry some of the CS parameters as metadata in RS dialog.=20 =20 However after several discussions we had on the mailer where we have not seen any use cases we agreed that there is no need to carry CS SDP params Please refer to mail thread http://www.ietf.org/mail-archive/web/siprec/current/msg01600.html =20 So I intend to remove this attribute from the MS block of the metadata model and close this ticket. =20 Please get back before 6/ 13 ( Monday) if any one has any concerns. =20 Regards, Ram ------_=_NextPart_001_01CC2B23.4E411DB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have not heard of any motivations for having = Codec-params in media stream block of the model.

So will remove the same = in the next version.

 

Regards,

Ram

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ram Mohan R (rmohanr)
Sent: Monday, June 06, 2011 10:19 = PM
To: siprec@ietf.org
Subject: [siprec] Ticket #71 = Media Stream / codec params

 

<snip> from ticket #71 = description:

 

From Prague minutes: "Slide = 9: Open item: Media stream: Codec params text change. Although = there 
wasn't any objection to changing codec params = text to refer to RS SDP (as 
opposed to CS SDP), it was not clear to = everyone why this was needed at all. 
Therefore it will be taken to the mailing = list."

 

</snip>

 

The codec parameters on the MS have been there = since the first cut at the metadata model. The intent at that time was = to see if there was any need to carry some of the CS parameters as = metadata in  RS dialog.

 

However = after several discussions we had on the mailer where we have not seen = any use cases we agreed that there is no need to carry CS SDP = params

Please refer to mail thread http://www.ietf.org/mail-archive/web/siprec/current/msg01600.html

 

So I intend to remove this attribute from the MS block = of the metadata model and close this ticket.

 

Please get = back before 6/ 13 ( Monday) if any one has any = concerns.

 

Regards,

Ram

------_=_NextPart_001_01CC2B23.4E411DB4-- From john.elwell@siemens-enterprise.com Tue Jun 14 23:55:48 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9327E21F8511 for ; Tue, 14 Jun 2011 23:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.256 X-Spam-Level: X-Spam-Status: No, score=-106.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlBdW5lwCgFJ for ; Tue, 14 Jun 2011 23:55:47 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 0FF6721F8510 for ; Tue, 14 Jun 2011 23:55:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1308120939!690996!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 15278 invoked from network); 15 Jun 2011 06:55:39 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-11.tower-216.messagelabs.com with SMTP; 15 Jun 2011 06:55:39 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id B46DE1EB83D3; Wed, 15 Jun 2011 08:55:39 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 15 Jun 2011 08:55:39 +0200 From: "Elwell, John" To: Paul Kyzivat , "Charles Eckel (eckelcu)" Date: Wed, 15 Jun 2011 08:55:37 +0200 Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: Acwq2Imv422Tf905TOiAllBr8TnKWAAUKTFA Message-ID: References: <4DDA89F2.50706@cisco.com><4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com><4DDBE5D1.7030704@cisco.com> <4DF78241.6050204@cisco.com> <4DF789D3.4050101@cisco.com> <4DF7CFF1.4010502@cisco.com> In-Reply-To: <4DF7CFF1.4010502@cisco.com> 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: "siprec@ietf.org" Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 06:55:48 -0000 I think Paul's recollection is correct. John=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 14 June 2011 22:18 > To: Charles Eckel (eckelcu) > Cc: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can=20 > we pick one of theseoptions? >=20 >=20 >=20 > On 6/14/2011 5:09 PM, Charles Eckel (eckelcu) wrote: > > I was thinking that in the metadata you would have the SDP=20 > for both CS1 > > MS1 and CS2 MS2, and then in the RS you would include the content > > attribute in the example provided below. >=20 > IIRC there was once some discussion in passing of whether we should=20 > include all the CS sdp in the metadata, and the decision was=20 > "no" - we=20 > would call out in the metamodel all the stuff that we wanted to carry. >=20 > Can somebody confirm/deny that? >=20 > Thanks, > Paul >=20 > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: Paul Kyzivat (pkyzivat) > >> Sent: Tuesday, June 14, 2011 9:18 AM > >> To: Charles Eckel (eckelcu) > >> Cc: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org > >> Subject: Re: [siprec] What does an MS object represent? Can we pick > > one of theseoptions? > >> > >> > >> > >> On 6/14/2011 11:58 AM, Charles Eckel (eckelcu) wrote: > >>> Hi Paul, > >>> > >>> My first thought is that mixing CS MSs with different a=3Dcontent > > values > >>> into a single RS MS is something that should probably be avoided. > >> > >> Yeah, certainly in cases of conflict. Not so clear if there is an > >> a=3Dcontent in one direction and none in the other. > >> > >> We may eventually need some sort of BCP or informational=20 > document with > >> guidelines on how to use all this stuff. > >> > >>> I do > >>> not think reusing the a=3Dcontent attribute for the RS MS=20 > complicates > >>> this. If you wanted to mix CS1 MS1 and CS1 MS2 with different > > content > >>> attributes into a single RS MS, you could include the following: > >>> > >>> a:content=3DCS1-MS1-content-attribute-value > >>> CS1-MS2-content-attribute-value > >> > >> Do we then know (or care) which came from which participant? > >> > >> Yes, I know I am getting really picky here, and it probably doesn't > >> matter. Maybe we can somehow just leave the details of how=20 > to do this > > to > >> the mechanism. > >> > >> Thanks, > >> Paul > >> > >>> Cheers, > >>> Charles > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat (pkyzivat) > >>>> Sent: Tuesday, June 14, 2011 8:46 AM > >>>> To: Elwell, John > >>>> Cc: Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 > siprec@ietf.org > >>>> Subject: Re: [siprec] What does an MS object represent?=20 > Can we pick > >>> one of theseoptions? > >>>> > >>>> > >>>> > >>>> On 6/14/2011 11:24 AM, Elwell, John wrote: > >>>>> Charles, > >>>>> > >>>>> I think it was Paul who first suggested that a=3Dcontent might not > > be > >>> rich enough, and I was just > >>>> discussing the consequences. So perhaps Paul should respond. > >>>> > >>>> Its all about namespaces, and being able to distinquish=20 > annotations > >>>> supplied by the SRC from those already present in the CS. For > >>> instance, > >>>> if the MS in the RS is a mix of multiple CS media=20 > streams that have > >>>> differing a=3Dcontent values, it would be difficult to=20 > represent that > >>>> using a=3Dcontent in the RS SDP using a=3Dcontent. > >>>> > >>>> There are probably lots of ways to skin that cat. We are=20 > just hand > >>>> waving right now. I don't know how deep we want to go=20 > with that in > > the > >>>> metamodel. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> John > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>>>> Sent: 10 June 2011 18:36 > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat); Ram Mohan R=20 > (rmohanr) > >>>>>> Cc: siprec@ietf.org > >>>>>> Subject: RE: [siprec] What does an MS object represent? Can > >>>>>> we pick one of theseoptions? > >>>>>> > >>>>>> Hi John, > >>>>>> > >>>>>> Given that the syntax for the content attribute in RFC 4796 > > allows > >>> for > >>>>>> the assignment of additional extension values: > >>>>>> > >>>>>> content-attribute =3D "a=3Dcontent:" mediacnt-tag > >>>>>> mediacnt-tag =3D mediacnt *("," mediacnt) > >>>>>> mediacnt =3D "slides" / "speaker" / "sl" / > > "main" > >>>>>> / "alt" / mediacnt-ext > >>>>>> mediacnt-ext =3D token > >>>>>> > >>>>>> do you still think it is not rich enough? It seems to be that > >>>>>> given the > >>>>>> content and label attributes plus the grouping framework, we > >>>>>> can express > >>>>>> pretty complex and detailed relationships. That said, it may > >>>>>> be simpler > >>>>>> to express in metadata than in SDP. Is that the motivation? > >>>>>> > >>>>>> Cheers, > >>>>>> Charles > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > > On > >>>>>> Behalf Of Elwell, John > >>>>>>> Sent: Tuesday, May 24, 2011 11:15 PM > >>>>>>> To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) > >>>>>>> Cc: siprec@ietf.org > >>>>>>> Subject: Re: [siprec] What does an MS object represent? Can we > >>> pick > >>>>>> one of theseoptions? > >>>>>>> > >>>>>>> Given that SDP's a=3Dcontent might not be rich enough,=20 > I think we > >>> need > >>>>>> to define something new for > >>>>>>> metadata, independent of a=3Dcontent. The SRC could choose to > >>>>>> derive the > >>>>>> metadata content attribute from > >>>>>>> the a=3Dcontent attributes of the contributing CS=20 > streams (that is > >>> an > >>>>>> SRC decision), but should not use > >>>>>>> the a=3Dcontent label in the RS SDP. > >>>>>>> > >>>>>>> John (as individual) > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>>>> Sent: 24 May 2011 18:07 > >>>>>>>> To: Ram Mohan R (rmohanr) > >>>>>>>> Cc: Elwell, John; siprec@ietf.org > >>>>>>>> Subject: Re: [siprec] What does an MS object represent? Can > >>>>>>>> we pick one of theseoptions? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: > >>>>>>>>> Paul/ John, > >>>>>>>>> > >>>>>>>>> I am ok to add attribute "content" in MS block of the model. > >>>>>>>>> > >>>>>>>>> The question is do we want to map this attribute in=20 > the model > > to > >>>>>>>>> 1) The Session Description Protocol (SDP) Content Attribute > >>>>>>>> defined in > >>>>>>>>> RFC 4796 OR > >>>>>>>>> 2)define our own content in the metadata XML which can take > >>>>>>>> values as > >>>>>>>>> "audio" / "main video" / "presentation video" / "current > >>>>>>>> speaker video" > >>>>>>>>> as suggested by John. > >>>>>>>> > >>>>>>>> Well... > >>>>>>>> > >>>>>>>> ISTM that if there is already an a=3Dcontent in the CS SDP, > >>>>>>>> then we would > >>>>>>>> want to report that in the metadata. > >>>>>>>> > >>>>>>>> If there is a pair (one from offer, one from answer, same > >>>>>>>> m-line offset) > >>>>>>>> and there is *not* an a=3Dcontent that pairs them, then we > >>>>>>>> would want to > >>>>>>>> report it anyway. > >>>>>>>> > >>>>>>>> But if we do that we have a problem with names and conflicts. > >>>>>> rfc4796 > >>>>>>>> doesn't define a lot of names, nor does it say whether > >>>>>> corresponding > >>>>>>>> streams in offer& answer must have the same names. > >>>>>>>> > >>>>>>>> So I think we have something similar but not quite the same, > >>>>>>>> and we need > >>>>>>>> to define something new. It must permit identifying streams > >>>>>>>> even though > >>>>>>>> we know nothing of their purpose. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Paul > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> siprec mailing list > >>>>>>> siprec@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>> > >>> > > > = From partr@cisco.com Wed Jun 15 02:19:51 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911A821F8450 for ; Wed, 15 Jun 2011 02:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.759 X-Spam-Level: X-Spam-Status: No, score=-9.759 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zgp2gW4nzc1n for ; Wed, 15 Jun 2011 02:19:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 567C51F0C66 for ; Wed, 15 Jun 2011 02:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=28360; q=dns/txt; s=iport; t=1308129588; x=1309339188; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=onEPwDdcc4HiEiJvRUYEMhTQuc8lRozwPNW7Inq4/cQ=; b=U3mT+O1bSHTOOQVIzwm3uN9zfFk/UABbCmOUkb/e+KVDVRzf0xie0CNB ixINGOTFa5N2qxRiUloCG6XImXA4E/Bndq7X6iE3PGSabd2hEVj6u0/K0 Zrnq3S2N4azdeqNqRImdmg5YHI+GrcVwmYrS6eXfAJsOjD7py0m5nsOYI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4BAN94+E1Io8UQ/2dsb2JhbABSl0uPBneIc6BHnkKGJgSHFo8cixQ X-IronPort-AV: E=Sophos;i="4.65,369,1304294400"; d="scan'208";a="94045713" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2011 09:19:38 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5F9JcGg005665; Wed, 15 Jun 2011 09:19:38 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 14:49:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jun 2011 14:49:37 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] extensionData in XML Thread-Index: AcwkU4vxkcoCYMQgTLePgkN1FWnjGwCU0UzgASV04yA= References: <4D9CDFC0.9070300@cisco.com><48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com><07465C1D981ABC41A344374066AE1A2C38AC31EB52@TLVMBX01.nice.com><4DECD435.9050306@cisco.com><948BAC33-911A-426F-8E20-AA15F2DE8AC0@neustar.biz><4DECDB90.5080704@cisco.com><08D51778-55E4-44D6-87E1-45DE2FA23725@neustar.biz><4DECDFBE.9020000@cisco.com> From: "Parthasarathi R (partr)" To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "Rosen, Brian" X-OriginalArrivalTime: 15 Jun 2011 09:19:37.0740 (UTC) FILETIME=[594204C0:01CC2B3D] Cc: siprec@ietf.org, "Peter Saint-Andre \(psaintan\)" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 09:19:51 -0000 Hi all, As there is no clear consensus on any approach, I'll continue to make the next revision by keeping extensiondata as an open item with the current text. Let us discuss during the coming interim meeting for the closure of this open item. Also, I'm updating extensiondata XML schema definition as per earlier Peter comment. Thanks Partha=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Thursday, June 09, 2011 7:13 PM To: Paul Kyzivat (pkyzivat); Rosen, Brian Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) Subject: Re: [siprec] extensionData in XML Brian, Please read inline. Thanks Partha=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Monday, June 06, 2011 7:40 PM To: Rosen, Brian Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) Subject: Re: [siprec] extensionData in XML On 6/6/2011 9:57 AM, Rosen, Brian wrote: > If the rule is "no change if not mentioned" for partial updates, then that would be the same here, right? That's always how partial updates work. =20 Even the current mechanism in metadata format draft is same as you expect which uses URN UUID. Here, extensiondata is considered as separate element which has the property of "no change if not mentioned". The minor optimization is possible to achieve by using xml:id as mentioned in the below mail and the minor limitation in the optimization is that xml:id scope MUST be span across single CSG in different CS in the model.=20 Also, any partial update mechanism of an XML element requires some sort of unique id. Please look into RFC 5261 for x-path based partial update which is more complex compare to the current mechanism in the draft. But the issue raised is to optimize in a way that no unique id is required to track this extension data element. So, we proposed extensiondata without any unique-id which has Paul mentioned caveats. Why can't we define extensions the same way, even if their are multiple of them?=20 The current proposal is inline with your expectation If you need to remove something, then you have to define semantics for that (like assign a null value). Agreed, the authors will come up "null" value in case we get the consensus for the current mechanism in the format draft. =20 Thanks Partha =20 Anything is possible - all it requires is the right definitions. :-) Each approach has its own consequences. The consequences I mentioned are for the current approach as it has been conceived to date. What you suggest is possible, but then it would require a syntax to distinguish between adding/replacing/removing a sub-element. (Or maybe just replacing/removing.) I'll let Partha/Ram comment on that, since they are defining the format. Thanks, Paul > Brian > On Jun 6, 2011, at 9:52 AM, Paul Kyzivat wrote: > >> Brian, >> >> Yeah, this isn't about xml itself, its about how we are using it. >> This is the approach taken for all the data in updates to elements. >> I guess we could define this as a one-off, or else we could define it as a sub-element by sub-element property. But that would seem to be confusing. Also, if you did this, then it gets hard to do the converse if you do want to remove the extension data for the remainder of a session. >> >> Thanks, >> Paul >> >> On 6/6/2011 9:31 AM, Rosen, Brian wrote: >>> I don't understand this. >>> >>> We can define it that way, but AFAIK, there isn't anything in XML standards that would force that to be true. >>> >>> An extension point like this just allows you to add some new stuff, defined in a new namespace. All it really does is allow a way for an older implementation to ignore what is in there if it doesn't understand it. >>> >>> Brian >>> >>> On Jun 6, 2011, at 9:20 AM, Paul Kyzivat wrote: >>> >>>> I'd like to point out an implication of this approach: >>>> >>>> When you send an update to an entity (in the example its a session) >>>> and include extension data, that extension data applies to the=20 >>>> session from that time forward until changed. >>>> >>>> If you later send another update to the same entity, regardless of=20 >>>> your reason for sending that update, if you fail to include the=20 >>>> extension data again you are saying that the extension data no=20 >>>> longer applies to the session. If you want it to continue to apply=20 >>>> you must transmit it again. That of course means you must remember=20 >>>> what extension data you previously sent, so that you *can* send it again. >>>> >>>> That may be fine. I just don't want people saying they like this=20 >>>> approach without having considered the implications. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 6/6/2011 4:19 AM, Leon Portman wrote: >>>>> I am ok with the proposal. Looking good >>>>> >>>>> Leon >>>>> >>>>> -----Original Message----- >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>> Sent: Saturday, June 04, 2011 3:54 AM >>>>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor=20 >>>>> (krehor); Rosen, Brian; HKaplan@acmepacket.com >>>>> Cc: siprec@ietf.org; Peter Saint-Andre (psaintan) >>>>> Subject: RE: [siprec] extensionData in XML >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> Based on the discussion in last interim meeting and mail thread discussion on http://www.ietf.org/mail-archive/web/siprec/current/msg01749.html and below mail thread, I have not seen anybody looking for separate extensiondata metadata XML tag. So, the authors of the draft plans to revise the next revision with "Extensiondata as an extension within metadata block" and example is as follows: >>>>> >>>>> >>>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> >>>>> In case anybody has difference of opinion, Please let us know by coming Thursday which helps us to update the next revision. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>>>> Behalf Of Parthasarathi R (partr) >>>>> Sent: Tuesday, April 19, 2011 4:01 PM >>>>> To: Dan Burnett; Paul Kyzivat (pkyzivat); Leon Portman; Ken Rehor >>>>> (krehor) >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> Dan& all, >>>>> >>>>> Sorry for the late reply. Thanks for sharing your XML experience. >>>>> tag is provided as extensions to SIPREC metadata. The current approach allows to ignore the extension-data in case SRS does not understand. >>>>> >>>>> I have added few extensiondata as a note of this mail which were=20 >>>>> discussed during earlier SIPREC interim meeting. The open question >>>>> here is whether the extension-data has to be passed every time=20 >>>>> (during >>>>> partial-update) within metadata XML tag (participant, session) update or it is enough to send only when extension-data changes. Partial update of any specific XML elements needs unique id. RFC 5261 recommends to use xml:id or type-id as unique attribute. >>>>> >>>>> The following example illustrate three different mechanism for >>>>> extensiondata: >>>>> >>>>> Extensiondata as separate metadata block: (Current format in the=20 >>>>> draft - works for partial update, URN UUID is used in all metadata >>>>> block as of >>>>> now) >>>>> >>>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>> id=3D"urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" >>>>> = parent=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> Extensiondata as separate metadata block using xml:id:(Id reduction) >>>>> >>>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>> = parent=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> Extensiondata as an extension within metadata block: (Ignore the=20 >>>>> attribute but needs to be passed in each partial updated) >>>>> Example: >>>>> >>>> group=3D"urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" /> >>>>> >>>>> >>>>> sip:alice@cisco.com >>>>> >>>>> >>>>> >>>>> >>>>> Please let me know which best suites SIPREC metadata. Including Leon& Ken explicitly because they provides lot of Extension data attributes during the discussion of metadata model. >>>>> >>>>> I'm fine with any of the above approach. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> Note: >>>>> End point information: ip/port, device id (MAC address), DN (used for the call, in case of multiline). >>>>> Device type: external, station, IVR, routing point, QUEUE,=20 >>>>> Gateway, MCU, Operator, etc Participant Role: caller, called,=20 >>>>> added, last_redirecting, redirecting, conferencing, queing,=20 >>>>> redirected AgentId, OSLogin >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>>>> Behalf Of Dan Burnett >>>>> Sent: Monday, April 11, 2011 9:15 PM >>>>> To: Paul Kyzivat (pkyzivat) >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> As someone who works quite a bit with XML, I'll point out that there is an important distinction between data for extensibility and expected application-specific data. As an example of the latter, EMMA [1] is an XML format for representing the input of a user (human being, commonly) to an automated system, by speech, gesture, pen, etc. Since the way an input is interpreted is dependent upon its intended use, there was a need for a designated application-specific section to represent the semantics (meaning) of the input. >>>>> To make it easier for machine consumers of this format that may be seeking the semantics, there is a designated element "interpretation" >>>>> that holds this information. The contents of this element are arbitrary XML in an application-specific XML namespace. >>>>> >>>>> On the other hand, every XML specification I've worked on in W3C=20 >>>>> has needed a way for implementers to innovate via extensions. >>>>> Traditionally this is handled via custom elements and attributes in an implementer-specific namespace to avoid name collision with the standard elements and attributes. Since these true innovation extensions can occur anywhere, there is no specific XML element established in most specifications for "extensions". Instead, the specification defines the expected behavior of a conformant processor upon encountering elements and attributes outside of the specification's standard namespace. The nice thing about this approach is that allows for innovation in a way that does not cause name collision but which could become part of the standard in the future (and be moved into the standard's namespace). >>>>> For the specifications I worked on, we always required that a conformant processor had to do the behavior defined in the specification when it received a conformant document but that the behavior of the processor when it encountered non-standard elements and attributes was at its own discretion -- it could process the attributes, ignore them, or report an error, as it deemed appropriate. >>>>> >>>>> >>>>> So the real question for us here is whether these extension=20 >>>>> elements are >>>>> *extensions* (which do not require a custom element/location) or *expected application-specific information* (which can benefit from custom elements and prescribed locations in the XML tree). >>>>> >>>>> -- dan >>>>> >>>>> [1] http://www.w3.org/TR/emma/ >>>>> >>>>> On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: >>>>> >>>>>> >>>>>> >>>>>> On 4/6/2011 8:57 AM, Elwell, John wrote: >>>>>>> Yes, I would be keen to hear Peter's or other opinions, but one=20 >>>>>>> other >>>>> >>>>>>> point. One of the properties of XML is that it is human- readable. >>>>>>> Having extension data as a child element of the element=20 >>>>>>> representing the object to which it applies seems, in my=20 >>>>>>> opinion, to make it more readable. Having extension data as a=20 >>>>>>> separate element, with a link to >>>>> >>>>>>> the element to which it applies, seems hard for a human reader,=20 >>>>>>> particularly if the link is a long, random string. >>>>>> >>>>>> IMO human readability of the xml is a secondary/tertiary concern. >>>>>> (SIP is in theory readable, but real sip on the wire tends to be=20 >>>>>> difficult to read due to need to match up non-ergonomic numeric=20 >>>>>> addresses and tags from one message to another.) >>>>>> >>>>>> I'm inclined to agree it would be better to embed extensions into >>>>>> the basic elements, but not primarily due to readability. IMO=20 >>>>>> extensions should function as much like the predefined parts as possible. >>>>>> (Today's extension may become common usage tomorrow.) >>>>>> >>>>>> I just don't know enough xml to define this "correctly". >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>>> Sent: 06 April 2011 10:16 >>>>>>>> To: Elwell, John; Hadriel Kaplan >>>>>>>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre >>>>>>>> (psaintan) >>>>>>>> Subject: RE: [siprec] extensionData in XML >>>>>>>> >>>>>>>> John, >>>>>>>> >>>>>>>> Please read inline >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>>> Sent: Wednesday, April 06, 2011 2:02 PM >>>>>>>> To: Parthasarathi R (partr); Hadriel Kaplan >>>>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>>>> Subject: RE: [siprec] extensionData in XML >>>>>>>> >>>>>>>> I already posted on this topic on the other thread. Partha=20 >>>>>>>> states below an additional motivation for handling extension=20 >>>>>>>> data in the way specified in the current I-D. My counter=20 >>>>>>>> argument is that anyone >>>>> >>>>>>>> specifying particular extension data could specify the expected >>>>>>>> behaviour when extension data is present in an object and then=20 >>>>>>>> absent when that object is updated. For some types of metadata=20 >>>>>>>> it could be that absence means it no longer applies, and for=20 >>>>>>>> other types of metadata it could be that absence means it has not changed. >>>>>>>> >>>>>>>> Currently, metadata format draft XML element is written >>>>>>>> with the basics that "it is no longer applies" in case specific >>>>>>>> element is absent in the update. The question is how the=20 >>>>>>>> information >>>>> >>>>>>>> of extensiondata absence means "it is no longer applies" or "it >>>>>>>> has not changed" has to be passed between SRC and SRS. Here,=20 >>>>>>>> there is a need of common understanding between SRC and SRS or=20 >>>>>>>> else the information will be misunderstand even though both=20 >>>>>>>> parties understand the specific extension. >>>>>>>> >>>>>>>> The current extensiondata is taken the route of all other=20 >>>>>>>> metadata block XML element definition. There may be better way=20 >>>>>>>> to represent in extensiondata XML element apart from creating=20 >>>>>>>> new metadata block with URN UUID. I'm including Peter for his=20 >>>>>>>> advise on XML front. >>>>>>>> >>>>>>>> The latter approach would avoid the need for repeating large=20 >>>>>>>> quantities of metadata each time there is a minor change to an=20 >>>>>>>> object. >>>>>>>> >>>>>>>> John (as individual) >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>>>>>>> R (partr) >>>>>>>>> Sent: 03 April 2011 19:46 >>>>>>>>> To: Hadriel Kaplan >>>>>>>>> Cc: siprec@ietf.org; Jain, Rajnish >>>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>>> >>>>>>>>> Hadriel, >>>>>>>>> >>>>>>>>> I guess we have common understaning to the extend that the >>>>>>>> intention >>>>>>>>> is to send some extensiondata (Unknown) attribute by SRC >>>>>>>> which may or >>>>>>>>> may not understand by SRS and also for the usage of xs:any as=20 >>>>>>>>> the solution. Few stuff are missing in yours proposal w.r.t >>>>>>>> partial data >>>>>>>>> passing of extensiondata: >>>>>>>>> >>>>>>>>> The question is whether there is a need to pass the extension=20 >>>>>>>>> data during every time the corresponding metadata block is=20 >>>>>>>>> passed or updated. For example, CS metadata block sends=20 >>>>>>>>> extension >>>>>>>> data specific >>>>>>>>> to call center data like Agent is remote or local, agent or >>>>>>>> customer >>>>>>>>> initiated call (direction) during the CS block creation >>>>>>>> (INVITE) and >>>>>>>>> these constant information in extensiondata is not required to >>>>>>>>> be passed in each update of CS metadata like adding video >>>>>>>> stream in the >>>>>>>>> mid-session. >>>>>>>>> >>>>>>>>> The current model allows to pass extensiondata only during >>>>>>>> the initial >>>>>>>> >>>>>>>>> CS block creation and there is no need to update or resend=20 >>>>>>>>> while CS >>>>> >>>>>>>>> block is getting updated with other CS information. IMO, >>>>>>>> The current >>>>>>>>> extensiondata mechanism is required as SIPREC puts lot of >>>>>>>> call centre >>>>>>>>> specific attributes proposed during metadata model draft=20 >>>>>>>>> review as outside the scope of SIPREC and most of the=20 >>>>>>>>> attributes >>>>>>>> mentioned are >>>>>>>>> constant within the scope of session. >>>>>>>>> >>>>>>>>> Also, it is possible to pass update only extension data within >>>>>>>>> RS session without impacting parent element. Please let me >>>>>>>> know your and >>>>>>>>> others opinion whethter it is fine to continue with the=20 >>>>>>>>> current extension-data element or to move xs:any element to=20 >>>>>>>>> each of the metadata block. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>> ________________________________ >>>>>>>>> >>>>>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>>>>>> Sent: Sat 4/2/2011 6:19 PM >>>>>>>>> To: Parthasarathi R (partr) >>>>>>>>> Cc: Jain, Rajnish; siprec@ietf.org >>>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Partha, >>>>>>>>> I think you're missing my point (or I'm missing yours) - you=20 >>>>>>>>> can do >>>>> >>>>>>>>> all of that without specifying an "extensionData" XML element. >>>>>>>>> Unknown XML elements are simply ignored by the other side, so=20 >>>>>>>>> Cisco >>>>> >>>>>>>>> can add a "ciscoPrivateData" XML element wherever it wants >>>>>>>> and send it >>>>>>>> >>>>>>>>> to an Acme; and that private element will be ignored by Acme=20 >>>>>>>>> while everything else will continue to work. Which I think is >>>>>>>> the behavior >>>>>>>>> you want, right? >>>>>>>>> >>>>>>>>> -hadriel >>>>>>>>> >>>>>>>>> >>>>>>>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>>>>>>> >>>>>>>>>> Hadriel/Raj, >>>>>>>>>> >>>>>>>>>> Extensiondata XML is provided as per Metadata model >>>>>>>>> extensiondata block. >>>>>>>>>> During the initial discussion of metadata model draft, we >>>>>>>>> realized that >>>>>>>>>> lot of attributes specified for recording are call center >>>>>>>>> specific or >>>>>>>>>> specific domain related and it is outside the scope of IETF >>>>>>>>> SIPREC but >>>>>>>>>> it is required for those specific solution to work. >>>>>>>>> Extensiondata XML >>>>>>>>>> element helps to meet those requirement. >>>>>>>>>> >>>>>>>>>> Extensiondata is provided with URN UUID to pass or not pass=20 >>>>>>>>>> independently in partial data. But it is open item whether >>>>>>>>> extensiondata >>>>>>>>>> has to be within specific metadatablock or not. >>>>>>>>>> >>>>>>>>>> Please read inline for more comments. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Partha >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>>>>>>> Of Jain, Rajnish >>>>>>>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>>>>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>>>>>>> Subject: Re: [siprec] extensionData in XML >>>>>>>>>> >>>>>>>>>> There may be such motivation from how the CSTA standards >>>>>>>>> are specified. >>>>>>>>>> They have an element called privateData for each message. It=20 >>>>>>>>>> is a placeholder for any non-standardized extensions. This=20 >>>>>>>>>> could >>>>>>>>> be legacy >>>>>>>>>> and may not mean much for the modern text based protocols. >>>>>>>>>> >>>>>>>>>> I really didn't get the reason why is it not >>>>>>>>> require for modern >>>>>>>>>> text based protocols. This is more like generic param in >>>>>>>>> SIP or xs:any >>>>>>>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That said, I think you're right (this generally applies >>>>>>>> to any text >>>>>>>>>> based protocols and is the fundamental basis for=20 >>>>>>>>>> forward/backward compatibility in such protocols). >>>>>>>>>> >>>>>>>>>> Raj >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----------------------------------------------------- >>>>>>>>>> Please consider the environment before printing this email. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>>> Behalf Of Hadriel Kaplan >>>>>>>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>>>>>>> To: siprec@ietf.org >>>>>>>>>>> Subject: [siprec] extensionData in XML >>>>>>>>>>> >>>>>>>>>>> Howdy, >>>>>>>>>>> With regards to the extensionData concept and XML, I have >>>>>>>>> a few basic >>>>>>>>>>> questions. I am by no means an XML expert so it could >>>>>>>>> just be my lack >>>>>>>>>> >>>>>>>>>>> of knowledge which makes me confused. If so, just tell >>>>>>>> me to RTFM. >>>>>>>>>>> >>>>>>>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>>>>>>> A recording metadata object contains additional data not >>>>>>>>> specified >>>>>>>>>>> as >>>>>>>>>>> part of siprec. This is intended to accommodate >>>>>>>> future standards >>>>>>>>>>> track extensions, as well as vendor and user specific >>>>>>>> extensions. >>>>>>>>>>> The mechanism MUST provide a means of unambiguously >>>>>>>>> distinguishing >>>>>>>>>>> such extension data. >>>>>>>>>>> >>>>>>>>>>> What confuses me is I didn't think XML had to do such >>>>>>>>> machinations to >>>>>>>>>>> accommodate this need. I thought we could just specify >>>>>>>> in our RFCs >>>>>>>> >>>>>>>>>>> that unknown XML elements and attributes MUST be >>>>>>>> ignored, so that >>>>>>>>>>> future RFCs could add them without having to leave >>>>>>>>> specific "blob" XML >>>>>>>>>> >>>>>>>>>>> elements to carry such data. Or at least that's what >>>>>>>> we've done so >>>>>>>> >>>>>>>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>>>>>>> namespace model that could be used to disambiguate=20 >>>>>>>>>>> proprietary elements from standard ones. If both of those=20 >>>>>>>>>>> theories >>>>>>>>> are correct, >>>>>>>>>>> why do we need to define an extensionData element? >>>>>>>>>>> >>>>>>>>>>> -hadriel >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>> >>>>>>>>>> DISCLAIMER: This e-mail may contain information that is >>>>>>>>> confidential, >>>>>>>>>> privileged or otherwise protected from disclosure. If you >>>>>>>> are not an >>>>>>>> >>>>>>>>>> intended recipient of this e-mail, do not duplicate or >>>>>>>>> redistribute it >>>>>>>>>> by any means. Please delete it and any attachments and >>>>>>>>> notify the sender >>>>>>>>>> that you have received it in error. Unintended recipients >>>>>>>>> are prohibited >>>>>>>>>> from taking action on the basis of information in this >>>>>>>> e-mail.E-mail >>>>>>>> >>>>>>>>>> messages may contain computer viruses or other defects, >>>>>>>> may not be >>>>>>>>>> accurately replicated on other systems, or may be >>>>>>>>> intercepted, deleted >>>>>>>>>> or interfered with without the knowledge of the sender or >>>>>>>>> the intended >>>>>>>>>> recipient. If you are not comfortable with the risks >>>>>>>> associated with >>>>>>>> >>>>>>>>>> e-mail messages, you may decide not to use e-mail to >>>>>>>>> communicate with >>>>>>>>>> IPC. IPC reserves the right, to the extent and under >>>>>>>> circumstances >>>>>>>>>> permitted by applicable law, to retain, monitor and >>>>>>>> intercept e-mail >>>>>>>> >>>>>>>>>> messages to and from its systems. >>>>>>>>>> _______________________________________________ >>>>>>>>>> siprec mailing list >>>>>>>>>> siprec@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>> >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Wed Jun 15 06:55:17 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D7E21F8577 for ; Wed, 15 Jun 2011 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPHN9xhw8X24 for ; Wed, 15 Jun 2011 06:55:16 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 5DB7B21F857A for ; Wed, 15 Jun 2011 06:55:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1308146113!9295109!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 15201 invoked from network); 15 Jun 2011 13:55:13 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-11.tower-182.messagelabs.com with SMTP; 15 Jun 2011 13:55:13 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 98CA723F03E2; Wed, 15 Jun 2011 15:55:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 15 Jun 2011 15:55:13 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Wed, 15 Jun 2011 15:55:12 +0200 Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwqqBWQRa5aTOhOTFePwAaN63zg8gAuypUw Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> <4DF77EB5.9060009@cisco.com> In-Reply-To: <4DF77EB5.9060009@cisco.com> 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: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:55:17 -0000 Paul, But if the two SRCs are somehow cooperating to the extent that they can sha= re the same global ID for the CS, could they not also share the same local = ID for the MS? Why does it need to be a global ID? John > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 14 June 2011 16:31 > To: siprec@ietf.org > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > John, > > Consider another case: two SRCs in the same CS (perhaps one at each > "end".) They are both sending metadata about the same CS and MSs. > > Suppose they want to cooperate with each other. They have the > potential > to use the same ID to reference the CS, so that the SRS will > know they > are talking about the same one. But with RS-specific MS ids > there is no > way for them to indicate that they are talking about the same > MSs. With > global MS ids, they could accomplish this. > > Thanks, > Paul > > On 6/14/2011 11:03 AM, Elwell, John wrote: > > Partha, > > > > Thanks for the examples. The character count for the delta > is about 2500 when a new MS is created compared to about 2100 > when the MS is retained. This seems to be in line with my > previous gut feeling. > > > > Concerning the need for "SRS implementers to guess how old > MS and new MS are related", I don't think they are related, > except by having other things in common like a common > participant or a common CSG. > > > > John (as individual) > > > >> -----Original Message----- > >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >> Sent: 14 June 2011 13:15 > >> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; Ram > >> Mohan R (rmohanr); siprec@ietf.org > >> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >> > >> Hi all, > >> > >> Sorry for the delay. Just to double confirm everybody > >> understanding with > >> SIP message example, I added the example with creating new MS and > >> reusing the same MS as an attachment with this mail. > >> > >> Please note that creating new MS is putting SRS > implementers to guess > >> how old MS and new MS are related. Also, few scenario like > Even after > >> looking into the example, the intention is to use local > variable, I'm > >> ok. > >> > >> Thanks > >> Partha > >> > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) > >> Sent: Friday, June 10, 2011 10:57 PM > >> To: Leon Portman; Elwell, John; Parthasarathi R (partr); > Ram Mohan R > >> (rmohanr); siprec@ietf.org > >> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >> > >> Please excuse the delay. I am catching up after having been away on > >> vacation. > >> In light of this better understanding of the use case, I also > >> prefer the > >> option favored by John and Leon to model as a separate MS. In this > >> specific case, I would expect the properties of the MS to > >> change when A > >> is transferred to C, so I expect the overhead in creating > a new MS vs. > >> reusing the same MS to be minimal and not worth the added > >> complexity to > >> the model. > >> > >> Cheers, > >> Charles > >> > >>> -----Original Message----- > >>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >>> Sent: Tuesday, May 31, 2011 6:19 AM > >>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel > (eckelcu); > >>> Ram Mohan R (rmohanr); siprec@ietf.org > >>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >>> > >>> Hello > >>> > >>> I also having a problem even without a quantification of number of > >>> update messages that CS MS is remains same between > >> different CS. So I > >> do prefer to keep it simple and keep it per CS. > >>> > >>> Leon > >>> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Elwell, John > >>> Sent: Friday, May 27, 2011 12:26 PM > >>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R > >>> (rmohanr); siprec@ietf.org > >>> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>> Sent: 26 May 2011 15:55 > >>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > >>>> siprec@ietf.org > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >>>> > >>>> John, > >>>> > >>>> The callflow mentioned by me is the basic primitive in the call > >>>> center scenario wherein customer (participant) is same throughout > >>>> the session and agents are changed using transfer service > >> and B2BUA > >> acts as SRC. > >>>> IMO, it is one of key requirement to be considered in case we > >>>> support for partial-update. > >>> [JRE] Agreed the Participant remains the same, but we are > discussing > >> MS. > >>> > >>>> This may not be the only callflow where MS partial-update is > >>>> required in this fashion. During -00 format draft, I thought that > >>>> the partial-update is not required but lot of folks raised the > >>>> concern that partial update is important. Current, -01 > >> format draft > >>>> is designed to support partial-update. Now, You propose > >> to restrict > >>>> MS partial-update across CS. IMO, it is a not good idea > >> to restrict > >>>> in the protocol level. Anyway, I think that we need > >> others opinion > >>>> before conclude here. > >>> [JRE] I am not opposed to partial update, but I would > like to avoid > >>> distorting the model just to gain some efficiency improvements in > >>> certain cases. To me it is not intuitive that a MS on one > >> CS and an MS > >> > >>> on another CS are the same object, just because one of the > >>> Participants is common to both CSs. In the transfer-between-agents > >> example, although one of the Participants is common to the > >> two CSs, this > >> is not true for the other Participants. > >>> > >>> Let's try to quantify the efficiency improvement. In the blind > >>> transfer case, the partial updates would at least have to include: > >>> - the removal of P1 from CS1 (where P1 is the first agent > >> and CS1 is > >>> the first CS); > >>> - the removal of P2 from CS1 (where P2 is the transferred > >>> participant); > >>> - the termination of CS1; > >>> - the removal of CS1 from CSG1; > >>> - the creation of CS2 (the CS that results from transfer); > >>> - the addition to of CS2 to CSG1; > >>> - the addition of P2 to CSG1; > >>> - the addition of P3 to CS2 (where P3 is the second agent); > >>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); > >>> - the removal of P2 as a recipient of MS1; > >>> - the termination of MS1; > >>> - the creation of MS3; > >>> - the addition of P3 as a sender of MS3; > >>> - the addition of P2 as a recipient of MS3. > >>> > >>> So all we are arguing about is whether we also include in > >> the partial > >>> updates EITHER (this I think is your proposal): > >>> - the removal of P1 as a recipient of MS2; > >>> - the addition of P3 as a recipient of MS2; > >>> > >>> OR > >>> - the removal of P1 as recipient of MS2; > >>> - the removal of P2 as a sender of MS2; > >>> - the termination MS2; > >>> - the creation of MS4; > >>> - the addition of P3 as a recipient of MS4; > >>> - the addition of P2 as a sender of MS4. > >>> > >>> So with the first option the total number of deltas is 14+2=3D16. > >>> For the second option the total number of deltas is 14+6=3D20. > >>> > >>> Some of the details might be wrong, but I hope you can see > >> the point I > >> > >>> am getting at. Looked at this way, the efficiency saving by > >> recycling > >>> MS2 for use in consecutive CSs is relatively small. Or > perhaps your > >>> intention is also to recycle MS1 (this time, the recipient > >> remaining > >>> the same but the sender changing). That would reduce the number of > >>> deltas slightly further. The impact on XML size might not > >> be quite in > >>> proportion to the reduction in the number of deltas, since by > >> recycling MS2 it has to have a global identifier, not an identifier > >> local to a CS. Or perhaps it could have an identifier > local to a CSG. > >>> > >>> I also see that with your proposal it doesn't force the MS to be > >>> recycled - an SRC could still choose to model it as separate MSs. > >>> However, in that case it would still need to use global > identifiers > >> for MSs. > >>> > >>> I am not necessarily opposed to your proposal for recycling > >> MS objects > >> > >>> outside the context of a single CS - I can see advantages and > >>> disadvantages. I just want to make sure the group makes > an informed > >> decision. > >>> > >>> John (as individual) > >>> > >>> > >>>> > >>>> Enhancing label attribute across the multiple SIP message to tie > >>>> between Metadata XML and RS SDP m-line is possible. SRC has to > >>>> ensure that label for the given RS SDP m-line should have > >> same label > >> > >>>> throughout single CSG even though it span across multiple CS and > >>>> multiple RS. Even then, it will not meet partial-update > >> requirement > >>>> as mentioned below in this mail thread. At this moment, > >> I'm favoring > >> > >>>> URN UUID and not label attribute enhancement. > >>>> > >>>> Please read inline > >>>> > >>>> Thanks > >>>> Partha > >>>> > >>>> -----Original Message----- > >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>> Sent: Wednesday, May 25, 2011 7:17 PM > >>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R > >>>> (rmohanr); siprec@ietf.org > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>>> Sent: 25 May 2011 08:48 > >>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > >> (rmohanr); > >>>>> siprec@ietf.org > >>>>> Subject: RE: [siprec] Can an MS object span several CSs > >> in a CSG? > >>>>> > >>>>> John, > >>>>> > >>>>> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> =3D > >>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA > >>>>> converts REFER > >>>>> > >>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA > >>>>> updates RS > >>>>>> with CS2, Participant1 as A& participant2 as C, > >> MS1(A's media > >>>>>> stream), MS2(C's media stream). There is no update on RS1, > >>>>> CSG1, MS1, > >>>>>> MS2. MS2 will become MS2 with the new association and > >> in terms > >>>>>> of format, it will associate with tag > >>>>> [JRE] What harm is done (what do we lose) if, following > >>>> transfer, A's > >>>>> media stream is called MS3 and C's media stream is called MS4? > >>>>> > >>>> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>> =3D > >>>>> To indicate MS1 as MS3, MS1 media block has to be > >>>> stopped in > >>>>> the partial-update and start MS3 separate which is not > >> required in > >> > >>>>> case there is a means to have common MS1. > >>>> [JRE] It seems this distorts the model in order to give > >> some minor > >>>> efficiency improvement during metadata updates. I doubt that this > >>>> alone is sufficient justification for having the MS > >> persist from one > >> > >>>> CS to another CS. > >>>> > >>>>> > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > >>>>> MS3 can reference the same SDP m-line (through a=3Dlabel) as MS1, > >>>>> and likewise MS4 could reference the same SDP m-line as > >> MS2, if we > >> > >>>>> are concerned about recycling media descriptions in RS SDP. > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> As you mentioned, we will lose recycling of media > >>>> description > >>>>> in RS SDP without common value in media stream object for this > >>>>> scenario. > >>>> [JRE] I don't understand your point. With my proposal we > >> can still > >>>> recycle RS SDP m-lines. > >>>> > >>>> Agreed that Recycle is possible with your proposal. > >>>> I indicated > >>>> the need for unique-id in this requirement > >>>> > >>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label > >>>> attribute > >>>>> scope is within single SIP message and not required to > >> be unique > >>>>> in all SIP messages of a given dialog. > >>>> [JRE] But I think we could nail that down as a requirement of the > >>>> SIPREC protocol. > >>>> > >>>> John (as individual) > >>>> > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>> John (as individual) > >>>>> > >>>>>> > >>>>>> Thanks > >>>>>> Partha > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Charles Eckel (eckelcu) > >>>>>> Sent: Wednesday, May 25, 2011 1:39 AM > >>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); > >>>> 'Elwell, John'; > >>>>>> 'siprec@ietf.org' > >>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a > >> CSG? > >>>>>> > >>>>>> Hi Ram, > >>>>>> > >>>>>> I think that is many cases, they will be treated as > >> separate MSs > >> > >>>>>> due to the complexities you mention. However, I am trying to > >>>> understand if > >>>>>> Partha feels allowing an SRC to treat them as a single MS is > >>>>>> still required. If not, then what is a use case? A concrete > >>>>>> example would help me, and potentially others, to better > >>>>>> understand the > >>>>> motivation behind > >>>>>> Partha's requirement for modeling media from multiple CSs > >>>>> as a single > >>>>>> MS. > >>>>>> > >>>>>> Cheers, > >>>>>> Charles > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Ram Mohan R (rmohanr) > >>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM > >>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); > >>>>> Elwell, John; > >>>>>>> siprec@ietf.org > >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs > >>>> in a CSG? > >>>>>>> > >>>>>>> Charles, > >>>>>>> > >>>>>>> I did bring about this specific usecase of MMOH/MOH > >>>> stream being > >>>>>>> played to different participants earlier and suggested that > >>>>>> they have > >>>>>>> to treated as a same MS across multiple CSs > >>>> (potentially recorded > >>>>>> using multiple RSs). > >>>>>>> Refer > >>>>>>> > >>>> http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > >>>>>>> > >>>>>>> We had several discussions on it and it and several > >>>> folks were in > >>>>>>> favor of treating it as separate MS as there would be > >>>>>> complexity in DB > >>>>>> design. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Ram > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: siprec-bounces@ietf.org > >>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>> Behalf Of Charles Eckel (eckelcu) > >>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM > >>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > >>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > >>>>> in a CSG? > >>>>>>>> > >>>>>>>> Hi Partha, > >>>>>>>> > >>>>>>>> Is an example of this the same music on hold audio stream > >>>>>> existing > >>>>>>>> as the same MS within multiple CSs? If so, then I > >>>>> understand your > >>>>>>>> requirement to be that the SRC be able to > >> indicate multiple > >>>>>>>> instances of this audio stream within several CSs as > >>>>>> being the same > >>>>>>>> MS. Is that correct? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Charles > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: siprec-bounces@ietf.org > >>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>> Behalf Of Parthasarathi R (partr) > >>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM > >>>>>>>>> To: Elwell, John; siprec@ietf.org > >>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > >>>>>> in a CSG? > >>>>>>>>> > >>>>>>>>> John, > >>>>>>>>> > >>>>>>>>> I agree that it is not mandatory to consider recorded > >>>>>> stream of a > >>>>>>>>> specific participant in several CS within the same > >>>> CSG as one > >>>>>>>> recorded > >>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a > >>>>>> SRC in case > >>>>>>>>> it wishes to design in such a way. > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> Partha > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: siprec-bounces@ietf.org > >>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>> Behalf > >>>>>>>>> Of Elwell, John > >>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM > >>>>>>>>> To: siprec@ietf.org > >>>>>>>>> Subject: [siprec] Can an MS object span several CSs > >>>> in a CSG? > >>>>>>>>> > >>>>>>>>> We seem to have consensus that a Media Stream object > >>>>>> represents a > >>>>>>>>> recorded media stream, contributed to by one, > >>>> several or all > >>>>>>>>> Participants. However, Partha also wrote: > >>>>>>>>> > >>>>>>>>> "2) Each MS lifetime related to CSG because participant > >>>>>> may move > >>>>>>>>> from one CS to another CS within single CSG and also > >>>>>> CSG will span > >>>>>> > >>>>>>>>> across multiple RS." > >>>>>>>>> > >>>>>>>>> I am not sure we had resolved this during earlier > >>>>>> discussions on > >>>>>>>>> the scope of an MS object. Although the same > >>>> Participant can > >>>>>>>>> participate > >>>>>>>> in > >>>>>>>>> several CSs within the same CSG, I don't think the > >>>>>> recorded media > >>>>>>>>> streams need to be considered the same. Any other views? > >>>>>>>>> > >>>>>>>>> John (as individual) > >>>>>>>>> _______________________________________________ > >>>>>>>>> siprec mailing list > >>>>>>>>> siprec@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>>> _______________________________________________ > >>>>>>>>> siprec mailing list > >>>>>>>>> siprec@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>> _______________________________________________ > >>>>>>>> siprec mailing list > >>>>>>>> siprec@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>> > >>>>> > >>>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >> > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@cisco.com Wed Jun 15 07:42:44 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23F121F8553 for ; Wed, 15 Jun 2011 07:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.417 X-Spam-Level: X-Spam-Status: No, score=-110.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p4zXiEP98aC for ; Wed, 15 Jun 2011 07:42:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7116621F8547 for ; Wed, 15 Jun 2011 07:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=19642; q=dns/txt; s=iport; t=1308148962; x=1309358562; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fH4ZsNIjwTKNpwdERJD65QTjY0fnhKt2jxAHJqo6qOo=; b=MwKKuWqM/Xb8NR3YGb/J/0tvHEnhlViwpgk73BSNsHQoPvCEzUnX8Yr2 xYIAt7Xd/IUopHEpl1ctopd6BZtA3Erkt9Uk4+F/o+i77yzuA9bC2DsTs LIT0Bz+dtotzYxlu3OO1/5SbZ30bdnBnUniU4L1HD/Y0tr/NAwoMfk6f/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBABTE+E2Q/khN/2dsb2JhbABSl0uPBneIc6BDnkCGJgSRToRbizE X-IronPort-AV: E=Sophos;i="4.65,370,1304294400"; d="scan'208";a="94107769" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2011 14:42:41 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5FEgeh5025828; Wed, 15 Jun 2011 14:42:40 GMT Message-ID: <4DF8C4E0.8020409@cisco.com> Date: Wed, 15 Jun 2011 10:42:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Elwell, John" References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> <4DF77EB5.9060009@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:42:44 -0000 On 6/15/2011 9:55 AM, Elwell, John wrote: > Paul, > > But if the two SRCs are somehow cooperating to the extent that they can share the same global ID for the CS, could they not also share the same local ID for the MS? Why does it need to be a global ID? They could *know* each other's local id for the MS. They might even agree to use the *same* value for the local id. E.g. we have SRC#1 and SRC#2, each using 123 as the local id for the "same" stream. But to the SRS, there is one MS with id SRC#1:123, and another MS with SRC#2:123. It does not know they are the same. (That is the point of local scoping.) So even though the two SRCs know they are talking about the same MS they have no way to tell that to the SRS. Thanks, Paul > John > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 14 June 2011 16:31 >> To: siprec@ietf.org >> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >> >> John, >> >> Consider another case: two SRCs in the same CS (perhaps one at each >> "end".) They are both sending metadata about the same CS and MSs. >> >> Suppose they want to cooperate with each other. They have the >> potential >> to use the same ID to reference the CS, so that the SRS will >> know they >> are talking about the same one. But with RS-specific MS ids >> there is no >> way for them to indicate that they are talking about the same >> MSs. With >> global MS ids, they could accomplish this. >> >> Thanks, >> Paul >> >> On 6/14/2011 11:03 AM, Elwell, John wrote: >>> Partha, >>> >>> Thanks for the examples. The character count for the delta >> is about 2500 when a new MS is created compared to about 2100 >> when the MS is retained. This seems to be in line with my >> previous gut feeling. >>> >>> Concerning the need for "SRS implementers to guess how old >> MS and new MS are related", I don't think they are related, >> except by having other things in common like a common >> participant or a common CSG. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>> Sent: 14 June 2011 13:15 >>>> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; Ram >>>> Mohan R (rmohanr); siprec@ietf.org >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>> >>>> Hi all, >>>> >>>> Sorry for the delay. Just to double confirm everybody >>>> understanding with >>>> SIP message example, I added the example with creating new MS and >>>> reusing the same MS as an attachment with this mail. >>>> >>>> Please note that creating new MS is putting SRS >> implementers to guess >>>> how old MS and new MS are related. Also, few scenario like >> Even after >>>> looking into the example, the intention is to use local >> variable, I'm >>>> ok. >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) >>>> Sent: Friday, June 10, 2011 10:57 PM >>>> To: Leon Portman; Elwell, John; Parthasarathi R (partr); >> Ram Mohan R >>>> (rmohanr); siprec@ietf.org >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>> >>>> Please excuse the delay. I am catching up after having been away on >>>> vacation. >>>> In light of this better understanding of the use case, I also >>>> prefer the >>>> option favored by John and Leon to model as a separate MS. In this >>>> specific case, I would expect the properties of the MS to >>>> change when A >>>> is transferred to C, so I expect the overhead in creating >> a new MS vs. >>>> reusing the same MS to be minimal and not worth the added >>>> complexity to >>>> the model. >>>> >>>> Cheers, >>>> Charles >>>> >>>>> -----Original Message----- >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>> Sent: Tuesday, May 31, 2011 6:19 AM >>>>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel >> (eckelcu); >>>>> Ram Mohan R (rmohanr); siprec@ietf.org >>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>> >>>>> Hello >>>>> >>>>> I also having a problem even without a quantification of number of >>>>> update messages that CS MS is remains same between >>>> different CS. So I >>>> do prefer to keep it simple and keep it per CS. >>>>> >>>>> Leon >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Elwell, John >>>>> Sent: Friday, May 27, 2011 12:26 PM >>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R >>>>> (rmohanr); siprec@ietf.org >>>>> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>> Sent: 26 May 2011 15:55 >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); >>>>>> siprec@ietf.org >>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>>> >>>>>> John, >>>>>> >>>>>> The callflow mentioned by me is the basic primitive in the call >>>>>> center scenario wherein customer (participant) is same throughout >>>>>> the session and agents are changed using transfer service >>>> and B2BUA >>>> acts as SRC. >>>>>> IMO, it is one of key requirement to be considered in case we >>>>>> support for partial-update. >>>>> [JRE] Agreed the Participant remains the same, but we are >> discussing >>>> MS. >>>>> >>>>>> This may not be the only callflow where MS partial-update is >>>>>> required in this fashion. During -00 format draft, I thought that >>>>>> the partial-update is not required but lot of folks raised the >>>>>> concern that partial update is important. Current, -01 >>>> format draft >>>>>> is designed to support partial-update. Now, You propose >>>> to restrict >>>>>> MS partial-update across CS. IMO, it is a not good idea >>>> to restrict >>>>>> in the protocol level. Anyway, I think that we need >>>> others opinion >>>>>> before conclude here. >>>>> [JRE] I am not opposed to partial update, but I would >> like to avoid >>>>> distorting the model just to gain some efficiency improvements in >>>>> certain cases. To me it is not intuitive that a MS on one >>>> CS and an MS >>>> >>>>> on another CS are the same object, just because one of the >>>>> Participants is common to both CSs. In the transfer-between-agents >>>> example, although one of the Participants is common to the >>>> two CSs, this >>>> is not true for the other Participants. >>>>> >>>>> Let's try to quantify the efficiency improvement. In the blind >>>>> transfer case, the partial updates would at least have to include: >>>>> - the removal of P1 from CS1 (where P1 is the first agent >>>> and CS1 is >>>>> the first CS); >>>>> - the removal of P2 from CS1 (where P2 is the transferred >>>>> participant); >>>>> - the termination of CS1; >>>>> - the removal of CS1 from CSG1; >>>>> - the creation of CS2 (the CS that results from transfer); >>>>> - the addition to of CS2 to CSG1; >>>>> - the addition of P2 to CSG1; >>>>> - the addition of P3 to CS2 (where P3 is the second agent); >>>>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); >>>>> - the removal of P2 as a recipient of MS1; >>>>> - the termination of MS1; >>>>> - the creation of MS3; >>>>> - the addition of P3 as a sender of MS3; >>>>> - the addition of P2 as a recipient of MS3. >>>>> >>>>> So all we are arguing about is whether we also include in >>>> the partial >>>>> updates EITHER (this I think is your proposal): >>>>> - the removal of P1 as a recipient of MS2; >>>>> - the addition of P3 as a recipient of MS2; >>>>> >>>>> OR >>>>> - the removal of P1 as recipient of MS2; >>>>> - the removal of P2 as a sender of MS2; >>>>> - the termination MS2; >>>>> - the creation of MS4; >>>>> - the addition of P3 as a recipient of MS4; >>>>> - the addition of P2 as a sender of MS4. >>>>> >>>>> So with the first option the total number of deltas is 14+2=16. >>>>> For the second option the total number of deltas is 14+6=20. >>>>> >>>>> Some of the details might be wrong, but I hope you can see >>>> the point I >>>> >>>>> am getting at. Looked at this way, the efficiency saving by >>>> recycling >>>>> MS2 for use in consecutive CSs is relatively small. Or >> perhaps your >>>>> intention is also to recycle MS1 (this time, the recipient >>>> remaining >>>>> the same but the sender changing). That would reduce the number of >>>>> deltas slightly further. The impact on XML size might not >>>> be quite in >>>>> proportion to the reduction in the number of deltas, since by >>>> recycling MS2 it has to have a global identifier, not an identifier >>>> local to a CS. Or perhaps it could have an identifier >> local to a CSG. >>>>> >>>>> I also see that with your proposal it doesn't force the MS to be >>>>> recycled - an SRC could still choose to model it as separate MSs. >>>>> However, in that case it would still need to use global >> identifiers >>>> for MSs. >>>>> >>>>> I am not necessarily opposed to your proposal for recycling >>>> MS objects >>>> >>>>> outside the context of a single CS - I can see advantages and >>>>> disadvantages. I just want to make sure the group makes >> an informed >>>> decision. >>>>> >>>>> John (as individual) >>>>> >>>>> >>>>>> >>>>>> Enhancing label attribute across the multiple SIP message to tie >>>>>> between Metadata XML and RS SDP m-line is possible. SRC has to >>>>>> ensure that label for the given RS SDP m-line should have >>>> same label >>>> >>>>>> throughout single CSG even though it span across multiple CS and >>>>>> multiple RS. Even then, it will not meet partial-update >>>> requirement >>>>>> as mentioned below in this mail thread. At this moment, >>>> I'm favoring >>>> >>>>>> URN UUID and not label attribute enhancement. >>>>>> >>>>>> Please read inline >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>> Sent: Wednesday, May 25, 2011 7:17 PM >>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R >>>>>> (rmohanr); siprec@ietf.org >>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>> Sent: 25 May 2011 08:48 >>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R >>>> (rmohanr); >>>>>>> siprec@ietf.org >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >>>> in a CSG? >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> >>>> ================================================================== >>>>>>> = >>>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA >>>>>>> converts REFER >>>>>>> >>>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA >>>>>>> updates RS >>>>>>>> with CS2, Participant1 as A& participant2 as C, >>>> MS1(A's media >>>>>>>> stream), MS2(C's media stream). There is no update on RS1, >>>>>>> CSG1, MS1, >>>>>>>> MS2. MS2 will become MS2 with the new association and >>>> in terms >>>>>>>> of format, it will associate with tag >>>>>>> [JRE] What harm is done (what do we lose) if, following >>>>>> transfer, A's >>>>>>> media stream is called MS3 and C's media stream is called MS4? >>>>>>> >>>>>> >>>> >> ==================================================================== >>>>>> = >>>>>>> To indicate MS1 as MS3, MS1 media block has to be >>>>>> stopped in >>>>>>> the partial-update and start MS3 separate which is not >>>> required in >>>> >>>>>>> case there is a means to have common MS1. >>>>>> [JRE] It seems this distorts the model in order to give >>>> some minor >>>>>> efficiency improvement during metadata updates. I doubt that this >>>>>> alone is sufficient justification for having the MS >>>> persist from one >>>> >>>>>> CS to another CS. >>>>>> >>>>>>> >>>>>>> ============================================================== >>>>>>> ========== >>>>>>> ======================= >>>>>>> MS3 can reference the same SDP m-line (through a=label) as MS1, >>>>>>> and likewise MS4 could reference the same SDP m-line as >>>> MS2, if we >>>> >>>>>>> are concerned about recycling media descriptions in RS SDP. >>>>>>> ============================================================== >>>>>>> ========== >>>>>>> ================== >>>>>>> As you mentioned, we will lose recycling of media >>>>>> description >>>>>>> in RS SDP without common value in media stream object for this >>>>>>> scenario. >>>>>> [JRE] I don't understand your point. With my proposal we >>>> can still >>>>>> recycle RS SDP m-lines. >>>>>> >>>>>> Agreed that Recycle is possible with your proposal. >>>>>> I indicated >>>>>> the need for unique-id in this requirement >>>>>> >>>>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label >>>>>> attribute >>>>>>> scope is within single SIP message and not required to >>>> be unique >>>>>>> in all SIP messages of a given dialog. >>>>>> [JRE] But I think we could nail that down as a requirement of the >>>>>> SIPREC protocol. >>>>>> >>>>>> John (as individual) >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Charles Eckel (eckelcu) >>>>>>>> Sent: Wednesday, May 25, 2011 1:39 AM >>>>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); >>>>>> 'Elwell, John'; >>>>>>>> 'siprec@ietf.org' >>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a >>>> CSG? >>>>>>>> >>>>>>>> Hi Ram, >>>>>>>> >>>>>>>> I think that is many cases, they will be treated as >>>> separate MSs >>>> >>>>>>>> due to the complexities you mention. However, I am trying to >>>>>> understand if >>>>>>>> Partha feels allowing an SRC to treat them as a single MS is >>>>>>>> still required. If not, then what is a use case? A concrete >>>>>>>> example would help me, and potentially others, to better >>>>>>>> understand the >>>>>>> motivation behind >>>>>>>> Partha's requirement for modeling media from multiple CSs >>>>>>> as a single >>>>>>>> MS. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Charles >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ram Mohan R (rmohanr) >>>>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM >>>>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >>>>>>> Elwell, John; >>>>>>>>> siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >>>>>> in a CSG? >>>>>>>>> >>>>>>>>> Charles, >>>>>>>>> >>>>>>>>> I did bring about this specific usecase of MMOH/MOH >>>>>> stream being >>>>>>>>> played to different participants earlier and suggested that >>>>>>>> they have >>>>>>>>> to treated as a same MS across multiple CSs >>>>>> (potentially recorded >>>>>>>> using multiple RSs). >>>>>>>>> Refer >>>>>>>>> >>>>>> http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html >>>>>>>>> >>>>>>>>> We had several discussions on it and it and several >>>>>> folks were in >>>>>>>>> favor of treating it as separate MS as there would be >>>>>>>> complexity in DB >>>>>>>> design. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ram >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>> Behalf Of Charles Eckel (eckelcu) >>>>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM >>>>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org >>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>>>> in a CSG? >>>>>>>>>> >>>>>>>>>> Hi Partha, >>>>>>>>>> >>>>>>>>>> Is an example of this the same music on hold audio stream >>>>>>>> existing >>>>>>>>>> as the same MS within multiple CSs? If so, then I >>>>>>> understand your >>>>>>>>>> requirement to be that the SRC be able to >>>> indicate multiple >>>>>>>>>> instances of this audio stream within several CSs as >>>>>>>> being the same >>>>>>>>>> MS. Is that correct? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Charles >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>> Behalf Of Parthasarathi R (partr) >>>>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM >>>>>>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>>>>> in a CSG? >>>>>>>>>>> >>>>>>>>>>> John, >>>>>>>>>>> >>>>>>>>>>> I agree that it is not mandatory to consider recorded >>>>>>>> stream of a >>>>>>>>>>> specific participant in several CS within the same >>>>>> CSG as one >>>>>>>>>> recorded >>>>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a >>>>>>>> SRC in case >>>>>>>>>>> it wishes to design in such a way. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Partha >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>> Behalf >>>>>>>>>>> Of Elwell, John >>>>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM >>>>>>>>>>> To: siprec@ietf.org >>>>>>>>>>> Subject: [siprec] Can an MS object span several CSs >>>>>> in a CSG? >>>>>>>>>>> >>>>>>>>>>> We seem to have consensus that a Media Stream object >>>>>>>> represents a >>>>>>>>>>> recorded media stream, contributed to by one, >>>>>> several or all >>>>>>>>>>> Participants. However, Partha also wrote: >>>>>>>>>>> >>>>>>>>>>> "2) Each MS lifetime related to CSG because participant >>>>>>>> may move >>>>>>>>>>> from one CS to another CS within single CSG and also >>>>>>>> CSG will span >>>>>>>> >>>>>>>>>>> across multiple RS." >>>>>>>>>>> >>>>>>>>>>> I am not sure we had resolved this during earlier >>>>>>>> discussions on >>>>>>>>>>> the scope of an MS object. Although the same >>>>>> Participant can >>>>>>>>>>> participate >>>>>>>>>> in >>>>>>>>>>> several CSs within the same CSG, I don't think the >>>>>>>> recorded media >>>>>>>>>>> streams need to be considered the same. Any other views? >>>>>>>>>>> >>>>>>>>>>> John (as individual) >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>> _______________________________________________ >>>>>>>>>> siprec mailing list >>>>>>>>>> siprec@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > From john.elwell@siemens-enterprise.com Wed Jun 15 08:53:43 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087E111E8119 for ; Wed, 15 Jun 2011 08:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOXsZsk9PbRx for ; Wed, 15 Jun 2011 08:53:41 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 6D7A611E8081 for ; Wed, 15 Jun 2011 08:53:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1308153219!9136318!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 10098 invoked from network); 15 Jun 2011 15:53:39 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-13.tower-182.messagelabs.com with SMTP; 15 Jun 2011 15:53:39 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id ECE3823F03E8; Wed, 15 Jun 2011 17:53:38 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 15 Jun 2011 17:53:38 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Wed, 15 Jun 2011 17:53:38 +0200 Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: Acwrant3Twb/H532S2+7WAUbPi/QXAACbD+Q Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> <4DF77EB5.9060009@cisco.com> <4DF8C4E0.8020409@cisco.com> In-Reply-To: <4DF8C4E0.8020409@cisco.com> 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: "siprec@ietf.org" Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 15:53:43 -0000 OK, I understand. So I will go along with the majority. Any other opinions = whether we need global ID or local ID for MS? John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 15 June 2011 15:43 > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > On 6/15/2011 9:55 AM, Elwell, John wrote: > > Paul, > > > > But if the two SRCs are somehow cooperating to the extent > that they can share the same global ID for the CS, could they > not also share the same local ID for the MS? Why does it need > to be a global ID? > > They could *know* each other's local id for the MS. > They might even agree to use the *same* value for the local id. > > E.g. we have SRC#1 and SRC#2, each using 123 as the local id for the > "same" stream. > > But to the SRS, there is one MS with id SRC#1:123, and > another MS with > SRC#2:123. It does not know they are the same. (That is the point of > local scoping.) > > So even though the two SRCs know they are talking about the > same MS they > have no way to tell that to the SRS. > > Thanks, > Paul > > > John > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 14 June 2011 16:31 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > >> > >> John, > >> > >> Consider another case: two SRCs in the same CS (perhaps one at each > >> "end".) They are both sending metadata about the same CS and MSs. > >> > >> Suppose they want to cooperate with each other. They have the > >> potential > >> to use the same ID to reference the CS, so that the SRS will > >> know they > >> are talking about the same one. But with RS-specific MS ids > >> there is no > >> way for them to indicate that they are talking about the same > >> MSs. With > >> global MS ids, they could accomplish this. > >> > >> Thanks, > >> Paul > >> > >> On 6/14/2011 11:03 AM, Elwell, John wrote: > >>> Partha, > >>> > >>> Thanks for the examples. The character count for the delta > >> is about 2500 when a new MS is created compared to about 2100 > >> when the MS is retained. This seems to be in line with my > >> previous gut feeling. > >>> > >>> Concerning the need for "SRS implementers to guess how old > >> MS and new MS are related", I don't think they are related, > >> except by having other things in common like a common > >> participant or a common CSG. > >>> > >>> John (as individual) > >>> > >>>> -----Original Message----- > >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>> Sent: 14 June 2011 13:15 > >>>> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; Ram > >>>> Mohan R (rmohanr); siprec@ietf.org > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >>>> > >>>> Hi all, > >>>> > >>>> Sorry for the delay. Just to double confirm everybody > >>>> understanding with > >>>> SIP message example, I added the example with creating new MS and > >>>> reusing the same MS as an attachment with this mail. > >>>> > >>>> Please note that creating new MS is putting SRS > >> implementers to guess > >>>> how old MS and new MS are related. Also, few scenario like > >> Even after > >>>> looking into the example, the intention is to use local > >> variable, I'm > >>>> ok. > >>>> > >>>> Thanks > >>>> Partha > >>>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) > >>>> Sent: Friday, June 10, 2011 10:57 PM > >>>> To: Leon Portman; Elwell, John; Parthasarathi R (partr); > >> Ram Mohan R > >>>> (rmohanr); siprec@ietf.org > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >>>> > >>>> Please excuse the delay. I am catching up after having > been away on > >>>> vacation. > >>>> In light of this better understanding of the use case, I also > >>>> prefer the > >>>> option favored by John and Leon to model as a separate > MS. In this > >>>> specific case, I would expect the properties of the MS to > >>>> change when A > >>>> is transferred to C, so I expect the overhead in creating > >> a new MS vs. > >>>> reusing the same MS to be minimal and not worth the added > >>>> complexity to > >>>> the model. > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> -----Original Message----- > >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >>>>> Sent: Tuesday, May 31, 2011 6:19 AM > >>>>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel > >> (eckelcu); > >>>>> Ram Mohan R (rmohanr); siprec@ietf.org > >>>>> Subject: RE: [siprec] Can an MS object span several CSs > in a CSG? > >>>>> > >>>>> Hello > >>>>> > >>>>> I also having a problem even without a quantification > of number of > >>>>> update messages that CS MS is remains same between > >>>> different CS. So I > >>>> do prefer to keep it simple and keep it per CS. > >>>>> > >>>>> Leon > >>>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf Of Elwell, John > >>>>> Sent: Friday, May 27, 2011 12:26 PM > >>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); > Ram Mohan R > >>>>> (rmohanr); siprec@ietf.org > >>>>> Subject: Re: [siprec] Can an MS object span several CSs > in a CSG? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>>>> Sent: 26 May 2011 15:55 > >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > (rmohanr); > >>>>>> siprec@ietf.org > >>>>>> Subject: RE: [siprec] Can an MS object span several > CSs in a CSG? > >>>>>> > >>>>>> John, > >>>>>> > >>>>>> The callflow mentioned by me is the basic primitive in the call > >>>>>> center scenario wherein customer (participant) is same > throughout > >>>>>> the session and agents are changed using transfer service > >>>> and B2BUA > >>>> acts as SRC. > >>>>>> IMO, it is one of key requirement to be considered in case we > >>>>>> support for partial-update. > >>>>> [JRE] Agreed the Participant remains the same, but we are > >> discussing > >>>> MS. > >>>>> > >>>>>> This may not be the only callflow where MS partial-update is > >>>>>> required in this fashion. During -00 format draft, I > thought that > >>>>>> the partial-update is not required but lot of folks raised the > >>>>>> concern that partial update is important. Current, -01 > >>>> format draft > >>>>>> is designed to support partial-update. Now, You propose > >>>> to restrict > >>>>>> MS partial-update across CS. IMO, it is a not good idea > >>>> to restrict > >>>>>> in the protocol level. Anyway, I think that we need > >>>> others opinion > >>>>>> before conclude here. > >>>>> [JRE] I am not opposed to partial update, but I would > >> like to avoid > >>>>> distorting the model just to gain some efficiency > improvements in > >>>>> certain cases. To me it is not intuitive that a MS on one > >>>> CS and an MS > >>>> > >>>>> on another CS are the same object, just because one of the > >>>>> Participants is common to both CSs. In the > transfer-between-agents > >>>> example, although one of the Participants is common to the > >>>> two CSs, this > >>>> is not true for the other Participants. > >>>>> > >>>>> Let's try to quantify the efficiency improvement. In the blind > >>>>> transfer case, the partial updates would at least have > to include: > >>>>> - the removal of P1 from CS1 (where P1 is the first agent > >>>> and CS1 is > >>>>> the first CS); > >>>>> - the removal of P2 from CS1 (where P2 is the transferred > >>>>> participant); > >>>>> - the termination of CS1; > >>>>> - the removal of CS1 from CSG1; > >>>>> - the creation of CS2 (the CS that results from transfer); > >>>>> - the addition to of CS2 to CSG1; > >>>>> - the addition of P2 to CSG1; > >>>>> - the addition of P3 to CS2 (where P3 is the second agent); > >>>>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); > >>>>> - the removal of P2 as a recipient of MS1; > >>>>> - the termination of MS1; > >>>>> - the creation of MS3; > >>>>> - the addition of P3 as a sender of MS3; > >>>>> - the addition of P2 as a recipient of MS3. > >>>>> > >>>>> So all we are arguing about is whether we also include in > >>>> the partial > >>>>> updates EITHER (this I think is your proposal): > >>>>> - the removal of P1 as a recipient of MS2; > >>>>> - the addition of P3 as a recipient of MS2; > >>>>> > >>>>> OR > >>>>> - the removal of P1 as recipient of MS2; > >>>>> - the removal of P2 as a sender of MS2; > >>>>> - the termination MS2; > >>>>> - the creation of MS4; > >>>>> - the addition of P3 as a recipient of MS4; > >>>>> - the addition of P2 as a sender of MS4. > >>>>> > >>>>> So with the first option the total number of deltas is 14+2=3D16. > >>>>> For the second option the total number of deltas is 14+6=3D20. > >>>>> > >>>>> Some of the details might be wrong, but I hope you can see > >>>> the point I > >>>> > >>>>> am getting at. Looked at this way, the efficiency saving by > >>>> recycling > >>>>> MS2 for use in consecutive CSs is relatively small. Or > >> perhaps your > >>>>> intention is also to recycle MS1 (this time, the recipient > >>>> remaining > >>>>> the same but the sender changing). That would reduce > the number of > >>>>> deltas slightly further. The impact on XML size might not > >>>> be quite in > >>>>> proportion to the reduction in the number of deltas, since by > >>>> recycling MS2 it has to have a global identifier, not an > identifier > >>>> local to a CS. Or perhaps it could have an identifier > >> local to a CSG. > >>>>> > >>>>> I also see that with your proposal it doesn't force the MS to be > >>>>> recycled - an SRC could still choose to model it as > separate MSs. > >>>>> However, in that case it would still need to use global > >> identifiers > >>>> for MSs. > >>>>> > >>>>> I am not necessarily opposed to your proposal for recycling > >>>> MS objects > >>>> > >>>>> outside the context of a single CS - I can see advantages and > >>>>> disadvantages. I just want to make sure the group makes > >> an informed > >>>> decision. > >>>>> > >>>>> John (as individual) > >>>>> > >>>>> > >>>>>> > >>>>>> Enhancing label attribute across the multiple SIP > message to tie > >>>>>> between Metadata XML and RS SDP m-line is possible. SRC has to > >>>>>> ensure that label for the given RS SDP m-line should have > >>>> same label > >>>> > >>>>>> throughout single CSG even though it span across > multiple CS and > >>>>>> multiple RS. Even then, it will not meet partial-update > >>>> requirement > >>>>>> as mentioned below in this mail thread. At this moment, > >>>> I'm favoring > >>>> > >>>>>> URN UUID and not label attribute enhancement. > >>>>>> > >>>>>> Please read inline > >>>>>> > >>>>>> Thanks > >>>>>> Partha > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>>> Sent: Wednesday, May 25, 2011 7:17 PM > >>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); > Ram Mohan R > >>>>>> (rmohanr); siprec@ietf.org > >>>>>> Subject: RE: [siprec] Can an MS object span several > CSs in a CSG? > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>>>>> Sent: 25 May 2011 08:48 > >>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > >>>> (rmohanr); > >>>>>>> siprec@ietf.org > >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs > >>>> in a CSG? > >>>>>>> > >>>>>>> John, > >>>>>>> > >>>>>>> > >>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D > >>>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA > >>>>>>> converts REFER > >>>>>>> > >>>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA > >>>>>>> updates RS > >>>>>>>> with CS2, Participant1 as A& participant2 as C, > >>>> MS1(A's media > >>>>>>>> stream), MS2(C's media stream). There is no update on RS1, > >>>>>>> CSG1, MS1, > >>>>>>>> MS2. MS2 will become MS2 with the new association and > >>>> in terms > >>>>>>>> of format, it will associate with tag > >>>>>>> [JRE] What harm is done (what do we lose) if, following > >>>>>> transfer, A's > >>>>>>> media stream is called MS3 and C's media stream is called MS4? > >>>>>>> > >>>>>> > >>>> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>> =3D > >>>>>>> To indicate MS1 as MS3, MS1 media block has to be > >>>>>> stopped in > >>>>>>> the partial-update and start MS3 separate which is not > >>>> required in > >>>> > >>>>>>> case there is a means to have common MS1. > >>>>>> [JRE] It seems this distorts the model in order to give > >>>> some minor > >>>>>> efficiency improvement during metadata updates. I > doubt that this > >>>>>> alone is sufficient justification for having the MS > >>>> persist from one > >>>> > >>>>>> CS to another CS. > >>>>>> > >>>>>>> > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >>>>>>> MS3 can reference the same SDP m-line (through > a=3Dlabel) as MS1, > >>>>>>> and likewise MS4 could reference the same SDP m-line as > >>>> MS2, if we > >>>> > >>>>>>> are concerned about recycling media descriptions in RS SDP. > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> As you mentioned, we will lose recycling of media > >>>>>> description > >>>>>>> in RS SDP without common value in media stream object for this > >>>>>>> scenario. > >>>>>> [JRE] I don't understand your point. With my proposal we > >>>> can still > >>>>>> recycle RS SDP m-lines. > >>>>>> > >>>>>> Agreed that Recycle is possible with your proposal. > >>>>>> I indicated > >>>>>> the need for unique-id in this requirement > >>>>>> > >>>>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label > >>>>>> attribute > >>>>>>> scope is within single SIP message and not required to > >>>> be unique > >>>>>>> in all SIP messages of a given dialog. > >>>>>> [JRE] But I think we could nail that down as a > requirement of the > >>>>>> SIPREC protocol. > >>>>>> > >>>>>> John (as individual) > >>>>>> > >>>>>>> > >>>>>>> Thanks > >>>>>>> Partha > >>>>>>> > >>>>>>> John (as individual) > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> Partha > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Charles Eckel (eckelcu) > >>>>>>>> Sent: Wednesday, May 25, 2011 1:39 AM > >>>>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); > >>>>>> 'Elwell, John'; > >>>>>>>> 'siprec@ietf.org' > >>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a > >>>> CSG? > >>>>>>>> > >>>>>>>> Hi Ram, > >>>>>>>> > >>>>>>>> I think that is many cases, they will be treated as > >>>> separate MSs > >>>> > >>>>>>>> due to the complexities you mention. However, I am trying to > >>>>>> understand if > >>>>>>>> Partha feels allowing an SRC to treat them as a single MS is > >>>>>>>> still required. If not, then what is a use case? A concrete > >>>>>>>> example would help me, and potentially others, to better > >>>>>>>> understand the > >>>>>>> motivation behind > >>>>>>>> Partha's requirement for modeling media from multiple CSs > >>>>>>> as a single > >>>>>>>> MS. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Charles > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Ram Mohan R (rmohanr) > >>>>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM > >>>>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); > >>>>>>> Elwell, John; > >>>>>>>>> siprec@ietf.org > >>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs > >>>>>> in a CSG? > >>>>>>>>> > >>>>>>>>> Charles, > >>>>>>>>> > >>>>>>>>> I did bring about this specific usecase of MMOH/MOH > >>>>>> stream being > >>>>>>>>> played to different participants earlier and suggested that > >>>>>>>> they have > >>>>>>>>> to treated as a same MS across multiple CSs > >>>>>> (potentially recorded > >>>>>>>> using multiple RSs). > >>>>>>>>> Refer > >>>>>>>>> > >>>>>> > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > >>>>>>>>> > >>>>>>>>> We had several discussions on it and it and several > >>>>>> folks were in > >>>>>>>>> favor of treating it as separate MS as there would be > >>>>>>>> complexity in DB > >>>>>>>> design. > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Ram > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: siprec-bounces@ietf.org > >>>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>>>> Behalf Of Charles Eckel (eckelcu) > >>>>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM > >>>>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > >>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > >>>>>>> in a CSG? > >>>>>>>>>> > >>>>>>>>>> Hi Partha, > >>>>>>>>>> > >>>>>>>>>> Is an example of this the same music on hold audio stream > >>>>>>>> existing > >>>>>>>>>> as the same MS within multiple CSs? If so, then I > >>>>>>> understand your > >>>>>>>>>> requirement to be that the SRC be able to > >>>> indicate multiple > >>>>>>>>>> instances of this audio stream within several CSs as > >>>>>>>> being the same > >>>>>>>>>> MS. Is that correct? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Charles > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: siprec-bounces@ietf.org > >>>>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>>>> Behalf Of Parthasarathi R (partr) > >>>>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM > >>>>>>>>>>> To: Elwell, John; siprec@ietf.org > >>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > >>>>>>>> in a CSG? > >>>>>>>>>>> > >>>>>>>>>>> John, > >>>>>>>>>>> > >>>>>>>>>>> I agree that it is not mandatory to consider recorded > >>>>>>>> stream of a > >>>>>>>>>>> specific participant in several CS within the same > >>>>>> CSG as one > >>>>>>>>>> recorded > >>>>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a > >>>>>>>> SRC in case > >>>>>>>>>>> it wishes to design in such a way. > >>>>>>>>>>> > >>>>>>>>>>> Thanks > >>>>>>>>>>> Partha > >>>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: siprec-bounces@ietf.org > >>>>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>>>> Behalf > >>>>>>>>>>> Of Elwell, John > >>>>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM > >>>>>>>>>>> To: siprec@ietf.org > >>>>>>>>>>> Subject: [siprec] Can an MS object span several CSs > >>>>>> in a CSG? > >>>>>>>>>>> > >>>>>>>>>>> We seem to have consensus that a Media Stream object > >>>>>>>> represents a > >>>>>>>>>>> recorded media stream, contributed to by one, > >>>>>> several or all > >>>>>>>>>>> Participants. However, Partha also wrote: > >>>>>>>>>>> > >>>>>>>>>>> "2) Each MS lifetime related to CSG because participant > >>>>>>>> may move > >>>>>>>>>>> from one CS to another CS within single CSG and also > >>>>>>>> CSG will span > >>>>>>>> > >>>>>>>>>>> across multiple RS." > >>>>>>>>>>> > >>>>>>>>>>> I am not sure we had resolved this during earlier > >>>>>>>> discussions on > >>>>>>>>>>> the scope of an MS object. Although the same > >>>>>> Participant can > >>>>>>>>>>> participate > >>>>>>>>>> in > >>>>>>>>>>> several CSs within the same CSG, I don't think the > >>>>>>>> recorded media > >>>>>>>>>>> streams need to be considered the same. Any other views? > >>>>>>>>>>> > >>>>>>>>>>> John (as individual) > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> siprec mailing list > >>>>>>>>>>> siprec@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> siprec mailing list > >>>>>>>>>>> siprec@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> siprec mailing list > >>>>>>>>>> siprec@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> siprec mailing list > >>>>> siprec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >>> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >> > > > From pkyzivat@cisco.com Wed Jun 15 10:40:51 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8843221F84B9 for ; Wed, 15 Jun 2011 10:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.425 X-Spam-Level: X-Spam-Status: No, score=-110.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBXTLBbM1Iqp for ; Wed, 15 Jun 2011 10:40:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id C502021F84E1 for ; Wed, 15 Jun 2011 10:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=22867; q=dns/txt; s=iport; t=1308159632; x=1309369232; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MmKClfohaLh/fPKe6OHgzdB7aDFwGcKnpf4T0Us1h6I=; b=dYNmDT+r96j7hy52t9tJ+Dzwyjeh1KvLS7whAm/F4UF4mSCVwiOh9D7R n0zTyiHipxbFyzwNBa9L9Us3+wsYJCZeHCISTgvNXILypxkzmR9ElAzA5 1q39eMmXISf9CLDZahWpfFI9tprDuLRYHSbawolC2ZmORQG1+H/NIHNDT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4BAEbu+E2tJXHA/2dsb2JhbABSl1CPCHepc55DhiYEkU6EW4sx X-IronPort-AV: E=Sophos;i="4.65,370,1304294400"; d="scan'208";a="236475888" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-1.cisco.com with ESMTP; 15 Jun 2011 17:40:31 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p5FHeTjH004979; Wed, 15 Jun 2011 17:40:30 GMT Message-ID: <4DF8EE8D.7020002@cisco.com> Date: Wed, 15 Jun 2011 13:40:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Elwell, John" References: <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> <4DF77EB5.9060009@cisco.com> <4DF8C4E0.8020409@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:40:51 -0000 There are many ways to skin the unique id cat, depending on what problems we most want to optimize: - the uuid urn we are currently specifying. it takes 45 bytes on the wire, but only 16 bytes to store in binary. New values can be computed with the cost of an SHA-1 computation over something locally unique that need not be large. - we could invent a way to encode the same kinds of values more compactly if on-the-wire size is the concern. For instance, with radix 64 the same value could be represented in 22 bytes rather than 45. - if cost of computation is an issue, we could use two-part uuids, where one part is as above, and the other part is a simple integer. This would take more bytes to transmit and store, but (arguably) less computation to generate. - we could use two-part ids as above, but where one part is optional to supply, defaulting to a per-RS value. Normally you would only supply one part, but could supply both parts if you want to reference an id that doesn't include the RS-default. Two-part ids would be large, while one-part ones could be small. The overall average would depend on locality - if most ids are per-RS then the average would be small. The SRS would still have to store both parts, but it could also use optimization tricks if it wishes. IMO the simplest thing is just to go with uuid urns. But the last option above would also work for me if people feel the added complexity is justified. Thanks, Paul On 6/15/2011 11:53 AM, Elwell, John wrote: > OK, I understand. So I will go along with the majority. Any other opinions whether we need global ID or local ID for MS? > > John > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 15 June 2011 15:43 >> To: Elwell, John >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >> >> >> >> On 6/15/2011 9:55 AM, Elwell, John wrote: >>> Paul, >>> >>> But if the two SRCs are somehow cooperating to the extent >> that they can share the same global ID for the CS, could they >> not also share the same local ID for the MS? Why does it need >> to be a global ID? >> >> They could *know* each other's local id for the MS. >> They might even agree to use the *same* value for the local id. >> >> E.g. we have SRC#1 and SRC#2, each using 123 as the local id for the >> "same" stream. >> >> But to the SRS, there is one MS with id SRC#1:123, and >> another MS with >> SRC#2:123. It does not know they are the same. (That is the point of >> local scoping.) >> >> So even though the two SRCs know they are talking about the >> same MS they >> have no way to tell that to the SRS. >> >> Thanks, >> Paul >> >>> John >>> >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: 14 June 2011 16:31 >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >>>> >>>> John, >>>> >>>> Consider another case: two SRCs in the same CS (perhaps one at each >>>> "end".) They are both sending metadata about the same CS and MSs. >>>> >>>> Suppose they want to cooperate with each other. They have the >>>> potential >>>> to use the same ID to reference the CS, so that the SRS will >>>> know they >>>> are talking about the same one. But with RS-specific MS ids >>>> there is no >>>> way for them to indicate that they are talking about the same >>>> MSs. With >>>> global MS ids, they could accomplish this. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 6/14/2011 11:03 AM, Elwell, John wrote: >>>>> Partha, >>>>> >>>>> Thanks for the examples. The character count for the delta >>>> is about 2500 when a new MS is created compared to about 2100 >>>> when the MS is retained. This seems to be in line with my >>>> previous gut feeling. >>>>> >>>>> Concerning the need for "SRS implementers to guess how old >>>> MS and new MS are related", I don't think they are related, >>>> except by having other things in common like a common >>>> participant or a common CSG. >>>>> >>>>> John (as individual) >>>>> >>>>>> -----Original Message----- >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>> Sent: 14 June 2011 13:15 >>>>>> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; Ram >>>>>> Mohan R (rmohanr); siprec@ietf.org >>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Sorry for the delay. Just to double confirm everybody >>>>>> understanding with >>>>>> SIP message example, I added the example with creating new MS and >>>>>> reusing the same MS as an attachment with this mail. >>>>>> >>>>>> Please note that creating new MS is putting SRS >>>> implementers to guess >>>>>> how old MS and new MS are related. Also, few scenario like >>>> Even after >>>>>> looking into the example, the intention is to use local >>>> variable, I'm >>>>>> ok. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) >>>>>> Sent: Friday, June 10, 2011 10:57 PM >>>>>> To: Leon Portman; Elwell, John; Parthasarathi R (partr); >>>> Ram Mohan R >>>>>> (rmohanr); siprec@ietf.org >>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>>> >>>>>> Please excuse the delay. I am catching up after having >> been away on >>>>>> vacation. >>>>>> In light of this better understanding of the use case, I also >>>>>> prefer the >>>>>> option favored by John and Leon to model as a separate >> MS. In this >>>>>> specific case, I would expect the properties of the MS to >>>>>> change when A >>>>>> is transferred to C, so I expect the overhead in creating >>>> a new MS vs. >>>>>> reusing the same MS to be minimal and not worth the added >>>>>> complexity to >>>>>> the model. >>>>>> >>>>>> Cheers, >>>>>> Charles >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>> Sent: Tuesday, May 31, 2011 6:19 AM >>>>>>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel >>>> (eckelcu); >>>>>>> Ram Mohan R (rmohanr); siprec@ietf.org >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >> in a CSG? >>>>>>> >>>>>>> Hello >>>>>>> >>>>>>> I also having a problem even without a quantification >> of number of >>>>>>> update messages that CS MS is remains same between >>>>>> different CS. So I >>>>>> do prefer to keep it simple and keep it per CS. >>>>>>> >>>>>>> Leon >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>>>>>> Behalf Of Elwell, John >>>>>>> Sent: Friday, May 27, 2011 12:26 PM >>>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); >> Ram Mohan R >>>>>>> (rmohanr); siprec@ietf.org >>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >> in a CSG? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>>> Sent: 26 May 2011 15:55 >>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R >> (rmohanr); >>>>>>>> siprec@ietf.org >>>>>>>> Subject: RE: [siprec] Can an MS object span several >> CSs in a CSG? >>>>>>>> >>>>>>>> John, >>>>>>>> >>>>>>>> The callflow mentioned by me is the basic primitive in the call >>>>>>>> center scenario wherein customer (participant) is same >> throughout >>>>>>>> the session and agents are changed using transfer service >>>>>> and B2BUA >>>>>> acts as SRC. >>>>>>>> IMO, it is one of key requirement to be considered in case we >>>>>>>> support for partial-update. >>>>>>> [JRE] Agreed the Participant remains the same, but we are >>>> discussing >>>>>> MS. >>>>>>> >>>>>>>> This may not be the only callflow where MS partial-update is >>>>>>>> required in this fashion. During -00 format draft, I >> thought that >>>>>>>> the partial-update is not required but lot of folks raised the >>>>>>>> concern that partial update is important. Current, -01 >>>>>> format draft >>>>>>>> is designed to support partial-update. Now, You propose >>>>>> to restrict >>>>>>>> MS partial-update across CS. IMO, it is a not good idea >>>>>> to restrict >>>>>>>> in the protocol level. Anyway, I think that we need >>>>>> others opinion >>>>>>>> before conclude here. >>>>>>> [JRE] I am not opposed to partial update, but I would >>>> like to avoid >>>>>>> distorting the model just to gain some efficiency >> improvements in >>>>>>> certain cases. To me it is not intuitive that a MS on one >>>>>> CS and an MS >>>>>> >>>>>>> on another CS are the same object, just because one of the >>>>>>> Participants is common to both CSs. In the >> transfer-between-agents >>>>>> example, although one of the Participants is common to the >>>>>> two CSs, this >>>>>> is not true for the other Participants. >>>>>>> >>>>>>> Let's try to quantify the efficiency improvement. In the blind >>>>>>> transfer case, the partial updates would at least have >> to include: >>>>>>> - the removal of P1 from CS1 (where P1 is the first agent >>>>>> and CS1 is >>>>>>> the first CS); >>>>>>> - the removal of P2 from CS1 (where P2 is the transferred >>>>>>> participant); >>>>>>> - the termination of CS1; >>>>>>> - the removal of CS1 from CSG1; >>>>>>> - the creation of CS2 (the CS that results from transfer); >>>>>>> - the addition to of CS2 to CSG1; >>>>>>> - the addition of P2 to CSG1; >>>>>>> - the addition of P3 to CS2 (where P3 is the second agent); >>>>>>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); >>>>>>> - the removal of P2 as a recipient of MS1; >>>>>>> - the termination of MS1; >>>>>>> - the creation of MS3; >>>>>>> - the addition of P3 as a sender of MS3; >>>>>>> - the addition of P2 as a recipient of MS3. >>>>>>> >>>>>>> So all we are arguing about is whether we also include in >>>>>> the partial >>>>>>> updates EITHER (this I think is your proposal): >>>>>>> - the removal of P1 as a recipient of MS2; >>>>>>> - the addition of P3 as a recipient of MS2; >>>>>>> >>>>>>> OR >>>>>>> - the removal of P1 as recipient of MS2; >>>>>>> - the removal of P2 as a sender of MS2; >>>>>>> - the termination MS2; >>>>>>> - the creation of MS4; >>>>>>> - the addition of P3 as a recipient of MS4; >>>>>>> - the addition of P2 as a sender of MS4. >>>>>>> >>>>>>> So with the first option the total number of deltas is 14+2=16. >>>>>>> For the second option the total number of deltas is 14+6=20. >>>>>>> >>>>>>> Some of the details might be wrong, but I hope you can see >>>>>> the point I >>>>>> >>>>>>> am getting at. Looked at this way, the efficiency saving by >>>>>> recycling >>>>>>> MS2 for use in consecutive CSs is relatively small. Or >>>> perhaps your >>>>>>> intention is also to recycle MS1 (this time, the recipient >>>>>> remaining >>>>>>> the same but the sender changing). That would reduce >> the number of >>>>>>> deltas slightly further. The impact on XML size might not >>>>>> be quite in >>>>>>> proportion to the reduction in the number of deltas, since by >>>>>> recycling MS2 it has to have a global identifier, not an >> identifier >>>>>> local to a CS. Or perhaps it could have an identifier >>>> local to a CSG. >>>>>>> >>>>>>> I also see that with your proposal it doesn't force the MS to be >>>>>>> recycled - an SRC could still choose to model it as >> separate MSs. >>>>>>> However, in that case it would still need to use global >>>> identifiers >>>>>> for MSs. >>>>>>> >>>>>>> I am not necessarily opposed to your proposal for recycling >>>>>> MS objects >>>>>> >>>>>>> outside the context of a single CS - I can see advantages and >>>>>>> disadvantages. I just want to make sure the group makes >>>> an informed >>>>>> decision. >>>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Enhancing label attribute across the multiple SIP >> message to tie >>>>>>>> between Metadata XML and RS SDP m-line is possible. SRC has to >>>>>>>> ensure that label for the given RS SDP m-line should have >>>>>> same label >>>>>> >>>>>>>> throughout single CSG even though it span across >> multiple CS and >>>>>>>> multiple RS. Even then, it will not meet partial-update >>>>>> requirement >>>>>>>> as mentioned below in this mail thread. At this moment, >>>>>> I'm favoring >>>>>> >>>>>>>> URN UUID and not label attribute enhancement. >>>>>>>> >>>>>>>> Please read inline >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>>> Sent: Wednesday, May 25, 2011 7:17 PM >>>>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); >> Ram Mohan R >>>>>>>> (rmohanr); siprec@ietf.org >>>>>>>> Subject: RE: [siprec] Can an MS object span several >> CSs in a CSG? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>>>> Sent: 25 May 2011 08:48 >>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R >>>>>> (rmohanr); >>>>>>>>> siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >>>>>> in a CSG? >>>>>>>>> >>>>>>>>> John, >>>>>>>>> >>>>>>>>> >>>>>> >> ================================================================== >>>>>>>>> = >>>>>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA >>>>>>>>> converts REFER >>>>>>>>> >>>>>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA >>>>>>>>> updates RS >>>>>>>>>> with CS2, Participant1 as A& participant2 as C, >>>>>> MS1(A's media >>>>>>>>>> stream), MS2(C's media stream). There is no update on RS1, >>>>>>>>> CSG1, MS1, >>>>>>>>>> MS2. MS2 will become MS2 with the new association and >>>>>> in terms >>>>>>>>>> of format, it will associate with tag >>>>>>>>> [JRE] What harm is done (what do we lose) if, following >>>>>>>> transfer, A's >>>>>>>>> media stream is called MS3 and C's media stream is called MS4? >>>>>>>>> >>>>>>>> >>>>>> >>>> >> ==================================================================== >>>>>>>> = >>>>>>>>> To indicate MS1 as MS3, MS1 media block has to be >>>>>>>> stopped in >>>>>>>>> the partial-update and start MS3 separate which is not >>>>>> required in >>>>>> >>>>>>>>> case there is a means to have common MS1. >>>>>>>> [JRE] It seems this distorts the model in order to give >>>>>> some minor >>>>>>>> efficiency improvement during metadata updates. I >> doubt that this >>>>>>>> alone is sufficient justification for having the MS >>>>>> persist from one >>>>>> >>>>>>>> CS to another CS. >>>>>>>> >>>>>>>>> >>>>>>>>> ============================================================== >>>>>>>>> ========== >>>>>>>>> ======================= >>>>>>>>> MS3 can reference the same SDP m-line (through >> a=label) as MS1, >>>>>>>>> and likewise MS4 could reference the same SDP m-line as >>>>>> MS2, if we >>>>>> >>>>>>>>> are concerned about recycling media descriptions in RS SDP. >>>>>>>>> ============================================================== >>>>>>>>> ========== >>>>>>>>> ================== >>>>>>>>> As you mentioned, we will lose recycling of media >>>>>>>> description >>>>>>>>> in RS SDP without common value in media stream object for this >>>>>>>>> scenario. >>>>>>>> [JRE] I don't understand your point. With my proposal we >>>>>> can still >>>>>>>> recycle RS SDP m-lines. >>>>>>>> >>>>>>>> Agreed that Recycle is possible with your proposal. >>>>>>>> I indicated >>>>>>>> the need for unique-id in this requirement >>>>>>>> >>>>>>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label >>>>>>>> attribute >>>>>>>>> scope is within single SIP message and not required to >>>>>> be unique >>>>>>>>> in all SIP messages of a given dialog. >>>>>>>> [JRE] But I think we could nail that down as a >> requirement of the >>>>>>>> SIPREC protocol. >>>>>>>> >>>>>>>> John (as individual) >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>> >>>>>>>>> John (as individual) >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Partha >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Charles Eckel (eckelcu) >>>>>>>>>> Sent: Wednesday, May 25, 2011 1:39 AM >>>>>>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); >>>>>>>> 'Elwell, John'; >>>>>>>>>> 'siprec@ietf.org' >>>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a >>>>>> CSG? >>>>>>>>>> >>>>>>>>>> Hi Ram, >>>>>>>>>> >>>>>>>>>> I think that is many cases, they will be treated as >>>>>> separate MSs >>>>>> >>>>>>>>>> due to the complexities you mention. However, I am trying to >>>>>>>> understand if >>>>>>>>>> Partha feels allowing an SRC to treat them as a single MS is >>>>>>>>>> still required. If not, then what is a use case? A concrete >>>>>>>>>> example would help me, and potentially others, to better >>>>>>>>>> understand the >>>>>>>>> motivation behind >>>>>>>>>> Partha's requirement for modeling media from multiple CSs >>>>>>>>> as a single >>>>>>>>>> MS. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Charles >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Ram Mohan R (rmohanr) >>>>>>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM >>>>>>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >>>>>>>>> Elwell, John; >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >>>>>>>> in a CSG? >>>>>>>>>>> >>>>>>>>>>> Charles, >>>>>>>>>>> >>>>>>>>>>> I did bring about this specific usecase of MMOH/MOH >>>>>>>> stream being >>>>>>>>>>> played to different participants earlier and suggested that >>>>>>>>>> they have >>>>>>>>>>> to treated as a same MS across multiple CSs >>>>>>>> (potentially recorded >>>>>>>>>> using multiple RSs). >>>>>>>>>>> Refer >>>>>>>>>>> >>>>>>>> >> http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html >>>>>>>>>>> >>>>>>>>>>> We had several discussions on it and it and several >>>>>>>> folks were in >>>>>>>>>>> favor of treating it as separate MS as there would be >>>>>>>>>> complexity in DB >>>>>>>>>> design. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Ram >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Charles Eckel (eckelcu) >>>>>>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM >>>>>>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org >>>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>>>>>> in a CSG? >>>>>>>>>>>> >>>>>>>>>>>> Hi Partha, >>>>>>>>>>>> >>>>>>>>>>>> Is an example of this the same music on hold audio stream >>>>>>>>>> existing >>>>>>>>>>>> as the same MS within multiple CSs? If so, then I >>>>>>>>> understand your >>>>>>>>>>>> requirement to be that the SRC be able to >>>>>> indicate multiple >>>>>>>>>>>> instances of this audio stream within several CSs as >>>>>>>>>> being the same >>>>>>>>>>>> MS. Is that correct? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Charles >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Parthasarathi R (partr) >>>>>>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM >>>>>>>>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>>>>>>> in a CSG? >>>>>>>>>>>>> >>>>>>>>>>>>> John, >>>>>>>>>>>>> >>>>>>>>>>>>> I agree that it is not mandatory to consider recorded >>>>>>>>>> stream of a >>>>>>>>>>>>> specific participant in several CS within the same >>>>>>>> CSG as one >>>>>>>>>>>> recorded >>>>>>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a >>>>>>>>>> SRC in case >>>>>>>>>>>>> it wishes to design in such a way. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Partha >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>>>> Behalf >>>>>>>>>>>>> Of Elwell, John >>>>>>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM >>>>>>>>>>>>> To: siprec@ietf.org >>>>>>>>>>>>> Subject: [siprec] Can an MS object span several CSs >>>>>>>> in a CSG? >>>>>>>>>>>>> >>>>>>>>>>>>> We seem to have consensus that a Media Stream object >>>>>>>>>> represents a >>>>>>>>>>>>> recorded media stream, contributed to by one, >>>>>>>> several or all >>>>>>>>>>>>> Participants. However, Partha also wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> "2) Each MS lifetime related to CSG because participant >>>>>>>>>> may move >>>>>>>>>>>>> from one CS to another CS within single CSG and also >>>>>>>>>> CSG will span >>>>>>>>>> >>>>>>>>>>>>> across multiple RS." >>>>>>>>>>>>> >>>>>>>>>>>>> I am not sure we had resolved this during earlier >>>>>>>>>> discussions on >>>>>>>>>>>>> the scope of an MS object. Although the same >>>>>>>> Participant can >>>>>>>>>>>>> participate >>>>>>>>>>>> in >>>>>>>>>>>>> several CSs within the same CSG, I don't think the >>>>>>>>>> recorded media >>>>>>>>>>>>> streams need to be considered the same. Any other views? >>>>>>>>>>>>> >>>>>>>>>>>>> John (as individual) >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> siprec mailing list >>>>>>>>>>>>> siprec@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> siprec mailing list >>>>>>>>>>>>> siprec@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> siprec mailing list >>>>>>>>>>>> siprec@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> >> > From john.elwell@siemens-enterprise.com Fri Jun 17 09:28:17 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FE211E8107 for ; Fri, 17 Jun 2011 09:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBO9dsWD-Xkg for ; Fri, 17 Jun 2011 09:28:16 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id EC84A9E8007 for ; Fri, 17 Jun 2011 09:28:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1308328086!15864397!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 23067 invoked from network); 17 Jun 2011 16:28:06 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-9.tower-174.messagelabs.com with SMTP; 17 Jun 2011 16:28:06 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 4E3521EB83ED for ; Fri, 17 Jun 2011 18:28:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 17 Jun 2011 18:28:06 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 17 Jun 2011 18:28:05 +0200 Thread-Topic: Preparation for next weeks' call (Thursday 2011-06-23) Thread-Index: AcwtC4kZFCdJa9kuRGGilpMVpTuhow== 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: [siprec] Preparation for next weeks' call (Thursday 2011-06-23) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 16:28:17 -0000 1. Presenters, please let me have your slides by Tuesday latest. Otherwise = you will lose your slot. 2. I had been expecting new versions of the metadata model and format draft= s by now - please post them in the next couple of days if you want them dis= cussed on Thursday. 3. There has been no discussion of Charles's draft on RTP (-01 posted yeste= rday, thanks Charles). If folks want that added to the agenda, I suggest th= ey start commenting on the list. 4. Materials and joining instructions available from here: http://trac.tools.ietf.org/wg/siprec/trac/wiki/WikiStart John = From john.elwell@siemens-enterprise.com Fri Jun 17 09:35:05 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C52121F8465 for ; Fri, 17 Jun 2011 09:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KRV0plIkwaB for ; Fri, 17 Jun 2011 09:35:04 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id B97FA21F8445 for ; Fri, 17 Jun 2011 09:35:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1308328494!40073121!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 2579 invoked from network); 17 Jun 2011 16:34:54 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-12.tower-27.messagelabs.com with SMTP; 17 Jun 2011 16:34:54 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 413741EB83EE; Fri, 17 Jun 2011 18:35:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 17 Jun 2011 18:35:02 +0200 From: "Elwell, John" To: "siprec@ietf.org" , "Charles Eckel (eckelcu)" Date: Fri, 17 Jun 2011 18:35:00 +0200 Thread-Topic: I-D Action: draft-eckel-siprec-rtp-rec-01.txt Thread-Index: AcwsaNcOEe0gqVPXQ0yXvD4ktkTVMwAo3uRA Message-ID: References: <20110616210242.4832.4179.idtracker@ietfa.amsl.com> In-Reply-To: <20110616210242.4832.4179.idtracker@ietfa.amsl.com> 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: [siprec] I-D Action: draft-eckel-siprec-rtp-rec-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 16:35:05 -0000 Charles, I still have a concern on the wording in section 13. It says: "If an SRC or SRS is sending RTP, it is RECOMMENDED to use symmetric =20 RTP." Why would an SRS send RTP (as opposed to RTCP)? John > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: 16 June 2011 22:03 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-eckel-siprec-rtp-rec-01.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Real-time Transport Protocol (RTP)=20 > Recommendations for SIPREC > Author(s) : Charles Eckel > Filename : draft-eckel-siprec-rtp-rec-01.txt > Pages : 11 > Date : 2011-06-16 >=20 > This document provides recommendations and guidelines for RTP and > RTCP in the context of SIPREC. This document exists as a=20 > standalone > document to facilitate discussion of the RTP=20 > recommendations, and it > is anticipated that portions of this document will be incorporated > into [I-D.portman-siprec-protocol] rather than this document itself > being adopted as a working group document. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > = From eckelcu@cisco.com Fri Jun 17 11:56:02 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19239E802A for ; Fri, 17 Jun 2011 11:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn5A3x4eXH6h for ; Fri, 17 Jun 2011 11:56:02 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id EF9759E8026 for ; Fri, 17 Jun 2011 11:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2919; q=dns/txt; s=iport; t=1308336961; x=1309546561; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=uBNxK8ilIU7QT2CL6xenL/o8zlfSwKIrgbHAs36LLkg=; b=lnTjAc7/9X9Bdqr3qbX/t22TdigyrVvFV7YIUyIG5OvBgCUUxVifs5uB F7srLy94pvvINvDKZGYZ+YFQJNuEN0BilmXPFobnLPDJBCNnR8e7YHhkO RzEKx1MRy14UznkYLK6/a17t8mry3wB0MktO8y5AnFE1Lq+lEOL/BY02a c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAG6i+02rRDoJ/2dsb2JhbABSl0ePCXepep12hicEhyCPJos1 X-IronPort-AV: E=Sophos;i="4.65,382,1304294400"; d="scan'208";a="339879608" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2011 18:56:01 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5HIu1sd007722; Fri, 17 Jun 2011 18:56:01 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Jun 2011 11:56:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jun 2011 11:55:59 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-eckel-siprec-rtp-rec-01.txt Thread-Index: AcwsaNcOEe0gqVPXQ0yXvD4ktkTVMwAo3uRAAAS6UJA= References: <20110616210242.4832.4179.idtracker@ietfa.amsl.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , X-OriginalArrivalTime: 17 Jun 2011 18:56:01.0414 (UTC) FILETIME=[338F6260:01CC2D20] Subject: Re: [siprec] I-D Action: draft-eckel-siprec-rtp-rec-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 18:56:02 -0000 Hi John, I tried to address this concern by handling RTP and RTCP separately: If an SRC or SRS is sending RTP, it is RECOMMENDED to use symmetric RTP. If an SRC or SRS is sending RTCP, it is RECOMMENDED to use symmetric RTCP. I agree that the SRS will generally not need to send RTP, and that only the RTCP recommendation will apply to the SRS, but I did not want to exclude it and did not see the harm in including the SRS in the considerations for RTP. I you think it is better to change to: If an SRC is sending RTP, it is RECOMMENDED to use symmetric RTP. If an SRC or SRS is sending RTCP, it is RECOMMENDED to use symmetric RTCP. Cheers, Charles > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, June 17, 2011 9:35 AM > To: siprec@ietf.org; Charles Eckel (eckelcu) > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt >=20 > Charles, >=20 > I still have a concern on the wording in section 13. It says: > "If an SRC or SRS is sending RTP, it is RECOMMENDED to use symmetric > RTP." > Why would an SRS send RTP (as opposed to RTCP)? >=20 > John >=20 >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: 16 June 2011 22:03 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > Title : Real-time Transport Protocol (RTP) > > Recommendations for SIPREC > > Author(s) : Charles Eckel > > Filename : draft-eckel-siprec-rtp-rec-01.txt > > Pages : 11 > > Date : 2011-06-16 > > > > This document provides recommendations and guidelines for RTP and > > RTCP in the context of SIPREC. This document exists as a > > standalone > > document to facilitate discussion of the RTP > > recommendations, and it > > is anticipated that portions of this document will be incorporated > > into [I-D.portman-siprec-protocol] rather than this document itself > > being adopted as a working group document. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.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-eckel-siprec-rtp-rec-01.txt > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From partr@cisco.com Fri Jun 17 13:22:47 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677EC9E8065 for ; Fri, 17 Jun 2011 13:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.342 X-Spam-Level: X-Spam-Status: No, score=-10.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOCAqaET+dkV for ; Fri, 17 Jun 2011 13:22:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEAF9E805F for ; Fri, 17 Jun 2011 13:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=1990; q=dns/txt; s=iport; t=1308342166; x=1309551766; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=aZ0VvT73v4TxXeoiorz/LJnDiyNhixv7a4vDrvbTS4w=; b=mR9YUCTYlvAcoSXZDkPv/g4ZPvWFeKTXodRsOBPU1AMvJwDC2nXFcP2E 6tJtcy/5qUNAO8SyE0R6FJG+le94vyMYerGBHeX2nJTV5RZ61Nj/fkbMm nbVxQRM2zparPUWigNX5nOmWtCKhZdPUt/M0ykhoxZwk0lQLhLUlGXGKy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUBAMy2+01Io8UQ/2dsb2JhbABSl0hBjkl3qkSdcIYnBIcejyiLHQ X-IronPort-AV: E=Sophos;i="4.65,383,1304294400"; d="scan'208";a="94598954" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2011 20:22:44 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5HKMhHL028907 for ; Fri, 17 Jun 2011 20:22:43 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 18 Jun 2011 01:52:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 18 Jun 2011 01:52:44 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review Request for draft-ram-siprec-metadata-format-02.txt Thread-Index: AcwtKTSuv7g1rIpnTFWCwTLYeo2iDAAAXerw From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 17 Jun 2011 20:22:44.0111 (UTC) FILETIME=[509BF1F0:01CC2D2C] Subject: [siprec] Review Request for draft-ram-siprec-metadata-format-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 20:22:47 -0000 Hi, As per the mailing list comments and meeting discussion, we have updated -02 draft of draft-ram-siprec-metadata-format and send it for review. The draft is available at http://www.ietf.org/id/draft-ram-siprec-metadata-format-02.txt. The following updates are done as part of -02 draft: =20 1) Changed recording element as a container element instead of recording-metadata element. Also, removed existing recording element as RS SIP dialog will carry those metadata info. =20 2) Updated XML examples, XML schema as per review comments =20 3) Made "group" element as an optional one=20 =20 4) Updated elements, attributes in metadata XML as per the latest metadata model. Could you please review and provide your expert comments on the draft. Thanks Partha =20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Saturday, June 18, 2011 1:30 AM To: Parthasarathi R (partr) Cc: Parthasarathi R (partr); Ram Mohan R (rmohanr) Subject: New Version Notification for draft-ram-siprec-metadata-format-02.txt A new version of I-D, draft-ram-siprec-metadata-format-02.txt has been successfully submitted by Parthasarathi Ravindran and posted to the IETF repository. Filename: draft-ram-siprec-metadata-format Revision: 02 Title: Session Initiation Protocol (SIP) Recording Metadata Format Creation date: 2011-06-17 WG ID: Individual Submission Number of pages: 19 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document focuses on the Recording metadata format which describes the communication session. =20 The IETF Secretariat From Henry.Lum@alcatel-lucent.com Fri Jun 17 13:44:30 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD509E8051 for ; Fri, 17 Jun 2011 13:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjIofqaoB+Gi for ; Fri, 17 Jun 2011 13:44:28 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 15F599E8033 for ; Fri, 17 Jun 2011 13:44:27 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p5HKiQJg026642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2011 15:44:26 -0500 (CDT) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5HKiOZ1018968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jun 2011 15:44:25 -0500 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p5HKiN1S021799; Fri, 17 Jun 2011 13:44:23 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Jun 2011 13:44:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jun 2011 13:44:21 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7407358376@NAHALD.us.int.genesyslab.com> In-Reply-To: <4DF8C4E0.8020409@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwraoGY85PiN+LzTEOpAI9MKAfySABwsWng References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> <4DF77EB5.9060009@cisco.com> <4DF8C4E0.8020409@cis! co.com> From: "Henry Lum" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 17 Jun 2011 20:44:23.0415 (UTC) FILETIME=[570E0070:01CC2D2F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: siprec@ietf.org Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 20:44:30 -0000 I thought the local ID is relative to the CS and not the SRC, meaning two cooperative SRCs should both refer to a MS as CS#1:1. That said, I am not objecting to the use of uuid for an MS if this makes synchronization between SRCs simpler. However, I still find it confusing to allow an MS to be moved across CS and participants. I worry that we can abuse the MS semantics to reuse MS as if it is a physical port of media since an MS is no longer tied to the lifetime of a CS. Keeping an MS to within a CS makes it clear about segments of a call when it gets transferred from person to person. It will be up to the SRS to stitch the segments of a call (multiple MS) together. Regards, Henry -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, June 15, 2011 10:43 AM To: Elwell, John Cc: siprec@ietf.org Subject: Re: [siprec] Can an MS object span several CSs in a CSG? On 6/15/2011 9:55 AM, Elwell, John wrote: > Paul, > > But if the two SRCs are somehow cooperating to the extent that they can share the same global ID for the CS, could they not also share the same local ID for the MS? Why does it need to be a global ID? They could *know* each other's local id for the MS. They might even agree to use the *same* value for the local id. E.g. we have SRC#1 and SRC#2, each using 123 as the local id for the=20 "same" stream. But to the SRS, there is one MS with id SRC#1:123, and another MS with=20= SRC#2:123. It does not know they are the same. (That is the point of=20 local scoping.) So even though the two SRCs know they are talking about the same MS they have no way to tell that to the SRS. Thanks, Paul > John > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 14 June 2011 16:31 >> To: siprec@ietf.org >> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >> >> John, >> >> Consider another case: two SRCs in the same CS (perhaps one at each >> "end".) They are both sending metadata about the same CS and MSs. >> >> Suppose they want to cooperate with each other. They have the >> potential >> to use the same ID to reference the CS, so that the SRS will >> know they >> are talking about the same one. But with RS-specific MS ids >> there is no >> way for them to indicate that they are talking about the same >> MSs. With >> global MS ids, they could accomplish this. >> >> Thanks, >> Paul >> >> On 6/14/2011 11:03 AM, Elwell, John wrote: >>> Partha, >>> >>> Thanks for the examples. The character count for the delta >> is about 2500 when a new MS is created compared to about 2100 >> when the MS is retained. This seems to be in line with my >> previous gut feeling. >>> >>> Concerning the need for "SRS implementers to guess how old >> MS and new MS are related", I don't think they are related, >> except by having other things in common like a common >> participant or a common CSG. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>> Sent: 14 June 2011 13:15 >>>> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; Ram >>>> Mohan R (rmohanr); siprec@ietf.org >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>> >>>> Hi all, >>>> >>>> Sorry for the delay. Just to double confirm everybody >>>> understanding with >>>> SIP message example, I added the example with creating new MS and >>>> reusing the same MS as an attachment with this mail. >>>> >>>> Please note that creating new MS is putting SRS >> implementers to guess >>>> how old MS and new MS are related. Also, few scenario like >> Even after >>>> looking into the example, the intention is to use local >> variable, I'm >>>> ok. >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) >>>> Sent: Friday, June 10, 2011 10:57 PM >>>> To: Leon Portman; Elwell, John; Parthasarathi R (partr); >> Ram Mohan R >>>> (rmohanr); siprec@ietf.org >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>> >>>> Please excuse the delay. I am catching up after having been away on >>>> vacation. >>>> In light of this better understanding of the use case, I also >>>> prefer the >>>> option favored by John and Leon to model as a separate MS. In this >>>> specific case, I would expect the properties of the MS to >>>> change when A >>>> is transferred to C, so I expect the overhead in creating >> a new MS vs. >>>> reusing the same MS to be minimal and not worth the added >>>> complexity to >>>> the model. >>>> >>>> Cheers, >>>> Charles >>>> >>>>> -----Original Message----- >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>> Sent: Tuesday, May 31, 2011 6:19 AM >>>>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel >> (eckelcu); >>>>> Ram Mohan R (rmohanr); siprec@ietf.org >>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>> >>>>> Hello >>>>> >>>>> I also having a problem even without a quantification of number of >>>>> update messages that CS MS is remains same between >>>> different CS. So I >>>> do prefer to keep it simple and keep it per CS. >>>>> >>>>> Leon >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Elwell, John >>>>> Sent: Friday, May 27, 2011 12:26 PM >>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R >>>>> (rmohanr); siprec@ietf.org >>>>> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>> Sent: 26 May 2011 15:55 >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); >>>>>> siprec@ietf.org >>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>>> >>>>>> John, >>>>>> >>>>>> The callflow mentioned by me is the basic primitive in the call >>>>>> center scenario wherein customer (participant) is same throughout >>>>>> the session and agents are changed using transfer service >>>> and B2BUA >>>> acts as SRC. >>>>>> IMO, it is one of key requirement to be considered in case we >>>>>> support for partial-update. >>>>> [JRE] Agreed the Participant remains the same, but we are >> discussing >>>> MS. >>>>> >>>>>> This may not be the only callflow where MS partial-update is >>>>>> required in this fashion. During -00 format draft, I thought that >>>>>> the partial-update is not required but lot of folks raised the >>>>>> concern that partial update is important. Current, -01 >>>> format draft >>>>>> is designed to support partial-update. Now, You propose >>>> to restrict >>>>>> MS partial-update across CS. IMO, it is a not good idea >>>> to restrict >>>>>> in the protocol level. Anyway, I think that we need >>>> others opinion >>>>>> before conclude here. >>>>> [JRE] I am not opposed to partial update, but I would >> like to avoid >>>>> distorting the model just to gain some efficiency improvements in >>>>> certain cases. To me it is not intuitive that a MS on one >>>> CS and an MS >>>> >>>>> on another CS are the same object, just because one of the >>>>> Participants is common to both CSs. In the transfer-between-agents >>>> example, although one of the Participants is common to the >>>> two CSs, this >>>> is not true for the other Participants. >>>>> >>>>> Let's try to quantify the efficiency improvement. In the blind >>>>> transfer case, the partial updates would at least have to include: >>>>> - the removal of P1 from CS1 (where P1 is the first agent >>>> and CS1 is >>>>> the first CS); >>>>> - the removal of P2 from CS1 (where P2 is the transferred >>>>> participant); >>>>> - the termination of CS1; >>>>> - the removal of CS1 from CSG1; >>>>> - the creation of CS2 (the CS that results from transfer); >>>>> - the addition to of CS2 to CSG1; >>>>> - the addition of P2 to CSG1; >>>>> - the addition of P3 to CS2 (where P3 is the second agent); >>>>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); >>>>> - the removal of P2 as a recipient of MS1; >>>>> - the termination of MS1; >>>>> - the creation of MS3; >>>>> - the addition of P3 as a sender of MS3; >>>>> - the addition of P2 as a recipient of MS3. >>>>> >>>>> So all we are arguing about is whether we also include in >>>> the partial >>>>> updates EITHER (this I think is your proposal): >>>>> - the removal of P1 as a recipient of MS2; >>>>> - the addition of P3 as a recipient of MS2; >>>>> >>>>> OR >>>>> - the removal of P1 as recipient of MS2; >>>>> - the removal of P2 as a sender of MS2; >>>>> - the termination MS2; >>>>> - the creation of MS4; >>>>> - the addition of P3 as a recipient of MS4; >>>>> - the addition of P2 as a sender of MS4. >>>>> >>>>> So with the first option the total number of deltas is 14+2=3D16. >>>>> For the second option the total number of deltas is 14+6=3D20. >>>>> >>>>> Some of the details might be wrong, but I hope you can see >>>> the point I >>>> >>>>> am getting at. Looked at this way, the efficiency saving by >>>> recycling >>>>> MS2 for use in consecutive CSs is relatively small. Or >> perhaps your >>>>> intention is also to recycle MS1 (this time, the recipient >>>> remaining >>>>> the same but the sender changing). That would reduce the number of >>>>> deltas slightly further. The impact on XML size might not >>>> be quite in >>>>> proportion to the reduction in the number of deltas, since by >>>> recycling MS2 it has to have a global identifier, not an identifier >>>> local to a CS. Or perhaps it could have an identifier >> local to a CSG. >>>>> >>>>> I also see that with your proposal it doesn't force the MS to be >>>>> recycled - an SRC could still choose to model it as separate MSs. >>>>> However, in that case it would still need to use global >> identifiers >>>> for MSs. >>>>> >>>>> I am not necessarily opposed to your proposal for recycling >>>> MS objects >>>> >>>>> outside the context of a single CS - I can see advantages and >>>>> disadvantages. I just want to make sure the group makes >> an informed >>>> decision. >>>>> >>>>> John (as individual) >>>>> >>>>> >>>>>> >>>>>> Enhancing label attribute across the multiple SIP message to tie >>>>>> between Metadata XML and RS SDP m-line is possible. SRC has to >>>>>> ensure that label for the given RS SDP m-line should have >>>> same label >>>> >>>>>> throughout single CSG even though it span across multiple CS and >>>>>> multiple RS. Even then, it will not meet partial-update >>>> requirement >>>>>> as mentioned below in this mail thread. At this moment, >>>> I'm favoring >>>> >>>>>> URN UUID and not label attribute enhancement. >>>>>> >>>>>> Please read inline >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>> Sent: Wednesday, May 25, 2011 7:17 PM >>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R >>>>>> (rmohanr); siprec@ietf.org >>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>> Sent: 25 May 2011 08:48 >>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R >>>> (rmohanr); >>>>>>> siprec@ietf.org >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >>>> in a CSG? >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> =3D >>>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA >>>>>>> converts REFER >>>>>>> >>>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA >>>>>>> updates RS >>>>>>>> with CS2, Participant1 as A& participant2 as C, >>>> MS1(A's media >>>>>>>> stream), MS2(C's media stream). There is no update on RS1, >>>>>>> CSG1, MS1, >>>>>>>> MS2. MS2 will become MS2 with the new association and >>>> in terms >>>>>>>> of format, it will associate with tag >>>>>>> [JRE] What harm is done (what do we lose) if, following >>>>>> transfer, A's >>>>>>> media stream is called MS3 and C's media stream is called MS4? >>>>>>> >>>>>> >>>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> =3D >>>>>>> To indicate MS1 as MS3, MS1 media block has to be >>>>>> stopped in >>>>>>> the partial-update and start MS3 separate which is not >>>> required in >>>> >>>>>>> case there is a means to have common MS1. >>>>>> [JRE] It seems this distorts the model in order to give >>>> some minor >>>>>> efficiency improvement during metadata updates. I doubt that this >>>>>> alone is sufficient justification for having the MS >>>> persist from one >>>> >>>>>> CS to another CS. >>>>>> >>>>>>> >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>>>>>> MS3 can reference the same SDP m-line (through a=3Dlabel) as MS1,= >>>>>>> and likewise MS4 could reference the same SDP m-line as >>>> MS2, if we >>>> >>>>>>> are concerned about recycling media descriptions in RS SDP. >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> As you mentioned, we will lose recycling of media >>>>>> description >>>>>>> in RS SDP without common value in media stream object for this >>>>>>> scenario. >>>>>> [JRE] I don't understand your point. With my proposal we >>>> can still >>>>>> recycle RS SDP m-lines. >>>>>> >>>>>> Agreed that Recycle is possible with your proposal. >>>>>> I indicated >>>>>> the need for unique-id in this requirement >>>>>> >>>>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label >>>>>> attribute >>>>>>> scope is within single SIP message and not required to >>>> be unique >>>>>>> in all SIP messages of a given dialog. >>>>>> [JRE] But I think we could nail that down as a requirement of the >>>>>> SIPREC protocol. >>>>>> >>>>>> John (as individual) >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Charles Eckel (eckelcu) >>>>>>>> Sent: Wednesday, May 25, 2011 1:39 AM >>>>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); >>>>>> 'Elwell, John'; >>>>>>>> 'siprec@ietf.org' >>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a >>>> CSG? >>>>>>>> >>>>>>>> Hi Ram, >>>>>>>> >>>>>>>> I think that is many cases, they will be treated as >>>> separate MSs >>>> >>>>>>>> due to the complexities you mention. However, I am trying to >>>>>> understand if >>>>>>>> Partha feels allowing an SRC to treat them as a single MS is >>>>>>>> still required. If not, then what is a use case? A concrete >>>>>>>> example would help me, and potentially others, to better >>>>>>>> understand the >>>>>>> motivation behind >>>>>>>> Partha's requirement for modeling media from multiple CSs >>>>>>> as a single >>>>>>>> MS. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Charles >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ram Mohan R (rmohanr) >>>>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM >>>>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >>>>>>> Elwell, John; >>>>>>>>> siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >>>>>> in a CSG? >>>>>>>>> >>>>>>>>> Charles, >>>>>>>>> >>>>>>>>> I did bring about this specific usecase of MMOH/MOH >>>>>> stream being >>>>>>>>> played to different participants earlier and suggested that >>>>>>>> they have >>>>>>>>> to treated as a same MS across multiple CSs >>>>>> (potentially recorded >>>>>>>> using multiple RSs). >>>>>>>>> Refer >>>>>>>>> >>>>>> http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html >>>>>>>>> >>>>>>>>> We had several discussions on it and it and several >>>>>> folks were in >>>>>>>>> favor of treating it as separate MS as there would be >>>>>>>> complexity in DB >>>>>>>> design. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ram >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>> Behalf Of Charles Eckel (eckelcu) >>>>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM >>>>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org >>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>>>> in a CSG? >>>>>>>>>> >>>>>>>>>> Hi Partha, >>>>>>>>>> >>>>>>>>>> Is an example of this the same music on hold audio stream >>>>>>>> existing >>>>>>>>>> as the same MS within multiple CSs? If so, then I >>>>>>> understand your >>>>>>>>>> requirement to be that the SRC be able to >>>> indicate multiple >>>>>>>>>> instances of this audio stream within several CSs as >>>>>>>> being the same >>>>>>>>>> MS. Is that correct? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Charles >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>> Behalf Of Parthasarathi R (partr) >>>>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM >>>>>>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>>>>> in a CSG? >>>>>>>>>>> >>>>>>>>>>> John, >>>>>>>>>>> >>>>>>>>>>> I agree that it is not mandatory to consider recorded >>>>>>>> stream of a >>>>>>>>>>> specific participant in several CS within the same >>>>>> CSG as one >>>>>>>>>> recorded >>>>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a >>>>>>>> SRC in case >>>>>>>>>>> it wishes to design in such a way. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Partha >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>> Behalf >>>>>>>>>>> Of Elwell, John >>>>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM >>>>>>>>>>> To: siprec@ietf.org >>>>>>>>>>> Subject: [siprec] Can an MS object span several CSs >>>>>> in a CSG? >>>>>>>>>>> >>>>>>>>>>> We seem to have consensus that a Media Stream object >>>>>>>> represents a >>>>>>>>>>> recorded media stream, contributed to by one, >>>>>> several or all >>>>>>>>>>> Participants. However, Partha also wrote: >>>>>>>>>>> >>>>>>>>>>> "2) Each MS lifetime related to CSG because participant >>>>>>>> may move >>>>>>>>>>> from one CS to another CS within single CSG and also >>>>>>>> CSG will span >>>>>>>> >>>>>>>>>>> across multiple RS." >>>>>>>>>>> >>>>>>>>>>> I am not sure we had resolved this during earlier >>>>>>>> discussions on >>>>>>>>>>> the scope of an MS object. Although the same >>>>>> Participant can >>>>>>>>>>> participate >>>>>>>>>> in >>>>>>>>>>> several CSs within the same CSG, I don't think the >>>>>>>> recorded media >>>>>>>>>>> streams need to be considered the same. Any other views? >>>>>>>>>>> >>>>>>>>>>> John (as individual) >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>> _______________________________________________ >>>>>>>>>> siprec mailing list >>>>>>>>>> siprec@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From pkyzivat@cisco.com Fri Jun 17 14:11:30 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AF921F8458 for ; Fri, 17 Jun 2011 14:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEr7uC3YbwrZ for ; Fri, 17 Jun 2011 14:11:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1736621F8460 for ; Fri, 17 Jun 2011 14:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=22490; q=dns/txt; s=iport; t=1308345087; x=1309554687; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=k794LKNMmmIMT0zzyeV4hnuXWVGA8/jyTztOhLDIAGA=; b=DngGpg+Z5LitpIRI86SnmVCwf/NfyE+ov50UUhe5V+RLPrZ4ZPgYQ7G7 lOxfrcqCeMb9yvbObYDnyNFd6htoj3O1Z6jXUBtgs4Se6l8kzWCzg6TnA xkDsACI51qDwLYqiT2QY7sVIdQiHZF3UDjHoQSp2leGEwgiLMTSBryjoy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAIXC+02Q/khR/2dsb2JhbABSl0qPCneIc6F4nXGGJwSRXoRfizo X-IronPort-AV: E=Sophos;i="4.65,383,1304294400"; d="scan'208";a="94601749" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2011 21:11:23 +0000 Received: from [10.86.254.178] ([10.86.254.178]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5HLBLmL002298; Fri, 17 Jun 2011 21:11:21 GMT Message-ID: <4DFBC2F9.1050806@cisco.com> Date: Fri, 17 Jun 2011 17:11:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Henry Lum References: <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> <4DF77EB5.9060009@cisco.com> <4DF8C4E0.8020409@cis! co.com> <059AF07365DC474393A19A3AF187DF7407358376@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7407358376@NAHALD.us.int.genesyslab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 21:11:30 -0000 On 6/17/2011 4:44 PM, Henry Lum wrote: > I thought the local ID is relative to the CS and not the SRC, meaning > two cooperative SRCs should both refer to a MS as CS#1:1. Hmm. I didn't think that is what was proposed. But it would work as long as the same MS cannot be in two CSs. (And I have so far been studiously staying out of that discussion.) Thanks, Paul > That said, I > am not objecting to the use of uuid for an MS if this makes > synchronization between SRCs simpler. > > However, I still find it confusing to allow an MS to be moved across CS > and participants. I worry that we can abuse the MS semantics to reuse MS > as if it is a physical port of media since an MS is no longer tied to > the lifetime of a CS. Keeping an MS to within a CS makes it clear about > segments of a call when it gets transferred from person to person. It > will be up to the SRS to stitch the segments of a call (multiple MS) > together. > > Regards, > Henry > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Wednesday, June 15, 2011 10:43 AM > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > On 6/15/2011 9:55 AM, Elwell, John wrote: >> Paul, >> >> But if the two SRCs are somehow cooperating to the extent that they > can share the same global ID for the CS, could they not also share the > same local ID for the MS? Why does it need to be a global ID? > > They could *know* each other's local id for the MS. > They might even agree to use the *same* value for the local id. > > E.g. we have SRC#1 and SRC#2, each using 123 as the local id for the > "same" stream. > > But to the SRS, there is one MS with id SRC#1:123, and another MS with > SRC#2:123. It does not know they are the same. (That is the point of > local scoping.) > > So even though the two SRCs know they are talking about the same MS they > > have no way to tell that to the SRS. > > Thanks, > Paul > >> John >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: 14 June 2011 16:31 >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >>> >>> John, >>> >>> Consider another case: two SRCs in the same CS (perhaps one at each >>> "end".) They are both sending metadata about the same CS and MSs. >>> >>> Suppose they want to cooperate with each other. They have the >>> potential >>> to use the same ID to reference the CS, so that the SRS will >>> know they >>> are talking about the same one. But with RS-specific MS ids >>> there is no >>> way for them to indicate that they are talking about the same >>> MSs. With >>> global MS ids, they could accomplish this. >>> >>> Thanks, >>> Paul >>> >>> On 6/14/2011 11:03 AM, Elwell, John wrote: >>>> Partha, >>>> >>>> Thanks for the examples. The character count for the delta >>> is about 2500 when a new MS is created compared to about 2100 >>> when the MS is retained. This seems to be in line with my >>> previous gut feeling. >>>> >>>> Concerning the need for "SRS implementers to guess how old >>> MS and new MS are related", I don't think they are related, >>> except by having other things in common like a common >>> participant or a common CSG. >>>> >>>> John (as individual) >>>> >>>>> -----Original Message----- >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>> Sent: 14 June 2011 13:15 >>>>> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; Ram >>>>> Mohan R (rmohanr); siprec@ietf.org >>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>> >>>>> Hi all, >>>>> >>>>> Sorry for the delay. Just to double confirm everybody >>>>> understanding with >>>>> SIP message example, I added the example with creating new MS and >>>>> reusing the same MS as an attachment with this mail. >>>>> >>>>> Please note that creating new MS is putting SRS >>> implementers to guess >>>>> how old MS and new MS are related. Also, few scenario like >>> Even after >>>>> looking into the example, the intention is to use local >>> variable, I'm >>>>> ok. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: Charles Eckel (eckelcu) >>>>> Sent: Friday, June 10, 2011 10:57 PM >>>>> To: Leon Portman; Elwell, John; Parthasarathi R (partr); >>> Ram Mohan R >>>>> (rmohanr); siprec@ietf.org >>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>> >>>>> Please excuse the delay. I am catching up after having been away on >>>>> vacation. >>>>> In light of this better understanding of the use case, I also >>>>> prefer the >>>>> option favored by John and Leon to model as a separate MS. In this >>>>> specific case, I would expect the properties of the MS to >>>>> change when A >>>>> is transferred to C, so I expect the overhead in creating >>> a new MS vs. >>>>> reusing the same MS to be minimal and not worth the added >>>>> complexity to >>>>> the model. >>>>> >>>>> Cheers, >>>>> Charles >>>>> >>>>>> -----Original Message----- >>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>> Sent: Tuesday, May 31, 2011 6:19 AM >>>>>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel >>> (eckelcu); >>>>>> Ram Mohan R (rmohanr); siprec@ietf.org >>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>>> >>>>>> Hello >>>>>> >>>>>> I also having a problem even without a quantification of number of >>>>>> update messages that CS MS is remains same between >>>>> different CS. So I >>>>> do prefer to keep it simple and keep it per CS. >>>>>> >>>>>> Leon >>>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of Elwell, John >>>>>> Sent: Friday, May 27, 2011 12:26 PM >>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R >>>>>> (rmohanr); siprec@ietf.org >>>>>> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>> Sent: 26 May 2011 15:55 >>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); >>>>>>> siprec@ietf.org >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> The callflow mentioned by me is the basic primitive in the call >>>>>>> center scenario wherein customer (participant) is same throughout >>>>>>> the session and agents are changed using transfer service >>>>> and B2BUA >>>>> acts as SRC. >>>>>>> IMO, it is one of key requirement to be considered in case we >>>>>>> support for partial-update. >>>>>> [JRE] Agreed the Participant remains the same, but we are >>> discussing >>>>> MS. >>>>>> >>>>>>> This may not be the only callflow where MS partial-update is >>>>>>> required in this fashion. During -00 format draft, I thought that >>>>>>> the partial-update is not required but lot of folks raised the >>>>>>> concern that partial update is important. Current, -01 >>>>> format draft >>>>>>> is designed to support partial-update. Now, You propose >>>>> to restrict >>>>>>> MS partial-update across CS. IMO, it is a not good idea >>>>> to restrict >>>>>>> in the protocol level. Anyway, I think that we need >>>>> others opinion >>>>>>> before conclude here. >>>>>> [JRE] I am not opposed to partial update, but I would >>> like to avoid >>>>>> distorting the model just to gain some efficiency improvements in >>>>>> certain cases. To me it is not intuitive that a MS on one >>>>> CS and an MS >>>>> >>>>>> on another CS are the same object, just because one of the >>>>>> Participants is common to both CSs. In the transfer-between-agents >>>>> example, although one of the Participants is common to the >>>>> two CSs, this >>>>> is not true for the other Participants. >>>>>> >>>>>> Let's try to quantify the efficiency improvement. In the blind >>>>>> transfer case, the partial updates would at least have to include: >>>>>> - the removal of P1 from CS1 (where P1 is the first agent >>>>> and CS1 is >>>>>> the first CS); >>>>>> - the removal of P2 from CS1 (where P2 is the transferred >>>>>> participant); >>>>>> - the termination of CS1; >>>>>> - the removal of CS1 from CSG1; >>>>>> - the creation of CS2 (the CS that results from transfer); >>>>>> - the addition to of CS2 to CSG1; >>>>>> - the addition of P2 to CSG1; >>>>>> - the addition of P3 to CS2 (where P3 is the second agent); >>>>>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); >>>>>> - the removal of P2 as a recipient of MS1; >>>>>> - the termination of MS1; >>>>>> - the creation of MS3; >>>>>> - the addition of P3 as a sender of MS3; >>>>>> - the addition of P2 as a recipient of MS3. >>>>>> >>>>>> So all we are arguing about is whether we also include in >>>>> the partial >>>>>> updates EITHER (this I think is your proposal): >>>>>> - the removal of P1 as a recipient of MS2; >>>>>> - the addition of P3 as a recipient of MS2; >>>>>> >>>>>> OR >>>>>> - the removal of P1 as recipient of MS2; >>>>>> - the removal of P2 as a sender of MS2; >>>>>> - the termination MS2; >>>>>> - the creation of MS4; >>>>>> - the addition of P3 as a recipient of MS4; >>>>>> - the addition of P2 as a sender of MS4. >>>>>> >>>>>> So with the first option the total number of deltas is 14+2=16. >>>>>> For the second option the total number of deltas is 14+6=20. >>>>>> >>>>>> Some of the details might be wrong, but I hope you can see >>>>> the point I >>>>> >>>>>> am getting at. Looked at this way, the efficiency saving by >>>>> recycling >>>>>> MS2 for use in consecutive CSs is relatively small. Or >>> perhaps your >>>>>> intention is also to recycle MS1 (this time, the recipient >>>>> remaining >>>>>> the same but the sender changing). That would reduce the number of >>>>>> deltas slightly further. The impact on XML size might not >>>>> be quite in >>>>>> proportion to the reduction in the number of deltas, since by >>>>> recycling MS2 it has to have a global identifier, not an identifier >>>>> local to a CS. Or perhaps it could have an identifier >>> local to a CSG. >>>>>> >>>>>> I also see that with your proposal it doesn't force the MS to be >>>>>> recycled - an SRC could still choose to model it as separate MSs. >>>>>> However, in that case it would still need to use global >>> identifiers >>>>> for MSs. >>>>>> >>>>>> I am not necessarily opposed to your proposal for recycling >>>>> MS objects >>>>> >>>>>> outside the context of a single CS - I can see advantages and >>>>>> disadvantages. I just want to make sure the group makes >>> an informed >>>>> decision. >>>>>> >>>>>> John (as individual) >>>>>> >>>>>> >>>>>>> >>>>>>> Enhancing label attribute across the multiple SIP message to tie >>>>>>> between Metadata XML and RS SDP m-line is possible. SRC has to >>>>>>> ensure that label for the given RS SDP m-line should have >>>>> same label >>>>> >>>>>>> throughout single CSG even though it span across multiple CS and >>>>>>> multiple RS. Even then, it will not meet partial-update >>>>> requirement >>>>>>> as mentioned below in this mail thread. At this moment, >>>>> I'm favoring >>>>> >>>>>>> URN UUID and not label attribute enhancement. >>>>>>> >>>>>>> Please read inline >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>> Sent: Wednesday, May 25, 2011 7:17 PM >>>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R >>>>>>> (rmohanr); siprec@ietf.org >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>>> Sent: 25 May 2011 08:48 >>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R >>>>> (rmohanr); >>>>>>>> siprec@ietf.org >>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >>>>> in a CSG? >>>>>>>> >>>>>>>> John, >>>>>>>> >>>>>>>> >>>>> ================================================================== >>>>>>>> = >>>>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA >>>>>>>> converts REFER >>>>>>>> >>>>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA >>>>>>>> updates RS >>>>>>>>> with CS2, Participant1 as A& participant2 as C, >>>>> MS1(A's media >>>>>>>>> stream), MS2(C's media stream). There is no update on RS1, >>>>>>>> CSG1, MS1, >>>>>>>>> MS2. MS2 will become MS2 with the new association and >>>>> in terms >>>>>>>>> of format, it will associate with tag >>>>>>>> [JRE] What harm is done (what do we lose) if, following >>>>>>> transfer, A's >>>>>>>> media stream is called MS3 and C's media stream is called MS4? >>>>>>>> >>>>>>> >>>>> >>> ==================================================================== >>>>>>> = >>>>>>>> To indicate MS1 as MS3, MS1 media block has to be >>>>>>> stopped in >>>>>>>> the partial-update and start MS3 separate which is not >>>>> required in >>>>> >>>>>>>> case there is a means to have common MS1. >>>>>>> [JRE] It seems this distorts the model in order to give >>>>> some minor >>>>>>> efficiency improvement during metadata updates. I doubt that this >>>>>>> alone is sufficient justification for having the MS >>>>> persist from one >>>>> >>>>>>> CS to another CS. >>>>>>> >>>>>>>> >>>>>>>> ============================================================== >>>>>>>> ========== >>>>>>>> ======================= >>>>>>>> MS3 can reference the same SDP m-line (through a=label) as MS1, >>>>>>>> and likewise MS4 could reference the same SDP m-line as >>>>> MS2, if we >>>>> >>>>>>>> are concerned about recycling media descriptions in RS SDP. >>>>>>>> ============================================================== >>>>>>>> ========== >>>>>>>> ================== >>>>>>>> As you mentioned, we will lose recycling of media >>>>>>> description >>>>>>>> in RS SDP without common value in media stream object for this >>>>>>>> scenario. >>>>>>> [JRE] I don't understand your point. With my proposal we >>>>> can still >>>>>>> recycle RS SDP m-lines. >>>>>>> >>>>>>> Agreed that Recycle is possible with your proposal. >>>>>>> I indicated >>>>>>> the need for unique-id in this requirement >>>>>>> >>>>>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label >>>>>>> attribute >>>>>>>> scope is within single SIP message and not required to >>>>> be unique >>>>>>>> in all SIP messages of a given dialog. >>>>>>> [JRE] But I think we could nail that down as a requirement of the >>>>>>> SIPREC protocol. >>>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> John (as individual) >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Charles Eckel (eckelcu) >>>>>>>>> Sent: Wednesday, May 25, 2011 1:39 AM >>>>>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); >>>>>>> 'Elwell, John'; >>>>>>>>> 'siprec@ietf.org' >>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a >>>>> CSG? >>>>>>>>> >>>>>>>>> Hi Ram, >>>>>>>>> >>>>>>>>> I think that is many cases, they will be treated as >>>>> separate MSs >>>>> >>>>>>>>> due to the complexities you mention. However, I am trying to >>>>>>> understand if >>>>>>>>> Partha feels allowing an SRC to treat them as a single MS is >>>>>>>>> still required. If not, then what is a use case? A concrete >>>>>>>>> example would help me, and potentially others, to better >>>>>>>>> understand the >>>>>>>> motivation behind >>>>>>>>> Partha's requirement for modeling media from multiple CSs >>>>>>>> as a single >>>>>>>>> MS. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Charles >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Ram Mohan R (rmohanr) >>>>>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM >>>>>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >>>>>>>> Elwell, John; >>>>>>>>>> siprec@ietf.org >>>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >>>>>>> in a CSG? >>>>>>>>>> >>>>>>>>>> Charles, >>>>>>>>>> >>>>>>>>>> I did bring about this specific usecase of MMOH/MOH >>>>>>> stream being >>>>>>>>>> played to different participants earlier and suggested that >>>>>>>>> they have >>>>>>>>>> to treated as a same MS across multiple CSs >>>>>>> (potentially recorded >>>>>>>>> using multiple RSs). >>>>>>>>>> Refer >>>>>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html >>>>>>>>>> >>>>>>>>>> We had several discussions on it and it and several >>>>>>> folks were in >>>>>>>>>> favor of treating it as separate MS as there would be >>>>>>>>> complexity in DB >>>>>>>>> design. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Ram >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>>> Behalf Of Charles Eckel (eckelcu) >>>>>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM >>>>>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org >>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>>>>> in a CSG? >>>>>>>>>>> >>>>>>>>>>> Hi Partha, >>>>>>>>>>> >>>>>>>>>>> Is an example of this the same music on hold audio stream >>>>>>>>> existing >>>>>>>>>>> as the same MS within multiple CSs? If so, then I >>>>>>>> understand your >>>>>>>>>>> requirement to be that the SRC be able to >>>>> indicate multiple >>>>>>>>>>> instances of this audio stream within several CSs as >>>>>>>>> being the same >>>>>>>>>>> MS. Is that correct? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Charles >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>>> Behalf Of Parthasarathi R (partr) >>>>>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM >>>>>>>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>>>>>> in a CSG? >>>>>>>>>>>> >>>>>>>>>>>> John, >>>>>>>>>>>> >>>>>>>>>>>> I agree that it is not mandatory to consider recorded >>>>>>>>> stream of a >>>>>>>>>>>> specific participant in several CS within the same >>>>>>> CSG as one >>>>>>>>>>> recorded >>>>>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a >>>>>>>>> SRC in case >>>>>>>>>>>> it wishes to design in such a way. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Partha >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>>> Behalf >>>>>>>>>>>> Of Elwell, John >>>>>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM >>>>>>>>>>>> To: siprec@ietf.org >>>>>>>>>>>> Subject: [siprec] Can an MS object span several CSs >>>>>>> in a CSG? >>>>>>>>>>>> >>>>>>>>>>>> We seem to have consensus that a Media Stream object >>>>>>>>> represents a >>>>>>>>>>>> recorded media stream, contributed to by one, >>>>>>> several or all >>>>>>>>>>>> Participants. However, Partha also wrote: >>>>>>>>>>>> >>>>>>>>>>>> "2) Each MS lifetime related to CSG because participant >>>>>>>>> may move >>>>>>>>>>>> from one CS to another CS within single CSG and also >>>>>>>>> CSG will span >>>>>>>>> >>>>>>>>>>>> across multiple RS." >>>>>>>>>>>> >>>>>>>>>>>> I am not sure we had resolved this during earlier >>>>>>>>> discussions on >>>>>>>>>>>> the scope of an MS object. Although the same >>>>>>> Participant can >>>>>>>>>>>> participate >>>>>>>>>>> in >>>>>>>>>>>> several CSs within the same CSG, I don't think the >>>>>>>>> recorded media >>>>>>>>>>>> streams need to be considered the same. Any other views? >>>>>>>>>>>> >>>>>>>>>>>> John (as individual) >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> siprec mailing list >>>>>>>>>>>> siprec@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> siprec mailing list >>>>>>>>>>>> siprec@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > > ------------------------------------------------------------------------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. > > From partr@cisco.com Fri Jun 17 14:23:05 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF25A11E80ED for ; Fri, 17 Jun 2011 14:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.774 X-Spam-Level: X-Spam-Status: No, score=-9.774 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfKJDrDl3dHh for ; Fri, 17 Jun 2011 14:23:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 46E5A11E807F for ; Fri, 17 Jun 2011 14:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=33192; q=dns/txt; s=iport; t=1308345782; x=1309555382; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=O3yGq4lfjnONhbryRGHU7Bk/C85VlATs3C+lhvBAV2Q=; b=Zb7YVML07aIrEWvk0rODx0BUeVB95B8n1jvDKN5Ux18jwdVtSz//ecVx BL7wigldlLA4LXm2vlb0hQrTRH2Cu1iCD9wO/UQ2N7PSvGubXg6XvbgX+ jmbuFh0DnVDqggyTxic6I4W0lMKl/4b4oJ0DcmQarsU8w+G4+7uujMR2Q s=; X-Files: MS across CS with full msg.txt : 6713 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAOfE+01Io8UQ/2dsb2JhbABEDpdNjwp3iHOiLJ1wgxqDDQSHHoVziTWLHQ X-IronPort-AV: E=Sophos;i="4.65,383,1304294400"; d="txt'?scan'208";a="94602418" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2011 21:22:59 +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 p5HLMxxp003922; Fri, 17 Jun 2011 21:22:59 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 18 Jun 2011 02:52:59 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC2D34.BA9BB4C1" Date: Sat, 18 Jun 2011 02:52:55 +0530 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF7407358376@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwraoGY85PiN+LzTEOpAI9MKAfySABwsWngAAEpqOA= References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> <4DF77EB5.9060009@cisco.com><4DF8C4E0.8020409@cis! co.com> <059AF07365DC474393A19A3AF187DF7407358376@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 17 Jun 2011 21:22:59.0351 (UTC) FILETIME=[BB75CA70:01CC2D34] Cc: siprec@ietf.org Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 21:23:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2D34.BA9BB4C1 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Henry, =20 However, I still find it confusing to allow an MS to be moved across CS and participants. I worry that we can abuse the MS semantics to reuse MS as if it is a physical port of media since an MS is no longer tied to the lifetime of a CS. Keeping an MS to within a CS makes it clear about segments of a call when it gets transferred from person to person. It will be up to the SRS to stitch the segments of a call (multiple MS) together. The clear demarcation exists for transfer from person to person exists using different CS-id after the transfer. I'm worried about stitching the segments of a call (session) in case same media type with multiple MS exists between CS. Say media stream of same media type MS1 & MS2 in CS1 of participant1 corresponds to MS3 & MS4 in CS2 of participant2 in single CSG, how to identify MS1 corresponds to MS3 or MS4 in CS2. I agree that it is possible to say that SRS should have some extended metadata mechanism to achieve to this but I preferred in case it is handled as part of metadata itself. As John mentioned below, the local-id is not going to save the bandwidth in the transfer scenario. Even I tried to see the example with full metadata XML update (instead of partial update) wherein the size of full message is less that local-id MS with partial update. I attached the message for your reference. Also, global id (URN UUID) will be able to achieve all the functionality of local-id (XML:id) but not the other way around. Say, SRS does not want to see the relation between MS1 to MS3 or MS4 in the above scenario, global id is not going to stop anything. Regards, Henry -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, June 15, 2011 10:43 AM To: Elwell, John Cc: siprec@ietf.org Subject: Re: [siprec] Can an MS object span several CSs in a CSG? On 6/15/2011 9:55 AM, Elwell, John wrote: > Paul, > > But if the two SRCs are somehow cooperating to the extent that they can share the same global ID for the CS, could they not also share the same local ID for the MS? Why does it need to be a global ID? They could *know* each other's local id for the MS. They might even agree to use the *same* value for the local id. E.g. we have SRC#1 and SRC#2, each using 123 as the local id for the "same" stream. But to the SRS, there is one MS with id SRC#1:123, and another MS with SRC#2:123. It does not know they are the same. (That is the point of local scoping.) So even though the two SRCs know they are talking about the same MS they have no way to tell that to the SRS. Thanks, Paul > John > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 14 June 2011 16:31 >> To: siprec@ietf.org >> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >> >> John, >> >> Consider another case: two SRCs in the same CS (perhaps one at each >> "end".) They are both sending metadata about the same CS and MSs. >> >> Suppose they want to cooperate with each other. They have the=20 >> potential to use the same ID to reference the CS, so that the SRS=20 >> will know they are talking about the same one. But with RS-specific=20 >> MS ids there is no way for them to indicate that they are talking=20 >> about the same MSs. With global MS ids, they could accomplish this. >> >> Thanks, >> Paul >> >> On 6/14/2011 11:03 AM, Elwell, John wrote: >>> Partha, >>> >>> Thanks for the examples. The character count for the delta >> is about 2500 when a new MS is created compared to about 2100 when=20 >> the MS is retained. This seems to be in line with my previous gut=20 >> feeling. >>> >>> Concerning the need for "SRS implementers to guess how old >> MS and new MS are related", I don't think they are related, except by >> having other things in common like a common participant or a common=20 >> CSG. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>> Sent: 14 June 2011 13:15 >>>> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; Ram Mohan=20 >>>> R (rmohanr); siprec@ietf.org >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>> >>>> Hi all, >>>> >>>> Sorry for the delay. Just to double confirm everybody understanding >>>> with SIP message example, I added the example with creating new MS=20 >>>> and reusing the same MS as an attachment with this mail. >>>> >>>> Please note that creating new MS is putting SRS >> implementers to guess >>>> how old MS and new MS are related. Also, few scenario like >> Even after >>>> looking into the example, the intention is to use local >> variable, I'm >>>> ok. >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) >>>> Sent: Friday, June 10, 2011 10:57 PM >>>> To: Leon Portman; Elwell, John; Parthasarathi R (partr); >> Ram Mohan R >>>> (rmohanr); siprec@ietf.org >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>> >>>> Please excuse the delay. I am catching up after having been away on >>>> vacation. >>>> In light of this better understanding of the use case, I also=20 >>>> prefer the option favored by John and Leon to model as a separate=20 >>>> MS. In this specific case, I would expect the properties of the MS=20 >>>> to change when A is transferred to C, so I expect the overhead in=20 >>>> creating >> a new MS vs. >>>> reusing the same MS to be minimal and not worth the added=20 >>>> complexity to the model. >>>> >>>> Cheers, >>>> Charles >>>> >>>>> -----Original Message----- >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>> Sent: Tuesday, May 31, 2011 6:19 AM >>>>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel >> (eckelcu); >>>>> Ram Mohan R (rmohanr); siprec@ietf.org >>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>> >>>>> Hello >>>>> >>>>> I also having a problem even without a quantification of number of >>>>> update messages that CS MS is remains same between >>>> different CS. So I >>>> do prefer to keep it simple and keep it per CS. >>>>> >>>>> Leon >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>>>> Behalf Of Elwell, John >>>>> Sent: Friday, May 27, 2011 12:26 PM >>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R=20 >>>>> (rmohanr); siprec@ietf.org >>>>> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>> Sent: 26 May 2011 15:55 >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); >>>>>> siprec@ietf.org >>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>>> >>>>>> John, >>>>>> >>>>>> The callflow mentioned by me is the basic primitive in the call=20 >>>>>> center scenario wherein customer (participant) is same throughout >>>>>> the session and agents are changed using transfer service >>>> and B2BUA >>>> acts as SRC. >>>>>> IMO, it is one of key requirement to be considered in case we=20 >>>>>> support for partial-update. >>>>> [JRE] Agreed the Participant remains the same, but we are >> discussing >>>> MS. >>>>> >>>>>> This may not be the only callflow where MS partial-update is=20 >>>>>> required in this fashion. During -00 format draft, I thought that >>>>>> the partial-update is not required but lot of folks raised the=20 >>>>>> concern that partial update is important. Current, -01 >>>> format draft >>>>>> is designed to support partial-update. Now, You propose >>>> to restrict >>>>>> MS partial-update across CS. IMO, it is a not good idea >>>> to restrict >>>>>> in the protocol level. Anyway, I think that we need >>>> others opinion >>>>>> before conclude here. >>>>> [JRE] I am not opposed to partial update, but I would >> like to avoid >>>>> distorting the model just to gain some efficiency improvements in=20 >>>>> certain cases. To me it is not intuitive that a MS on one >>>> CS and an MS >>>> >>>>> on another CS are the same object, just because one of the=20 >>>>> Participants is common to both CSs. In the transfer-between-agents >>>> example, although one of the Participants is common to the two CSs, >>>> this is not true for the other Participants. >>>>> >>>>> Let's try to quantify the efficiency improvement. In the blind=20 >>>>> transfer case, the partial updates would at least have to include: >>>>> - the removal of P1 from CS1 (where P1 is the first agent >>>> and CS1 is >>>>> the first CS); >>>>> - the removal of P2 from CS1 (where P2 is the transferred=20 >>>>> participant); >>>>> - the termination of CS1; >>>>> - the removal of CS1 from CSG1; >>>>> - the creation of CS2 (the CS that results from transfer); >>>>> - the addition to of CS2 to CSG1; >>>>> - the addition of P2 to CSG1; >>>>> - the addition of P3 to CS2 (where P3 is the second agent); >>>>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); >>>>> - the removal of P2 as a recipient of MS1; >>>>> - the termination of MS1; >>>>> - the creation of MS3; >>>>> - the addition of P3 as a sender of MS3; >>>>> - the addition of P2 as a recipient of MS3. >>>>> >>>>> So all we are arguing about is whether we also include in >>>> the partial >>>>> updates EITHER (this I think is your proposal): >>>>> - the removal of P1 as a recipient of MS2; >>>>> - the addition of P3 as a recipient of MS2; >>>>> >>>>> OR >>>>> - the removal of P1 as recipient of MS2; >>>>> - the removal of P2 as a sender of MS2; >>>>> - the termination MS2; >>>>> - the creation of MS4; >>>>> - the addition of P3 as a recipient of MS4; >>>>> - the addition of P2 as a sender of MS4. >>>>> >>>>> So with the first option the total number of deltas is 14+2=3D16. >>>>> For the second option the total number of deltas is 14+6=3D20. >>>>> >>>>> Some of the details might be wrong, but I hope you can see >>>> the point I >>>> >>>>> am getting at. Looked at this way, the efficiency saving by >>>> recycling >>>>> MS2 for use in consecutive CSs is relatively small. Or >> perhaps your >>>>> intention is also to recycle MS1 (this time, the recipient >>>> remaining >>>>> the same but the sender changing). That would reduce the number of >>>>> deltas slightly further. The impact on XML size might not >>>> be quite in >>>>> proportion to the reduction in the number of deltas, since by >>>> recycling MS2 it has to have a global identifier, not an identifier >>>> local to a CS. Or perhaps it could have an identifier >> local to a CSG. >>>>> >>>>> I also see that with your proposal it doesn't force the MS to be=20 >>>>> recycled - an SRC could still choose to model it as separate MSs. >>>>> However, in that case it would still need to use global >> identifiers >>>> for MSs. >>>>> >>>>> I am not necessarily opposed to your proposal for recycling >>>> MS objects >>>> >>>>> outside the context of a single CS - I can see advantages and=20 >>>>> disadvantages. I just want to make sure the group makes >> an informed >>>> decision. >>>>> >>>>> John (as individual) >>>>> >>>>> >>>>>> >>>>>> Enhancing label attribute across the multiple SIP message to tie=20 >>>>>> between Metadata XML and RS SDP m-line is possible. SRC has to=20 >>>>>> ensure that label for the given RS SDP m-line should have >>>> same label >>>> >>>>>> throughout single CSG even though it span across multiple CS and=20 >>>>>> multiple RS. Even then, it will not meet partial-update >>>> requirement >>>>>> as mentioned below in this mail thread. At this moment, >>>> I'm favoring >>>> >>>>>> URN UUID and not label attribute enhancement. >>>>>> >>>>>> Please read inline >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>> Sent: Wednesday, May 25, 2011 7:17 PM >>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R >>>>>> (rmohanr); siprec@ietf.org >>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>> Sent: 25 May 2011 08:48 >>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R >>>> (rmohanr); >>>>>>> siprec@ietf.org >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >>>> in a CSG? >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> >>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> =3D >>>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA >>>>>>> converts REFER >>>>>>> >>>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA >>>>>>> updates RS >>>>>>>> with CS2, Participant1 as A& participant2 as C, >>>> MS1(A's media >>>>>>>> stream), MS2(C's media stream). There is no update on RS1, >>>>>>> CSG1, MS1, >>>>>>>> MS2. MS2 will become MS2 with the new association and >>>> in terms >>>>>>>> of format, it will associate with tag >>>>>>> [JRE] What harm is done (what do we lose) if, following >>>>>> transfer, A's >>>>>>> media stream is called MS3 and C's media stream is called MS4? >>>>>>> >>>>>> >>>> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> =3D >>>>>>> To indicate MS1 as MS3, MS1 media block has to be >>>>>> stopped in >>>>>>> the partial-update and start MS3 separate which is not >>>> required in >>>> >>>>>>> case there is a means to have common MS1. >>>>>> [JRE] It seems this distorts the model in order to give >>>> some minor >>>>>> efficiency improvement during metadata updates. I doubt that this >>>>>> alone is sufficient justification for having the MS >>>> persist from one >>>> >>>>>> CS to another CS. >>>>>> >>>>>>> >>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> MS3 can reference the same SDP m-line (through a=3Dlabel) as = MS1,=20 >>>>>>> and likewise MS4 could reference the same SDP m-line as >>>> MS2, if we >>>> >>>>>>> are concerned about recycling media descriptions in RS SDP. >>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> As you mentioned, we will lose recycling of media >>>>>> description >>>>>>> in RS SDP without common value in media stream object for this=20 >>>>>>> scenario. >>>>>> [JRE] I don't understand your point. With my proposal we >>>> can still >>>>>> recycle RS SDP m-lines. >>>>>> >>>>>> Agreed that Recycle is possible with your proposal. >>>>>> I indicated >>>>>> the need for unique-id in this requirement >>>>>> >>>>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label >>>>>> attribute >>>>>>> scope is within single SIP message and not required to >>>> be unique >>>>>>> in all SIP messages of a given dialog. >>>>>> [JRE] But I think we could nail that down as a requirement of the >>>>>> SIPREC protocol. >>>>>> >>>>>> John (as individual) >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Charles Eckel (eckelcu) >>>>>>>> Sent: Wednesday, May 25, 2011 1:39 AM >>>>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); >>>>>> 'Elwell, John'; >>>>>>>> 'siprec@ietf.org' >>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a >>>> CSG? >>>>>>>> >>>>>>>> Hi Ram, >>>>>>>> >>>>>>>> I think that is many cases, they will be treated as >>>> separate MSs >>>> >>>>>>>> due to the complexities you mention. However, I am trying to >>>>>> understand if >>>>>>>> Partha feels allowing an SRC to treat them as a single MS is=20 >>>>>>>> still required. If not, then what is a use case? A concrete=20 >>>>>>>> example would help me, and potentially others, to better=20 >>>>>>>> understand the >>>>>>> motivation behind >>>>>>>> Partha's requirement for modeling media from multiple CSs >>>>>>> as a single >>>>>>>> MS. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Charles >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ram Mohan R (rmohanr) >>>>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM >>>>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >>>>>>> Elwell, John; >>>>>>>>> siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs >>>>>> in a CSG? >>>>>>>>> >>>>>>>>> Charles, >>>>>>>>> >>>>>>>>> I did bring about this specific usecase of MMOH/MOH >>>>>> stream being >>>>>>>>> played to different participants earlier and suggested that >>>>>>>> they have >>>>>>>>> to treated as a same MS across multiple CSs >>>>>> (potentially recorded >>>>>>>> using multiple RSs). >>>>>>>>> Refer >>>>>>>>> >>>>>> http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html >>>>>>>>> >>>>>>>>> We had several discussions on it and it and several >>>>>> folks were in >>>>>>>>> favor of treating it as separate MS as there would be >>>>>>>> complexity in DB >>>>>>>> design. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ram >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>> Behalf Of Charles Eckel (eckelcu) >>>>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM >>>>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org >>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>>>> in a CSG? >>>>>>>>>> >>>>>>>>>> Hi Partha, >>>>>>>>>> >>>>>>>>>> Is an example of this the same music on hold audio stream >>>>>>>> existing >>>>>>>>>> as the same MS within multiple CSs? If so, then I >>>>>>> understand your >>>>>>>>>> requirement to be that the SRC be able to >>>> indicate multiple >>>>>>>>>> instances of this audio stream within several CSs as >>>>>>>> being the same >>>>>>>>>> MS. Is that correct? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Charles >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>> Behalf Of Parthasarathi R (partr) >>>>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM >>>>>>>>>>> To: Elwell, John; siprec@ietf.org >>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs >>>>>>>> in a CSG? >>>>>>>>>>> >>>>>>>>>>> John, >>>>>>>>>>> >>>>>>>>>>> I agree that it is not mandatory to consider recorded >>>>>>>> stream of a >>>>>>>>>>> specific participant in several CS within the same >>>>>> CSG as one >>>>>>>>>> recorded >>>>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a >>>>>>>> SRC in case >>>>>>>>>>> it wishes to design in such a way. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Partha >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>> Behalf >>>>>>>>>>> Of Elwell, John >>>>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM >>>>>>>>>>> To: siprec@ietf.org >>>>>>>>>>> Subject: [siprec] Can an MS object span several CSs >>>>>> in a CSG? >>>>>>>>>>> >>>>>>>>>>> We seem to have consensus that a Media Stream object >>>>>>>> represents a >>>>>>>>>>> recorded media stream, contributed to by one, >>>>>> several or all >>>>>>>>>>> Participants. However, Partha also wrote: >>>>>>>>>>> >>>>>>>>>>> "2) Each MS lifetime related to CSG because participant >>>>>>>> may move >>>>>>>>>>> from one CS to another CS within single CSG and also >>>>>>>> CSG will span >>>>>>>> >>>>>>>>>>> across multiple RS." >>>>>>>>>>> >>>>>>>>>>> I am not sure we had resolved this during earlier >>>>>>>> discussions on >>>>>>>>>>> the scope of an MS object. Although the same >>>>>> Participant can >>>>>>>>>>> participate >>>>>>>>>> in >>>>>>>>>>> several CSs within the same CSG, I don't think the >>>>>>>> recorded media >>>>>>>>>>> streams need to be considered the same. Any other views? >>>>>>>>>>> >>>>>>>>>>> John (as individual) >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>> _______________________________________________ >>>>>>>>>> siprec mailing list >>>>>>>>>> siprec@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec =09 ------------------------------------------------------------------------ ------------------------------------------- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. =09 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CC2D34.BA9BB4C1 Content-Type: text/plain; name="MS across CS with full msg.txt" Content-Transfer-Encoding: base64 Content-Description: MS across CS with full msg.txt Content-Disposition: attachment; filename="MS across CS with full msg.txt" U2NlbmFyaW86DQoNCjEpIEEgY2FsbHMgQiB0aHJvdWdoIEIyQlVBLiBCMkJVQSBjcmVhdGVzIFJT IHRvd2FyZHMgU1JTIHdpdGggQ1NHMSwgQ1MxLA0KTVMxIChBJ3MgbWVkaWEgc3RyZWFtKSwgTVMy IChCJ3MgbWVkaWEgc3RyZWFtKSwgUGFydGljaXBhbnQxIGFzIEEgJg0KUGFydGljaXBhbnQyIGFz IEIuDQoyKSBCIHRyYW5zZmVyIHRoZSBjYWxsIG9mIEEgJiBCIHRvIEMgdXNpbmcgUkVGRVIsIEIy QlVBIGNvbnZlcnRzIFJFRkVSIHRvIFJFLUlOVklURSB0b3dhcmRzIEEgJiBDIGFuZCBBICYgQyBh cmUgY29ubmVjdGVkLiBCMkJVQSB1cGRhdGVzIFJTIHdpdGggQ1MyLCBQYXJ0aWNpcGFudDEgYXMg QSAmIHBhcnRpY2lwYW50MiBhcyBDLCBNUzEoQSdzIG1lZGlhIHN0cmVhbSksIE1TMihDJ3MgbWVk aWEgc3RyZWFtKS4gVGhlcmUgaXMgbm8gdXBkYXRlIG9uIFJTMSwgQ1NHMSwgTVMxLCBNUzIuIE1T MiB3aWxsIGJlY29tZSBNUzIgd2l0aCB0aGUgbmV3IGFzc29jaWF0aW9uIGFuZCBpbiB0ZXJtcyBv ZiBmb3JtYXQsIGl0IHdpbGwgYXNzb2NpYXRlIHdpdGggPHNlbmQ+IHRhZw0KDQpSUyBTSVAgbWVz c2FnZXMgd2l0aCBtZXRhZGF0YToNCg0KSW5pdGlhbCBJbnZpdGU6DQoNCklOVklURSBzaXA6MTA0 MUByZWNvcmRpbmdzZXJ2ZXIuY2lzY28uY29tOjUwNjA7dHJhbnNwb3J0PXRjcCBTSVAvMi4wDQpW aWE6IFNJUC8yLjAvVENQIDEwLjIxLjgzLjU4O2JyYW5jaD16OWhHNGJLLTE5OTM1LTEtNw0KTWF4 LUZvcndhcmRzOiA3MA0KVG86IDxzaXA6MTA0MUByZWNvcmRpbmdzZXJ2ZXIuY2lzY28uY29tPg0K RnJvbTogUmVjcmRpbmdDbGllbnQgPHNpcDoxMC4yMS44My41OD47dGFnPWRzNDNkNzYyNjMNCkNh bGwtSUQ6IDEyNTQ4MDg2OTcwMjYxQDE5Mi4xNjguMS42Nw0KQ1NlcTogMTAwIElOVklURQ0KQ29u dGVudC1MZW5ndGg6IHh4eA0KQ29udGFjdDogPHNpcDoxMC4yMS44My41ODo1MDYwO3RyYW5zcG9y dD10Y3A+O2F1ZGlvOw0KRGF0ZTogVHVlLCAxNiBEZWMgMjAxMCAyMzo0NTowNyBHTVQNCkNvbnRl bnQtVHlwZTogbXVsdGlwYXJ0L21peGVkO2JvdW5kYXJ5PXVuaXF1ZS1ib3VuZGFyeS0xDQpNSU1F LVZlcnNpb246IDEuMA0KDQotLXVuaXF1ZS1ib3VuZGFyeS0xDQpDb250ZW50LVR5cGU6IGFwcGxp Y2F0aW9uL1NEUA0KLi4uDQptPWF1ZGlvIDQ5MTcwIFJUUC9BVlAgMCAgICAgICAgICANCmE9cnRw bWFwOjAgUENNVS84MDAwDQphPWxhYmVsOjk2DQphPXNlbmRvbmx5DQouLi4NCm09dmlkZW8gNDkx NzQgUlRQL0FWUEYgOTYgICAgDQphPXJ0cG1hcDo5NiBILjI2NC85MDAwMA0KYT1sYWJlbDo5Nw0K YT1zZW5kb25seQ0KLi4uDQptPWF1ZGlvIDUxMzcyIFJUUC9BVlAgMCAgICAgICAgICANCmE9cnRw bWFwOjAgUENNVS84MDAwDQphPWxhYmVsOjk4DQphPXNlbmRvbmx5DQouLi4NCm09dmlkZW8gNDkx NzYgUlRQL0FWUEYgOTYgICAgICAgICANCmE9cnRwbWFwOjk2IEguMjY0LzkwMDAwDQphPWxhYmVs Ojk5DQphPXNlbmRvbmx5DQouLi4uDQoNCi0tdW5pcXVlLWJvdW5kYXJ5LTENCkNvbnRlbnQtdHlw ZTphcHBsaWNhdGlvbi9ycy1tZXRhZGF0YSt4bWwNCg0KPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNv ZGluZz0iVVRGLTgiPz4NCiAgPHJlY29yZGluZyB4bWxucz0ndXJuOmlldGY6cGFyYW1zOnhtbDpu czpyZWNvcmRpbmcnPg0KICAgICA8Z3JvdXAgaWQ9InVybjp1dWlkOmVmZTM5MzBiLTJhMzEtNGU2 YS1hNmFiLTIwM2ZkNzA3ODMwMiI+ICAgDQogICAgIDwvZ3JvdXA+DQogICAgIDxzZXNzaW9uIGlk PSJ1cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcwZi02ZGExZWVhZWI0MjUiPg0KICAgICAg IDxncm91cC1yZWY+dXJuOnV1aWQ6ZWZlMzkzMGItMmEzMS00ZTZhLWE2YWItMjAzZmQ3MDc4MzAy DQogICAgICAgPC9ncm91cC1yZWY+DQogICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQyMzo0 MTowN1o8L3N0YXJ0LXRpbWU+DQogICAgIDwvc2Vzc2lvbj4NCiAgICAgPHBhcnRpY2lwYW50IA0K ICAgICAgICBpZD0idXJuOnV1aWQ6YjJiN2MxMTItNTk4Mi00NjlkLTkwMDctNmRkYmVjY2E2NGQz Ig0KICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcwZi02ZGEx ZWVhZWI0MjUiPg0KICAgICAgICA8YW9yPnNpcDpwYXJ0aGFAYmxyLmNpc2NvLmNvbTwvYW9yPg0K ICAgICAgICA8c2VuZD51cm46dXVpZDo4YjUzZjNkZS1kYTM5LTQ4NDYtOTNjNy1lZTVlNWY4ZjZm MGI8L3NlbmQ+DQogICAgICAgIDxzZW5kPnVybjp1dWlkOjUwMDAwYzliLTkxOTEtNDBhNC04MjMx LTViY2JjYTVlMmIxNzwvc2VuZD4NCiAgICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQyMzo0 MTowN1o8L3N0YXJ0LXRpbWU+DQogICAgIDwvcGFydGljaXBhbnQ+DQogICAgIDxwYXJ0aWNpcGFu dCANCiAgICAgICAgIGlkPSJ1cm46dXVpZDpjZDI3Y2ZhMS0yYmRkLTQ4MzAtYTY1My03MDM3NGQx MGYxMDMiDQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDoxOGJiYTRmZjItOTY2My0xMWUwLTk1 MTYtNWI5YjQ4MjQwMTliIj4NCiAgICAgICAgIDxzdGFydC10aW1lPjIwMTAtMTItMTZUMjM6NDU6 MDdaPC9zdG9wLXRpbWU+DQogICAgICAgICA8YW9yPnNpcDpyYW1AYmxyLmNpc2NvLmNvbTwvYW9y Pg0KICAgICAgICAgPHNlbmQ+dXJuOnV1aWQ6NTAwMDBjOWItOTE5MS00MGE0LTgyMzEtNWJjYmNh NWUyYjE3PC9zZW5kPg0KICAgICAgICAgPHNlbmQ+dXJuOnV1aWQ6OGI1M2YzZGUtZGEzOS00ODQ2 LTkzYzctZWU1ZTVmOGY2ZjBiPC9zZW5kPg0KICAgICA8L3BhcnRpY2lwYW50Pg0KICAgICA8c3Ry ZWFtIGlkPSJ1cm46dXVpZDo1MDAwMGM5Yi05MTkxLTQwYTQtODIzMS01YmNiY2E1ZTJiMTciDQog ICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDo4NTVhNWRlZC04NDIwLTQ1NmQtYTcwZi02ZGExZWVh ZWI0MjUiPg0KICAgICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQyMzo0MTowN1o8L3N0YXJ0 LXRpbWU+DQogICAgICAgICA8bGFiZWw+OTY8L2xhYmVsPg0KICAgICA8L3N0cmVhbT4NCiAgICAg PHN0cmVhbSBpZD0idXJuOnV1aWQ6OGI1M2YzZGUtZGEzOS00ODQ2LTkzYzctZWU1ZTVmOGY2ZjBi Ig0KICAgICAgICAgc2Vzc2lvbj0idXJuOnV1aWQ6ODU1YTVkZWQtODQyMC00NTZkLWE3MGYtNmRh MWVlYWViNDI1Ij4NCiAgICAgICAgIDxzdGFydC10aW1lPjIwMTAtMTItMTZUMjM6NDE6MDdaPC9z dGFydC10aW1lPg0KICAgICAgICAgPGxhYmVsPjk3PC9sYWJlbD4NCiAgICAgPC9zdHJlYW0+DQog ICAgIDxzdHJlYW0gaWQ9InVybjp1dWlkOmYzMzczYTdiLTQ5NTgtNGU1NS04ODIwLWQwM2ExOTFm Yjc2YSINCiAgICAgICAgIHNlc3Npb249InVybjp1dWlkOmNkMjdjZmExLTJiZGQtNDgzMC1hNjUz LTcwMzc0ZDEwZjEwMyI+DQogICAgICAgICA8c3RhcnQtdGltZT4yMDEwLTEyLTE2VDIzOjQxOjA3 Wjwvc3RhcnQtdGltZT4NCiAgICAgICAgIDxsYWJlbD45ODwvbGFiZWw+DQogICAgIDwvc3RyZWFt Pg0KICAgICA8c3RyZWFtIGlkPSJ1cm46dXVpZDoxMjI1YzY5NS1jZmI4LTRlYmItYWFhYS04MGRh MzQ0ZWZhNmEiDQogICAgICAgICBzZXNzaW9uPSJ1cm46dXVpZDpjZDI3Y2ZhMS0yYmRkLTQ4MzAt YTY1My03MDM3NGQxMGYxMDMiPg0KICAgICAgICAgPHN0YXJ0LXRpbWU+MjAxMC0xMi0xNlQyMzo0 MTowN1o8L3N0YXJ0LXRpbWU+DQogICAgICAgICA8bGFiZWw+OTk8L2xhYmVsPg0KICAgICA8L3N0 cmVhbT4NCjwvcmVjb3JkaW5nPg0KDQotLXVuaXF1ZS1ib3VuZGFyeS0xLS0NCg0KUGFydGljaXBh bnQgY2hhbmdlIHVzaW5nIFJlLUlOVklURSB3aXRob3V0IE1TLCBDU0cgY2hhbmdlOg0KDQpJTlZJ VEUgc2lwOjEwNDFAcmVjb3JkaW5nc2VydmVyLmNpc2NvLmNvbTo1MDYwO3RyYW5zcG9ydD10Y3Ag U0lQLzIuMA0KVmlhOiBTSVAvMi4wL1RDUCAxMC4yMS44My41ODticmFuY2g9ejloRzRiSy0xOTkz NS0xLTkNCk1heC1Gb3J3YXJkczogNzANClRvOiA8c2lwOjEwNDFAcmVjb3JkaW5nc2VydmVyLmNp c2NvLmNvbT47dGFnPTUyNjJCQTAtMTNENA0KRnJvbTogUmVjcmRpbmdDbGllbnQgPHNpcDoxMC4y MS44My41OD47dGFnPWRzNDNkNzYyNjMNCkNhbGwtSUQ6IDEyNTQ4MDg2OTcwMjYxQDE5Mi4xNjgu MS42Nw0KQ1NlcTogMTAxIElOVklURQ0KQ29udGVudC1MZW5ndGg6IHh4eA0KQ29udGFjdDogPHNp cDoxMC4yMS44My41ODo1MDYwO3RyYW5zcG9ydD10Y3A+O2F1ZGlvOw0KRGF0ZTogVHVlLCAxNiBE ZWMgMjAxMCAyMzo0NTowNyBHTVQNCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkO2JvdW5k YXJ5PXVuaXF1ZS1ib3VuZGFyeS0xDQpNSU1FLVZlcnNpb246IDEuMA0KDQotLXVuaXF1ZS1ib3Vu ZGFyeS0xDQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL1NEUA0KLi4uDQptPWF1ZGlvIDQ5MTcw IFJUUC9BVlAgMCAgICAgICAgICANCmE9cnRwbWFwOjAgUENNVS84MDAwDQphPWxhYmVsOjk2DQph PXNlbmRvbmx5DQouLi4NCm09dmlkZW8gNDkxNzQgUlRQL0FWUEYgOTYgICAgDQphPXJ0cG1hcDo5 NiBILjI2NC85MDAwMA0KYT1sYWJlbDo5Nw0KYT1zZW5kb25seQ0KLi4uDQptPWF1ZGlvIDUxMzcy IFJUUC9BVlAgMCAgICAgICAgICANCmE9cnRwbWFwOjAgUENNVS84MDAwDQphPWxhYmVsOjk4DQph PXNlbmRvbmx5DQouLi4NCm09dmlkZW8gNDkxNzYgUlRQL0FWUEYgOTYgICAgICAgICANCmE9cnRw bWFwOjk2IEguMjY0LzkwMDAwDQphPWxhYmVsOjk5DQphPXNlbmRvbmx5DQouLi4uDQoNCi0tdW5p cXVlLWJvdW5kYXJ5LTENCkNvbnRlbnQtdHlwZTphcHBsaWNhdGlvbi9ycy1tZXRhZGF0YSt4bWwN Cg0KPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCiAgPHJlY29yZGluZyB4 bWxucz0ndXJuOmlldGY6cGFyYW1zOnhtbDpuczpyZWNvcmRpbmcnPg0KICAgICA8Z3JvdXAgaWQ9 InVybjp1dWlkOmVmZTM5MzBiLTJhMzEtNGU2YS1hNmFiLTIwM2ZkNzA3ODMwMiI+ICAgDQogICAg IDwvZ3JvdXA+DQogICAgIDxzZXNzaW9uIGlkPSJ1cm46dXVpZDoxOGJiYTRmZjItOTY2My0xMWUw LTk1MTYtNWI5YjQ4MjQwMTliIj4NCiAgICAgICA8Z3JvdXAtcmVmPnVybjp1dWlkOmVmZTM5MzBi LTJhMzEtNGU2YS1hNmFiLTIwM2ZkNzA3ODMwMg0KICAgICAgIDwvZ3JvdXAtcmVmPg0KICAgICAg IDxzdGFydC10aW1lPjIwMTAtMTItMTZUMjM6NDU6MDdaPC9zdGFydC10aW1lPg0KICAgICA8L3Nl c3Npb24+DQogICAgIDxwYXJ0aWNpcGFudCANCiAgICAgICAgaWQ9InVybjp1dWlkOmIyYjdjMTEy LTU5ODItNDY5ZC05MDA3LTZkZGJlY2NhNjRkMyINCiAgICAgICAgc2Vzc2lvbj0idXJuOnV1aWQ6 MThiYmE0ZmYyLTk2NjMtMTFlMC05NTE2LTViOWI0ODI0MDE5YiI+DQogICAgICAgIDxhb3I+c2lw OnBhcnRoYUBibHIuY2lzY28uY29tPC9hb3I+DQogICAgICAgIDxzZW5kPnVybjp1dWlkOjhiNTNm M2RlLWRhMzktNDg0Ni05M2M3LWVlNWU1ZjhmNmYwYjwvc2VuZD4NCiAgICAgICAgPHNlbmQ+dXJu OnV1aWQ6NTAwMDBjOWItOTE5MS00MGE0LTgyMzEtNWJjYmNhNWUyYjE3PC9zZW5kPg0KICAgICA8 L3BhcnRpY2lwYW50Pg0KICAgICA8cGFydGljaXBhbnQgDQogICAgICAgICBpZD0idXJuOnV1aWQ6 Y2QyN2NmYTEtMmJkZC00ODMwLWE2NTMtNzAzNzRkMTBmMTAzIg0KICAgICAgICAgc2Vzc2lvbj0i dXJuOnV1aWQ6MThiYmE0ZmYyLTk2NjMtMTFlMC05NTE2LTViOWI0ODI0MDE5YiI+DQogICAgICAg ICA8c3RhcnQtdGltZT4yMDEwLTEyLTE2VDIzOjQ1OjA3Wjwvc3RvcC10aW1lPg0KICAgICAgICAg PGFvcj5zaXA6cmFtQGJsci5jaXNjby5jb208L2Fvcj4NCiAgICAgICAgIDxzZW5kPnVybjp1dWlk OjUwMDAwYzliLTkxOTEtNDBhNC04MjMxLTViY2JjYTVlMmIxNzwvc2VuZD4NCiAgICAgICAgIDxz ZW5kPnVybjp1dWlkOjhiNTNmM2RlLWRhMzktNDg0Ni05M2M3LWVlNWU1ZjhmNmYwYjwvc2VuZD4N CiAgICAgPC9wYXJ0aWNpcGFudD4NCiAgICAgPHN0cmVhbSBpZD0idXJuOnV1aWQ6NTAwMDBjOWIt OTE5MS00MGE0LTgyMzEtNWJjYmNhNWUyYjE3Ig0KICAgICAgICAgc2Vzc2lvbj0idXJuOnV1aWQ6 MThiYmE0ZmYyLTk2NjMtMTFlMC05NTE2LTViOWI0ODI0MDE5YiI+DQogICAgICAgICA8bGFiZWw+ OTY8L2xhYmVsPg0KICAgICA8L3N0cmVhbT4NCiAgICAgPHN0cmVhbSBpZD0idXJuOnV1aWQ6OGI1 M2YzZGUtZGEzOS00ODQ2LTkzYzctZWU1ZTVmOGY2ZjBiIg0KICAgICAgICAgc2Vzc2lvbj0idXJu OnV1aWQ6MThiYmE0ZmYyLTk2NjMtMTFlMC05NTE2LTViOWI0ODI0MDE5YiI+DQogICAgICAgICA8 bGFiZWw+OTc8L2xhYmVsPg0KICAgICA8L3N0cmVhbT4NCiAgICAgPHN0cmVhbSBpZD0idXJuOnV1 aWQ6ZjMzNzNhN2ItNDk1OC00ZTU1LTg4MjAtZDAzYTE5MWZiNzZhIg0KICAgICAgICAgc2Vzc2lv bj0idXJuOnV1aWQ6MThiYmE0ZmYyLTk2NjMtMTFlMC05NTE2LTViOWI0ODI0MDE5YiI+DQogICAg ICAgICA8bGFiZWw+OTg8L2xhYmVsPg0KICAgICA8L3N0cmVhbT4NCiAgICAgPHN0cmVhbSBpZD0i dXJuOnV1aWQ6MTIyNWM2OTUtY2ZiOC00ZWJiLWFhYWEtODBkYTM0NGVmYTZhIg0KICAgICAgICAg c2Vzc2lvbj0idXJuOnV1aWQ6MThiYmE0ZmYyLTk2NjMtMTFlMC05NTE2LTViOWI0ODI0MDE5YiI+ DQogICAgICAgICA8bGFiZWw+OTk8L2xhYmVsPg0KICAgICA8L3N0cmVhbT4NCiAgICAgPC9zdHJl YW0+DQo8L3JlY29yZGluZz4NCg0KLS11bmlxdWUtYm91bmRhcnktMS0tDQo= ------_=_NextPart_001_01CC2D34.BA9BB4C1-- From partr@cisco.com Fri Jun 17 14:47:51 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959AE11E80EF for ; Fri, 17 Jun 2011 14:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXY1Xe8BhI+D for ; Fri, 17 Jun 2011 14:47:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC3A11E807F for ; Fri, 17 Jun 2011 14:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=5446; q=dns/txt; s=iport; t=1308347270; x=1309556870; h=mime-version:subject:date:message-id:from:to:cc; bh=Q5y5LqiC5Jv2WgSkOPeaZ0tK4+7ER6z3Ocj4ZK68Xc4=; b=L84vX6GiKZM0Z7KaMElsiWiqYPJmz6cuvyAwj6wzNdqcNnZqRn9jxv79 I7opeo3IIXEq4krUP0O8uVZZPCDrtUQHlL3WoyY0E6euK4lBUu9AVQC1V dTtyywU9IwWzCaEUgbbBFabtuj8CVjWUPlJOIvpJv1i1uV2W/7+DShLvs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK/K+01Io8UQ/2dsb2JhbABSpl93qxadcoYnBIcejyiLHQ X-IronPort-AV: E=Sophos;i="4.65,383,1304294400"; d="scan'208,217";a="94603533" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2011 21:47:48 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5HLll1j007074; Fri, 17 Jun 2011 21:47:47 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 18 Jun 2011 03:17:47 +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_01CC2D38.32265881" Date: Sat, 18 Jun 2011 03:17:45 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Codec parameter in stream element Thread-Index: AcwtODFs5cAtzLVpT6uDWToDw2bwTg== From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 17 Jun 2011 21:47:47.0901 (UTC) FILETIME=[32B47ED0:01CC2D38] Subject: [siprec] Codec parameter in stream element X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 21:47:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2D38.32265881 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, =20 Codec parameter in stream element is an open issue. It was discussed during IETF-80 and minutes of IETF-80 about this discussion is mentioned as a note of this mail.=20 =20 As per the recent conclusion in metadata, "recording" metadata information is retrieved from RS SIP headers. In the same way, it is possible to fetch codec parameter from RS SDP in SRS for codec parameter related to stream element in metadata as there is a linkage between stream element and RS SDP using label attribute. Please let me know any specific issue in fetching from RS SDP in SRS.=20 =20 Including John, Paul, Hadriel in this mail thread for aiming at the closure atleast during this interim meeting. =20 Thanks Partha =20 Note: IETF-80 Minutes: =20 Slide 18: Open issue: Codec parameter in stream element. John Elwell (from=20 floor) disliked duplication, but thought there was a need to consider what=20 information needs to be passed up to the application at the SRS, e.g., the media=20 type would be needed. So this could result in a small amount of duplication to=20 provide this in the XML for the application. Paul Kyzivat was most concerned=20 about the direction attribute, since it is hard to figure out from the RS SDP=20 the direction of the CS media. Paul also felt that the SRS could pass=20 information from the RS SDP up to the application if needed, without necessarily=20 requiring that information in XML. Hadriel Kaplan disliked duplication, although=20 the need for information in XML might depend on the RTP model. Will continue=20 discussion on relationship between information in XML and information in SDP on=20 the mailing list. ------_=_NextPart_001_01CC2D38.32265881 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
Codec = parameter in=20 stream element is an open issue. It was discussed during IETF-80 and = minutes of=20 IETF-80 about this discussion is mentioned as a note of this mail.=20
 
As per = the=20 recent conclusion in metadata, "recording" metadata information is=20 retrieved from RS SIP headers. In the same way, it is possible to = fetch=20 codec parameter from RS SDP in SRS for codec parameter related = to stream=20 element in metadata as there is a linkage between stream element = and RS SDP=20 using label attribute. Please let me know any specific issue in fetching = from RS=20 SDP in SRS. 
 
Including John,=20 Paul, Hadriel in this mail thread for aiming at the closure atleast = during this=20 interim meeting.
 
Thanks
Partha
 
Note:=20 IETF-80=20 Minutes:
 
Slide 18: Open issue: Codec = parameter in=20 stream element. John Elwell (from
floor) disliked duplication, but = thought=20 there was a need to consider what
information needs to be passed up = to the=20 application at the SRS, e.g., the media
type would be needed. So = this could=20 result in a small amount of duplication to
provide this in the XML = for the=20 application.  Paul Kyzivat was most concerned
about the = direction=20 attribute, since it is hard to figure out from the RS SDP
the = direction of=20 the CS media. Paul also felt that the SRS could pass
information = from the RS=20 SDP up to the application if needed, without necessarily
requiring = that=20 information in XML. Hadriel Kaplan disliked duplication, although =
the need=20 for information in XML might depend on the RTP model. Will continue=20
discussion on relationship between information in XML and = information in SDP=20 on
the mailing list.
------_=_NextPart_001_01CC2D38.32265881-- From pkyzivat@cisco.com Sat Jun 18 09:38:06 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64D111E81ED for ; Sat, 18 Jun 2011 09:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuLiZX1TaCwW for ; Sat, 18 Jun 2011 09:38:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5B111E80FD for ; Sat, 18 Jun 2011 09:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1992; q=dns/txt; s=iport; t=1308415086; x=1309624686; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WMO01Is0NIuSSldmWOhLftjyCQrjGbS3UAcx3R/4PvE=; b=ZDalSu9ReTekSOR7Mzu/uGTwRtkTgjUSYMkdP2DbeepLx3zzbY2Ot98d tzuvHWcmAuGN3+r3p2MLfjFr+9YSGA6A68vJVcFayhqsZ/98WAGuTbrNF 5z1ivIowme1ECdksSHIKsUP47APpCGduiRcRKzdaF+6NR2PEBNtjo2ITd A=; X-IronPort-AV: E=Sophos;i="4.65,386,1304294400"; d="scan'208";a="379904055" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 18 Jun 2011 16:38:06 +0000 Received: from [10.86.247.114] ([10.86.247.114]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5IGc4pv008049; Sat, 18 Jun 2011 16:38:05 GMT Message-ID: <4DFCD46C.1030408@cisco.com> Date: Sat, 18 Jun 2011 12:38:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Codec parameter in stream element X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 16:38:06 -0000 Yes, AFAIK we agreed that the codec info in the RS is sufficient - it describes the media as it is available to the SRS. It may not be the same as what was in the CS, but people were not concerned with knowning that. Thanks, Paul On 6/17/2011 5:47 PM, Parthasarathi R (partr) wrote: > Hi all, > Codec parameter in stream element is an open issue. It was discussed > during IETF-80 and minutes of IETF-80 about this discussion is mentioned > as a note of this mail. > As per the recent conclusion in metadata, "recording" metadata > information is retrieved from RS SIP headers. In the same way, it is > possible to fetch codec parameter from RS SDP in SRS for codec parameter > related to stream element in metadata as there is a linkage between > stream element and RS SDP using label attribute. Please let me know any > specific issue in fetching from RS SDP in SRS. > Including John, Paul, Hadriel in this mail thread for aiming at the > closure atleast during this interim meeting. > Thanks > Partha > Note: IETF-80 Minutes: > Slide 18: Open issue: Codec parameter in stream element. John Elwell (from > floor) disliked duplication, but thought there was a need to consider what > information needs to be passed up to the application at the SRS, e.g., > the media > type would be needed. So this could result in a small amount of > duplication to > provide this in the XML for the application. Paul Kyzivat was most > concerned > about the direction attribute, since it is hard to figure out from the > RS SDP > the direction of the CS media. Paul also felt that the SRS could pass > information from the RS SDP up to the application if needed, without > necessarily > requiring that information in XML. Hadriel Kaplan disliked duplication, > although > the need for information in XML might depend on the RTP model. Will > continue > discussion on relationship between information in XML and information in > SDP on > the mailing list. From rmohanr@cisco.com Sat Jun 18 20:40:42 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705FC21F84AD for ; Sat, 18 Jun 2011 20:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.965 X-Spam-Level: X-Spam-Status: No, score=-9.965 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOagvSDYcJ+z for ; Sat, 18 Jun 2011 20:40:41 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7733B21F84AC for ; Sat, 18 Jun 2011 20:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1728; q=dns/txt; s=iport; t=1308454841; x=1309664441; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=3gBT++Fn+r6DpBO2lQ0pyNYzEJ1eMUY6beVCy4+AxGg=; b=ifiBFh7tOdK/wfapqnhEKhW0LHvjBY6MU/7XTxDV+N3w1RR+mO4LwyP+ Czqrah3fDIGvYJ1/+VqqCdCvXHPAuN8m20LScXeWgvcxvRhW6ITpq6t/d paGPzzRQ+E5k0g67q2VcKwW7pspg95gGHIVie5X0GGL68JUxoIFn6ViK6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAGRv/U1Io8UR/2dsb2JhbABSl1WPCnemZJ0HhioEhx6PKYsg X-IronPort-AV: E=Sophos;i="4.65,387,1304294400"; d="scan'208";a="35876095" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 19 Jun 2011 03:40:39 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5J3edFJ008344; Sun, 19 Jun 2011 03:40:39 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 19 Jun 2011 09:10:38 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Jun 2011 09:10:37 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06C39AAF@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Use of RFC 2119 language in the metadata model Thread-Index: AcwQdhOQ6/kxuRXySmKl3XqMpU4g4Qdu++DA References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 19 Jun 2011 03:40:38.0894 (UTC) FILETIME=[A80368E0:01CC2E32] Subject: Re: [siprec] Use of RFC 2119 language in the metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 03:40:42 -0000 Hi John / All, I have not seen any views / discussion on this thread. I am planning to publish draft-ietf-siprec-metadata-01. Before I go ahead would like to get the opinion on how to go about for this issue.=20 Do we want to leave the current language ( use of RFC 2119) as it is for ver 01 and re-visit later when we merge format in to model ? OR Do we want to remove all the normative statements right now(for 01) and have them (around the format portions) when we merge format and model ? Let me know your opinions soon. I plan to publish the draft by Monday evening or Tuesday morning(at the most). Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, May 12, 2011 12:58 PM > To: siprec@ietf.org > Subject: [siprec] Use of RFC 2119 language in the metadata model >=20 > Draft-ietf-metadata-00 makes extensive use of RFC 2119 language. At > present this is an Informational document (although that does not > necessarily prevent the use of RFC 2119 language), but eventually we > anticipate incorporating the format material, and as a result the > document would target a Proposed Standard. The format stuff clearly has > to be implemented by SRCs and SRSs, so I would expect normative > language around those aspects. However, to draw a clear distinction > between what has to be implemented and what is just abstract we > probably need to refrain from RFC 2119 language when just describing > the abstract model. Views? >=20 > John >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From trac+siprec@trac.tools.ietf.org Mon Jun 20 00:00:29 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FAD228010 for ; Mon, 20 Jun 2011 00:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DZ6opIttFmj for ; Mon, 20 Jun 2011 00:00:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF0622800F for ; Mon, 20 Jun 2011 00:00:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QYYTF-0005i9-1W; Mon, 20 Jun 2011 00:00:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: rmohanr@cisco.com X-Trac-Project: siprec Date: Mon, 20 Jun 2011 07:00:29 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/71#comment:1 Message-ID: <084.4bfd71a144db9d646881e077abe0258a@trac.tools.ietf.org> References: <075.7b3e219c15a294040b4f56d6c75e934e@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <075.7b3e219c15a294040b4f56d6c75e934e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rmohanr@cisco.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #71: Media Stream / codec params X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 07:00:30 -0000 #71: Media Stream / codec params Changes (by rmohanr@…): * status: new => closed * resolution: => fixed Comment: After discussions in mailer there was a general agreement that passing of CS SDP parameters in RS dialog is not needed. http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html Hence closing this ticket as resolved. The codec param attribute shall be removed from model. -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: rmohanr@… Type: defect | Status: closed Priority: minor | Milestone: Component: Metadata Model | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------------------+--------------------------- Ticket URL: siprec From john.elwell@siemens-enterprise.com Mon Jun 20 01:31:19 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EF211E8086 for ; Mon, 20 Jun 2011 01:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00jIH1U7qzxS for ; Mon, 20 Jun 2011 01:31:19 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id D701B11E8080 for ; Mon, 20 Jun 2011 01:31:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1308558677!1223266!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 32737 invoked from network); 20 Jun 2011 08:31:17 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-11.tower-216.messagelabs.com with SMTP; 20 Jun 2011 08:31:17 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 523111EB83D3; Mon, 20 Jun 2011 10:31:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 20 Jun 2011 10:31:17 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Mon, 20 Jun 2011 10:31:16 +0200 Thread-Topic: I-D Action: draft-eckel-siprec-rtp-rec-01.txt Thread-Index: AcwsaNcOEe0gqVPXQ0yXvD4ktkTVMwAo3uRAAAS6UJAAgPmrsA== Message-ID: References: <20110616210242.4832.4179.idtracker@ietfa.amsl.com> In-Reply-To: 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: [siprec] I-D Action: draft-eckel-siprec-rtp-rec-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 08:31:20 -0000 Charles, What I had in mind was something along the following lines: "It is RECOMMENDED to use symmetric RTP. Although an SRS will not normally = transmit RTP, it will transmit RTCP as well as receiving RTP and RTCP. Like= wise, although an SRC will not normally receive RTP, it will receive RTCP a= s well as transmitting RTP and RTCP." Your latest proposal seems to suggest that sending RTCP is optional, and I = am not sure we want to condone that. John > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 17 June 2011 19:56 > To: Elwell, John; siprec@ietf.org > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt >=20 > Hi John, >=20 > I tried to address this concern by handling RTP and RTCP separately: >=20 > If an SRC or SRS is sending RTP, it is RECOMMENDED to use symmetric > RTP. If an SRC or SRS is sending RTCP, it is RECOMMENDED to use > symmetric RTCP. >=20 > I agree that the SRS will generally not need to send RTP, and=20 > that only > the RTCP recommendation will apply to the SRS, but I did not want to > exclude it and did not see the harm in including the SRS in the > considerations for RTP. I you think it is better to change to: >=20 > If an SRC is sending RTP, it is RECOMMENDED to use symmetric > RTP. If an SRC or SRS is sending RTCP, it is RECOMMENDED to use > symmetric RTCP. >=20 > Cheers, > Charles >=20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, June 17, 2011 9:35 AM > > To: siprec@ietf.org; Charles Eckel (eckelcu) > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > >=20 > > Charles, > >=20 > > I still have a concern on the wording in section 13. It says: > > "If an SRC or SRS is sending RTP, it is RECOMMENDED to use symmetric > > RTP." > > Why would an SRS send RTP (as opposed to RTCP)? > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: i-d-announce-bounces@ietf.org > > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > > internet-drafts@ietf.org > > > Sent: 16 June 2011 22:03 > > > To: i-d-announce@ietf.org > > > Subject: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > > > Title : Real-time Transport Protocol (RTP) > > > Recommendations for SIPREC > > > Author(s) : Charles Eckel > > > Filename : draft-eckel-siprec-rtp-rec-01.txt > > > Pages : 11 > > > Date : 2011-06-16 > > > > > > This document provides recommendations and guidelines=20 > for RTP and > > > RTCP in the context of SIPREC. This document exists as a > > > standalone > > > document to facilitate discussion of the RTP > > > recommendations, and it > > > is anticipated that portions of this document will be > incorporated > > > into [I-D.portman-siprec-protocol] rather than this document > itself > > > being adopted as a working group document. > > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > This Internet-Draft can be retrieved at: > > >=20 > ftp://ftp.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.txt > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > = From john.elwell@siemens-enterprise.com Mon Jun 20 03:53:27 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F4F11E814A for ; Mon, 20 Jun 2011 03:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AGoiMhKffO6 for ; Mon, 20 Jun 2011 03:53:25 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 4C23911E80C6 for ; Mon, 20 Jun 2011 03:53:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1308567202!9603519!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 16066 invoked from network); 20 Jun 2011 10:53:22 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-8.tower-182.messagelabs.com with SMTP; 20 Jun 2011 10:53:22 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id A7DFD1EB83EE; Mon, 20 Jun 2011 12:53:22 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 20 Jun 2011 12:53:22 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , Henry Lum , "Paul Kyzivat (pkyzivat)" Date: Mon, 20 Jun 2011 12:53:21 +0200 Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwraoGY85PiN+LzTEOpAI9MKAfySABwsWngAAEpqOAAgVv9QA== Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> <4DF77EB5.9060009@cisco.com><4DF8C4E0.8020409@cis! co.com> <059AF07365DC474393A19A3AF187DF7407358376@NAHALD.us.int.genesyslab.com> In-Reply-To: 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: "siprec@ietf.org" Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 10:53:27 -0000 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 17 June 2011 22:23 > To: Henry Lum; Paul Kyzivat (pkyzivat); Elwell, John > Cc: siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > Henry, > > > However, I still find it confusing to allow an MS to be moved > across CS > and participants. I worry that we can abuse the MS semantics > to reuse MS > as if it is a physical port of media since an MS is no longer tied to > the lifetime of a CS. Keeping an MS to within a CS makes it > clear about > segments of a call when it gets transferred from person to person. It > will be up to the SRS to stitch the segments of a call (multiple MS) > together. > > > The clear demarcation exists for transfer from person to person exists > using different CS-id after the transfer. > > I'm worried about stitching the segments of a call (session) in case > same media type with multiple MS exists between CS. Say media > stream of > same media type MS1 & MS2 in CS1 of participant1 corresponds to MS3 & > MS4 in CS2 of participant2 in single CSG, how to identify MS1 > corresponds to MS3 or MS4 in CS2. I agree that it is possible to say > that SRS should have some extended metadata mechanism to > achieve to this > but I preferred in case it is handled as part of metadata itself. [JRE] What is meant by "MS1 corresponds to MS3 or MS4"? What exactly is thi= s correspondence? I can understand how the two MS are both part of CSs fro= m the same CSG. I can also understand how they can both be transmitted by t= he same Participant. I can also understand that they might be for the same = media type (e.g., video) and have same content (e.g., slides, current speak= er). All this is visible from the metadata. What other aspect of correspond= ence requires the two MSs to have the same identifier? Or putting the quest= ion another way, what harm is done if the two MSs have different identifier= s? John > > As John mentioned below, the local-id is not going to save > the bandwidth > in the transfer scenario. Even I tried to see the example with full > metadata XML update (instead of partial update) wherein the > size of full > message is less that local-id MS with partial update. I attached the > message for your reference. > > Also, global id (URN UUID) will be able to achieve all the > functionality > of local-id (XML:id) but not the other way around. Say, SRS does not > want to see the relation between MS1 to MS3 or MS4 in the above > scenario, global id is not going to stop anything. > > Regards, > Henry > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Wednesday, June 15, 2011 10:43 AM > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > On 6/15/2011 9:55 AM, Elwell, John wrote: > > Paul, > > > > But if the two SRCs are somehow cooperating to the extent that they > can share the same global ID for the CS, could they not also share the > same local ID for the MS? Why does it need to be a global ID? > > They could *know* each other's local id for the MS. > They might even agree to use the *same* value for the local id. > > E.g. we have SRC#1 and SRC#2, each using 123 as the local id for the > "same" stream. > > But to the SRS, there is one MS with id SRC#1:123, and another MS with > SRC#2:123. It does not know they are the same. (That is the point of > local scoping.) > > So even though the two SRCs know they are talking about the > same MS they > > have no way to tell that to the SRS. > > Thanks, > Paul > > > John > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 14 June 2011 16:31 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > >> > >> John, > >> > >> Consider another case: two SRCs in the same CS (perhaps one at each > >> "end".) They are both sending metadata about the same CS and MSs. > >> > >> Suppose they want to cooperate with each other. They have the > >> potential to use the same ID to reference the CS, so that the SRS > >> will know they are talking about the same one. But with > RS-specific > >> MS ids there is no way for them to indicate that they are talking > >> about the same MSs. With global MS ids, they could accomplish this. > >> > >> Thanks, > >> Paul > >> > >> On 6/14/2011 11:03 AM, Elwell, John wrote: > >>> Partha, > >>> > >>> Thanks for the examples. The character count for the delta > >> is about 2500 when a new MS is created compared to about 2100 when > >> the MS is retained. This seems to be in line with my previous gut > >> feeling. > >>> > >>> Concerning the need for "SRS implementers to guess how old > >> MS and new MS are related", I don't think they are > related, except by > > >> having other things in common like a common participant or > a common > >> CSG. > >>> > >>> John (as individual) > >>> > >>>> -----Original Message----- > >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>> Sent: 14 June 2011 13:15 > >>>> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; > Ram Mohan > >>>> R (rmohanr); siprec@ietf.org > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >>>> > >>>> Hi all, > >>>> > >>>> Sorry for the delay. Just to double confirm everybody > understanding > > >>>> with SIP message example, I added the example with > creating new MS > >>>> and reusing the same MS as an attachment with this mail. > >>>> > >>>> Please note that creating new MS is putting SRS > >> implementers to guess > >>>> how old MS and new MS are related. Also, few scenario like > >> Even after > >>>> looking into the example, the intention is to use local > >> variable, I'm > >>>> ok. > >>>> > >>>> Thanks > >>>> Partha > >>>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) > >>>> Sent: Friday, June 10, 2011 10:57 PM > >>>> To: Leon Portman; Elwell, John; Parthasarathi R (partr); > >> Ram Mohan R > >>>> (rmohanr); siprec@ietf.org > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >>>> > >>>> Please excuse the delay. I am catching up after having > been away on > > >>>> vacation. > >>>> In light of this better understanding of the use case, I also > >>>> prefer the option favored by John and Leon to model as a > separate > >>>> MS. In this specific case, I would expect the properties > of the MS > >>>> to change when A is transferred to C, so I expect the > overhead in > >>>> creating > >> a new MS vs. > >>>> reusing the same MS to be minimal and not worth the added > >>>> complexity to the model. > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> -----Original Message----- > >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >>>>> Sent: Tuesday, May 31, 2011 6:19 AM > >>>>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel > >> (eckelcu); > >>>>> Ram Mohan R (rmohanr); siprec@ietf.org > >>>>> Subject: RE: [siprec] Can an MS object span several CSs > in a CSG? > >>>>> > >>>>> Hello > >>>>> > >>>>> I also having a problem even without a quantification > of number of > > >>>>> update messages that CS MS is remains same between > >>>> different CS. So I > >>>> do prefer to keep it simple and keep it per CS. > >>>>> > >>>>> Leon > >>>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf Of Elwell, John > >>>>> Sent: Friday, May 27, 2011 12:26 PM > >>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); > Ram Mohan R > >>>>> (rmohanr); siprec@ietf.org > >>>>> Subject: Re: [siprec] Can an MS object span several CSs > in a CSG? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>>>> Sent: 26 May 2011 15:55 > >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > (rmohanr); > > >>>>>> siprec@ietf.org > >>>>>> Subject: RE: [siprec] Can an MS object span several > CSs in a CSG? > >>>>>> > >>>>>> John, > >>>>>> > >>>>>> The callflow mentioned by me is the basic primitive in > the call > >>>>>> center scenario wherein customer (participant) is same > throughout > > >>>>>> the session and agents are changed using transfer service > >>>> and B2BUA > >>>> acts as SRC. > >>>>>> IMO, it is one of key requirement to be considered in case we > >>>>>> support for partial-update. > >>>>> [JRE] Agreed the Participant remains the same, but we are > >> discussing > >>>> MS. > >>>>> > >>>>>> This may not be the only callflow where MS partial-update is > >>>>>> required in this fashion. During -00 format draft, I > thought that > > >>>>>> the partial-update is not required but lot of folks raised the > >>>>>> concern that partial update is important. Current, -01 > >>>> format draft > >>>>>> is designed to support partial-update. Now, You propose > >>>> to restrict > >>>>>> MS partial-update across CS. IMO, it is a not good idea > >>>> to restrict > >>>>>> in the protocol level. Anyway, I think that we need > >>>> others opinion > >>>>>> before conclude here. > >>>>> [JRE] I am not opposed to partial update, but I would > >> like to avoid > >>>>> distorting the model just to gain some efficiency > improvements in > >>>>> certain cases. To me it is not intuitive that a MS on one > >>>> CS and an MS > >>>> > >>>>> on another CS are the same object, just because one of the > >>>>> Participants is common to both CSs. In the > transfer-between-agents > >>>> example, although one of the Participants is common to > the two CSs, > > >>>> this is not true for the other Participants. > >>>>> > >>>>> Let's try to quantify the efficiency improvement. In the blind > >>>>> transfer case, the partial updates would at least have > to include: > >>>>> - the removal of P1 from CS1 (where P1 is the first agent > >>>> and CS1 is > >>>>> the first CS); > >>>>> - the removal of P2 from CS1 (where P2 is the transferred > >>>>> participant); > >>>>> - the termination of CS1; > >>>>> - the removal of CS1 from CSG1; > >>>>> - the creation of CS2 (the CS that results from transfer); > >>>>> - the addition to of CS2 to CSG1; > >>>>> - the addition of P2 to CSG1; > >>>>> - the addition of P3 to CS2 (where P3 is the second agent); > >>>>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); > >>>>> - the removal of P2 as a recipient of MS1; > >>>>> - the termination of MS1; > >>>>> - the creation of MS3; > >>>>> - the addition of P3 as a sender of MS3; > >>>>> - the addition of P2 as a recipient of MS3. > >>>>> > >>>>> So all we are arguing about is whether we also include in > >>>> the partial > >>>>> updates EITHER (this I think is your proposal): > >>>>> - the removal of P1 as a recipient of MS2; > >>>>> - the addition of P3 as a recipient of MS2; > >>>>> > >>>>> OR > >>>>> - the removal of P1 as recipient of MS2; > >>>>> - the removal of P2 as a sender of MS2; > >>>>> - the termination MS2; > >>>>> - the creation of MS4; > >>>>> - the addition of P3 as a recipient of MS4; > >>>>> - the addition of P2 as a sender of MS4. > >>>>> > >>>>> So with the first option the total number of deltas is 14+2=3D16. > >>>>> For the second option the total number of deltas is 14+6=3D20. > >>>>> > >>>>> Some of the details might be wrong, but I hope you can see > >>>> the point I > >>>> > >>>>> am getting at. Looked at this way, the efficiency saving by > >>>> recycling > >>>>> MS2 for use in consecutive CSs is relatively small. Or > >> perhaps your > >>>>> intention is also to recycle MS1 (this time, the recipient > >>>> remaining > >>>>> the same but the sender changing). That would reduce > the number of > > >>>>> deltas slightly further. The impact on XML size might not > >>>> be quite in > >>>>> proportion to the reduction in the number of deltas, since by > >>>> recycling MS2 it has to have a global identifier, not an > identifier > > >>>> local to a CS. Or perhaps it could have an identifier > >> local to a CSG. > >>>>> > >>>>> I also see that with your proposal it doesn't force the > MS to be > >>>>> recycled - an SRC could still choose to model it as > separate MSs. > >>>>> However, in that case it would still need to use global > >> identifiers > >>>> for MSs. > >>>>> > >>>>> I am not necessarily opposed to your proposal for recycling > >>>> MS objects > >>>> > >>>>> outside the context of a single CS - I can see advantages and > >>>>> disadvantages. I just want to make sure the group makes > >> an informed > >>>> decision. > >>>>> > >>>>> John (as individual) > >>>>> > >>>>> > >>>>>> > >>>>>> Enhancing label attribute across the multiple SIP > message to tie > >>>>>> between Metadata XML and RS SDP m-line is possible. SRC has to > >>>>>> ensure that label for the given RS SDP m-line should have > >>>> same label > >>>> > >>>>>> throughout single CSG even though it span across > multiple CS and > >>>>>> multiple RS. Even then, it will not meet partial-update > >>>> requirement > >>>>>> as mentioned below in this mail thread. At this moment, > >>>> I'm favoring > >>>> > >>>>>> URN UUID and not label attribute enhancement. > >>>>>> > >>>>>> Please read inline > >>>>>> > >>>>>> Thanks > >>>>>> Partha > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>>> Sent: Wednesday, May 25, 2011 7:17 PM > >>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); > Ram Mohan R > > >>>>>> (rmohanr); siprec@ietf.org > >>>>>> Subject: RE: [siprec] Can an MS object span several > CSs in a CSG? > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>>>>> Sent: 25 May 2011 08:48 > >>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > >>>> (rmohanr); > >>>>>>> siprec@ietf.org > >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs > >>>> in a CSG? > >>>>>>> > >>>>>>> John, > >>>>>>> > >>>>>>> > >>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D > >>>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA > >>>>>>> converts REFER > >>>>>>> > >>>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA > >>>>>>> updates RS > >>>>>>>> with CS2, Participant1 as A& participant2 as C, > >>>> MS1(A's media > >>>>>>>> stream), MS2(C's media stream). There is no update on RS1, > >>>>>>> CSG1, MS1, > >>>>>>>> MS2. MS2 will become MS2 with the new association and > >>>> in terms > >>>>>>>> of format, it will associate with tag > >>>>>>> [JRE] What harm is done (what do we lose) if, following > >>>>>> transfer, A's > >>>>>>> media stream is called MS3 and C's media stream is called MS4? > >>>>>>> > >>>>>> > >>>> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>> =3D > >>>>>>> To indicate MS1 as MS3, MS1 media block has to be > >>>>>> stopped in > >>>>>>> the partial-update and start MS3 separate which is not > >>>> required in > >>>> > >>>>>>> case there is a means to have common MS1. > >>>>>> [JRE] It seems this distorts the model in order to give > >>>> some minor > >>>>>> efficiency improvement during metadata updates. I > doubt that this > > >>>>>> alone is sufficient justification for having the MS > >>>> persist from one > >>>> > >>>>>> CS to another CS. > >>>>>> > >>>>>>> > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >>>>>>> MS3 can reference the same SDP m-line (through > a=3Dlabel) as MS1, > >>>>>>> and likewise MS4 could reference the same SDP m-line as > >>>> MS2, if we > >>>> > >>>>>>> are concerned about recycling media descriptions in RS SDP. > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> As you mentioned, we will lose recycling of media > >>>>>> description > >>>>>>> in RS SDP without common value in media stream object > for this > >>>>>>> scenario. > >>>>>> [JRE] I don't understand your point. With my proposal we > >>>> can still > >>>>>> recycle RS SDP m-lines. > >>>>>> > >>>>>> Agreed that Recycle is possible with your proposal. > >>>>>> I indicated > >>>>>> the need for unique-id in this requirement > >>>>>> > >>>>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label > >>>>>> attribute > >>>>>>> scope is within single SIP message and not required to > >>>> be unique > >>>>>>> in all SIP messages of a given dialog. > >>>>>> [JRE] But I think we could nail that down as a > requirement of the > > >>>>>> SIPREC protocol. > >>>>>> > >>>>>> John (as individual) > >>>>>> > >>>>>>> > >>>>>>> Thanks > >>>>>>> Partha > >>>>>>> > >>>>>>> John (as individual) > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> Partha > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Charles Eckel (eckelcu) > >>>>>>>> Sent: Wednesday, May 25, 2011 1:39 AM > >>>>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); > >>>>>> 'Elwell, John'; > >>>>>>>> 'siprec@ietf.org' > >>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a > >>>> CSG? > >>>>>>>> > >>>>>>>> Hi Ram, > >>>>>>>> > >>>>>>>> I think that is many cases, they will be treated as > >>>> separate MSs > >>>> > >>>>>>>> due to the complexities you mention. However, I am trying to > >>>>>> understand if > >>>>>>>> Partha feels allowing an SRC to treat them as a single MS is > >>>>>>>> still required. If not, then what is a use case? A concrete > >>>>>>>> example would help me, and potentially others, to better > >>>>>>>> understand the > >>>>>>> motivation behind > >>>>>>>> Partha's requirement for modeling media from multiple CSs > >>>>>>> as a single > >>>>>>>> MS. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Charles > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Ram Mohan R (rmohanr) > >>>>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM > >>>>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); > >>>>>>> Elwell, John; > >>>>>>>>> siprec@ietf.org > >>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs > >>>>>> in a CSG? > >>>>>>>>> > >>>>>>>>> Charles, > >>>>>>>>> > >>>>>>>>> I did bring about this specific usecase of MMOH/MOH > >>>>>> stream being > >>>>>>>>> played to different participants earlier and suggested that > >>>>>>>> they have > >>>>>>>>> to treated as a same MS across multiple CSs > >>>>>> (potentially recorded > >>>>>>>> using multiple RSs). > >>>>>>>>> Refer > >>>>>>>>> > >>>>>> > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > >>>>>>>>> > >>>>>>>>> We had several discussions on it and it and several > >>>>>> folks were in > >>>>>>>>> favor of treating it as separate MS as there would be > >>>>>>>> complexity in DB > >>>>>>>> design. > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Ram > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: siprec-bounces@ietf.org > >>>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>>>> Behalf Of Charles Eckel (eckelcu) > >>>>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM > >>>>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > >>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > >>>>>>> in a CSG? > >>>>>>>>>> > >>>>>>>>>> Hi Partha, > >>>>>>>>>> > >>>>>>>>>> Is an example of this the same music on hold audio stream > >>>>>>>> existing > >>>>>>>>>> as the same MS within multiple CSs? If so, then I > >>>>>>> understand your > >>>>>>>>>> requirement to be that the SRC be able to > >>>> indicate multiple > >>>>>>>>>> instances of this audio stream within several CSs as > >>>>>>>> being the same > >>>>>>>>>> MS. Is that correct? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Charles > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: siprec-bounces@ietf.org > >>>>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>>>> Behalf Of Parthasarathi R (partr) > >>>>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM > >>>>>>>>>>> To: Elwell, John; siprec@ietf.org > >>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > >>>>>>>> in a CSG? > >>>>>>>>>>> > >>>>>>>>>>> John, > >>>>>>>>>>> > >>>>>>>>>>> I agree that it is not mandatory to consider recorded > >>>>>>>> stream of a > >>>>>>>>>>> specific participant in several CS within the same > >>>>>> CSG as one > >>>>>>>>>> recorded > >>>>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a > >>>>>>>> SRC in case > >>>>>>>>>>> it wishes to design in such a way. > >>>>>>>>>>> > >>>>>>>>>>> Thanks > >>>>>>>>>>> Partha > >>>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: siprec-bounces@ietf.org > >>>>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>>>> Behalf > >>>>>>>>>>> Of Elwell, John > >>>>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM > >>>>>>>>>>> To: siprec@ietf.org > >>>>>>>>>>> Subject: [siprec] Can an MS object span several CSs > >>>>>> in a CSG? > >>>>>>>>>>> > >>>>>>>>>>> We seem to have consensus that a Media Stream object > >>>>>>>> represents a > >>>>>>>>>>> recorded media stream, contributed to by one, > >>>>>> several or all > >>>>>>>>>>> Participants. However, Partha also wrote: > >>>>>>>>>>> > >>>>>>>>>>> "2) Each MS lifetime related to CSG because participant > >>>>>>>> may move > >>>>>>>>>>> from one CS to another CS within single CSG and also > >>>>>>>> CSG will span > >>>>>>>> > >>>>>>>>>>> across multiple RS." > >>>>>>>>>>> > >>>>>>>>>>> I am not sure we had resolved this during earlier > >>>>>>>> discussions on > >>>>>>>>>>> the scope of an MS object. Although the same > >>>>>> Participant can > >>>>>>>>>>> participate > >>>>>>>>>> in > >>>>>>>>>>> several CSs within the same CSG, I don't think the > >>>>>>>> recorded media > >>>>>>>>>>> streams need to be considered the same. Any other views? > >>>>>>>>>>> > >>>>>>>>>>> John (as individual) > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> siprec mailing list > >>>>>>>>>>> siprec@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> siprec mailing list > >>>>>>>>>>> siprec@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> siprec mailing list > >>>>>>>>>> siprec@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> siprec mailing list > >>>>> siprec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >>> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >> > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > > -------------------------------------------------------------- > ---------- > ------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential and proprietary information of Alcatel-Lucent and/or its > affiliated entities. Access by the intended recipient only is > authorized. Any liability arising from any party acting, or refraining > from acting, on any information contained in this e-mail is hereby > excluded. If you are not the intended recipient, please notify the > sender immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other > person, use it > for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Mon Jun 20 03:57:18 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428D611E814A for ; Mon, 20 Jun 2011 03:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo9SABCsvPu9 for ; Mon, 20 Jun 2011 03:57:17 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 5A7BC11E813F for ; Mon, 20 Jun 2011 03:57:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1308567433!8609319!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 10551 invoked from network); 20 Jun 2011 10:57:13 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-5.tower-216.messagelabs.com with SMTP; 20 Jun 2011 10:57:13 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id B2EA523F03E2; Mon, 20 Jun 2011 12:57:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 20 Jun 2011 12:57:14 +0200 From: "Elwell, John" To: Paul Kyzivat , "Parthasarathi R (partr)" Date: Mon, 20 Jun 2011 12:57:12 +0200 Thread-Topic: Codec parameter in stream element Thread-Index: Acwt1htz4JH8fAqlTYyd52KDCeW4NgBYqZPQ Message-ID: References: <4DFCD46C.1030408@cisco.com> In-Reply-To: <4DFCD46C.1030408@cisco.com> 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: "siprec@ietf.org" Subject: Re: [siprec] Codec parameter in stream element X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 10:57:18 -0000 Yes, I think Paul's summary of where we are is correct. John=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 18 June 2011 17:38 > To: Parthasarathi R (partr) > Cc: siprec@ietf.org; Elwell, John; HKaplan@acmepacket.com > Subject: Re: Codec parameter in stream element >=20 > Yes, AFAIK we agreed that the codec info in the RS is sufficient - it=20 > describes the media as it is available to the SRS. It may not be the=20 > same as what was in the CS, but people were not concerned=20 > with knowning=20 > that. >=20 > Thanks, > Paul >=20 > On 6/17/2011 5:47 PM, Parthasarathi R (partr) wrote: > > Hi all, > > Codec parameter in stream element is an open issue. It was discussed > > during IETF-80 and minutes of IETF-80 about this discussion=20 > is mentioned > > as a note of this mail. > > As per the recent conclusion in metadata, "recording" metadata > > information is retrieved from RS SIP headers. In the same way, it is > > possible to fetch codec parameter from RS SDP in SRS for=20 > codec parameter > > related to stream element in metadata as there is a linkage between > > stream element and RS SDP using label attribute. Please let=20 > me know any > > specific issue in fetching from RS SDP in SRS. > > Including John, Paul, Hadriel in this mail thread for aiming at the > > closure atleast during this interim meeting. > > Thanks > > Partha > > Note: IETF-80 Minutes: > > Slide 18: Open issue: Codec parameter in stream element.=20 > John Elwell (from > > floor) disliked duplication, but thought there was a need=20 > to consider what > > information needs to be passed up to the application at the=20 > SRS, e.g., > > the media > > type would be needed. So this could result in a small amount of > > duplication to > > provide this in the XML for the application. Paul Kyzivat was most > > concerned > > about the direction attribute, since it is hard to figure=20 > out from the > > RS SDP > > the direction of the CS media. Paul also felt that the SRS=20 > could pass > > information from the RS SDP up to the application if needed, without > > necessarily > > requiring that information in XML. Hadriel Kaplan disliked=20 > duplication, > > although > > the need for information in XML might depend on the RTP model. Will > > continue > > discussion on relationship between information in XML and=20 > information in > > SDP on > > the mailing list. > = From john.elwell@siemens-enterprise.com Mon Jun 20 04:00:54 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B85411E814E for ; Mon, 20 Jun 2011 04:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.958 X-Spam-Level: X-Spam-Status: No, score=-105.958 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoz-yGGchvkg for ; Mon, 20 Jun 2011 04:00:53 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 52AFA11E8143 for ; Mon, 20 Jun 2011 04:00:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1308567644!22027858!8 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 30569 invoked from network); 20 Jun 2011 11:00:51 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-7.tower-174.messagelabs.com with SMTP; 20 Jun 2011 11:00:51 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id C26DF1EB83D3; Mon, 20 Jun 2011 13:00:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 20 Jun 2011 13:00:51 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Mon, 20 Jun 2011 13:00:50 +0200 Thread-Topic: [siprec] Use of RFC 2119 language in the metadata model Thread-Index: AcwQdhOQ6/kxuRXySmKl3XqMpU4g4Qdu++DAAEG8wAA= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD06C39AAF@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06C39AAF@XMB-BGL-417.cisco.com> 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: [siprec] Use of RFC 2119 language in the metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 11:00:54 -0000 Ram, As there has been no list discussion on this, in follow-up to my question, = I suggest you keep the RFC 2119 language as is in -01 and revisit when we m= erge the format stuff into the draft (see my separate email on that topic).= You may wish to add it to your slides as an open issue for discussion at t= he meeting (put it at the end). John =20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 19 June 2011 04:41 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Use of RFC 2119 language in the metadata model >=20 > Hi John / All, >=20 > I have not seen any views / discussion on this thread. >=20 > I am planning to publish draft-ietf-siprec-metadata-01. Before I go > ahead would like to get the opinion on how to go about for=20 > this issue.=20 > Do we want to leave the current language ( use of RFC 2119)=20 > as it is for > ver 01 and re-visit later when we merge format in to model ? > OR > Do we want to remove all the normative statements right=20 > now(for 01) and > have them (around the format portions) when we merge format=20 > and model ? >=20 > Let me know your opinions soon. I plan to publish the draft by Monday > evening or Tuesday morning(at the most). >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Thursday, May 12, 2011 12:58 PM > > To: siprec@ietf.org > > Subject: [siprec] Use of RFC 2119 language in the metadata model > >=20 > > Draft-ietf-metadata-00 makes extensive use of RFC 2119 language. At > > present this is an Informational document (although that does not > > necessarily prevent the use of RFC 2119 language), but eventually we > > anticipate incorporating the format material, and as a result the > > document would target a Proposed Standard. The format stuff clearly > has > > to be implemented by SRCs and SRSs, so I would expect normative > > language around those aspects. However, to draw a clear distinction > > between what has to be implemented and what is just abstract we > > probably need to refrain from RFC 2119 language when just describing > > the abstract model. Views? > >=20 > > John > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Mon Jun 20 04:01:56 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9106211E8151 for ; Mon, 20 Jun 2011 04:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAK1unOOuCKG for ; Mon, 20 Jun 2011 04:01:56 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id B0F4811E8143 for ; Mon, 20 Jun 2011 04:01:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1308567714!8595344!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 29628 invoked from network); 20 Jun 2011 11:01:54 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-2.tower-182.messagelabs.com with SMTP; 20 Jun 2011 11:01:54 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id C182923F03E2 for ; Mon, 20 Jun 2011 13:01:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 20 Jun 2011 13:01:54 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 20 Jun 2011 13:01:53 +0200 Thread-Topic: Adoption of material from draft-ram-siprec-metadata-format-02 Thread-Index: AcwvOXaZg+4+wDzBQu2PC/LOxWkIwA== 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: [siprec] Adoption of material from draft-ram-siprec-metadata-format-02 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 11:01:56 -0000 Although there are some open issues, to be discussed during Thursday's call= , I would like the WG to consider whether material in draft-ram-siprec-meta= data-format-02 is ready for adoption into draft-ietf-siprec-metadata, i.e.,= bring it under WG control. In particular, between now and the call, please= consider whether: - the material is heading roughly in an acceptable direction; - there are any issues that really should be closed before adoption; - there are any aspects of the draft that should not be adopted at this tim= e. If, on the call or shortly afterwards, we can agree on adoption, the author= s of the two drafts would be asked to perform a merger and publish a new ve= rsion of draft-ietf-siprec-metadata before the cut-off for IETF#81 (2011-07= -11). John= From partr@cisco.com Mon Jun 20 04:03:38 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88F211E8156 for ; Mon, 20 Jun 2011 04:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.359 X-Spam-Level: X-Spam-Status: No, score=-10.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bhDxbiVpJwt for ; Mon, 20 Jun 2011 04:03:38 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A88F611E814E for ; Mon, 20 Jun 2011 04:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=3016; q=dns/txt; s=iport; t=1308567817; x=1309777417; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+74m2CpUioEXl/Jt1Ls4bMPY0GZD0Uyf9AEpWCAm3D0=; b=QxkLFhqHfiUKrwdWmi6JydIv3Q/a9emrUJj2dfJJneJVXuX8nYnTc5Ag cjFz6td4XSPdXnbLYOUT89EuMWwsc0SNEV8xYvR8blAEU3QeqtPIqOSGi mchvQxGosi5w1TRBDOrW9fzEyLzFZKnS2AoucDxdI35hxA9FTsIkXlCsK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAANgn/01Io8UR/2dsb2JhbABTl1GPCneIc6ElnUyGKgSHHo8piyA X-IronPort-AV: E=Sophos;i="4.65,392,1304294400"; d="scan'208";a="36038067" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 20 Jun 2011 11:03:26 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5KB3Q62021288; Mon, 20 Jun 2011 11:03:26 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 16:33:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 16:33:25 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Codec parameter in stream element Thread-Index: Acwt1htz4JH8fAqlTYyd52KDCeW4NgBYqZPQAAAODpA= References: <4DFCD46C.1030408@cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 20 Jun 2011 11:03:26.0607 (UTC) FILETIME=[AE0471F0:01CC2F39] Cc: siprec@ietf.org Subject: Re: [siprec] Codec parameter in stream element X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 11:03:38 -0000 Paul/John, Thanks for the confirmation. Based on the below mail thread discussion, I'm considering "codec parameter in stream element" open item in metadata format as closed. I'll update the slide for interim meeting accordingly. Thanks Partha=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, June 20, 2011 4:27 PM To: Paul Kyzivat (pkyzivat); Parthasarathi R (partr) Cc: siprec@ietf.org; HKaplan@acmepacket.com Subject: RE: Codec parameter in stream element Yes, I think Paul's summary of where we are is correct. John=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 18 June 2011 17:38 > To: Parthasarathi R (partr) > Cc: siprec@ietf.org; Elwell, John; HKaplan@acmepacket.com > Subject: Re: Codec parameter in stream element >=20 > Yes, AFAIK we agreed that the codec info in the RS is sufficient - it=20 > describes the media as it is available to the SRS. It may not be the=20 > same as what was in the CS, but people were not concerned with=20 > knowning that. >=20 > Thanks, > Paul >=20 > On 6/17/2011 5:47 PM, Parthasarathi R (partr) wrote: > > Hi all, > > Codec parameter in stream element is an open issue. It was discussed > > during IETF-80 and minutes of IETF-80 about this discussion > is mentioned > > as a note of this mail. > > As per the recent conclusion in metadata, "recording" metadata=20 > > information is retrieved from RS SIP headers. In the same way, it is > > possible to fetch codec parameter from RS SDP in SRS for > codec parameter > > related to stream element in metadata as there is a linkage between=20 > > stream element and RS SDP using label attribute. Please let > me know any > > specific issue in fetching from RS SDP in SRS. > > Including John, Paul, Hadriel in this mail thread for aiming at the=20 > > closure atleast during this interim meeting. > > Thanks > > Partha > > Note: IETF-80 Minutes: > > Slide 18: Open issue: Codec parameter in stream element.=20 > John Elwell (from > > floor) disliked duplication, but thought there was a need > to consider what > > information needs to be passed up to the application at the > SRS, e.g., > > the media > > type would be needed. So this could result in a small amount of=20 > > duplication to provide this in the XML for the application. Paul=20 > > Kyzivat was most concerned about the direction attribute, since it=20 > > is hard to figure > out from the > > RS SDP > > the direction of the CS media. Paul also felt that the SRS > could pass > > information from the RS SDP up to the application if needed, without > > necessarily requiring that information in XML. Hadriel Kaplan=20 > > disliked > duplication, > > although > > the need for information in XML might depend on the RTP model. Will=20 > > continue discussion on relationship between information in XML and > information in > > SDP on > > the mailing list. >=20 From internet-drafts@ietf.org Mon Jun 20 04:22:28 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AEC11E8154; Mon, 20 Jun 2011 04:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rtc2ZkpU0P8I; Mon, 20 Jun 2011 04:22:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC2D11E810D; Mon, 20 Jun 2011 04:22:28 -0700 (PDT) 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.55 Message-ID: <20110620112228.5609.29422.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 04:22:28 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 11:22:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : Session Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-01.txt Pages : 23 Date : 2011-06-20 Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-01.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-siprec-metadata-01.txt From rmohanr@cisco.com Mon Jun 20 04:27:52 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B21511E810C for ; Mon, 20 Jun 2011 04:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7iI+H-0q9nY for ; Mon, 20 Jun 2011 04:27:51 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 10D8411E807A for ; Mon, 20 Jun 2011 04:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2435; q=dns/txt; s=iport; t=1308569271; x=1309778871; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tISlxHx3DjEgn9sV9elQQcspmoFFw0avtYJ+82OvzCY=; b=knIma/uGZGXn+IscF0IOgHVvv0kwR14DtsriFrOCbDx1TeTSn768bOLF zjBoKI3zmfujPjHmIBobQEUONK/QG65vLeVIv3NHN5Qpfpetue7FVVmaQ WBe++6aQeVMB/5lspnyiTZNXVSvykO9rzKLnlwRAucx+5oRJpA4TVM0jb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkBAOkt/01Io8UT/2dsb2JhbABTl1FBjkl3qhedToYqBIcejymLIA X-IronPort-AV: E=Sophos;i="4.65,393,1304294400"; d="scan'208";a="36041687" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 20 Jun 2011 11:27:49 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5KBRnd5014066 for ; Mon, 20 Jun 2011 11:27:49 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 16:57:49 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 16:57:46 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06C39D26@XMB-BGL-417.cisco.com> In-Reply-To: <20110620112228.5609.29422.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for review of draft-ietf-siprec-metadata-01.txt Thread-Index: AcwvPGUitpS/9om4R4W4EfmJY0D05wAABxZg References: <20110620112228.5609.29422.idtracker@ietfa.amsl.com> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 20 Jun 2011 11:27:49.0237 (UTC) FILETIME=[15D01250:01CC2F3D] Subject: [siprec] Request for review of draft-ietf-siprec-metadata-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 11:27:52 -0000 Hello All, I have just posted a new version for metadata model.=20 http://tools.ietf.org/html/draft-ietf-siprec-metadata-01 It has following changes: 1) CSG is made optional in the model. The model and instance diagrams and the associations are updated to reflect the same. 2) Incorporated the agreed comments after the=20 last interim - http://www.ietf.org/mail-archive/web/siprec/current/msg01991.html 3) Incorporated Muthu's comments - http://www.ietf.org/mail-archive/web/siprec/current/msg02012.html 4) Incorporated the comments from Henry / Charles Please review the draft and provide your valuable comments. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Monday, June 20, 2011 4:52 PM > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SIP Recording Working > Group of the IETF. >=20 > Title : Session Initiation Protocol (SIP) Recording > Metadata > Author(s) : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ietf-siprec-metadata-01.txt > Pages : 23 > Date : 2011-06-20 >=20 > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes the metadata model as > viewed by Session Recording Server(SRS). >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-metadata-01.txt > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Mon Jun 20 04:29:44 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A487811E807E for ; Mon, 20 Jun 2011 04:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.617 X-Spam-Level: X-Spam-Status: No, score=-9.617 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8QnwjTBOEiC for ; Mon, 20 Jun 2011 04:29:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B72AD11E807A for ; Mon, 20 Jun 2011 04:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2983; q=dns/txt; s=iport; t=1308569383; x=1309778983; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=NEQoo99D2nH8jInsXwbwHy2Bcg8ODVS7xYDHnCMNVY0=; b=G6ElfnrRnoyl8A0/8dQ6wAMLktNISpHJ08luNLzO0/QuN3JSxpVYjFt7 k68gTkk+vMBPodkaArNfp7Bpekav5f9vQsWiP4PW1fbDgI5IMtxOtsTwk ueDKbbEbrzG9jKanRYSXWN4jh+mgj68PHS/SZ4zxk9h1qRyzh9re3NL+7 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAOkt/01Io8UR/2dsb2JhbABTl1GPCneIc6EknU6GKgSHHo8piyA X-IronPort-AV: E=Sophos;i="4.65,393,1304294400"; d="scan'208";a="94865443" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2011 11:29:41 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5KBTfbW025277; Mon, 20 Jun 2011 11:29:41 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 16:59:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 16:59:39 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06C39D29@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Use of RFC 2119 language in the metadata model Thread-Index: AcwQdhOQ6/kxuRXySmKl3XqMpU4g4Qdu++DAAEG8wAAAAQopYA== References: <35BCE99A477D6A4986FB2216D8CF2CFD06C39AAF@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 20 Jun 2011 11:29:41.0413 (UTC) FILETIME=[58ACC550:01CC2F3D] Subject: Re: [siprec] Use of RFC 2119 language in the metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 11:29:44 -0000 John, Thanks for response. I kept the language as it is and posted the draft. Also I have added a point in slides(of June 23 interim) to track this item. Regards, Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, June 20, 2011 4:31 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Use of RFC 2119 language in the metadata model >=20 > Ram, >=20 > As there has been no list discussion on this, in follow-up to my > question, I suggest you keep the RFC 2119 language as is in -01 and > revisit when we merge the format stuff into the draft (see my separate > email on that topic). You may wish to add it to your slides as an open > issue for discussion at the meeting (put it at the end). >=20 > John >=20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 19 June 2011 04:41 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] Use of RFC 2119 language in the metadata model > > > > Hi John / All, > > > > I have not seen any views / discussion on this thread. > > > > I am planning to publish draft-ietf-siprec-metadata-01. Before I go > > ahead would like to get the opinion on how to go about for > > this issue. > > Do we want to leave the current language ( use of RFC 2119) > > as it is for > > ver 01 and re-visit later when we merge format in to model ? > > OR > > Do we want to remove all the normative statements right > > now(for 01) and > > have them (around the format portions) when we merge format > > and model ? > > > > Let me know your opinions soon. I plan to publish the draft by Monday > > evening or Tuesday morning(at the most). > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Thursday, May 12, 2011 12:58 PM > > > To: siprec@ietf.org > > > Subject: [siprec] Use of RFC 2119 language in the metadata model > > > > > > Draft-ietf-metadata-00 makes extensive use of RFC 2119 language. At > > > present this is an Informational document (although that does not > > > necessarily prevent the use of RFC 2119 language), but eventually > we > > > anticipate incorporating the format material, and as a result the > > > document would target a Proposed Standard. The format stuff clearly > > has > > > to be implemented by SRCs and SRSs, so I would expect normative > > > language around those aspects. However, to draw a clear distinction > > > between what has to be implemented and what is just abstract we > > > probably need to refrain from RFC 2119 language when just > describing > > > the abstract model. Views? > > > > > > John > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > From partr@cisco.com Mon Jun 20 04:49:55 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC1511E80A4 for ; Mon, 20 Jun 2011 04:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.381 X-Spam-Level: X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujNziUbd1tTs for ; Mon, 20 Jun 2011 04:49:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 799EE11E807A for ; Mon, 20 Jun 2011 04:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=27737; q=dns/txt; s=iport; t=1308570592; x=1309780192; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=R/NWTgdK0Qr8ir0DhZykz+/gfz7q1Yzt8WLEWtCr3p4=; b=ZUfh2tox/uD04vsdOcgJ/lkhfvT09XZdOfsAji5KmUxCYfncF4bV1206 NhjkoGTZOiKuv6mPeI2hDz3MWEu/iQyAA7a3Qg5SK8KpFQ7eQB5AljFWU TT6rIou9+kLM7KjWm3WZPY6883stjbQODBBF2CJfxHnVxqQFIEWue1JGc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAJYy/01Io8US/2dsb2JhbABFDpdRjwp3iHOhB51Vgx2DDQSHHo8piyA X-IronPort-AV: E=Sophos;i="4.65,393,1304294400"; d="scan'208";a="94869609" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2011 11:49:49 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5KBnn8Y017617; Mon, 20 Jun 2011 11:49:49 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 17:19:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 17:19:27 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwraoGY85PiN+LzTEOpAI9MKAfySABwsWngAAEpqOAAgVv9QAAAniMg References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com><4DF77EB5.9060009@cisco.com><4DF8C4E0.8020409@cis! co.c om> <05 9AF07365DC47 4393A19A3AF187DF7407358376@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Henry Lum" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 20 Jun 2011 11:49:31.0117 (UTC) FILETIME=[1DCB31D0:01CC2F40] Cc: siprec@ietf.org Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 11:49:55 -0000 John, [JRE] What is meant by "MS1 corresponds to MS3 or MS4"? What exactly is this correspondence?=20 For example, Two audio stream (MS1, MS2) without content type in CS1 by participant1 has to be correspond to an another two audio stream (MS3, MS4) without content type in CS2 by participant1 under single CSG1. Here is the question how to identify MS1 to MS3 or MS4? [JRE] I can understand how the two MS are both part of CSs from the same CSG. I can also understand how they can both be transmitted by the same Participant. I can also understand that they might be for the same media type (e.g., video) and have same content (e.g., slides, current speaker). All this is visible from the metadata.=20 We are in the same page till here. The missing piece is the relationship for same multiple media types across CS if exist without content type. Here, I may have concern about some specific case which I could think of. I'm fine with local MS id in case folks feel that the above scenario is just one of the corner case for the solution. I could think of slightly modified proposal in your label attribute extension. Say CSG1:MSid as the unique-id wherein CSG1 is the globally unique-id and MSid is the extension of label attribute wherein label attribute for the given MS is same throughout the given CSG. [JRE]What other aspect of correspondence requires the two MSs to have the same identifier?=20 Ram mentioned about multicast scenario in another mail thread wherein correspondence is required between two MSs. Or putting the question another way, what harm is done if the two MSs have different identifiers? Thanks Partha =20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, June 20, 2011 4:23 PM To: Parthasarathi R (partr); Henry Lum; Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 17 June 2011 22:23 > To: Henry Lum; Paul Kyzivat (pkyzivat); Elwell, John > Cc: siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > Henry, > > > However, I still find it confusing to allow an MS to be moved across=20 > CS and participants. I worry that we can abuse the MS semantics to=20 > reuse MS as if it is a physical port of media since an MS is no longer > tied to the lifetime of a CS. Keeping an MS to within a CS makes it=20 > clear about segments of a call when it gets transferred from person to > person. It will be up to the SRS to stitch the segments of a call=20 > (multiple MS) together. > > > The clear demarcation exists for transfer from person to person exists > using different CS-id after the transfer. > > I'm worried about stitching the segments of a call (session) in case=20 > same media type with multiple MS exists between CS. Say media stream=20 > of same media type MS1 & MS2 in CS1 of participant1 corresponds to MS3 > & > MS4 in CS2 of participant2 in single CSG, how to identify MS1=20 > corresponds to MS3 or MS4 in CS2. I agree that it is possible to say=20 > that SRS should have some extended metadata mechanism to achieve to=20 > this but I preferred in case it is handled as part of metadata itself. [JRE] What is meant by "MS1 corresponds to MS3 or MS4"? What exactly is this correspondence? I can understand how the two MS are both part of CSs from the same CSG. I can also understand how they can both be transmitted by the same Participant. I can also understand that they might be for the same media type (e.g., video) and have same content (e.g., slides, current speaker). All this is visible from the metadata. What other aspect of correspondence requires the two MSs to have the same identifier? Or putting the question another way, what harm is done if the two MSs have different identifiers? John > > As John mentioned below, the local-id is not going to save the=20 > bandwidth in the transfer scenario. Even I tried to see the example=20 > with full metadata XML update (instead of partial update) wherein the=20 > size of full message is less that local-id MS with partial update. I=20 > attached the message for your reference. > > Also, global id (URN UUID) will be able to achieve all the=20 > functionality of local-id (XML:id) but not the other way around. Say,=20 > SRS does not want to see the relation between MS1 to MS3 or MS4 in the > above scenario, global id is not going to stop anything. > > Regards, > Henry > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, June 15, 2011 10:43 AM > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > On 6/15/2011 9:55 AM, Elwell, John wrote: > > Paul, > > > > But if the two SRCs are somehow cooperating to the extent that they > can share the same global ID for the CS, could they not also share the > same local ID for the MS? Why does it need to be a global ID? > > They could *know* each other's local id for the MS. > They might even agree to use the *same* value for the local id. > > E.g. we have SRC#1 and SRC#2, each using 123 as the local id for the > "same" stream. > > But to the SRS, there is one MS with id SRC#1:123, and another MS with > SRC#2:123. It does not know they are the same. (That is the point of > local scoping.) > > So even though the two SRCs know they are talking about the > same MS they > > have no way to tell that to the SRS. > > Thanks, > Paul > > > John > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 14 June 2011 16:31 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > >> > >> John, > >> > >> Consider another case: two SRCs in the same CS (perhaps one at each > >> "end".) They are both sending metadata about the same CS and MSs. > >> > >> Suppose they want to cooperate with each other. They have the > >> potential to use the same ID to reference the CS, so that the SRS > >> will know they are talking about the same one. But with > RS-specific > >> MS ids there is no way for them to indicate that they are talking > >> about the same MSs. With global MS ids, they could accomplish this. > >> > >> Thanks, > >> Paul > >> > >> On 6/14/2011 11:03 AM, Elwell, John wrote: > >>> Partha, > >>> > >>> Thanks for the examples. The character count for the delta > >> is about 2500 when a new MS is created compared to about 2100 when > >> the MS is retained. This seems to be in line with my previous gut > >> feeling. > >>> > >>> Concerning the need for "SRS implementers to guess how old > >> MS and new MS are related", I don't think they are > related, except by > > >> having other things in common like a common participant or > a common > >> CSG. > >>> > >>> John (as individual) > >>> > >>>> -----Original Message----- > >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>> Sent: 14 June 2011 13:15 > >>>> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; > Ram Mohan > >>>> R (rmohanr); siprec@ietf.org > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >>>> > >>>> Hi all, > >>>> > >>>> Sorry for the delay. Just to double confirm everybody > understanding > > >>>> with SIP message example, I added the example with > creating new MS > >>>> and reusing the same MS as an attachment with this mail. > >>>> > >>>> Please note that creating new MS is putting SRS > >> implementers to guess > >>>> how old MS and new MS are related. Also, few scenario like > >> Even after > >>>> looking into the example, the intention is to use local > >> variable, I'm > >>>> ok. > >>>> > >>>> Thanks > >>>> Partha > >>>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) > >>>> Sent: Friday, June 10, 2011 10:57 PM > >>>> To: Leon Portman; Elwell, John; Parthasarathi R (partr); > >> Ram Mohan R > >>>> (rmohanr); siprec@ietf.org > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >>>> > >>>> Please excuse the delay. I am catching up after having > been away on > > >>>> vacation. > >>>> In light of this better understanding of the use case, I also > >>>> prefer the option favored by John and Leon to model as a > separate > >>>> MS. In this specific case, I would expect the properties > of the MS > >>>> to change when A is transferred to C, so I expect the > overhead in > >>>> creating > >> a new MS vs. > >>>> reusing the same MS to be minimal and not worth the added > >>>> complexity to the model. > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> -----Original Message----- > >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >>>>> Sent: Tuesday, May 31, 2011 6:19 AM > >>>>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel > >> (eckelcu); > >>>>> Ram Mohan R (rmohanr); siprec@ietf.org > >>>>> Subject: RE: [siprec] Can an MS object span several CSs > in a CSG? > >>>>> > >>>>> Hello > >>>>> > >>>>> I also having a problem even without a quantification > of number of > > >>>>> update messages that CS MS is remains same between > >>>> different CS. So I > >>>> do prefer to keep it simple and keep it per CS. > >>>>> > >>>>> Leon > >>>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf Of Elwell, John > >>>>> Sent: Friday, May 27, 2011 12:26 PM > >>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); > Ram Mohan R > >>>>> (rmohanr); siprec@ietf.org > >>>>> Subject: Re: [siprec] Can an MS object span several CSs > in a CSG? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>>>> Sent: 26 May 2011 15:55 > >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > (rmohanr); > > >>>>>> siprec@ietf.org > >>>>>> Subject: RE: [siprec] Can an MS object span several > CSs in a CSG? > >>>>>> > >>>>>> John, > >>>>>> > >>>>>> The callflow mentioned by me is the basic primitive in > the call > >>>>>> center scenario wherein customer (participant) is same > throughout > > >>>>>> the session and agents are changed using transfer service > >>>> and B2BUA > >>>> acts as SRC. > >>>>>> IMO, it is one of key requirement to be considered in case we > >>>>>> support for partial-update. > >>>>> [JRE] Agreed the Participant remains the same, but we are > >> discussing > >>>> MS. > >>>>> > >>>>>> This may not be the only callflow where MS partial-update is > >>>>>> required in this fashion. During -00 format draft, I > thought that > > >>>>>> the partial-update is not required but lot of folks raised the > >>>>>> concern that partial update is important. Current, -01 > >>>> format draft > >>>>>> is designed to support partial-update. Now, You propose > >>>> to restrict > >>>>>> MS partial-update across CS. IMO, it is a not good idea > >>>> to restrict > >>>>>> in the protocol level. Anyway, I think that we need > >>>> others opinion > >>>>>> before conclude here. > >>>>> [JRE] I am not opposed to partial update, but I would > >> like to avoid > >>>>> distorting the model just to gain some efficiency > improvements in > >>>>> certain cases. To me it is not intuitive that a MS on one > >>>> CS and an MS > >>>> > >>>>> on another CS are the same object, just because one of the > >>>>> Participants is common to both CSs. In the > transfer-between-agents > >>>> example, although one of the Participants is common to > the two CSs, > > >>>> this is not true for the other Participants. > >>>>> > >>>>> Let's try to quantify the efficiency improvement. In the blind > >>>>> transfer case, the partial updates would at least have > to include: > >>>>> - the removal of P1 from CS1 (where P1 is the first agent > >>>> and CS1 is > >>>>> the first CS); > >>>>> - the removal of P2 from CS1 (where P2 is the transferred > >>>>> participant); > >>>>> - the termination of CS1; > >>>>> - the removal of CS1 from CSG1; > >>>>> - the creation of CS2 (the CS that results from transfer); > >>>>> - the addition to of CS2 to CSG1; > >>>>> - the addition of P2 to CSG1; > >>>>> - the addition of P3 to CS2 (where P3 is the second agent); > >>>>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); > >>>>> - the removal of P2 as a recipient of MS1; > >>>>> - the termination of MS1; > >>>>> - the creation of MS3; > >>>>> - the addition of P3 as a sender of MS3; > >>>>> - the addition of P2 as a recipient of MS3. > >>>>> > >>>>> So all we are arguing about is whether we also include in > >>>> the partial > >>>>> updates EITHER (this I think is your proposal): > >>>>> - the removal of P1 as a recipient of MS2; > >>>>> - the addition of P3 as a recipient of MS2; > >>>>> > >>>>> OR > >>>>> - the removal of P1 as recipient of MS2; > >>>>> - the removal of P2 as a sender of MS2; > >>>>> - the termination MS2; > >>>>> - the creation of MS4; > >>>>> - the addition of P3 as a recipient of MS4; > >>>>> - the addition of P2 as a sender of MS4. > >>>>> > >>>>> So with the first option the total number of deltas is = 14+2=3D16. > >>>>> For the second option the total number of deltas is 14+6=3D20. > >>>>> > >>>>> Some of the details might be wrong, but I hope you can see > >>>> the point I > >>>> > >>>>> am getting at. Looked at this way, the efficiency saving by > >>>> recycling > >>>>> MS2 for use in consecutive CSs is relatively small. Or > >> perhaps your > >>>>> intention is also to recycle MS1 (this time, the recipient > >>>> remaining > >>>>> the same but the sender changing). That would reduce > the number of > > >>>>> deltas slightly further. The impact on XML size might not > >>>> be quite in > >>>>> proportion to the reduction in the number of deltas, since by > >>>> recycling MS2 it has to have a global identifier, not an > identifier > > >>>> local to a CS. Or perhaps it could have an identifier > >> local to a CSG. > >>>>> > >>>>> I also see that with your proposal it doesn't force the > MS to be > >>>>> recycled - an SRC could still choose to model it as > separate MSs. > >>>>> However, in that case it would still need to use global > >> identifiers > >>>> for MSs. > >>>>> > >>>>> I am not necessarily opposed to your proposal for recycling > >>>> MS objects > >>>> > >>>>> outside the context of a single CS - I can see advantages and > >>>>> disadvantages. I just want to make sure the group makes > >> an informed > >>>> decision. > >>>>> > >>>>> John (as individual) > >>>>> > >>>>> > >>>>>> > >>>>>> Enhancing label attribute across the multiple SIP > message to tie > >>>>>> between Metadata XML and RS SDP m-line is possible. SRC has to > >>>>>> ensure that label for the given RS SDP m-line should have > >>>> same label > >>>> > >>>>>> throughout single CSG even though it span across > multiple CS and > >>>>>> multiple RS. Even then, it will not meet partial-update > >>>> requirement > >>>>>> as mentioned below in this mail thread. At this moment, > >>>> I'm favoring > >>>> > >>>>>> URN UUID and not label attribute enhancement. > >>>>>> > >>>>>> Please read inline > >>>>>> > >>>>>> Thanks > >>>>>> Partha > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>>> Sent: Wednesday, May 25, 2011 7:17 PM > >>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); > Ram Mohan R > > >>>>>> (rmohanr); siprec@ietf.org > >>>>>> Subject: RE: [siprec] Can an MS object span several > CSs in a CSG? > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>>>>> Sent: 25 May 2011 08:48 > >>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > >>>> (rmohanr); > >>>>>>> siprec@ietf.org > >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs > >>>> in a CSG? > >>>>>>> > >>>>>>> John, > >>>>>>> > >>>>>>> > >>>> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D > >>>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA > >>>>>>> converts REFER > >>>>>>> > >>>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA > >>>>>>> updates RS > >>>>>>>> with CS2, Participant1 as A& participant2 as C, > >>>> MS1(A's media > >>>>>>>> stream), MS2(C's media stream). There is no update on RS1, > >>>>>>> CSG1, MS1, > >>>>>>>> MS2. MS2 will become MS2 with the new association and > >>>> in terms > >>>>>>>> of format, it will associate with tag > >>>>>>> [JRE] What harm is done (what do we lose) if, following > >>>>>> transfer, A's > >>>>>>> media stream is called MS3 and C's media stream is called MS4? > >>>>>>> > >>>>>> > >>>> > >> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>> =3D > >>>>>>> To indicate MS1 as MS3, MS1 media block has to be > >>>>>> stopped in > >>>>>>> the partial-update and start MS3 separate which is not > >>>> required in > >>>> > >>>>>>> case there is a means to have common MS1. > >>>>>> [JRE] It seems this distorts the model in order to give > >>>> some minor > >>>>>> efficiency improvement during metadata updates. I > doubt that this > > >>>>>> alone is sufficient justification for having the MS > >>>> persist from one > >>>> > >>>>>> CS to another CS. > >>>>>> > >>>>>>> > >>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> MS3 can reference the same SDP m-line (through > a=3Dlabel) as MS1, > >>>>>>> and likewise MS4 could reference the same SDP m-line as > >>>> MS2, if we > >>>> > >>>>>>> are concerned about recycling media descriptions in RS SDP. > >>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> As you mentioned, we will lose recycling of media > >>>>>> description > >>>>>>> in RS SDP without common value in media stream object > for this > >>>>>>> scenario. > >>>>>> [JRE] I don't understand your point. With my proposal we > >>>> can still > >>>>>> recycle RS SDP m-lines. > >>>>>> > >>>>>> Agreed that Recycle is possible with your proposal. > >>>>>> I indicated > >>>>>> the need for unique-id in this requirement > >>>>>> > >>>>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label > >>>>>> attribute > >>>>>>> scope is within single SIP message and not required to > >>>> be unique > >>>>>>> in all SIP messages of a given dialog. > >>>>>> [JRE] But I think we could nail that down as a > requirement of the > > >>>>>> SIPREC protocol. > >>>>>> > >>>>>> John (as individual) > >>>>>> > >>>>>>> > >>>>>>> Thanks > >>>>>>> Partha > >>>>>>> > >>>>>>> John (as individual) > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> Partha > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Charles Eckel (eckelcu) > >>>>>>>> Sent: Wednesday, May 25, 2011 1:39 AM > >>>>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); > >>>>>> 'Elwell, John'; > >>>>>>>> 'siprec@ietf.org' > >>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a > >>>> CSG? > >>>>>>>> > >>>>>>>> Hi Ram, > >>>>>>>> > >>>>>>>> I think that is many cases, they will be treated as > >>>> separate MSs > >>>> > >>>>>>>> due to the complexities you mention. However, I am trying to > >>>>>> understand if > >>>>>>>> Partha feels allowing an SRC to treat them as a single MS is > >>>>>>>> still required. If not, then what is a use case? A concrete > >>>>>>>> example would help me, and potentially others, to better > >>>>>>>> understand the > >>>>>>> motivation behind > >>>>>>>> Partha's requirement for modeling media from multiple CSs > >>>>>>> as a single > >>>>>>>> MS. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Charles > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Ram Mohan R (rmohanr) > >>>>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM > >>>>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); > >>>>>>> Elwell, John; > >>>>>>>>> siprec@ietf.org > >>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs > >>>>>> in a CSG? > >>>>>>>>> > >>>>>>>>> Charles, > >>>>>>>>> > >>>>>>>>> I did bring about this specific usecase of MMOH/MOH > >>>>>> stream being > >>>>>>>>> played to different participants earlier and suggested that > >>>>>>>> they have > >>>>>>>>> to treated as a same MS across multiple CSs > >>>>>> (potentially recorded > >>>>>>>> using multiple RSs). > >>>>>>>>> Refer > >>>>>>>>> > >>>>>> > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > >>>>>>>>> > >>>>>>>>> We had several discussions on it and it and several > >>>>>> folks were in > >>>>>>>>> favor of treating it as separate MS as there would be > >>>>>>>> complexity in DB > >>>>>>>> design. > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Ram > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: siprec-bounces@ietf.org > >>>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>>>> Behalf Of Charles Eckel (eckelcu) > >>>>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM > >>>>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > >>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > >>>>>>> in a CSG? > >>>>>>>>>> > >>>>>>>>>> Hi Partha, > >>>>>>>>>> > >>>>>>>>>> Is an example of this the same music on hold audio stream > >>>>>>>> existing > >>>>>>>>>> as the same MS within multiple CSs? If so, then I > >>>>>>> understand your > >>>>>>>>>> requirement to be that the SRC be able to > >>>> indicate multiple > >>>>>>>>>> instances of this audio stream within several CSs as > >>>>>>>> being the same > >>>>>>>>>> MS. Is that correct? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Charles > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: siprec-bounces@ietf.org > >>>>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>>>> Behalf Of Parthasarathi R (partr) > >>>>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM > >>>>>>>>>>> To: Elwell, John; siprec@ietf.org > >>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > >>>>>>>> in a CSG? > >>>>>>>>>>> > >>>>>>>>>>> John, > >>>>>>>>>>> > >>>>>>>>>>> I agree that it is not mandatory to consider recorded > >>>>>>>> stream of a > >>>>>>>>>>> specific participant in several CS within the same > >>>>>> CSG as one > >>>>>>>>>> recorded > >>>>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a > >>>>>>>> SRC in case > >>>>>>>>>>> it wishes to design in such a way. > >>>>>>>>>>> > >>>>>>>>>>> Thanks > >>>>>>>>>>> Partha > >>>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: siprec-bounces@ietf.org > >>>>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>>>> Behalf > >>>>>>>>>>> Of Elwell, John > >>>>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM > >>>>>>>>>>> To: siprec@ietf.org > >>>>>>>>>>> Subject: [siprec] Can an MS object span several CSs > >>>>>> in a CSG? > >>>>>>>>>>> > >>>>>>>>>>> We seem to have consensus that a Media Stream object > >>>>>>>> represents a > >>>>>>>>>>> recorded media stream, contributed to by one, > >>>>>> several or all > >>>>>>>>>>> Participants. However, Partha also wrote: > >>>>>>>>>>> > >>>>>>>>>>> "2) Each MS lifetime related to CSG because participant > >>>>>>>> may move > >>>>>>>>>>> from one CS to another CS within single CSG and also > >>>>>>>> CSG will span > >>>>>>>> > >>>>>>>>>>> across multiple RS." > >>>>>>>>>>> > >>>>>>>>>>> I am not sure we had resolved this during earlier > >>>>>>>> discussions on > >>>>>>>>>>> the scope of an MS object. Although the same > >>>>>> Participant can > >>>>>>>>>>> participate > >>>>>>>>>> in > >>>>>>>>>>> several CSs within the same CSG, I don't think the > >>>>>>>> recorded media > >>>>>>>>>>> streams need to be considered the same. Any other views? > >>>>>>>>>>> > >>>>>>>>>>> John (as individual) > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> siprec mailing list > >>>>>>>>>>> siprec@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> siprec mailing list > >>>>>>>>>>> siprec@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> siprec mailing list > >>>>>>>>>> siprec@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> siprec mailing list > >>>>> siprec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >>> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >> > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > > -------------------------------------------------------------- > ---------- > ------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain > confidential and proprietary information of Alcatel-Lucent and/or its > affiliated entities. Access by the intended recipient only is > authorized. Any liability arising from any party acting, or refraining > from acting, on any information contained in this e-mail is hereby > excluded. If you are not the intended recipient, please notify the > sender immediately, destroy the original transmission and its > attachments and do not disclose the contents to any other > person, use it > for any purpose, or store or copy the information in any medium. > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent > and/or its affiliated entities. > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Mon Jun 20 06:17:45 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CED811E8102 for ; Mon, 20 Jun 2011 06:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1FIrPa663dH for ; Mon, 20 Jun 2011 06:17:45 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 8FC7711E808A for ; Mon, 20 Jun 2011 06:17:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1308575863!9618020!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 4310 invoked from network); 20 Jun 2011 13:17:43 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-8.tower-182.messagelabs.com with SMTP; 20 Jun 2011 13:17:43 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 089631EB83ED for ; Mon, 20 Jun 2011 15:17:43 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 20 Jun 2011 15:17:43 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 20 Jun 2011 15:17:41 +0200 Thread-Topic: Draft-portman-siprec-protocol-04 - comment on option tag usage Thread-Index: AcwvTG83BVvJYZbTTrGBKFs13fJ47A== 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: [siprec] Draft-portman-siprec-protocol-04 - comment on option tag usage X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:17:45 -0000 "When a user agent inserts a Require header field with the option tag record-aware, the UAS MUST only provide recording indications through the media level SDP." Can we have some discussion on whether we really need this? Putting an opti= on tag in a Require header field is normally only done when absolutely esse= ntial, since it will result in request rejection (or call rejection in the = case of an initial INVITE request) if the option concerned is not supported= . I rather doubt we would want a CS to fail just because one of the UAs is = not recording-aware. John From john.elwell@siemens-enterprise.com Mon Jun 20 07:58:20 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE2711E8163 for ; Mon, 20 Jun 2011 07:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZZZkhR8kkpz for ; Mon, 20 Jun 2011 07:58:19 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 4042311E8129 for ; Mon, 20 Jun 2011 07:58:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1308581897!7293184!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 4078 invoked from network); 20 Jun 2011 14:58:17 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-12.tower-216.messagelabs.com with SMTP; 20 Jun 2011 14:58:17 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 9301C23F03E9 for ; Mon, 20 Jun 2011 16:58:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 20 Jun 2011 16:58:17 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 20 Jun 2011 16:58:17 +0200 Thread-Topic: Materials for interim Thread-Index: AcwvWnyUYDMXr37BTSmn+kHmFZxEag== 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: [siprec] Materials for interim X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 14:58:20 -0000 All materials for Thursday's interim (Webex and audio details, agenda, slid= es) are posted at: http://trac.tools.ietf.org/wg/siprec/trac/wiki/WikiStart John = From pkyzivat@cisco.com Mon Jun 20 08:30:39 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCB69E801B for ; Mon, 20 Jun 2011 08:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.445 X-Spam-Level: X-Spam-Status: No, score=-110.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3y2gN+IxDg+C for ; Mon, 20 Jun 2011 08:30:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9530B9E801A for ; Mon, 20 Jun 2011 08:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1776; q=dns/txt; s=iport; t=1308583837; x=1309793437; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=F2JFGk+bBdRiUtcPE55qNSjF6C4/0Gn7qnVH0Sjrn6Q=; b=jZEp54j/Y88h1/s/Eccp2zzPu1wm4qcHiSHc3tYuYiG7O9oSw8wZgPou xgPTWpa/VZ5Fl6KgSOcMbtcczWJbT1KMqfCwqfp2X6BphElmo+PS/AtV9 rN1KcApnWUhNygeBXoB2F1HQvc/CHGCm5aG0r+3Q3gO0TGdGdTircjAl1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgHAGhm/02tJXG8/2dsb2JhbABTmBWOSneqVJ1nhioEkV6EYIs9 X-IronPort-AV: E=Sophos;i="4.65,394,1304294400"; d="scan'208";a="717398550" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-6.cisco.com with ESMTP; 20 Jun 2011 15:30:36 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5KFUZhv020784 for ; Mon, 20 Jun 2011 15:30:35 GMT Message-ID: <4DFF679B.30705@cisco.com> Date: Mon, 20 Jun 2011 11:30:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Draft-portman-siprec-protocol-04 - comment on option tag usage X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:30:39 -0000 On 6/20/2011 9:17 AM, Elwell, John wrote: > "When a user agent inserts a Require header field with the option tag > record-aware, the UAS MUST only provide recording indications through > the media level SDP." > Can we have some discussion on whether we really need this? Putting an option tag in a Require header field is normally only done when absolutely essential, since it will result in request rejection (or call rejection in the case of an initial INVITE request) if the option concerned is not supported. I rather doubt we would want a CS to fail just because one of the UAs is not recording-aware. Are you asking whether we need the option? Or whether we need this statement about behavior when the option is mentioned in a Require header? AFAIK we are agreed on having the option. Once it exists, there is the potential to put it in a Require header, whether this is a good idea or not. 3261 already says what should happen if an option is present in a Require header. I don't think we need to talk about that. But mentioning an option in Require, or Supported, *does not* ensure that the behavior associated with the option will be *used*. If we wanted to have a way to do that we would have to add some additional syntax some place. I will also note that technically, mentioning an option in Require does not imply that it is also supported by the UA sending the message with the Require header. What we get with an option, and placement of it in Supported, is that then the SRC *MAY* send the indication of recording in the signaling. That is the part we care about. If we have a need to *REQURE* that the indication be sent in signaling, we need more mechanism than simply options. Thanks, Paul From john.elwell@siemens-enterprise.com Mon Jun 20 08:37:47 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9763B9E802E for ; Mon, 20 Jun 2011 08:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFi7b78+hv7q for ; Mon, 20 Jun 2011 08:37:46 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 35D429E8030 for ; Mon, 20 Jun 2011 08:37:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1308584264!9625012!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 24317 invoked from network); 20 Jun 2011 15:37:44 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-11.tower-182.messagelabs.com with SMTP; 20 Jun 2011 15:37:44 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id CE9AA23F03E2; Mon, 20 Jun 2011 17:37:44 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 20 Jun 2011 17:37:45 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Mon, 20 Jun 2011 17:37:44 +0200 Thread-Topic: [siprec] Draft-portman-siprec-protocol-04 - comment on option tag usage Thread-Index: AcwvXwS6pq91T2gmTmatKGqgdkDxmwAAIb8A Message-ID: References: <4DFF679B.30705@cisco.com> In-Reply-To: <4DFF679B.30705@cisco.com> 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: [siprec] Draft-portman-siprec-protocol-04 - comment on option tag usage X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:37:47 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 20 June 2011 16:31 > To: siprec@ietf.org > Subject: Re: [siprec] Draft-portman-siprec-protocol-04 -=20 > comment on option tag usage >=20 >=20 >=20 > On 6/20/2011 9:17 AM, Elwell, John wrote: > > "When a user agent inserts a Require header field with the=20 > option tag > > record-aware, the UAS MUST only provide recording=20 > indications through > > the media level SDP." > > Can we have some discussion on whether we really need this?=20 > Putting an option tag in a Require header field is normally=20 > only done when absolutely essential, since it will result in=20 > request rejection (or call rejection in the case of an=20 > initial INVITE request) if the option concerned is not=20 > supported. I rather doubt we would want a CS to fail just=20 > because one of the UAs is not recording-aware. >=20 > Are you asking whether we need the option? Or whether we need this=20 > statement about behavior when the option is mentioned in a=20 > Require header? [JRE] I am only asking about Require. >=20 > AFAIK we are agreed on having the option. [JRE] Quite so. >=20 > Once it exists, there is the potential to put it in a Require header,=20 > whether this is a good idea or not. >=20 > 3261 already says what should happen if an option is present in a=20 > Require header. I don't think we need to talk about that. >=20 > But mentioning an option in Require, or Supported, *does not* ensure=20 > that the behavior associated with the option will be *used*. If we=20 > wanted to have a way to do that we would have to add some additional=20 > syntax some place. [JRE] I think there might be precedents for specifications that define opti= on tags to say they MUST NOT or SHOULD NOT be used in Require, although I d= on't have examples to hand. I wondered whether we needed to do something si= milar. John >=20 > I will also note that technically, mentioning an option in=20 > Require does=20 > not imply that it is also supported by the UA sending the=20 > message with=20 > the Require header. >=20 > What we get with an option, and placement of it in Supported, is that=20 > then the SRC *MAY* send the indication of recording in the signaling.=20 > That is the part we care about. If we have a need to *REQURE*=20 > that the=20 > indication be sent in signaling, we need more mechanism than=20 > simply options. >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From eckelcu@cisco.com Mon Jun 20 08:40:48 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492C19E801A for ; Mon, 20 Jun 2011 08:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpO+B3i83aor for ; Mon, 20 Jun 2011 08:40:44 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9C70D9E8018 for ; Mon, 20 Jun 2011 08:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1804; q=dns/txt; s=iport; t=1308584444; x=1309794044; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=soI/kp47LpOMSooDBWRoBSZLFHPzNlSGjCCX7D/48Qc=; b=l4dWAb03lP7PVUMBLmmn7OByk35+6uPiC3+W3g8GjSaLT3xkZLNa2oc5 WZTSMxOhZsVQ5mrNRO0YIc76HAArBTTaDP7yi4jz951HwQETaODzN/ixg 1wLGsAiBsfvPO3vr/EU8MheFRJzqbQo8IIn4CkWvFiaO2jELsKcP3LN/7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAADJp/02rRDoJ/2dsb2JhbABTl1WPC3eqR51rhioEhyCPJ4s4 X-IronPort-AV: E=Sophos;i="4.65,394,1304294400"; d="scan'208";a="341672110" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 20 Jun 2011 15:40:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5KFeiMr000967; Mon, 20 Jun 2011 15:40:44 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 08:40:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 08:40:42 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02 Thread-Index: AcwvOXaZg+4+wDzBQu2PC/LOxWkIwAAJgwgw References: From: "Charles Eckel (eckelcu)" To: "Elwell, John" , X-OriginalArrivalTime: 20 Jun 2011 15:40:43.0808 (UTC) FILETIME=[6A8FDA00:01CC2F60] Subject: Re: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:40:48 -0000 Hi John, One general comment/question I have received from web application savvy coworkers with whom I have discussed the contents of this draft is that the metadata is essentially a document and HTTP already has well defined mechanisms for document sharing and updating, so why not exchange an HTTP address for the document and leverage those mechanisms instead of sending all the metadata within SIP messages. My assumption is that the requirement is to have a SIP based solutions that does not require an HTTP server. Is that accurate? Thanks, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Monday, June 20, 2011 4:02 AM > To: siprec@ietf.org > Subject: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02 >=20 > Although there are some open issues, to be discussed during Thursday's call, I would like the WG to > consider whether material in draft-ram-siprec-metadata-format-02 is ready for adoption into draft- > ietf-siprec-metadata, i.e., bring it under WG control. In particular, between now and the call, please > consider whether: > - the material is heading roughly in an acceptable direction; > - there are any issues that really should be closed before adoption; > - there are any aspects of the draft that should not be adopted at this time. >=20 > If, on the call or shortly afterwards, we can agree on adoption, the authors of the two drafts would > be asked to perform a merger and publish a new version of draft-ietf-siprec-metadata before the cut- > off for IETF#81 (2011-07-11). >=20 > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Mon Jun 20 08:56:39 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE139E8029 for ; Mon, 20 Jun 2011 08:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3xXT2AADINV for ; Mon, 20 Jun 2011 08:56:38 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id A72299E800D for ; Mon, 20 Jun 2011 08:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4775; q=dns/txt; s=iport; t=1308585398; x=1309794998; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=p0xSP55E5+cm/U3W9c4cSgKoRok7OOndvqeJQIPg5vE=; b=AW1RIS0ziRilHMFNthdz0NOvapKzItjFB6keuEwMhU3wLNvYjDemqGz9 3fj9bSdN3GZHqCAWkxU2SKD9h2ZJC6gPjZirWC2eVVvVYU5SC922nvVS8 URSqtq2Uacb3NcRkK6Y39n5//yGE9xFtamjH4aB0iaQ/OCRPG061UjYej U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAD1t/02rRDoI/2dsb2JhbABTl1WPC3eqR51uhioEhyCPJ4s4 X-IronPort-AV: E=Sophos;i="4.65,395,1304294400"; d="scan'208";a="380947994" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 20 Jun 2011 15:56:38 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5KFucrV017612; Mon, 20 Jun 2011 15:56:38 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 08:56:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 08:56:36 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-eckel-siprec-rtp-rec-01.txt Thread-Index: AcwsaNcOEe0gqVPXQ0yXvD4ktkTVMwAo3uRAAAS6UJAAgPmrsAAPr3dQ References: <20110616210242.4832.4179.idtracker@ietfa.amsl.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , X-OriginalArrivalTime: 20 Jun 2011 15:56:38.0129 (UTC) FILETIME=[A361AE10:01CC2F62] Subject: Re: [siprec] I-D Action: draft-eckel-siprec-rtp-rec-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:56:39 -0000 Hi John, Other comments I have received on this section have been to address RTP and RTCP separately. In order to address your concern as well as these, how about the following: When sending RTP, it is RECOMMENDED to use symmetric RTP. When sending RTCP, it is RECOMMENDED to use symmetric RTCP. Although an SRS will not normally send RTP, it will send RTCP as well as receive RTP and RTCP. Likewise, although an SRC will not normally receive RTP, it will receive RTCP as well as send RTP and RTCP. Cheers, Charles > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, June 20, 2011 1:31 AM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt >=20 > Charles, >=20 > What I had in mind was something along the following lines: > "It is RECOMMENDED to use symmetric RTP. Although an SRS will not normally transmit RTP, it will > transmit RTCP as well as receiving RTP and RTCP. Likewise, although an SRC will not normally receive > RTP, it will receive RTCP as well as transmitting RTP and RTCP." >=20 > Your latest proposal seems to suggest that sending RTCP is optional, and I am not sure we want to > condone that. >=20 > John >=20 >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 17 June 2011 19:56 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > Hi John, > > > > I tried to address this concern by handling RTP and RTCP separately: > > > > If an SRC or SRS is sending RTP, it is RECOMMENDED to use symmetric > > RTP. If an SRC or SRS is sending RTCP, it is RECOMMENDED to use > > symmetric RTCP. > > > > I agree that the SRS will generally not need to send RTP, and > > that only > > the RTCP recommendation will apply to the SRS, but I did not want to > > exclude it and did not see the harm in including the SRS in the > > considerations for RTP. I you think it is better to change to: > > > > If an SRC is sending RTP, it is RECOMMENDED to use symmetric > > RTP. If an SRC or SRS is sending RTCP, it is RECOMMENDED to use > > symmetric RTCP. > > > > Cheers, > > Charles > > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Friday, June 17, 2011 9:35 AM > > > To: siprec@ietf.org; Charles Eckel (eckelcu) > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > Charles, > > > > > > I still have a concern on the wording in section 13. It says: > > > "If an SRC or SRS is sending RTP, it is RECOMMENDED to use symmetric > > > RTP." > > > Why would an SRS send RTP (as opposed to RTCP)? > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: i-d-announce-bounces@ietf.org > > > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > > > internet-drafts@ietf.org > > > > Sent: 16 June 2011 22:03 > > > > To: i-d-announce@ietf.org > > > > Subject: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts directories. > > > > > > > > Title : Real-time Transport Protocol (RTP) > > > > Recommendations for SIPREC > > > > Author(s) : Charles Eckel > > > > Filename : draft-eckel-siprec-rtp-rec-01.txt > > > > Pages : 11 > > > > Date : 2011-06-16 > > > > > > > > This document provides recommendations and guidelines > > for RTP and > > > > RTCP in the context of SIPREC. This document exists as a > > > > standalone > > > > document to facilitate discussion of the RTP > > > > recommendations, and it > > > > is anticipated that portions of this document will be > > incorporated > > > > into [I-D.portman-siprec-protocol] rather than this document > > itself > > > > being adopted as a working group document. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.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-eckel-siprec-rtp-rec-01.txt > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > From pkyzivat@cisco.com Mon Jun 20 09:11:10 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393DD21F8497 for ; Mon, 20 Jun 2011 09:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.45 X-Spam-Level: X-Spam-Status: No, score=-110.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrwbP6La7uiH for ; Mon, 20 Jun 2011 09:11:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA1E1F0C54 for ; Mon, 20 Jun 2011 09:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2483; q=dns/txt; s=iport; t=1308586250; x=1309795850; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SK1b4gm5hVXxx+na0us5hq9HbIZv4iwVnwOjZRrSjEs=; b=OaaEzOTnBAdfynqikyytL7Sx7dG8AqoOMsqoYu0iAW9uCKXniya5kkUN IY/49mWJY+0z5dOp43ccIu0KzYB7QVOR0ShUimcHoIjAIkNclSQgfzjkU RK1vFBO5iVVScVb9ENnbGE9ju5ZvklA/Hokr3m3Hpb476l6KlvxNlawO+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALlw/02tJXG+/2dsb2JhbABTpmB3qjydcYYqBJFehGCLPQ X-IronPort-AV: E=Sophos;i="4.65,395,1304294400"; d="scan'208";a="380964690" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 20 Jun 2011 16:10:16 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5KGAFGO003167; Mon, 20 Jun 2011 16:10:15 GMT Message-ID: <4DFF70E7.6070900@cisco.com> Date: Mon, 20 Jun 2011 12:10:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Elwell, John" References: <4DFF679B.30705@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Draft-portman-siprec-protocol-04 - comment on option tag usage X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 16:11:10 -0000 On 6/20/2011 11:37 AM, Elwell, John wrote: > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 20 June 2011 16:31 >> To: siprec@ietf.org >> Subject: Re: [siprec] Draft-portman-siprec-protocol-04 - >> comment on option tag usage >> >> >> >> On 6/20/2011 9:17 AM, Elwell, John wrote: >>> "When a user agent inserts a Require header field with the >> option tag >>> record-aware, the UAS MUST only provide recording >> indications through >>> the media level SDP." >>> Can we have some discussion on whether we really need this? >> Putting an option tag in a Require header field is normally >> only done when absolutely essential, since it will result in >> request rejection (or call rejection in the case of an >> initial INVITE request) if the option concerned is not >> supported. I rather doubt we would want a CS to fail just >> because one of the UAs is not recording-aware. >> >> Are you asking whether we need the option? Or whether we need this >> statement about behavior when the option is mentioned in a >> Require header? > [JRE] I am only asking about Require. > >> >> AFAIK we are agreed on having the option. > [JRE] Quite so. > > >> >> Once it exists, there is the potential to put it in a Require header, >> whether this is a good idea or not. >> >> 3261 already says what should happen if an option is present in a >> Require header. I don't think we need to talk about that. >> >> But mentioning an option in Require, or Supported, *does not* ensure >> that the behavior associated with the option will be *used*. If we >> wanted to have a way to do that we would have to add some additional >> syntax some place. > [JRE] I think there might be precedents for specifications that define option tags to say they MUST NOT or SHOULD NOT be used in Require, although I don't have examples to hand. I wondered whether we needed to do something similar. I see little point to that. It simply provides another potential error. Using the option in Require is a stupid thing to do in any case that I can think of. But you can't legislate against stupidity. There is no incremental cost to a UA for handling the receipt of this option in a Require, so why worry about it? If anything, perhaps we could just include a *note* on the futility of using it in Require, and just leave it at that. Thanks, Paul From pkyzivat@cisco.com Mon Jun 20 10:59:32 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF5511E80B2 for ; Mon, 20 Jun 2011 10:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.456 X-Spam-Level: X-Spam-Status: No, score=-110.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcMIDDVynxOD for ; Mon, 20 Jun 2011 10:59:31 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id D192D11E808A for ; Mon, 20 Jun 2011 10:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2856; q=dns/txt; s=iport; t=1308592771; x=1309802371; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=M2q4eT9yaVyHPITF+hnKjaJlRtp1EeeNG1FX6Rl2Jwg=; b=aSwSdZXpzr0ql/q5YDk8w0cgR/o4sfarKROREe0dEF+8Qoup0RTQjloS OYYHksWUbC0M/CX5fgOKzVzSCWY5nHhjsToYSz0btlKfr4M4JNjFQmUYe 1X8hQzPj6J2bn8NPXVbVa4g1AWcTv+6JzYfu3WC56BReZ57f4Q6lxY1ek Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUBAJOJ/02rRDoI/2dsb2JhbABTl1dBjkp3qlWeB4YqBJFehGCLPQ X-IronPort-AV: E=Sophos;i="4.65,395,1304294400"; d="scan'208";a="717556266" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 20 Jun 2011 17:59:31 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5KHxV1m025243 for ; Mon, 20 Jun 2011 17:59:31 GMT Message-ID: <4DFF8A82.3000809@cisco.com> Date: Mon, 20 Jun 2011 13:59:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 17:59:32 -0000 Charles, IIRC, the major driving forces were timeliness and synchronicity of metadata with the actual signaling, especially when initially establishing a RS, so that suitable decisions can be made about whether to record a session, etc. AFAIK the avoidance of an HTTP server in the SRS wasn't a concern. (Its assumed in general to be a very capable box, and probably has an HTTP interface for querying, though that is out of our scope for now.) Avoiding an http client in the src might be slightly more significant, but I don't think that was much of a concern either. Could we have skinned this cat with an http approach? Probably. Obviously we had a lot more sip expertise than http expertise in the group. That may have been an influence as well. Thanks, Paul On 6/20/2011 11:40 AM, Charles Eckel (eckelcu) wrote: > Hi John, > > One general comment/question I have received from web application savvy > coworkers with whom I have discussed the contents of this draft is that > the metadata is essentially a document and HTTP already has well defined > mechanisms for document sharing and updating, so why not exchange an > HTTP address for the document and leverage those mechanisms instead of > sending all the metadata within SIP messages. My assumption is that the > requirement is to have a SIP based solutions that does not require an > HTTP server. Is that accurate? > > Thanks, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John >> Sent: Monday, June 20, 2011 4:02 AM >> To: siprec@ietf.org >> Subject: [siprec] Adoption of material > fromdraft-ram-siprec-metadata-format-02 >> >> Although there are some open issues, to be discussed during Thursday's > call, I would like the WG to >> consider whether material in draft-ram-siprec-metadata-format-02 is > ready for adoption into draft- >> ietf-siprec-metadata, i.e., bring it under WG control. In particular, > between now and the call, please >> consider whether: >> - the material is heading roughly in an acceptable direction; >> - there are any issues that really should be closed before adoption; >> - there are any aspects of the draft that should not be adopted at > this time. >> >> If, on the call or shortly afterwards, we can agree on adoption, the > authors of the two drafts would >> be asked to perform a merger and publish a new version of > draft-ietf-siprec-metadata before the cut- >> off for IETF#81 (2011-07-11). >> >> John >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Mon Jun 20 11:38:08 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D75421F84E0 for ; Mon, 20 Jun 2011 11:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QurJNSEqACFS for ; Mon, 20 Jun 2011 11:38:07 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id DFBB021F84DB for ; Mon, 20 Jun 2011 11:38:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1308595075!36110424!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 5903 invoked from network); 20 Jun 2011 18:37:55 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-10.tower-27.messagelabs.com with SMTP; 20 Jun 2011 18:37:55 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id DF7671EB83ED; Mon, 20 Jun 2011 20:38:04 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 20 Jun 2011 20:38:04 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Mon, 20 Jun 2011 20:38:04 +0200 Thread-Topic: [siprec] Draft-portman-siprec-protocol-04 - comment on option tag usage Thread-Index: AcwvZJVM+/DE1Kb4T/CZbWtavzu8vAAFIx7w Message-ID: References: <4DFF679B.30705@cisco.com> <4DFF70E7.6070900@cisco.com> In-Reply-To: <4DFF70E7.6070900@cisco.com> 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: "siprec@ietf.org" Subject: Re: [siprec] Draft-portman-siprec-protocol-04 - comment on option tag usage X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 18:38:08 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 20 June 2011 17:10 > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] Draft-portman-siprec-protocol-04 -=20 > comment on option tag usage >=20 >=20 >=20 > On 6/20/2011 11:37 AM, Elwell, John wrote: > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 20 June 2011 16:31 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Draft-portman-siprec-protocol-04 - > >> comment on option tag usage > >> > >> > >> > >> On 6/20/2011 9:17 AM, Elwell, John wrote: > >>> "When a user agent inserts a Require header field with the > >> option tag > >>> record-aware, the UAS MUST only provide recording > >> indications through > >>> the media level SDP." > >>> Can we have some discussion on whether we really need this? > >> Putting an option tag in a Require header field is normally > >> only done when absolutely essential, since it will result in > >> request rejection (or call rejection in the case of an > >> initial INVITE request) if the option concerned is not > >> supported. I rather doubt we would want a CS to fail just > >> because one of the UAs is not recording-aware. > >> > >> Are you asking whether we need the option? Or whether we need this > >> statement about behavior when the option is mentioned in a > >> Require header? > > [JRE] I am only asking about Require. > > > >> > >> AFAIK we are agreed on having the option. > > [JRE] Quite so. > > > > > >> > >> Once it exists, there is the potential to put it in a=20 > Require header, > >> whether this is a good idea or not. > >> > >> 3261 already says what should happen if an option is present in a > >> Require header. I don't think we need to talk about that. > >> > >> But mentioning an option in Require, or Supported, *does=20 > not* ensure > >> that the behavior associated with the option will be *used*. If we > >> wanted to have a way to do that we would have to add some=20 > additional > >> syntax some place. > > [JRE] I think there might be precedents for specifications=20 > that define option tags to say they MUST NOT or SHOULD NOT be=20 > used in Require, although I don't have examples to hand. I=20 > wondered whether we needed to do something similar. >=20 > I see little point to that. It simply provides another=20 > potential error. > Using the option in Require is a stupid thing to do in any=20 > case that I=20 > can think of. But you can't legislate against stupidity. There is no=20 > incremental cost to a UA for handling the receipt of this option in a=20 > Require, so why worry about it? >=20 > If anything, perhaps we could just include a *note* on the=20 > futility of=20 > using it in Require, and just leave it at that. [JRE] Yes, that would make sense. John >=20 > Thanks, > Paul > = From john.elwell@siemens-enterprise.com Mon Jun 20 11:47:34 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0CF11E808E for ; Mon, 20 Jun 2011 11:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VdnDWDAZRjC for ; Mon, 20 Jun 2011 11:47:33 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id C22BB11E8112 for ; Mon, 20 Jun 2011 11:47:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1308595651!22091985!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 15176 invoked from network); 20 Jun 2011 18:47:31 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-14.tower-174.messagelabs.com with SMTP; 20 Jun 2011 18:47:31 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 0902C23F03E6; Mon, 20 Jun 2011 20:47:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 20 Jun 2011 20:47:31 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Mon, 20 Jun 2011 20:47:29 +0200 Thread-Topic: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02 Thread-Index: AcwvOXaZg+4+wDzBQu2PC/LOxWkIwAAJgwgwAAZ9uPA= Message-ID: References: In-Reply-To: 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: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 18:47:34 -0000 Charles, I don't recall whether we discussed non-SIP means for transporting metadata= . We certainly discussed transmitting it separately from INVITE/UPDATE, and= concluded that in most cases metadata changes would coincide with SDP upda= tes, and therefore other SIP methods (such as INFO) would be less efficient= . By having a separate channel (HTTP) for metadata, there is the issue of syn= chronizing it with SDP updates. Certainly that would be achievable, but doe= s it make the solution unnecessarily complicated? XML document transport in SIP messages is certainly nothing new. Furthermore, we have had only this one draft on metadata format/transport f= or several months. As the only candidate, we seemed to have reached, by def= ault, a situation where it is only a question of when we adopt it, not if. = So any other solution would require a draft very quickly, so that we can co= mpare and contrast. John =20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 20 June 2011 16:41 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Adoption of material=20 > fromdraft-ram-siprec-metadata-format-02 >=20 > Hi John, >=20 > One general comment/question I have received from web=20 > application savvy > coworkers with whom I have discussed the contents of this=20 > draft is that > the metadata is essentially a document and HTTP already has=20 > well defined > mechanisms for document sharing and updating, so why not exchange an > HTTP address for the document and leverage those mechanisms instead of > sending all the metadata within SIP messages. My assumption=20 > is that the > requirement is to have a SIP based solutions that does not require an > HTTP server. Is that accurate? >=20 > Thanks, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Monday, June 20, 2011 4:02 AM > > To: siprec@ietf.org > > Subject: [siprec] Adoption of material > fromdraft-ram-siprec-metadata-format-02 > >=20 > > Although there are some open issues, to be discussed during=20 > Thursday's > call, I would like the WG to > > consider whether material in draft-ram-siprec-metadata-format-02 is > ready for adoption into draft- > > ietf-siprec-metadata, i.e., bring it under WG control. In=20 > particular, > between now and the call, please > > consider whether: > > - the material is heading roughly in an acceptable direction; > > - there are any issues that really should be closed before adoption; > > - there are any aspects of the draft that should not be adopted at > this time. > >=20 > > If, on the call or shortly afterwards, we can agree on adoption, the > authors of the two drafts would > > be asked to perform a merger and publish a new version of > draft-ietf-siprec-metadata before the cut- > > off for IETF#81 (2011-07-11). > >=20 > > John > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Mon Jun 20 11:48:53 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A968D11E80AB for ; Mon, 20 Jun 2011 11:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPiF3WWRe8h2 for ; Mon, 20 Jun 2011 11:48:52 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id EEFFA11E80A5 for ; Mon, 20 Jun 2011 11:48:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1308595731!22093882!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 13160 invoked from network); 20 Jun 2011 18:48:51 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-13.tower-174.messagelabs.com with SMTP; 20 Jun 2011 18:48:51 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 09CFC1EB83F1; Mon, 20 Jun 2011 20:48:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 20 Jun 2011 20:48:51 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Mon, 20 Jun 2011 20:48:49 +0200 Thread-Topic: I-D Action: draft-eckel-siprec-rtp-rec-01.txt Thread-Index: AcwsaNcOEe0gqVPXQ0yXvD4ktkTVMwAo3uRAAAS6UJAAgPmrsAAPr3dQAAYsgvA= Message-ID: References: <20110616210242.4832.4179.idtracker@ietfa.amsl.com> In-Reply-To: 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: [siprec] I-D Action: draft-eckel-siprec-rtp-rec-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 18:48:53 -0000 Might work, but is the term "symmetric RTCP" a well-established term? John =20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 20 June 2011 16:57 > To: Elwell, John; siprec@ietf.org > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt >=20 > Hi John, >=20 > Other comments I have received on this section have been to=20 > address RTP > and RTCP separately. In order to address your concern as well=20 > as these, > how about the following: >=20 > When sending RTP, it is RECOMMENDED to use symmetric RTP. When sending > RTCP, it is RECOMMENDED to use symmetric RTCP. Although an=20 > SRS will not > normally send RTP, it will send RTCP as well as receive RTP and RTCP. > Likewise, although an SRC will not normally receive RTP, it=20 > will receive > RTCP as well as send RTP and RTCP. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Monday, June 20, 2011 1:31 AM > > To: Charles Eckel (eckelcu); siprec@ietf.org > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > >=20 > > Charles, > >=20 > > What I had in mind was something along the following lines: > > "It is RECOMMENDED to use symmetric RTP. Although an SRS will not > normally transmit RTP, it will > > transmit RTCP as well as receiving RTP and RTCP. Likewise,=20 > although an > SRC will not normally receive > > RTP, it will receive RTCP as well as transmitting RTP and RTCP." > >=20 > > Your latest proposal seems to suggest that sending RTCP is optional, > and I am not sure we want to > > condone that. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 17 June 2011 19:56 > > > To: Elwell, John; siprec@ietf.org > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > Hi John, > > > > > > I tried to address this concern by handling RTP and RTCP=20 > separately: > > > > > > If an SRC or SRS is sending RTP, it is RECOMMENDED to use > symmetric > > > RTP. If an SRC or SRS is sending RTCP, it is=20 > RECOMMENDED to use > > > symmetric RTCP. > > > > > > I agree that the SRS will generally not need to send RTP, and > > > that only > > > the RTCP recommendation will apply to the SRS, but I did=20 > not want to > > > exclude it and did not see the harm in including the SRS in the > > > considerations for RTP. I you think it is better to change to: > > > > > > If an SRC is sending RTP, it is RECOMMENDED to use symmetric > > > RTP. If an SRC or SRS is sending RTCP, it is=20 > RECOMMENDED to use > > > symmetric RTCP. > > > > > > Cheers, > > > Charles > > > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Friday, June 17, 2011 9:35 AM > > > > To: siprec@ietf.org; Charles Eckel (eckelcu) > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > Charles, > > > > > > > > I still have a concern on the wording in section 13. It says: > > > > "If an SRC or SRS is sending RTP, it is RECOMMENDED to use > symmetric > > > > RTP." > > > > Why would an SRS send RTP (as opposed to RTCP)? > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: i-d-announce-bounces@ietf.org > > > > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > > > > internet-drafts@ietf.org > > > > > Sent: 16 June 2011 22:03 > > > > > To: i-d-announce@ietf.org > > > > > Subject: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > Internet-Drafts directories. > > > > > > > > > > Title : Real-time Transport Protocol (RTP) > > > > > Recommendations for SIPREC > > > > > Author(s) : Charles Eckel > > > > > Filename : draft-eckel-siprec-rtp-rec-01.txt > > > > > Pages : 11 > > > > > Date : 2011-06-16 > > > > > > > > > > This document provides recommendations and guidelines > > > for RTP and > > > > > RTCP in the context of SIPREC. This document exists as a > > > > > standalone > > > > > document to facilitate discussion of the RTP > > > > > recommendations, and it > > > > > is anticipated that portions of this document will be > > > incorporated > > > > > into [I-D.portman-siprec-protocol] rather than=20 > this document > > > itself > > > > > being adopted as a working group document. > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > > http://www.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > > >=20 > ftp://ftp.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.txt > > > > > _______________________________________________ > > > > > I-D-Announce mailing list > > > > > I-D-Announce@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > = From eckelcu@cisco.com Mon Jun 20 13:19:31 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AFD1F0C6F for ; Mon, 20 Jun 2011 13:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv82NCQ-zVyF for ; Mon, 20 Jun 2011 13:19:30 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id E7BBA1F0C38 for ; Mon, 20 Jun 2011 13:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5990; q=dns/txt; s=iport; t=1308601169; x=1309810769; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=I0O8VyddFI5iHzMJtWTDt7gCXSa0jF8kQJJ2mdjJAHY=; b=PEAUdi+eb6SqCCEQrRfUtBkN23XtOFLOQH2AkAxCQA8yF8mPjoW7liKf VTT9Zcf/QvoslvXGzcSlmFt3kE4v+0MdPdHXUoGUgKnCv2rhtZMnXGkl5 DBkVMWreNtTxKaZvbG+hj7IETQxxygLNDK2IcC3yoQUB5JcqwDlznxd7B Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAM6q/02rRDoH/2dsb2JhbABTl1qPC3eqZp4YhioEhyCPJ4s4 X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208";a="341986082" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 20 Jun 2011 20:19:29 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5KKJTCn019451; Mon, 20 Jun 2011 20:19:29 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 13:19:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 13:19:27 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-eckel-siprec-rtp-rec-01.txt Thread-Index: AcwsaNcOEe0gqVPXQ0yXvD4ktkTVMwAo3uRAAAS6UJAAgPmrsAAPr3dQAAYsgvAAAxWfEA== References: <20110616210242.4832.4179.idtracker@ietfa.amsl.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , X-OriginalArrivalTime: 20 Jun 2011 20:19:29.0459 (UTC) FILETIME=[5BD3A830:01CC2F87] Subject: Re: [siprec] I-D Action: draft-eckel-siprec-rtp-rec-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:19:31 -0000 Yes, both are defined in RFC 4961. Cheers, Charles > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, June 20, 2011 11:49 AM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt >=20 > Might work, but is the term "symmetric RTCP" a well-established term? >=20 > John >=20 >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 20 June 2011 16:57 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > Hi John, > > > > Other comments I have received on this section have been to > > address RTP > > and RTCP separately. In order to address your concern as well > > as these, > > how about the following: > > > > When sending RTP, it is RECOMMENDED to use symmetric RTP. When sending > > RTCP, it is RECOMMENDED to use symmetric RTCP. Although an > > SRS will not > > normally send RTP, it will send RTCP as well as receive RTP and RTCP. > > Likewise, although an SRC will not normally receive RTP, it > > will receive > > RTCP as well as send RTP and RTCP. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Monday, June 20, 2011 1:31 AM > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > Charles, > > > > > > What I had in mind was something along the following lines: > > > "It is RECOMMENDED to use symmetric RTP. Although an SRS will not > > normally transmit RTP, it will > > > transmit RTCP as well as receiving RTP and RTCP. Likewise, > > although an > > SRC will not normally receive > > > RTP, it will receive RTCP as well as transmitting RTP and RTCP." > > > > > > Your latest proposal seems to suggest that sending RTCP is optional, > > and I am not sure we want to > > > condone that. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > Sent: 17 June 2011 19:56 > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > Hi John, > > > > > > > > I tried to address this concern by handling RTP and RTCP > > separately: > > > > > > > > If an SRC or SRS is sending RTP, it is RECOMMENDED to use > > symmetric > > > > RTP. If an SRC or SRS is sending RTCP, it is > > RECOMMENDED to use > > > > symmetric RTCP. > > > > > > > > I agree that the SRS will generally not need to send RTP, and > > > > that only > > > > the RTCP recommendation will apply to the SRS, but I did > > not want to > > > > exclude it and did not see the harm in including the SRS in the > > > > considerations for RTP. I you think it is better to change to: > > > > > > > > If an SRC is sending RTP, it is RECOMMENDED to use symmetric > > > > RTP. If an SRC or SRS is sending RTCP, it is > > RECOMMENDED to use > > > > symmetric RTCP. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Friday, June 17, 2011 9:35 AM > > > > > To: siprec@ietf.org; Charles Eckel (eckelcu) > > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > Charles, > > > > > > > > > > I still have a concern on the wording in section 13. It says: > > > > > "If an SRC or SRS is sending RTP, it is RECOMMENDED to use > > symmetric > > > > > RTP." > > > > > Why would an SRS send RTP (as opposed to RTCP)? > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: i-d-announce-bounces@ietf.org > > > > > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > > > > > internet-drafts@ietf.org > > > > > > Sent: 16 June 2011 22:03 > > > > > > To: i-d-announce@ietf.org > > > > > > Subject: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > Internet-Drafts directories. > > > > > > > > > > > > Title : Real-time Transport Protocol (RTP) > > > > > > Recommendations for SIPREC > > > > > > Author(s) : Charles Eckel > > > > > > Filename : draft-eckel-siprec-rtp-rec-01.txt > > > > > > Pages : 11 > > > > > > Date : 2011-06-16 > > > > > > > > > > > > This document provides recommendations and guidelines > > > > for RTP and > > > > > > RTCP in the context of SIPREC. This document exists as a > > > > > > standalone > > > > > > document to facilitate discussion of the RTP > > > > > > recommendations, and it > > > > > > is anticipated that portions of this document will be > > > > incorporated > > > > > > into [I-D.portman-siprec-protocol] rather than > > this document > > > > itself > > > > > > being adopted as a working group document. > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.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-eckel-siprec-rtp-rec-01.txt > > > > > > _______________________________________________ > > > > > > I-D-Announce mailing list > > > > > > I-D-Announce@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > From john.elwell@siemens-enterprise.com Mon Jun 20 23:16:21 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC4411E80CF for ; Mon, 20 Jun 2011 23:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-AFV8W+03XJ for ; Mon, 20 Jun 2011 23:16:20 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id B71A111E809D for ; Mon, 20 Jun 2011 23:16:19 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1308636978!1343099!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 30191 invoked from network); 21 Jun 2011 06:16:18 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-11.tower-216.messagelabs.com with SMTP; 21 Jun 2011 06:16:18 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 5604823F03E2; Tue, 21 Jun 2011 08:16:18 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 21 Jun 2011 08:16:18 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Tue, 21 Jun 2011 08:16:17 +0200 Thread-Topic: I-D Action: draft-eckel-siprec-rtp-rec-01.txt Thread-Index: AcwsaNcOEe0gqVPXQ0yXvD4ktkTVMwAo3uRAAAS6UJAAgPmrsAAPr3dQAAYsgvAAAxWfEAAU7J8A Message-ID: References: <20110616210242.4832.4179.idtracker@ietfa.amsl.com> In-Reply-To: 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: [siprec] I-D Action: draft-eckel-siprec-rtp-rec-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 06:16:21 -0000 Charles, Sorry, I should have checked. In that case, I certainly like your words. John=20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 20 June 2011 21:19 > To: Elwell, John; siprec@ietf.org > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt >=20 > Yes, both are defined in RFC 4961. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Monday, June 20, 2011 11:49 AM > > To: Charles Eckel (eckelcu); siprec@ietf.org > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > >=20 > > Might work, but is the term "symmetric RTCP" a=20 > well-established term? > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 20 June 2011 16:57 > > > To: Elwell, John; siprec@ietf.org > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > Hi John, > > > > > > Other comments I have received on this section have been to > > > address RTP > > > and RTCP separately. In order to address your concern as well > > > as these, > > > how about the following: > > > > > > When sending RTP, it is RECOMMENDED to use symmetric RTP. When > sending > > > RTCP, it is RECOMMENDED to use symmetric RTCP. Although an > > > SRS will not > > > normally send RTP, it will send RTCP as well as receive RTP and > RTCP. > > > Likewise, although an SRC will not normally receive RTP, it > > > will receive > > > RTCP as well as send RTP and RTCP. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Monday, June 20, 2011 1:31 AM > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > Charles, > > > > > > > > What I had in mind was something along the following lines: > > > > "It is RECOMMENDED to use symmetric RTP. Although an=20 > SRS will not > > > normally transmit RTP, it will > > > > transmit RTCP as well as receiving RTP and RTCP. Likewise, > > > although an > > > SRC will not normally receive > > > > RTP, it will receive RTCP as well as transmitting RTP and RTCP." > > > > > > > > Your latest proposal seems to suggest that sending RTCP is > optional, > > > and I am not sure we want to > > > > condone that. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > Sent: 17 June 2011 19:56 > > > > > To: Elwell, John; siprec@ietf.org > > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > Hi John, > > > > > > > > > > I tried to address this concern by handling RTP and RTCP > > > separately: > > > > > > > > > > If an SRC or SRS is sending RTP, it is RECOMMENDED to use > > > symmetric > > > > > RTP. If an SRC or SRS is sending RTCP, it is > > > RECOMMENDED to use > > > > > symmetric RTCP. > > > > > > > > > > I agree that the SRS will generally not need to send RTP, and > > > > > that only > > > > > the RTCP recommendation will apply to the SRS, but I did > > > not want to > > > > > exclude it and did not see the harm in including the=20 > SRS in the > > > > > considerations for RTP. I you think it is better to change to: > > > > > > > > > > If an SRC is sending RTP, it is RECOMMENDED to use=20 > symmetric > > > > > RTP. If an SRC or SRS is sending RTCP, it is > > > RECOMMENDED to use > > > > > symmetric RTCP. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John=20 > [mailto:john.elwell@siemens-enterprise.com] > > > > > > Sent: Friday, June 17, 2011 9:35 AM > > > > > > To: siprec@ietf.org; Charles Eckel (eckelcu) > > > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > Charles, > > > > > > > > > > > > I still have a concern on the wording in section=20 > 13. It says: > > > > > > "If an SRC or SRS is sending RTP, it is RECOMMENDED to use > > > symmetric > > > > > > RTP." > > > > > > Why would an SRS send RTP (as opposed to RTCP)? > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: i-d-announce-bounces@ietf.org > > > > > > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > > > > > > internet-drafts@ietf.org > > > > > > > Sent: 16 June 2011 22:03 > > > > > > > To: i-d-announce@ietf.org > > > > > > > Subject: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > > Internet-Drafts directories. > > > > > > > > > > > > > > Title : Real-time Transport Protocol (RTP) > > > > > > > Recommendations for SIPREC > > > > > > > Author(s) : Charles Eckel > > > > > > > Filename : draft-eckel-siprec-rtp-rec-01.txt > > > > > > > Pages : 11 > > > > > > > Date : 2011-06-16 > > > > > > > > > > > > > > This document provides recommendations and guidelines > > > > > for RTP and > > > > > > > RTCP in the context of SIPREC. This document=20 > exists as a > > > > > > > standalone > > > > > > > document to facilitate discussion of the RTP > > > > > > > recommendations, and it > > > > > > > is anticipated that portions of this document will be > > > > > incorporated > > > > > > > into [I-D.portman-siprec-protocol] rather than > > > this document > > > > > itself > > > > > > > being adopted as a working group document. > > > > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > > > > > > > > > >=20 > ftp://ftp.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.txt > > > > > > > _______________________________________________ > > > > > > > I-D-Announce mailing list > > > > > > > I-D-Announce@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > > > Internet-Draft directories:=20 > http://www.ietf.org/shadow.html > > > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > = From Leon.Portman@nice.com Tue Jun 21 02:02:15 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C829E801E for ; Tue, 21 Jun 2011 02:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-mOGMzTTXZP for ; Tue, 21 Jun 2011 02:02:14 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0B99E8017 for ; Tue, 21 Jun 2011 02:02:14 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 21 Jun 2011 12:02:12 +0300 From: Leon Portman To: Paul Kyzivat , "siprec@ietf.org" Date: Tue, 21 Jun 2011 12:02:08 +0300 Thread-Topic: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02 Thread-Index: Acwvc9GH9M8y1vuZSxq3cub71esM/gAfP5Lg Message-ID: <07465C1D981ABC41A344374066AE1A2C38AF5C8E38@TLVMBX01.nice.com> References: <4DFF8A82.3000809@cisco.com> In-Reply-To: <4DFF8A82.3000809@cisco.com> 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: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 09:02:15 -0000 Actually we had lot of discussion about this issue (metadata over SIP or ov= er dedicated web service/HTTP) both internally and with partners. Main advantages (what I remember ) for SIP approach are as follows: 1. Simplicity, only one interface to implement, troubleshoot, secure and co= nfigure between SRC and SRS 2. RS SIP request is self-contained, it includes all relevant info in order= to SRS to decide how to do recording . For example participants identity, = location. So no need for SRS to correlate different messages from different= interfaces 3. Footprint on SRC. For some implementation it is not feasible to have bot= h SIP and HTTP stacks Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Monday, June 20, 2011 9:00 PM To: siprec@ietf.org Subject: Re: [siprec] Adoption of material fromdraft-ram-siprec-metadata-fo= rmat-02 Charles, IIRC, the major driving forces were timeliness and synchronicity of metadat= a with the actual signaling, especially when initially establishing a RS, s= o that suitable decisions can be made about whether to record a session, et= c. AFAIK the avoidance of an HTTP server in the SRS wasn't a concern. (Its ass= umed in general to be a very capable box, and probably has an HTTP interfac= e for querying, though that is out of our scope for now.) Avoiding an http = client in the src might be slightly more significant, but I don't think tha= t was much of a concern either. Could we have skinned this cat with an http approach? Probably. Obviously we had a lot more sip expertise than http expertise in the group.= That may have been an influence as well. Thanks, Paul On 6/20/2011 11:40 AM, Charles Eckel (eckelcu) wrote: > Hi John, > > One general comment/question I have received from web application=20 > savvy coworkers with whom I have discussed the contents of this draft=20 > is that the metadata is essentially a document and HTTP already has=20 > well defined mechanisms for document sharing and updating, so why not=20 > exchange an HTTP address for the document and leverage those=20 > mechanisms instead of sending all the metadata within SIP messages. My=20 > assumption is that the requirement is to have a SIP based solutions=20 > that does not require an HTTP server. Is that accurate? > > Thanks, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John >> Sent: Monday, June 20, 2011 4:02 AM >> To: siprec@ietf.org >> Subject: [siprec] Adoption of material > fromdraft-ram-siprec-metadata-format-02 >> >> Although there are some open issues, to be discussed during=20 >> Thursday's > call, I would like the WG to >> consider whether material in draft-ram-siprec-metadata-format-02 is > ready for adoption into draft- >> ietf-siprec-metadata, i.e., bring it under WG control. In particular, > between now and the call, please >> consider whether: >> - the material is heading roughly in an acceptable direction; >> - there are any issues that really should be closed before adoption; >> - there are any aspects of the draft that should not be adopted at > this time. >> >> If, on the call or shortly afterwards, we can agree on adoption, the > authors of the two drafts would >> be asked to perform a merger and publish a new version of > draft-ietf-siprec-metadata before the cut- >> off for IETF#81 (2011-07-11). >> >> John >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Tue Jun 21 08:27:19 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9DE11E816A for ; Tue, 21 Jun 2011 08:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.53 X-Spam-Level: X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YIhaODu1gZx for ; Tue, 21 Jun 2011 08:27:18 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 3624211E8148 for ; Tue, 21 Jun 2011 08:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=7606; q=dns/txt; s=iport; t=1308670038; x=1309879638; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=QZqtG16io53eM9VjXN06H8OPUUP5pwEDubLLJegwWBc=; b=FB9Ma31FGATQf1KwpCV0XH+thZ4vt0ed/xBHdCaFgIvV6ag8cPTtof1w Ygufpg6din6lKy+sHgKTDXohn3hfvzlwZt0tYSAkMOn+x9b6jWRPCn5lq jejxKAQOife2MszC1pL1tfQJHip2qErKW6zO0ltgDQAjT32HpN7Z6nmqo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAK63AE6rRDoG/2dsb2JhbABUl12PFHeqLp5IhioEhyKPL4s7 X-IronPort-AV: E=Sophos;i="4.65,401,1304294400"; d="scan'208";a="382280163" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2011 15:27:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5LFRGCQ011827; Tue, 21 Jun 2011 15:27:16 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 08:27:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jun 2011 08:27:14 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-eckel-siprec-rtp-rec-01.txt Thread-Index: AcwsaNcOEe0gqVPXQ0yXvD4ktkTVMwAo3uRAAAS6UJAAgPmrsAAPr3dQAAYsgvAAAxWfEAAU7J8AABMOF0A= References: <20110616210242.4832.4179.idtracker@ietfa.amsl.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , X-OriginalArrivalTime: 21 Jun 2011 15:27:16.0658 (UTC) FILETIME=[B3E04920:01CC3027] Subject: Re: [siprec] I-D Action: draft-eckel-siprec-rtp-rec-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:27:19 -0000 No worries, and thank you for reviewing. I hope others can have a look as well. So far I have not received any comments outside of yours from SIPREC, nor have I received any from AVT. Would it help if I put a few slides together for Thursday's interim meeting? Cheers, Charles=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, June 20, 2011 11:16 PM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt >=20 > Charles, >=20 > Sorry, I should have checked. In that case, I certainly like your words. >=20 > John >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 20 June 2011 21:19 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > Yes, both are defined in RFC 4961. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Monday, June 20, 2011 11:49 AM > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > Might work, but is the term "symmetric RTCP" a > > well-established term? > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > Sent: 20 June 2011 16:57 > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > Hi John, > > > > > > > > Other comments I have received on this section have been to > > > > address RTP > > > > and RTCP separately. In order to address your concern as well > > > > as these, > > > > how about the following: > > > > > > > > When sending RTP, it is RECOMMENDED to use symmetric RTP. When > > sending > > > > RTCP, it is RECOMMENDED to use symmetric RTCP. Although an > > > > SRS will not > > > > normally send RTP, it will send RTCP as well as receive RTP and > > RTCP. > > > > Likewise, although an SRC will not normally receive RTP, it > > > > will receive > > > > RTCP as well as send RTP and RTCP. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Monday, June 20, 2011 1:31 AM > > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > Charles, > > > > > > > > > > What I had in mind was something along the following lines: > > > > > "It is RECOMMENDED to use symmetric RTP. Although an > > SRS will not > > > > normally transmit RTP, it will > > > > > transmit RTCP as well as receiving RTP and RTCP. Likewise, > > > > although an > > > > SRC will not normally receive > > > > > RTP, it will receive RTCP as well as transmitting RTP and RTCP." > > > > > > > > > > Your latest proposal seems to suggest that sending RTCP is > > optional, > > > > and I am not sure we want to > > > > > condone that. > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > Sent: 17 June 2011 19:56 > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > Hi John, > > > > > > > > > > > > I tried to address this concern by handling RTP and RTCP > > > > separately: > > > > > > > > > > > > If an SRC or SRS is sending RTP, it is RECOMMENDED to use > > > > symmetric > > > > > > RTP. If an SRC or SRS is sending RTCP, it is > > > > RECOMMENDED to use > > > > > > symmetric RTCP. > > > > > > > > > > > > I agree that the SRS will generally not need to send RTP, and > > > > > > that only > > > > > > the RTCP recommendation will apply to the SRS, but I did > > > > not want to > > > > > > exclude it and did not see the harm in including the > > SRS in the > > > > > > considerations for RTP. I you think it is better to change to: > > > > > > > > > > > > If an SRC is sending RTP, it is RECOMMENDED to use > > symmetric > > > > > > RTP. If an SRC or SRS is sending RTCP, it is > > > > RECOMMENDED to use > > > > > > symmetric RTCP. > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Elwell, John > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > Sent: Friday, June 17, 2011 9:35 AM > > > > > > > To: siprec@ietf.org; Charles Eckel (eckelcu) > > > > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > > > Charles, > > > > > > > > > > > > > > I still have a concern on the wording in section > > 13. It says: > > > > > > > "If an SRC or SRS is sending RTP, it is RECOMMENDED to use > > > > symmetric > > > > > > > RTP." > > > > > > > Why would an SRS send RTP (as opposed to RTCP)? > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: i-d-announce-bounces@ietf.org > > > > > > > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > > > > > > > internet-drafts@ietf.org > > > > > > > > Sent: 16 June 2011 22:03 > > > > > > > > To: i-d-announce@ietf.org > > > > > > > > Subject: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > > > Internet-Drafts directories. > > > > > > > > > > > > > > > > Title : Real-time Transport Protocol (RTP) > > > > > > > > Recommendations for SIPREC > > > > > > > > Author(s) : Charles Eckel > > > > > > > > Filename : draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > Pages : 11 > > > > > > > > Date : 2011-06-16 > > > > > > > > > > > > > > > > This document provides recommendations and guidelines > > > > > > for RTP and > > > > > > > > RTCP in the context of SIPREC. This document > > exists as a > > > > > > > > standalone > > > > > > > > document to facilitate discussion of the RTP > > > > > > > > recommendations, and it > > > > > > > > is anticipated that portions of this document will be > > > > > > incorporated > > > > > > > > into [I-D.portman-siprec-protocol] rather than > > > > this document > > > > > > itself > > > > > > > > being adopted as a working group document. > > > > > > > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.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-eckel-siprec-rtp-rec-01.txt > > > > > > > > _______________________________________________ > > > > > > > > I-D-Announce mailing list > > > > > > > > I-D-Announce@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > Internet-Draft directories: > > http://www.ietf.org/shadow.html > > > > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > > > From john.elwell@siemens-enterprise.com Tue Jun 21 08:31:28 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3770C11E81AB for ; Tue, 21 Jun 2011 08:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm8kJevLfG27 for ; Tue, 21 Jun 2011 08:31:27 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 6DEF611E8148 for ; Tue, 21 Jun 2011 08:31:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1308670284!8708806!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 19422 invoked from network); 21 Jun 2011 15:31:25 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-2.tower-182.messagelabs.com with SMTP; 21 Jun 2011 15:31:25 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id E71DC23F03E2; Tue, 21 Jun 2011 17:31:24 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 21 Jun 2011 17:31:25 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Tue, 21 Jun 2011 17:31:24 +0200 Thread-Topic: I-D Action: draft-eckel-siprec-rtp-rec-01.txt Thread-Index: AcwsaNcOEe0gqVPXQ0yXvD4ktkTVMwAo3uRAAAS6UJAAgPmrsAAPr3dQAAYsgvAAAxWfEAAU7J8AABMOF0AAAFEysA== Message-ID: References: <20110616210242.4832.4179.idtracker@ietfa.amsl.com> In-Reply-To: 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: [siprec] I-D Action: draft-eckel-siprec-rtp-rec-01.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:31:28 -0000 Charles, I really wanted some list discussion, but we have some time at the end so b= y all means put some slides together and we will try to get discussion goin= g at the meeting if not before. Thanks, John =20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 21 June 2011 16:27 > To: Elwell, John; siprec@ietf.org > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt >=20 > No worries, and thank you for reviewing. I hope others can have a look > as well. So far I have not received any comments outside of yours from > SIPREC, nor have I received any from AVT. > Would it help if I put a few slides together for Thursday's interim > meeting? >=20 > Cheers, > Charles=20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Monday, June 20, 2011 11:16 PM > > To: Charles Eckel (eckelcu); siprec@ietf.org > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > >=20 > > Charles, > >=20 > > Sorry, I should have checked. In that case, I certainly like your > words. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 20 June 2011 21:19 > > > To: Elwell, John; siprec@ietf.org > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > Yes, both are defined in RFC 4961. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Monday, June 20, 2011 11:49 AM > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > Might work, but is the term "symmetric RTCP" a > > > well-established term? > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > Sent: 20 June 2011 16:57 > > > > > To: Elwell, John; siprec@ietf.org > > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > Hi John, > > > > > > > > > > Other comments I have received on this section have been to > > > > > address RTP > > > > > and RTCP separately. In order to address your concern as well > > > > > as these, > > > > > how about the following: > > > > > > > > > > When sending RTP, it is RECOMMENDED to use symmetric RTP. When > > > sending > > > > > RTCP, it is RECOMMENDED to use symmetric RTCP. Although an > > > > > SRS will not > > > > > normally send RTP, it will send RTCP as well as=20 > receive RTP and > > > RTCP. > > > > > Likewise, although an SRC will not normally receive RTP, it > > > > > will receive > > > > > RTCP as well as send RTP and RTCP. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John=20 > [mailto:john.elwell@siemens-enterprise.com] > > > > > > Sent: Monday, June 20, 2011 1:31 AM > > > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > Charles, > > > > > > > > > > > > What I had in mind was something along the following lines: > > > > > > "It is RECOMMENDED to use symmetric RTP. Although an > > > SRS will not > > > > > normally transmit RTP, it will > > > > > > transmit RTCP as well as receiving RTP and RTCP. Likewise, > > > > > although an > > > > > SRC will not normally receive > > > > > > RTP, it will receive RTCP as well as transmitting RTP and > RTCP." > > > > > > > > > > > > Your latest proposal seems to suggest that sending RTCP is > > > optional, > > > > > and I am not sure we want to > > > > > > condone that. > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > > Sent: 17 June 2011 19:56 > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > Subject: RE: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > > > Hi John, > > > > > > > > > > > > > > I tried to address this concern by handling RTP and RTCP > > > > > separately: > > > > > > > > > > > > > > If an SRC or SRS is sending RTP, it is=20 > RECOMMENDED to use > > > > > symmetric > > > > > > > RTP. If an SRC or SRS is sending RTCP, it is > > > > > RECOMMENDED to use > > > > > > > symmetric RTCP. > > > > > > > > > > > > > > I agree that the SRS will generally not need to send RTP, > and > > > > > > > that only > > > > > > > the RTCP recommendation will apply to the SRS, but I did > > > > > not want to > > > > > > > exclude it and did not see the harm in including the > > > SRS in the > > > > > > > considerations for RTP. I you think it is better to change > to: > > > > > > > > > > > > > > If an SRC is sending RTP, it is RECOMMENDED to use > > > symmetric > > > > > > > RTP. If an SRC or SRS is sending RTCP, it is > > > > > RECOMMENDED to use > > > > > > > symmetric RTCP. > > > > > > > > > > > > > > Cheers, > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Elwell, John > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > Sent: Friday, June 17, 2011 9:35 AM > > > > > > > > To: siprec@ietf.org; Charles Eckel (eckelcu) > > > > > > > > Subject: RE: I-D Action:=20 > draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > > > > > Charles, > > > > > > > > > > > > > > > > I still have a concern on the wording in section > > > 13. It says: > > > > > > > > "If an SRC or SRS is sending RTP, it is=20 > RECOMMENDED to use > > > > > symmetric > > > > > > > > RTP." > > > > > > > > Why would an SRS send RTP (as opposed to RTCP)? > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: i-d-announce-bounces@ietf.org > > > > > > > > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > > > > > > > > internet-drafts@ietf.org > > > > > > > > > Sent: 16 June 2011 22:03 > > > > > > > > > To: i-d-announce@ietf.org > > > > > > > > > Subject: I-D Action: draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > > > > Internet-Drafts directories. > > > > > > > > > > > > > > > > > > Title : Real-time Transport Protocol > (RTP) > > > > > > > > > Recommendations for SIPREC > > > > > > > > > Author(s) : Charles Eckel > > > > > > > > > Filename : > draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > Pages : 11 > > > > > > > > > Date : 2011-06-16 > > > > > > > > > > > > > > > > > > This document provides recommendations and=20 > guidelines > > > > > > > for RTP and > > > > > > > > > RTCP in the context of SIPREC. This document > > > exists as a > > > > > > > > > standalone > > > > > > > > > document to facilitate discussion of the RTP > > > > > > > > > recommendations, and it > > > > > > > > > is anticipated that portions of this=20 > document will be > > > > > > > incorporated > > > > > > > > > into [I-D.portman-siprec-protocol] rather than > > > > > this document > > > > > > > itself > > > > > > > > > being adopted as a working group document. > > > > > > > > > > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > > > > > > > > > > Internet-Drafts are also available by=20 > anonymous FTP at: > > > > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > > > > > > > > > > > > > > > > > > >=20 > ftp://ftp.ietf.org/internet-drafts/draft-eckel-siprec-rtp-rec-01.txt > > > > > > > > > _______________________________________________ > > > > > > > > > I-D-Announce mailing list > > > > > > > > > I-D-Announce@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > > Internet-Draft directories: > > > http://www.ietf.org/shadow.html > > > > > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > > > > > > > > = From Henry.Lum@alcatel-lucent.com Tue Jun 21 08:42:20 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E8611E80AE for ; Tue, 21 Jun 2011 08:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNUbgNkmwpGu for ; Tue, 21 Jun 2011 08:42:18 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 322CC11E827D for ; Tue, 21 Jun 2011 08:42:17 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p5LFgFdm020301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2011 10:42:15 -0500 (CDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5LFgDiP021745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jun 2011 10:42:15 -0500 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p5LFgCBV024020; Tue, 21 Jun 2011 08:42:13 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 08:42:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jun 2011 08:42:11 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7407358745@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwraoGY85PiN+LzTEOpAI9MKAfySABwsWngAAEpqOAAgVv9QAAAniMgADvUgeA= References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com><4DF77EB5.9060009@cisco.com><4DF8C4E0.8020409@cis! co.! ! com> < 059AF07365DC 474393A19A3AF187DF7407358376@NAHALD.us.int.genesyslab.com> From: "Henry Lum" To: "Parthasarathi R (partr)" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 21 Jun 2011 15:42:12.0818 (UTC) FILETIME=[CA077320:01CC3029] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: siprec@ietf.org Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:42:20 -0000 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Monday, June 20, 2011 7:49 AM > To: Elwell, John; Henry Lum; Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > John, >=20 > > [JRE] What is meant by "MS1 corresponds to MS3 or MS4"? What exactly is > this correspondence? > For example, Two audio stream (MS1, MS2) without content type > in CS1 by participant1 has to be correspond to an another two audio > stream (MS3, MS4) without content type in CS2 by participant1 under > single CSG1. Here is the question how to identify MS1 to MS3 or MS4? > >=20 > [JRE] I can understand how the two MS are both part of CSs from the > same CSG. I can also understand how they can both be transmitted by the > same Participant. I can also understand that they might be for the same > media type (e.g., video) and have same content (e.g., slides, current > speaker). All this is visible from the metadata. > We are in the same page till here. The missing piece is the > relationship for same multiple media types across CS if exist without > content type. Here, I may have concern about some specific case which I > could think of.=20 >I'm fine with local MS id in case folks feel that the > above scenario is just one of the corner case for the solution. >=20 > I could think of slightly modified proposal in your label attribute > extension. Say CSG1:MSid as the unique-id wherein CSG1 is the globally > unique-id and MSid is the extension of label attribute wherein label > attribute for the given MS is same throughout the given CSG. >=20 >=20 > [JRE]What other aspect of correspondence requires the two MSs to have > the same identifier? > Ram mentioned about multicast scenario in another mail thread > wherein correspondence is required between two MSs. [hlum] I couldn't find the email reference, but is the only correspondence to require the same identifier is that a CS sends two media streams with the same media type? Is there a way to further qualify the media stream beyond media type?=20 >=20 > Or putting the question another way, what harm is done if the two MSs > have different identifiers? >=20 >=20 > >=20 > Thanks > Partha >=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, June 20, 2011 4:23 PM > To: Parthasarathi R (partr); Henry Lum; Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 17 June 2011 22:23 > > To: Henry Lum; Paul Kyzivat (pkyzivat); Elwell, John > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > Henry, > > > > > > However, I still find it confusing to allow an MS to be moved across > > CS and participants. I worry that we can abuse the MS semantics to > > reuse MS as if it is a physical port of media since an MS is no > longer >=20 > > tied to the lifetime of a CS. Keeping an MS to within a CS makes it > > clear about segments of a call when it gets transferred from person > to >=20 > > person. It will be up to the SRS to stitch the segments of a call > > (multiple MS) together. > > > > > > The clear demarcation exists for transfer from person to person > exists >=20 > > using different CS-id after the transfer. > > > > I'm worried about stitching the segments of a call (session) in case > > same media type with multiple MS exists between CS. Say media stream > > of same media type MS1 & MS2 in CS1 of participant1 corresponds to > MS3 >=20 > > & > > MS4 in CS2 of participant2 in single CSG, how to identify MS1 > > corresponds to MS3 or MS4 in CS2. I agree that it is possible to say > > that SRS should have some extended metadata mechanism to achieve to > > this but I preferred in case it is handled as part of metadata > itself. > [JRE] What is meant by "MS1 corresponds to MS3 or MS4"? What exactly is > this correspondence? I can understand how the two MS are both part of > CSs from the same CSG. I can also understand how they can both be > transmitted by the same Participant. I can also understand that they > might be for the same media type (e.g., video) and have same content > (e.g., slides, current speaker). All this is visible from the metadata. > What other aspect of correspondence requires the two MSs to have the > same identifier? Or putting the question another way, what harm is done > if the two MSs have different identifiers? >=20 > John >=20 >=20 > > > > As John mentioned below, the local-id is not going to save the > > bandwidth in the transfer scenario. Even I tried to see the example > > with full metadata XML update (instead of partial update) wherein the > > size of full message is less that local-id MS with partial update. I > > attached the message for your reference. > > > > Also, global id (URN UUID) will be able to achieve all the > > functionality of local-id (XML:id) but not the other way around. Say, > > SRS does not want to see the relation between MS1 to MS3 or MS4 in > the >=20 > > above scenario, global id is not going to stop anything. > > > > Regards, > > Henry > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Wednesday, June 15, 2011 10:43 AM > > To: Elwell, John > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > On 6/15/2011 9:55 AM, Elwell, John wrote: > > > Paul, > > > > > > But if the two SRCs are somehow cooperating to the extent that they > > can share the same global ID for the CS, could they not also share > the > > same local ID for the MS? Why does it need to be a global ID? > > > > They could *know* each other's local id for the MS. > > They might even agree to use the *same* value for the local id. > > > > E.g. we have SRC#1 and SRC#2, each using 123 as the local id for the > > "same" stream. > > > > But to the SRS, there is one MS with id SRC#1:123, and another MS > with > > SRC#2:123. It does not know they are the same. (That is the point of > > local scoping.) > > > > So even though the two SRCs know they are talking about the > > same MS they > > > > have no way to tell that to the SRS. > > > > Thanks, > > Paul > > > > > John > > > > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org > > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > >> Sent: 14 June 2011 16:31 > > >> To: siprec@ietf.org > > >> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > >> > > >> John, > > >> > > >> Consider another case: two SRCs in the same CS (perhaps one at > each > > >> "end".) They are both sending metadata about the same CS and MSs. > > >> > > >> Suppose they want to cooperate with each other. They have the > > >> potential to use the same ID to reference the CS, so that the SRS > > >> will know they are talking about the same one. But with > > RS-specific > > >> MS ids there is no way for them to indicate that they are talking > > >> about the same MSs. With global MS ids, they could accomplish > this. > > >> > > >> Thanks, > > >> Paul > > >> > > >> On 6/14/2011 11:03 AM, Elwell, John wrote: > > >>> Partha, > > >>> > > >>> Thanks for the examples. The character count for the delta > > >> is about 2500 when a new MS is created compared to about 2100 when > > >> the MS is retained. This seems to be in line with my previous gut > > >> feeling. > > >>> > > >>> Concerning the need for "SRS implementers to guess how old > > >> MS and new MS are related", I don't think they are > > related, except by > > > > >> having other things in common like a common participant or > > a common > > >> CSG. > > >>> > > >>> John (as individual) > > >>> > > >>>> -----Original Message----- > > >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > >>>> Sent: 14 June 2011 13:15 > > >>>> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; > > Ram Mohan > > >>>> R (rmohanr); siprec@ietf.org > > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a > CSG? > > >>>> > > >>>> Hi all, > > >>>> > > >>>> Sorry for the delay. Just to double confirm everybody > > understanding > > > > >>>> with SIP message example, I added the example with > > creating new MS > > >>>> and reusing the same MS as an attachment with this mail. > > >>>> > > >>>> Please note that creating new MS is putting SRS > > >> implementers to guess > > >>>> how old MS and new MS are related. Also, few scenario like > > >> Even after > > >>>> looking into the example, the intention is to use local > > >> variable, I'm > > >>>> ok. > > >>>> > > >>>> Thanks > > >>>> Partha > > >>>> > > >>>> -----Original Message----- > > >>>> From: Charles Eckel (eckelcu) > > >>>> Sent: Friday, June 10, 2011 10:57 PM > > >>>> To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > >> Ram Mohan R > > >>>> (rmohanr); siprec@ietf.org > > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a > CSG? > > >>>> > > >>>> Please excuse the delay. I am catching up after having > > been away on > > > > >>>> vacation. > > >>>> In light of this better understanding of the use case, I also > > >>>> prefer the option favored by John and Leon to model as a > > separate > > >>>> MS. In this specific case, I would expect the properties > > of the MS > > >>>> to change when A is transferred to C, so I expect the > > overhead in > > >>>> creating > > >> a new MS vs. > > >>>> reusing the same MS to be minimal and not worth the added > > >>>> complexity to the model. > > >>>> > > >>>> Cheers, > > >>>> Charles > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] > > >>>>> Sent: Tuesday, May 31, 2011 6:19 AM > > >>>>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > >> (eckelcu); > > >>>>> Ram Mohan R (rmohanr); siprec@ietf.org > > >>>>> Subject: RE: [siprec] Can an MS object span several CSs > > in a CSG? > > >>>>> > > >>>>> Hello > > >>>>> > > >>>>> I also having a problem even without a quantification > > of number of > > > > >>>>> update messages that CS MS is remains same between > > >>>> different CS. So I > > >>>> do prefer to keep it simple and keep it per CS. > > >>>>> > > >>>>> Leon > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > >>>>> Behalf Of Elwell, John > > >>>>> Sent: Friday, May 27, 2011 12:26 PM > > >>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > Ram Mohan R > > >>>>> (rmohanr); siprec@ietf.org > > >>>>> Subject: Re: [siprec] Can an MS object span several CSs > > in a CSG? > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > >>>>>> Sent: 26 May 2011 15:55 > > >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > > (rmohanr); > > > > >>>>>> siprec@ietf.org > > >>>>>> Subject: RE: [siprec] Can an MS object span several > > CSs in a CSG? > > >>>>>> > > >>>>>> John, > > >>>>>> > > >>>>>> The callflow mentioned by me is the basic primitive in > > the call > > >>>>>> center scenario wherein customer (participant) is same > > throughout > > > > >>>>>> the session and agents are changed using transfer service > > >>>> and B2BUA > > >>>> acts as SRC. > > >>>>>> IMO, it is one of key requirement to be considered in case we > > >>>>>> support for partial-update. > > >>>>> [JRE] Agreed the Participant remains the same, but we are > > >> discussing > > >>>> MS. > > >>>>> > > >>>>>> This may not be the only callflow where MS partial-update is > > >>>>>> required in this fashion. During -00 format draft, I > > thought that > > > > >>>>>> the partial-update is not required but lot of folks raised the > > >>>>>> concern that partial update is important. Current, -01 > > >>>> format draft > > >>>>>> is designed to support partial-update. Now, You propose > > >>>> to restrict > > >>>>>> MS partial-update across CS. IMO, it is a not good idea > > >>>> to restrict > > >>>>>> in the protocol level. Anyway, I think that we need > > >>>> others opinion > > >>>>>> before conclude here. > > >>>>> [JRE] I am not opposed to partial update, but I would > > >> like to avoid > > >>>>> distorting the model just to gain some efficiency > > improvements in > > >>>>> certain cases. To me it is not intuitive that a MS on one > > >>>> CS and an MS > > >>>> > > >>>>> on another CS are the same object, just because one of the > > >>>>> Participants is common to both CSs. In the > > transfer-between-agents > > >>>> example, although one of the Participants is common to > > the two CSs, > > > > >>>> this is not true for the other Participants. > > >>>>> > > >>>>> Let's try to quantify the efficiency improvement. In the blind > > >>>>> transfer case, the partial updates would at least have > > to include: > > >>>>> - the removal of P1 from CS1 (where P1 is the first agent > > >>>> and CS1 is > > >>>>> the first CS); > > >>>>> - the removal of P2 from CS1 (where P2 is the transferred > > >>>>> participant); > > >>>>> - the termination of CS1; > > >>>>> - the removal of CS1 from CSG1; > > >>>>> - the creation of CS2 (the CS that results from transfer); > > >>>>> - the addition to of CS2 to CSG1; > > >>>>> - the addition of P2 to CSG1; > > >>>>> - the addition of P3 to CS2 (where P3 is the second agent); > > >>>>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); > > >>>>> - the removal of P2 as a recipient of MS1; > > >>>>> - the termination of MS1; > > >>>>> - the creation of MS3; > > >>>>> - the addition of P3 as a sender of MS3; > > >>>>> - the addition of P2 as a recipient of MS3. > > >>>>> > > >>>>> So all we are arguing about is whether we also include in > > >>>> the partial > > >>>>> updates EITHER (this I think is your proposal): > > >>>>> - the removal of P1 as a recipient of MS2; > > >>>>> - the addition of P3 as a recipient of MS2; > > >>>>> > > >>>>> OR > > >>>>> - the removal of P1 as recipient of MS2; > > >>>>> - the removal of P2 as a sender of MS2; > > >>>>> - the termination MS2; > > >>>>> - the creation of MS4; > > >>>>> - the addition of P3 as a recipient of MS4; > > >>>>> - the addition of P2 as a sender of MS4. > > >>>>> > > >>>>> So with the first option the total number of deltas is 14+2=3D16. > > >>>>> For the second option the total number of deltas is 14+6=3D20. > > >>>>> > > >>>>> Some of the details might be wrong, but I hope you can see > > >>>> the point I > > >>>> > > >>>>> am getting at. Looked at this way, the efficiency saving by > > >>>> recycling > > >>>>> MS2 for use in consecutive CSs is relatively small. Or > > >> perhaps your > > >>>>> intention is also to recycle MS1 (this time, the recipient > > >>>> remaining > > >>>>> the same but the sender changing). That would reduce > > the number of > > > > >>>>> deltas slightly further. The impact on XML size might not > > >>>> be quite in > > >>>>> proportion to the reduction in the number of deltas, since by > > >>>> recycling MS2 it has to have a global identifier, not an > > identifier > > > > >>>> local to a CS. Or perhaps it could have an identifier > > >> local to a CSG. > > >>>>> > > >>>>> I also see that with your proposal it doesn't force the > > MS to be > > >>>>> recycled - an SRC could still choose to model it as > > separate MSs. > > >>>>> However, in that case it would still need to use global > > >> identifiers > > >>>> for MSs. > > >>>>> > > >>>>> I am not necessarily opposed to your proposal for recycling > > >>>> MS objects > > >>>> > > >>>>> outside the context of a single CS - I can see advantages and > > >>>>> disadvantages. I just want to make sure the group makes > > >> an informed > > >>>> decision. > > >>>>> > > >>>>> John (as individual) > > >>>>> > > >>>>> > > >>>>>> > > >>>>>> Enhancing label attribute across the multiple SIP > > message to tie > > >>>>>> between Metadata XML and RS SDP m-line is possible. SRC has to > > >>>>>> ensure that label for the given RS SDP m-line should have > > >>>> same label > > >>>> > > >>>>>> throughout single CSG even though it span across > > multiple CS and > > >>>>>> multiple RS. Even then, it will not meet partial-update > > >>>> requirement > > >>>>>> as mentioned below in this mail thread. At this moment, > > >>>> I'm favoring > > >>>> > > >>>>>> URN UUID and not label attribute enhancement. > > >>>>>> > > >>>>>> Please read inline > > >>>>>> > > >>>>>> Thanks > > >>>>>> Partha > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > >>>>>> Sent: Wednesday, May 25, 2011 7:17 PM > > >>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > Ram Mohan R > > > > >>>>>> (rmohanr); siprec@ietf.org > > >>>>>> Subject: RE: [siprec] Can an MS object span several > > CSs in a CSG? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > >>>>>>> Sent: 25 May 2011 08:48 > > >>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > > >>>> (rmohanr); > > >>>>>>> siprec@ietf.org > > >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs > > >>>> in a CSG? > > >>>>>>> > > >>>>>>> John, > > >>>>>>> > > >>>>>>> > > >>>> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> =3D > > >>>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA > > >>>>>>> converts REFER > > >>>>>>> > > >>>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA > > >>>>>>> updates RS > > >>>>>>>> with CS2, Participant1 as A& participant2 as C, > > >>>> MS1(A's media > > >>>>>>>> stream), MS2(C's media stream). There is no update on RS1, > > >>>>>>> CSG1, MS1, > > >>>>>>>> MS2. MS2 will become MS2 with the new association and > > >>>> in terms > > >>>>>>>> of format, it will associate with tag > > >>>>>>> [JRE] What harm is done (what do we lose) if, following > > >>>>>> transfer, A's > > >>>>>>> media stream is called MS3 and C's media stream is called > MS4? > > >>>>>>> > > >>>>>> > > >>>> > > >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>> =3D > > >>>>>>> To indicate MS1 as MS3, MS1 media block has to be > > >>>>>> stopped in > > >>>>>>> the partial-update and start MS3 separate which is not > > >>>> required in > > >>>> > > >>>>>>> case there is a means to have common MS1. > > >>>>>> [JRE] It seems this distorts the model in order to give > > >>>> some minor > > >>>>>> efficiency improvement during metadata updates. I > > doubt that this > > > > >>>>>> alone is sufficient justification for having the MS > > >>>> persist from one > > >>>> > > >>>>>> CS to another CS. > > >>>>>> > > >>>>>>> > > >>>>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > >>>>>>> MS3 can reference the same SDP m-line (through > > a=3Dlabel) as MS1, > > >>>>>>> and likewise MS4 could reference the same SDP m-line as > > >>>> MS2, if we > > >>>> > > >>>>>>> are concerned about recycling media descriptions in RS SDP. > > >>>>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> As you mentioned, we will lose recycling of media > > >>>>>> description > > >>>>>>> in RS SDP without common value in media stream object > > for this > > >>>>>>> scenario. > > >>>>>> [JRE] I don't understand your point. With my proposal we > > >>>> can still > > >>>>>> recycle RS SDP m-lines. > > >>>>>> > > >>>>>> Agreed that Recycle is possible with your proposal. > > >>>>>> I indicated > > >>>>>> the need for unique-id in this requirement > > >>>>>> > > >>>>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label > > >>>>>> attribute > > >>>>>>> scope is within single SIP message and not required to > > >>>> be unique > > >>>>>>> in all SIP messages of a given dialog. > > >>>>>> [JRE] But I think we could nail that down as a > > requirement of the > > > > >>>>>> SIPREC protocol. > > >>>>>> > > >>>>>> John (as individual) > > >>>>>> > > >>>>>>> > > >>>>>>> Thanks > > >>>>>>> Partha > > >>>>>>> > > >>>>>>> John (as individual) > > >>>>>>> > > >>>>>>>> > > >>>>>>>> Thanks > > >>>>>>>> Partha > > >>>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Charles Eckel (eckelcu) > > >>>>>>>> Sent: Wednesday, May 25, 2011 1:39 AM > > >>>>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); > > >>>>>> 'Elwell, John'; > > >>>>>>>> 'siprec@ietf.org' > > >>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a > > >>>> CSG? > > >>>>>>>> > > >>>>>>>> Hi Ram, > > >>>>>>>> > > >>>>>>>> I think that is many cases, they will be treated as > > >>>> separate MSs > > >>>> > > >>>>>>>> due to the complexities you mention. However, I am trying to > > >>>>>> understand if > > >>>>>>>> Partha feels allowing an SRC to treat them as a single MS is > > >>>>>>>> still required. If not, then what is a use case? A concrete > > >>>>>>>> example would help me, and potentially others, to better > > >>>>>>>> understand the > > >>>>>>> motivation behind > > >>>>>>>> Partha's requirement for modeling media from multiple CSs > > >>>>>>> as a single > > >>>>>>>> MS. > > >>>>>>>> > > >>>>>>>> Cheers, > > >>>>>>>> Charles > > >>>>>>>> > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: Ram Mohan R (rmohanr) > > >>>>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM > > >>>>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > >>>>>>> Elwell, John; > > >>>>>>>>> siprec@ietf.org > > >>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs > > >>>>>> in a CSG? > > >>>>>>>>> > > >>>>>>>>> Charles, > > >>>>>>>>> > > >>>>>>>>> I did bring about this specific usecase of MMOH/MOH > > >>>>>> stream being > > >>>>>>>>> played to different participants earlier and suggested that > > >>>>>>>> they have > > >>>>>>>>> to treated as a same MS across multiple CSs > > >>>>>> (potentially recorded > > >>>>>>>> using multiple RSs). > > >>>>>>>>> Refer > > >>>>>>>>> > > >>>>>> > > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > > >>>>>>>>> > > >>>>>>>>> We had several discussions on it and it and several > > >>>>>> folks were in > > >>>>>>>>> favor of treating it as separate MS as there would be > > >>>>>>>> complexity in DB > > >>>>>>>> design. > > >>>>>>>>> > > >>>>>>>>> Regards, > > >>>>>>>>> Ram > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> -----Original Message----- > > >>>>>>>>>> From: siprec-bounces@ietf.org > > >>>>>>> [mailto:siprec-bounces@ietf.org] On > > >>>>>>>>>> Behalf Of Charles Eckel (eckelcu) > > >>>>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM > > >>>>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > >>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > > >>>>>>> in a CSG? > > >>>>>>>>>> > > >>>>>>>>>> Hi Partha, > > >>>>>>>>>> > > >>>>>>>>>> Is an example of this the same music on hold audio stream > > >>>>>>>> existing > > >>>>>>>>>> as the same MS within multiple CSs? If so, then I > > >>>>>>> understand your > > >>>>>>>>>> requirement to be that the SRC be able to > > >>>> indicate multiple > > >>>>>>>>>> instances of this audio stream within several CSs as > > >>>>>>>> being the same > > >>>>>>>>>> MS. Is that correct? > > >>>>>>>>>> > > >>>>>>>>>> Thanks, > > >>>>>>>>>> Charles > > >>>>>>>>>> > > >>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>> From: siprec-bounces@ietf.org > > >>>>>>>> [mailto:siprec-bounces@ietf.org] On > > >>>>>>>>>> Behalf Of Parthasarathi R (partr) > > >>>>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM > > >>>>>>>>>>> To: Elwell, John; siprec@ietf.org > > >>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > > >>>>>>>> in a CSG? > > >>>>>>>>>>> > > >>>>>>>>>>> John, > > >>>>>>>>>>> > > >>>>>>>>>>> I agree that it is not mandatory to consider recorded > > >>>>>>>> stream of a > > >>>>>>>>>>> specific participant in several CS within the same > > >>>>>> CSG as one > > >>>>>>>>>> recorded > > >>>>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a > > >>>>>>>> SRC in case > > >>>>>>>>>>> it wishes to design in such a way. > > >>>>>>>>>>> > > >>>>>>>>>>> Thanks > > >>>>>>>>>>> Partha > > >>>>>>>>>>> > > >>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>> From: siprec-bounces@ietf.org > > >>>>>>>> [mailto:siprec-bounces@ietf.org] On > > >>>>>>>>>> Behalf > > >>>>>>>>>>> Of Elwell, John > > >>>>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM > > >>>>>>>>>>> To: siprec@ietf.org > > >>>>>>>>>>> Subject: [siprec] Can an MS object span several CSs > > >>>>>> in a CSG? > > >>>>>>>>>>> > > >>>>>>>>>>> We seem to have consensus that a Media Stream object > > >>>>>>>> represents a > > >>>>>>>>>>> recorded media stream, contributed to by one, > > >>>>>> several or all > > >>>>>>>>>>> Participants. However, Partha also wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> "2) Each MS lifetime related to CSG because participant > > >>>>>>>> may move > > >>>>>>>>>>> from one CS to another CS within single CSG and also > > >>>>>>>> CSG will span > > >>>>>>>> > > >>>>>>>>>>> across multiple RS." > > >>>>>>>>>>> > > >>>>>>>>>>> I am not sure we had resolved this during earlier > > >>>>>>>> discussions on > > >>>>>>>>>>> the scope of an MS object. Although the same > > >>>>>> Participant can > > >>>>>>>>>>> participate > > >>>>>>>>>> in > > >>>>>>>>>>> several CSs within the same CSG, I don't think the > > >>>>>>>> recorded media > > >>>>>>>>>>> streams need to be considered the same. Any other views? > > >>>>>>>>>>> > > >>>>>>>>>>> John (as individual) > > >>>>>>>>>>> _______________________________________________ > > >>>>>>>>>>> siprec mailing list > > >>>>>>>>>>> siprec@ietf.org > > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>>>>>>>>> _______________________________________________ > > >>>>>>>>>>> siprec mailing list > > >>>>>>>>>>> siprec@ietf.org > > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>>>>>>>> _______________________________________________ > > >>>>>>>>>> siprec mailing list > > >>>>>>>>>> siprec@ietf.org > > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> _______________________________________________ > > >>>>> siprec mailing list > > >>>>> siprec@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>> > > >>> _______________________________________________ > > >>> siprec mailing list > > >>> siprec@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/siprec > > >>> > > >> _______________________________________________ > > >> siprec mailing list > > >> siprec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/siprec > > >> > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > -------------------------------------------------------------- > > ---------- > > ------------------------------------------- > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may > contain > > confidential and proprietary information of Alcatel-Lucent and/or its > > affiliated entities. Access by the intended recipient only is > > authorized. Any liability arising from any party acting, or > refraining > > from acting, on any information contained in this e-mail is hereby > > excluded. If you are not the intended recipient, please notify the > > sender immediately, destroy the original transmission and its > > attachments and do not disclose the contents to any other > > person, use it > > for any purpose, or store or copy the information in any medium. > > Copyright in this e-mail and any attachments belongs to Alcatel- > Lucent > > and/or its affiliated entities. > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 From partr@cisco.com Tue Jun 21 09:51:57 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB4821F84C9 for ; Tue, 21 Jun 2011 09:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBA8JyCW-lwQ for ; Tue, 21 Jun 2011 09:51:56 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8BED621F84C8 for ; Tue, 21 Jun 2011 09:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=5472; q=dns/txt; s=iport; t=1308675116; x=1309884716; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+v5hpVr6ctoYcle1m+DvzD5l9G57KTUQgEwHdBHizLQ=; b=fhdKIozPmWIggbeXkofqU3fLNsP/gUw8i5aOTzOYGn/BjXyaxWwFZbij KvA63N9hWIC4iMbdRFebATdIO84a3ksz0uRYN4vOEbDHbDihye1FvzGG7 m4D5h2rvCyBg+ai6D6gfgFu8U+iy9Y/sc4gvJe21w7l6Sqf0qC26xSZAE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAJjLAE5Io8UQ/2dsb2JhbABHDZddjxR3iHOhK54/gx6DDASHII8xiyM X-IronPort-AV: E=Sophos;i="4.65,402,1304294400"; d="scan'208";a="36707332" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 21 Jun 2011 16:51:49 +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 p5LGpmMl017775; Tue, 21 Jun 2011 16:51:48 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 22:21:48 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jun 2011 22:21:43 +0530 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AF5C8E38@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Adoptionof material fromdraft-ram-siprec-metadata-format-02 Thread-Index: Acwvc9GH9M8y1vuZSxq3cub71esM/gAfP5LgABAu1WA= References: <4DFF8A82.3000809@cisco.com> <07465C1D981ABC41A344374066AE1A2C38AF5C8E38@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Leon Portman" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 21 Jun 2011 16:51:48.0871 (UTC) FILETIME=[83269170:01CC3033] Subject: Re: [siprec] Adoptionof material fromdraft-ram-siprec-metadata-format-02 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:51:57 -0000 Hi all, I have raised non-SIP (HTTP, XMPP) mechanism for metadata as an open item in SIPREC architecture document before IETF-80. The related link is as follows: http://www.ietf.org/mail-archive/web/siprec/current/msg01608.html. The conclusion of IETF-80 SIPREC meeting is to use SIP as a mechanism which is discussed at slide-7 of SIPREC architecture (www.ietf.org/proceedings/80/slides/siprec-2.ppt). I attached the specific slide content and notes of the meeting for your reference. Thanks Partha Note: Slide contents: 01 draft states some examples of how metadata could be delivered to the SRC SIP Headers.=20 SDP. Event Package. INFO Package. Non SIP Means. Proposal - We seem to be converging on using INVITE/UPDATE on the RS Dialog so state this. Keep non SIP means although outside SIPREC scope. Conclusion in IETF-80: Proposal: List INVITE/UPDATE + non-SIP means only for metadata delivery? Hadriel Kaplan: Agrees, but don't mention specific methods (e.g. INVITE/UPDATE) Keith Drage: Clarified that this repeats stuff in the protocol document=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: Tuesday, June 21, 2011 2:32 PM To: Paul Kyzivat (pkyzivat); siprec@ietf.org Subject: Re: [siprec] Adoptionof material fromdraft-ram-siprec-metadata-format-02 Actually we had lot of discussion about this issue (metadata over SIP or over dedicated web service/HTTP) both internally and with partners. Main advantages (what I remember ) for SIP approach are as follows: 1. Simplicity, only one interface to implement, troubleshoot, secure and configure between SRC and SRS 2. RS SIP request is self-contained, it includes all relevant info in order to SRS to decide how to do recording . For example participants identity, location. So no need for SRS to correlate different messages from different interfaces 3. Footprint on SRC. For some implementation it is not feasible to have both SIP and HTTP stacks Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, June 20, 2011 9:00 PM To: siprec@ietf.org Subject: Re: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02 Charles, IIRC, the major driving forces were timeliness and synchronicity of metadata with the actual signaling, especially when initially establishing a RS, so that suitable decisions can be made about whether to record a session, etc. AFAIK the avoidance of an HTTP server in the SRS wasn't a concern. (Its assumed in general to be a very capable box, and probably has an HTTP interface for querying, though that is out of our scope for now.) Avoiding an http client in the src might be slightly more significant, but I don't think that was much of a concern either. Could we have skinned this cat with an http approach? Probably. Obviously we had a lot more sip expertise than http expertise in the group. That may have been an influence as well. Thanks, Paul On 6/20/2011 11:40 AM, Charles Eckel (eckelcu) wrote: > Hi John, > > One general comment/question I have received from web application=20 > savvy coworkers with whom I have discussed the contents of this draft=20 > is that the metadata is essentially a document and HTTP already has=20 > well defined mechanisms for document sharing and updating, so why not=20 > exchange an HTTP address for the document and leverage those=20 > mechanisms instead of sending all the metadata within SIP messages. My > assumption is that the requirement is to have a SIP based solutions=20 > that does not require an HTTP server. Is that accurate? > > Thanks, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John >> Sent: Monday, June 20, 2011 4:02 AM >> To: siprec@ietf.org >> Subject: [siprec] Adoption of material > fromdraft-ram-siprec-metadata-format-02 >> >> Although there are some open issues, to be discussed during=20 >> Thursday's > call, I would like the WG to >> consider whether material in draft-ram-siprec-metadata-format-02 is > ready for adoption into draft- >> ietf-siprec-metadata, i.e., bring it under WG control. In particular, > between now and the call, please >> consider whether: >> - the material is heading roughly in an acceptable direction; >> - there are any issues that really should be closed before adoption; >> - there are any aspects of the draft that should not be adopted at > this time. >> >> If, on the call or shortly afterwards, we can agree on adoption, the > authors of the two drafts would >> be asked to perform a merger and publish a new version of > draft-ietf-siprec-metadata before the cut- >> off for IETF#81 (2011-07-11). >> >> John >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Tue Jun 21 10:18:57 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF2F11E80B0 for ; Tue, 21 Jun 2011 10:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.414 X-Spam-Level: X-Spam-Status: No, score=-10.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBpv6iblH1Hr for ; Tue, 21 Jun 2011 10:18:55 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5E27D11E808B for ; Tue, 21 Jun 2011 10:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=31287; q=dns/txt; s=iport; t=1308676734; x=1309886334; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=q3T6AN7ba7RGhd4YC2hVLdbvOXzm7kk2Lms9tTBfN+o=; b=DnRIldnaQU4wbZTEzqMGldbvGe+RIh8A9COQ14sZl7RAyRVc4PYIdVrX qUYW8EtdK8Es4/PtabchQGNwysb6oSD0Tse/ankT/EOUqKexj0hXjGQbG tS7nTw28XMQ5AH+n1yc/XqvAThnb7bhh4maYWiqJhau5iqcopYmfpBHqt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAGnRAE5Io8UQ/2dsb2JhbABGDpddjxR3iHOhNZ47gx2DDQSHII8xiyM X-IronPort-AV: E=Sophos;i="4.65,402,1304294400"; d="scan'208";a="36717112" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 21 Jun 2011 17:17:03 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5LHH1A3028935; Tue, 21 Jun 2011 17:17:03 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 22:47:03 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jun 2011 22:46:56 +0530 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF7407358745@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwraoGY85PiN+LzTEOpAI9MKAfySABwsWngAAEpqOAAgVv9QAAAniMgADvUgeAAA1syoA== References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com><4DF77EB5.9060009@cisco.com><4DF8C4E0.8020409@cis! co.! ! com> <059AF07365 DC474393A19A3AF187DF7407358376@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF7407358745@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Henry Lum" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 21 Jun 2011 17:17:03.0418 (UTC) FILETIME=[09E419A0:01CC3037] Cc: siprec@ietf.org Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 17:18:57 -0000 Henry, The mail thread reference for multicast usecase is available at http://www.ietf.org/mail-archive/web/siprec/current/msg02051.html Thanks Partha=20 -----Original Message----- From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]=20 Sent: Tuesday, June 21, 2011 9:12 PM To: Parthasarathi R (partr); Elwell, John; Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Monday, June 20, 2011 7:49 AM > To: Elwell, John; Henry Lum; Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > John, >=20 > > [JRE] What is meant by "MS1 corresponds to MS3 or MS4"? What exactly is > this correspondence? > For example, Two audio stream (MS1, MS2) without content type > in CS1 by participant1 has to be correspond to an another two audio=20 > stream (MS3, MS4) without content type in CS2 by participant1 under=20 > single CSG1. Here is the question how to identify MS1 to MS3 or MS4? > >=20 > [JRE] I can understand how the two MS are both part of CSs from the=20 > same CSG. I can also understand how they can both be transmitted by the > same Participant. I can also understand that they might be for the same > media type (e.g., video) and have same content (e.g., slides, current=20 > speaker). All this is visible from the metadata. > We are in the same page till here. The missing piece is the=20 > relationship for same multiple media types across CS if exist without=20 > content type. Here, I may have concern about some specific case which I > could think of.=20 >I'm fine with local MS id in case folks feel that the above scenario=20 >is just one of the corner case for the solution. >=20 > I could think of slightly modified proposal in your label attribute=20 > extension. Say CSG1:MSid as the unique-id wherein CSG1 is the globally > unique-id and MSid is the extension of label attribute wherein label=20 > attribute for the given MS is same throughout the given CSG. >=20 >=20 > [JRE]What other aspect of correspondence requires the two MSs to have=20 > the same identifier? > Ram mentioned about multicast scenario in another mail thread > wherein correspondence is required between two MSs. [hlum] I couldn't find the email reference, but is the only correspondence to require the same identifier is that a CS sends two media streams with the same media type? Is there a way to further qualify the media stream beyond media type?=20 >=20 > Or putting the question another way, what harm is done if the two MSs > have different identifiers? >=20 >=20 > >=20 > Thanks > Partha >=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, June 20, 2011 4:23 PM > To: Parthasarathi R (partr); Henry Lum; Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 17 June 2011 22:23 > > To: Henry Lum; Paul Kyzivat (pkyzivat); Elwell, John > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > > > Henry, > > > > > > However, I still find it confusing to allow an MS to be moved across > > CS and participants. I worry that we can abuse the MS semantics to=20 > > reuse MS as if it is a physical port of media since an MS is no > longer >=20 > > tied to the lifetime of a CS. Keeping an MS to within a CS makes it=20 > > clear about segments of a call when it gets transferred from person > to >=20 > > person. It will be up to the SRS to stitch the segments of a call=20 > > (multiple MS) together. > > > > > > The clear demarcation exists for transfer from person to person > exists >=20 > > using different CS-id after the transfer. > > > > I'm worried about stitching the segments of a call (session) in case > > same media type with multiple MS exists between CS. Say media stream > > of same media type MS1 & MS2 in CS1 of participant1 corresponds to > MS3 >=20 > > & > > MS4 in CS2 of participant2 in single CSG, how to identify MS1=20 > > corresponds to MS3 or MS4 in CS2. I agree that it is possible to say > > that SRS should have some extended metadata mechanism to achieve to=20 > > this but I preferred in case it is handled as part of metadata > itself. > [JRE] What is meant by "MS1 corresponds to MS3 or MS4"? What exactly is > this correspondence? I can understand how the two MS are both part of=20 > CSs from the same CSG. I can also understand how they can both be=20 > transmitted by the same Participant. I can also understand that they=20 > might be for the same media type (e.g., video) and have same content=20 > (e.g., slides, current speaker). All this is visible from the metadata. > What other aspect of correspondence requires the two MSs to have the=20 > same identifier? Or putting the question another way, what harm is done > if the two MSs have different identifiers? >=20 > John >=20 >=20 > > > > As John mentioned below, the local-id is not going to save the=20 > > bandwidth in the transfer scenario. Even I tried to see the example=20 > > with full metadata XML update (instead of partial update) wherein the > > size of full message is less that local-id MS with partial update. I > > attached the message for your reference. > > > > Also, global id (URN UUID) will be able to achieve all the=20 > > functionality of local-id (XML:id) but not the other way around. Say, > > SRS does not want to see the relation between MS1 to MS3 or MS4 in > the >=20 > > above scenario, global id is not going to stop anything. > > > > Regards, > > Henry > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Wednesday, June 15, 2011 10:43 AM > > To: Elwell, John > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > On 6/15/2011 9:55 AM, Elwell, John wrote: > > > Paul, > > > > > > But if the two SRCs are somehow cooperating to the extent that they > > can share the same global ID for the CS, could they not also share > the > > same local ID for the MS? Why does it need to be a global ID? > > > > They could *know* each other's local id for the MS. > > They might even agree to use the *same* value for the local id. > > > > E.g. we have SRC#1 and SRC#2, each using 123 as the local id for the > > "same" stream. > > > > But to the SRS, there is one MS with id SRC#1:123, and another MS > with > > SRC#2:123. It does not know they are the same. (That is the point of > > local scoping.) > > > > So even though the two SRCs know they are talking about the same MS=20 > > they > > > > have no way to tell that to the SRS. > > > > Thanks, > > Paul > > > > > John > > > > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org > > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > >> Sent: 14 June 2011 16:31 > > >> To: siprec@ietf.org > > >> Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > >> > > >> John, > > >> > > >> Consider another case: two SRCs in the same CS (perhaps one at > each > > >> "end".) They are both sending metadata about the same CS and MSs. > > >> > > >> Suppose they want to cooperate with each other. They have the=20 > > >> potential to use the same ID to reference the CS, so that the SRS > > >> will know they are talking about the same one. But with > > RS-specific > > >> MS ids there is no way for them to indicate that they are talking > > >> about the same MSs. With global MS ids, they could accomplish > this. > > >> > > >> Thanks, > > >> Paul > > >> > > >> On 6/14/2011 11:03 AM, Elwell, John wrote: > > >>> Partha, > > >>> > > >>> Thanks for the examples. The character count for the delta > > >> is about 2500 when a new MS is created compared to about 2100 when > > >> the MS is retained. This seems to be in line with my previous gut > > >> feeling. > > >>> > > >>> Concerning the need for "SRS implementers to guess how old > > >> MS and new MS are related", I don't think they are > > related, except by > > > > >> having other things in common like a common participant or > > a common > > >> CSG. > > >>> > > >>> John (as individual) > > >>> > > >>>> -----Original Message----- > > >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > >>>> Sent: 14 June 2011 13:15 > > >>>> To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; > > Ram Mohan > > >>>> R (rmohanr); siprec@ietf.org > > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a > CSG? > > >>>> > > >>>> Hi all, > > >>>> > > >>>> Sorry for the delay. Just to double confirm everybody > > understanding > > > > >>>> with SIP message example, I added the example with > > creating new MS > > >>>> and reusing the same MS as an attachment with this mail. > > >>>> > > >>>> Please note that creating new MS is putting SRS > > >> implementers to guess > > >>>> how old MS and new MS are related. Also, few scenario like > > >> Even after > > >>>> looking into the example, the intention is to use local > > >> variable, I'm > > >>>> ok. > > >>>> > > >>>> Thanks > > >>>> Partha > > >>>> > > >>>> -----Original Message----- > > >>>> From: Charles Eckel (eckelcu) > > >>>> Sent: Friday, June 10, 2011 10:57 PM > > >>>> To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > >> Ram Mohan R > > >>>> (rmohanr); siprec@ietf.org > > >>>> Subject: RE: [siprec] Can an MS object span several CSs in a > CSG? > > >>>> > > >>>> Please excuse the delay. I am catching up after having > > been away on > > > > >>>> vacation. > > >>>> In light of this better understanding of the use case, I also=20 > > >>>> prefer the option favored by John and Leon to model as a > > separate > > >>>> MS. In this specific case, I would expect the properties > > of the MS > > >>>> to change when A is transferred to C, so I expect the > > overhead in > > >>>> creating > > >> a new MS vs. > > >>>> reusing the same MS to be minimal and not worth the added=20 > > >>>> complexity to the model. > > >>>> > > >>>> Cheers, > > >>>> Charles > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] > > >>>>> Sent: Tuesday, May 31, 2011 6:19 AM > > >>>>> To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > >> (eckelcu); > > >>>>> Ram Mohan R (rmohanr); siprec@ietf.org > > >>>>> Subject: RE: [siprec] Can an MS object span several CSs > > in a CSG? > > >>>>> > > >>>>> Hello > > >>>>> > > >>>>> I also having a problem even without a quantification > > of number of > > > > >>>>> update messages that CS MS is remains same between > > >>>> different CS. So I > > >>>> do prefer to keep it simple and keep it per CS. > > >>>>> > > >>>>> Leon > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > >>>>> Behalf Of Elwell, John > > >>>>> Sent: Friday, May 27, 2011 12:26 PM > > >>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > Ram Mohan R > > >>>>> (rmohanr); siprec@ietf.org > > >>>>> Subject: Re: [siprec] Can an MS object span several CSs > > in a CSG? > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > >>>>>> Sent: 26 May 2011 15:55 > > >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > > (rmohanr); > > > > >>>>>> siprec@ietf.org > > >>>>>> Subject: RE: [siprec] Can an MS object span several > > CSs in a CSG? > > >>>>>> > > >>>>>> John, > > >>>>>> > > >>>>>> The callflow mentioned by me is the basic primitive in > > the call > > >>>>>> center scenario wherein customer (participant) is same > > throughout > > > > >>>>>> the session and agents are changed using transfer service > > >>>> and B2BUA > > >>>> acts as SRC. > > >>>>>> IMO, it is one of key requirement to be considered in case we > > >>>>>> support for partial-update. > > >>>>> [JRE] Agreed the Participant remains the same, but we are > > >> discussing > > >>>> MS. > > >>>>> > > >>>>>> This may not be the only callflow where MS partial-update is=20 > > >>>>>> required in this fashion. During -00 format draft, I > > thought that > > > > >>>>>> the partial-update is not required but lot of folks raised the > > >>>>>> concern that partial update is important. Current, -01 > > >>>> format draft > > >>>>>> is designed to support partial-update. Now, You propose > > >>>> to restrict > > >>>>>> MS partial-update across CS. IMO, it is a not good idea > > >>>> to restrict > > >>>>>> in the protocol level. Anyway, I think that we need > > >>>> others opinion > > >>>>>> before conclude here. > > >>>>> [JRE] I am not opposed to partial update, but I would > > >> like to avoid > > >>>>> distorting the model just to gain some efficiency > > improvements in > > >>>>> certain cases. To me it is not intuitive that a MS on one > > >>>> CS and an MS > > >>>> > > >>>>> on another CS are the same object, just because one of the=20 > > >>>>> Participants is common to both CSs. In the > > transfer-between-agents > > >>>> example, although one of the Participants is common to > > the two CSs, > > > > >>>> this is not true for the other Participants. > > >>>>> > > >>>>> Let's try to quantify the efficiency improvement. In the blind > > >>>>> transfer case, the partial updates would at least have > > to include: > > >>>>> - the removal of P1 from CS1 (where P1 is the first agent > > >>>> and CS1 is > > >>>>> the first CS); > > >>>>> - the removal of P2 from CS1 (where P2 is the transferred=20 > > >>>>> participant); > > >>>>> - the termination of CS1; > > >>>>> - the removal of CS1 from CSG1; > > >>>>> - the creation of CS2 (the CS that results from transfer); > > >>>>> - the addition to of CS2 to CSG1; > > >>>>> - the addition of P2 to CSG1; > > >>>>> - the addition of P3 to CS2 (where P3 is the second agent); > > >>>>> - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); > > >>>>> - the removal of P2 as a recipient of MS1; > > >>>>> - the termination of MS1; > > >>>>> - the creation of MS3; > > >>>>> - the addition of P3 as a sender of MS3; > > >>>>> - the addition of P2 as a recipient of MS3. > > >>>>> > > >>>>> So all we are arguing about is whether we also include in > > >>>> the partial > > >>>>> updates EITHER (this I think is your proposal): > > >>>>> - the removal of P1 as a recipient of MS2; > > >>>>> - the addition of P3 as a recipient of MS2; > > >>>>> > > >>>>> OR > > >>>>> - the removal of P1 as recipient of MS2; > > >>>>> - the removal of P2 as a sender of MS2; > > >>>>> - the termination MS2; > > >>>>> - the creation of MS4; > > >>>>> - the addition of P3 as a recipient of MS4; > > >>>>> - the addition of P2 as a sender of MS4. > > >>>>> > > >>>>> So with the first option the total number of deltas is 14+2=3D16. > > >>>>> For the second option the total number of deltas is 14+6=3D20. > > >>>>> > > >>>>> Some of the details might be wrong, but I hope you can see > > >>>> the point I > > >>>> > > >>>>> am getting at. Looked at this way, the efficiency saving by > > >>>> recycling > > >>>>> MS2 for use in consecutive CSs is relatively small. Or > > >> perhaps your > > >>>>> intention is also to recycle MS1 (this time, the recipient > > >>>> remaining > > >>>>> the same but the sender changing). That would reduce > > the number of > > > > >>>>> deltas slightly further. The impact on XML size might not > > >>>> be quite in > > >>>>> proportion to the reduction in the number of deltas, since by > > >>>> recycling MS2 it has to have a global identifier, not an > > identifier > > > > >>>> local to a CS. Or perhaps it could have an identifier > > >> local to a CSG. > > >>>>> > > >>>>> I also see that with your proposal it doesn't force the > > MS to be > > >>>>> recycled - an SRC could still choose to model it as > > separate MSs. > > >>>>> However, in that case it would still need to use global > > >> identifiers > > >>>> for MSs. > > >>>>> > > >>>>> I am not necessarily opposed to your proposal for recycling > > >>>> MS objects > > >>>> > > >>>>> outside the context of a single CS - I can see advantages and=20 > > >>>>> disadvantages. I just want to make sure the group makes > > >> an informed > > >>>> decision. > > >>>>> > > >>>>> John (as individual) > > >>>>> > > >>>>> > > >>>>>> > > >>>>>> Enhancing label attribute across the multiple SIP > > message to tie > > >>>>>> between Metadata XML and RS SDP m-line is possible. SRC has to > > >>>>>> ensure that label for the given RS SDP m-line should have > > >>>> same label > > >>>> > > >>>>>> throughout single CSG even though it span across > > multiple CS and > > >>>>>> multiple RS. Even then, it will not meet partial-update > > >>>> requirement > > >>>>>> as mentioned below in this mail thread. At this moment, > > >>>> I'm favoring > > >>>> > > >>>>>> URN UUID and not label attribute enhancement. > > >>>>>> > > >>>>>> Please read inline > > >>>>>> > > >>>>>> Thanks > > >>>>>> Partha > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > >>>>>> Sent: Wednesday, May 25, 2011 7:17 PM > > >>>>>> To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > Ram Mohan R > > > > >>>>>> (rmohanr); siprec@ietf.org > > >>>>>> Subject: RE: [siprec] Can an MS object span several > > CSs in a CSG? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > >>>>>>> Sent: 25 May 2011 08:48 > > >>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > > >>>> (rmohanr); > > >>>>>>> siprec@ietf.org > > >>>>>>> Subject: RE: [siprec] Can an MS object span several CSs > > >>>> in a CSG? > > >>>>>>> > > >>>>>>> John, > > >>>>>>> > > >>>>>>> > > >>>> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> =3D > > >>>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA > > >>>>>>> converts REFER > > >>>>>>> > > >>>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA > > >>>>>>> updates RS > > >>>>>>>> with CS2, Participant1 as A& participant2 as C, > > >>>> MS1(A's media > > >>>>>>>> stream), MS2(C's media stream). There is no update on RS1, > > >>>>>>> CSG1, MS1, > > >>>>>>>> MS2. MS2 will become MS2 with the new association and > > >>>> in terms > > >>>>>>>> of format, it will associate with tag > > >>>>>>> [JRE] What harm is done (what do we lose) if, following > > >>>>>> transfer, A's > > >>>>>>> media stream is called MS3 and C's media stream is called > MS4? > > >>>>>>> > > >>>>>> > > >>>> > > >> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>> =3D > > >>>>>>> To indicate MS1 as MS3, MS1 media block has to be > > >>>>>> stopped in > > >>>>>>> the partial-update and start MS3 separate which is not > > >>>> required in > > >>>> > > >>>>>>> case there is a means to have common MS1. > > >>>>>> [JRE] It seems this distorts the model in order to give > > >>>> some minor > > >>>>>> efficiency improvement during metadata updates. I > > doubt that this > > > > >>>>>> alone is sufficient justification for having the MS > > >>>> persist from one > > >>>> > > >>>>>> CS to another CS. > > >>>>>> > > >>>>>>> > > >>>>>>> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> MS3 can reference the same SDP m-line (through > > a=3Dlabel) as MS1, > > >>>>>>> and likewise MS4 could reference the same SDP m-line as > > >>>> MS2, if we > > >>>> > > >>>>>>> are concerned about recycling media descriptions in RS SDP. > > >>>>>>> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>> As you mentioned, we will lose recycling of media > > >>>>>> description > > >>>>>>> in RS SDP without common value in media stream object > > for this > > >>>>>>> scenario. > > >>>>>> [JRE] I don't understand your point. With my proposal we > > >>>> can still > > >>>>>> recycle RS SDP m-lines. > > >>>>>> > > >>>>>> Agreed that Recycle is possible with your proposal. > > >>>>>> I indicated > > >>>>>> the need for unique-id in this requirement > > >>>>>> > > >>>>>>> AFAIK, Your proposal needs enhancement in RFC 4574 as label > > >>>>>> attribute > > >>>>>>> scope is within single SIP message and not required to > > >>>> be unique > > >>>>>>> in all SIP messages of a given dialog. > > >>>>>> [JRE] But I think we could nail that down as a > > requirement of the > > > > >>>>>> SIPREC protocol. > > >>>>>> > > >>>>>> John (as individual) > > >>>>>> > > >>>>>>> > > >>>>>>> Thanks > > >>>>>>> Partha > > >>>>>>> > > >>>>>>> John (as individual) > > >>>>>>> > > >>>>>>>> > > >>>>>>>> Thanks > > >>>>>>>> Partha > > >>>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Charles Eckel (eckelcu) > > >>>>>>>> Sent: Wednesday, May 25, 2011 1:39 AM > > >>>>>>>> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); > > >>>>>> 'Elwell, John'; > > >>>>>>>> 'siprec@ietf.org' > > >>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs in a > > >>>> CSG? > > >>>>>>>> > > >>>>>>>> Hi Ram, > > >>>>>>>> > > >>>>>>>> I think that is many cases, they will be treated as > > >>>> separate MSs > > >>>> > > >>>>>>>> due to the complexities you mention. However, I am trying to > > >>>>>> understand if > > >>>>>>>> Partha feels allowing an SRC to treat them as a single MS is > > >>>>>>>> still required. If not, then what is a use case? A concrete > > >>>>>>>> example would help me, and potentially others, to better=20 > > >>>>>>>> understand the > > >>>>>>> motivation behind > > >>>>>>>> Partha's requirement for modeling media from multiple CSs > > >>>>>>> as a single > > >>>>>>>> MS. > > >>>>>>>> > > >>>>>>>> Cheers, > > >>>>>>>> Charles > > >>>>>>>> > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: Ram Mohan R (rmohanr) > > >>>>>>>>> Sent: Tuesday, May 24, 2011 9:36 AM > > >>>>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > >>>>>>> Elwell, John; > > >>>>>>>>> siprec@ietf.org > > >>>>>>>>> Subject: RE: [siprec] Can an MS object span several CSs > > >>>>>> in a CSG? > > >>>>>>>>> > > >>>>>>>>> Charles, > > >>>>>>>>> > > >>>>>>>>> I did bring about this specific usecase of MMOH/MOH > > >>>>>> stream being > > >>>>>>>>> played to different participants earlier and suggested that > > >>>>>>>> they have > > >>>>>>>>> to treated as a same MS across multiple CSs > > >>>>>> (potentially recorded > > >>>>>>>> using multiple RSs). > > >>>>>>>>> Refer > > >>>>>>>>> > > >>>>>> > > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > > >>>>>>>>> > > >>>>>>>>> We had several discussions on it and it and several > > >>>>>> folks were in > > >>>>>>>>> favor of treating it as separate MS as there would be > > >>>>>>>> complexity in DB > > >>>>>>>> design. > > >>>>>>>>> > > >>>>>>>>> Regards, > > >>>>>>>>> Ram > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> -----Original Message----- > > >>>>>>>>>> From: siprec-bounces@ietf.org > > >>>>>>> [mailto:siprec-bounces@ietf.org] On > > >>>>>>>>>> Behalf Of Charles Eckel (eckelcu) > > >>>>>>>>>> Sent: Tuesday, May 24, 2011 9:11 PM > > >>>>>>>>>> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > >>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > > >>>>>>> in a CSG? > > >>>>>>>>>> > > >>>>>>>>>> Hi Partha, > > >>>>>>>>>> > > >>>>>>>>>> Is an example of this the same music on hold audio stream > > >>>>>>>> existing > > >>>>>>>>>> as the same MS within multiple CSs? If so, then I > > >>>>>>> understand your > > >>>>>>>>>> requirement to be that the SRC be able to > > >>>> indicate multiple > > >>>>>>>>>> instances of this audio stream within several CSs as > > >>>>>>>> being the same > > >>>>>>>>>> MS. Is that correct? > > >>>>>>>>>> > > >>>>>>>>>> Thanks, > > >>>>>>>>>> Charles > > >>>>>>>>>> > > >>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>> From: siprec-bounces@ietf.org > > >>>>>>>> [mailto:siprec-bounces@ietf.org] On > > >>>>>>>>>> Behalf Of Parthasarathi R (partr) > > >>>>>>>>>>> Sent: Tuesday, May 24, 2011 4:26 AM > > >>>>>>>>>>> To: Elwell, John; siprec@ietf.org > > >>>>>>>>>>> Subject: Re: [siprec] Can an MS object span several CSs > > >>>>>>>> in a CSG? > > >>>>>>>>>>> > > >>>>>>>>>>> John, > > >>>>>>>>>>> > > >>>>>>>>>>> I agree that it is not mandatory to consider recorded > > >>>>>>>> stream of a > > >>>>>>>>>>> specific participant in several CS within the same > > >>>>>> CSG as one > > >>>>>>>>>> recorded > > >>>>>>>>>>> stream but SIPREC protocol design MUST NOT restrict a > > >>>>>>>> SRC in case > > >>>>>>>>>>> it wishes to design in such a way. > > >>>>>>>>>>> > > >>>>>>>>>>> Thanks > > >>>>>>>>>>> Partha > > >>>>>>>>>>> > > >>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>> From: siprec-bounces@ietf.org > > >>>>>>>> [mailto:siprec-bounces@ietf.org] On > > >>>>>>>>>> Behalf > > >>>>>>>>>>> Of Elwell, John > > >>>>>>>>>>> Sent: Tuesday, May 24, 2011 1:06 PM > > >>>>>>>>>>> To: siprec@ietf.org > > >>>>>>>>>>> Subject: [siprec] Can an MS object span several CSs > > >>>>>> in a CSG? > > >>>>>>>>>>> > > >>>>>>>>>>> We seem to have consensus that a Media Stream object > > >>>>>>>> represents a > > >>>>>>>>>>> recorded media stream, contributed to by one, > > >>>>>> several or all > > >>>>>>>>>>> Participants. However, Partha also wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> "2) Each MS lifetime related to CSG because participant > > >>>>>>>> may move > > >>>>>>>>>>> from one CS to another CS within single CSG and also > > >>>>>>>> CSG will span > > >>>>>>>> > > >>>>>>>>>>> across multiple RS." > > >>>>>>>>>>> > > >>>>>>>>>>> I am not sure we had resolved this during earlier > > >>>>>>>> discussions on > > >>>>>>>>>>> the scope of an MS object. Although the same > > >>>>>> Participant can > > >>>>>>>>>>> participate > > >>>>>>>>>> in > > >>>>>>>>>>> several CSs within the same CSG, I don't think the > > >>>>>>>> recorded media > > >>>>>>>>>>> streams need to be considered the same. Any other views? > > >>>>>>>>>>> > > >>>>>>>>>>> John (as individual) > > >>>>>>>>>>> _______________________________________________ > > >>>>>>>>>>> siprec mailing list > > >>>>>>>>>>> siprec@ietf.org > > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>>>>>>>>> _______________________________________________ > > >>>>>>>>>>> siprec mailing list > > >>>>>>>>>>> siprec@ietf.org > > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>>>>>>>> _______________________________________________ > > >>>>>>>>>> siprec mailing list > > >>>>>>>>>> siprec@ietf.org > > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> _______________________________________________ > > >>>>> siprec mailing list > > >>>>> siprec@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>> > > >>> _______________________________________________ > > >>> siprec mailing list > > >>> siprec@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/siprec > > >>> > > >> _______________________________________________ > > >> siprec mailing list > > >> siprec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/siprec > > >> > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > -------------------------------------------------------------- > > ---------- > > ------------------------------------------- > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may > contain > > confidential and proprietary information of Alcatel-Lucent and/or its > > affiliated entities. Access by the intended recipient only is=20 > > authorized. Any liability arising from any party acting, or > refraining > > from acting, on any information contained in this e-mail is hereby=20 > > excluded. If you are not the intended recipient, please notify the=20 > > sender immediately, destroy the original transmission and its=20 > > attachments and do not disclose the contents to any other person,=20 > > use it for any purpose, or store or copy the information in any=20 > > medium. > > Copyright in this e-mail and any attachments belongs to Alcatel- > Lucent > > and/or its affiliated entities. > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > =09 ------------------------------------------------------------------------ ------------------------------------------- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. =09 From partr@cisco.com Thu Jun 23 01:45:09 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8263511E80B9 for ; Thu, 23 Jun 2011 01:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.428 X-Spam-Level: X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+UsMU8TXos8 for ; Thu, 23 Jun 2011 01:45:08 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA8E11E80B5 for ; Thu, 23 Jun 2011 01:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=6699; q=dns/txt; s=iport; t=1308818708; x=1310028308; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=zG3io87tgxaFpHrq1Ne1fuGKlanXqWNPvkH6OoNi0Ng=; b=YJYj8kBGDPiOH/GDEsJ7/w3ejE+w5upLFF2DVEtD0L0tfkASmLHVpn2s XJIw0b/NhME0TjLa9d5dDrUaQC4A3D48+sC8/0dK6e3VYROv6hbWXv3xQ /1XIITr1jBbnLrtl7SZOOUKRRRLS1styrM0hE/GC8TbzCLyKhQVu+/k7k Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8BALn7Ak5Io8US/2dsb2JhbABGDZgEjxp3iHOibp4sgyCDDQSHJI88iyg X-IronPort-AV: E=Sophos;i="4.65,412,1304294400"; d="scan'208";a="37604829" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 23 Jun 2011 08:45:06 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5N8j4BX003396; Thu, 23 Jun 2011 08:45:04 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 14:15:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jun 2011 14:15:06 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Adoption of material from draft-ram-siprec-metadata-format-02 Thread-Index: Acwvc9GH9M8y1vuZSxq3cub71esM/gAfP5LgABAu1WAAU0E7gA== References: <4DFF8A82.3000809@cisco.com><07465C1D981ABC41A344374066AE1A2C38AF5C8E38@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Leon Portman" , "Paul Kyzivat (pkyzivat)" , , "Charles Eckel (eckelcu)" , "Elwell, John" X-OriginalArrivalTime: 23 Jun 2011 08:45:04.0913 (UTC) FILETIME=[D90FB810:01CC3181] Subject: Re: [siprec] Adoption of material from draft-ram-siprec-metadata-format-02 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 08:45:09 -0000 Hi all, I haven't seen any closure for the below mail. In that scenario, it is an (re-)open item in SIPREC architecture. In case lot of folks interested in non-SIP (generic) based metadata passing mechanism, Let us discuss in detail during today's Interim meeting and take an approach to move forward. Also, draft-ram-siprec-metadata-format is designed with the assumption that SIP will be used for passing metadata approach. BTW, there was analyze on using "REST" XML approach for metadata passing which will be more suitable for HTTP based interfaces but it is an overkill for SIP based mechanism. It was highlighted in Slide-11 of draft-ram-siprec-metadata-format presentation in IETF-80 (www.ietf.org/proceedings/80/slides/siprec-1.ppt).=20 Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Tuesday, June 21, 2011 10:22 PM To: Leon Portman; Paul Kyzivat (pkyzivat); siprec@ietf.org Subject: Re: [siprec] Adoptionofmaterial fromdraft-ram-siprec-metadata-format-02 Hi all, I have raised non-SIP (HTTP, XMPP) mechanism for metadata as an open item in SIPREC architecture document before IETF-80. The related link is as follows: http://www.ietf.org/mail-archive/web/siprec/current/msg01608.html. The conclusion of IETF-80 SIPREC meeting is to use SIP as a mechanism which is discussed at slide-7 of SIPREC architecture (www.ietf.org/proceedings/80/slides/siprec-2.ppt). I attached the specific slide content and notes of the meeting for your reference. Thanks Partha Note: Slide contents: 01 draft states some examples of how metadata could be delivered to the SRC SIP Headers.=20 SDP. Event Package. INFO Package. Non SIP Means. Proposal - We seem to be converging on using INVITE/UPDATE on the RS Dialog so state this. Keep non SIP means although outside SIPREC scope. Conclusion in IETF-80: Proposal: List INVITE/UPDATE + non-SIP means only for metadata delivery? Hadriel Kaplan: Agrees, but don't mention specific methods (e.g. INVITE/UPDATE) Keith Drage: Clarified that this repeats stuff in the protocol document=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: Tuesday, June 21, 2011 2:32 PM To: Paul Kyzivat (pkyzivat); siprec@ietf.org Subject: Re: [siprec] Adoptionof material fromdraft-ram-siprec-metadata-format-02 Actually we had lot of discussion about this issue (metadata over SIP or over dedicated web service/HTTP) both internally and with partners. Main advantages (what I remember ) for SIP approach are as follows: 1. Simplicity, only one interface to implement, troubleshoot, secure and configure between SRC and SRS 2. RS SIP request is self-contained, it includes all relevant info in order to SRS to decide how to do recording . For example participants identity, location. So no need for SRS to correlate different messages from different interfaces 3. Footprint on SRC. For some implementation it is not feasible to have both SIP and HTTP stacks Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, June 20, 2011 9:00 PM To: siprec@ietf.org Subject: Re: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02 Charles, IIRC, the major driving forces were timeliness and synchronicity of metadata with the actual signaling, especially when initially establishing a RS, so that suitable decisions can be made about whether to record a session, etc. AFAIK the avoidance of an HTTP server in the SRS wasn't a concern. (Its assumed in general to be a very capable box, and probably has an HTTP interface for querying, though that is out of our scope for now.) Avoiding an http client in the src might be slightly more significant, but I don't think that was much of a concern either. Could we have skinned this cat with an http approach? Probably. Obviously we had a lot more sip expertise than http expertise in the group. That may have been an influence as well. Thanks, Paul On 6/20/2011 11:40 AM, Charles Eckel (eckelcu) wrote: > Hi John, > > One general comment/question I have received from web application=20 > savvy coworkers with whom I have discussed the contents of this draft=20 > is that the metadata is essentially a document and HTTP already has=20 > well defined mechanisms for document sharing and updating, so why not=20 > exchange an HTTP address for the document and leverage those=20 > mechanisms instead of sending all the metadata within SIP messages. My > assumption is that the requirement is to have a SIP based solutions=20 > that does not require an HTTP server. Is that accurate? > > Thanks, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John >> Sent: Monday, June 20, 2011 4:02 AM >> To: siprec@ietf.org >> Subject: [siprec] Adoption of material > fromdraft-ram-siprec-metadata-format-02 >> >> Although there are some open issues, to be discussed during=20 >> Thursday's > call, I would like the WG to >> consider whether material in draft-ram-siprec-metadata-format-02 is > ready for adoption into draft- >> ietf-siprec-metadata, i.e., bring it under WG control. In particular, > between now and the call, please >> consider whether: >> - the material is heading roughly in an acceptable direction; >> - there are any issues that really should be closed before adoption; >> - there are any aspects of the draft that should not be adopted at > this time. >> >> If, on the call or shortly afterwards, we can agree on adoption, the > authors of the two drafts would >> be asked to perform a merger and publish a new version of > draft-ietf-siprec-metadata before the cut- >> off for IETF#81 (2011-07-11). >> >> John >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Fri Jun 24 02:42:30 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E0921F8598 for ; Fri, 24 Jun 2011 02:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1HxktnDlGk4 for ; Fri, 24 Jun 2011 02:42:30 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 9CA0521F8592 for ; Fri, 24 Jun 2011 02:42:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1308908548!9929122!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 8161 invoked from network); 24 Jun 2011 09:42:28 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-3.tower-182.messagelabs.com with SMTP; 24 Jun 2011 09:42:28 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 347B923F03E2 for ; Fri, 24 Jun 2011 11:42:28 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 24 Jun 2011 11:42:28 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 24 Jun 2011 11:42:26 +0200 Thread-Topic: Adoption of material from draft-ram-siprec-metadata-format-02 Thread-Index: AcwvOXaZg+4+wDzBQu2PC/LOxWkIwADGO23Q Message-ID: Keywords: SIPREC 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: [siprec] Adoption of material from draft-ram-siprec-metadata-format-02 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 09:42:30 -0000 On yesterday's call there was no objection to adopting the material from me= tadata-format-02 (updated in line with agreements at the meeting) into draf= t-ietf-siprec-metadata. Also there has not been any objection on the list. = So please raise any concerns THIS WEEK. On Monday I intend to instruct the = authors of the two drafts to commence the merger. John > -----Original Message----- > From: Elwell, John=20 > Sent: 20 June 2011 12:02 > To: siprec@ietf.org > Subject: Adoption of material from draft-ram-siprec-metadata-format-02 >=20 > Although there are some open issues, to be discussed during=20 > Thursday's call, I would like the WG to consider whether=20 > material in draft-ram-siprec-metadata-format-02 is ready for=20 > adoption into draft-ietf-siprec-metadata, i.e., bring it=20 > under WG control. In particular, between now and the call,=20 > please consider whether: > - the material is heading roughly in an acceptable direction; > - there are any issues that really should be closed before adoption; > - there are any aspects of the draft that should not be=20 > adopted at this time. >=20 > If, on the call or shortly afterwards, we can agree on=20 > adoption, the authors of the two drafts would be asked to=20 > perform a merger and publish a new version of=20 > draft-ietf-siprec-metadata before the cut-off for IETF#81=20 > (2011-07-11). >=20 > John= From john.elwell@siemens-enterprise.com Fri Jun 24 02:55:10 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCDE11E8089 for ; Fri, 24 Jun 2011 02:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.968 X-Spam-Level: X-Spam-Status: No, score=-105.968 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAjz5h956Q0m for ; Fri, 24 Jun 2011 02:55:09 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id E0CCD11E8081 for ; Fri, 24 Jun 2011 02:55:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1308909285!48218808!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 30375 invoked from network); 24 Jun 2011 09:54:45 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-21.messagelabs.com with SMTP; 24 Jun 2011 09:54:45 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 52FA81EB83ED for ; Fri, 24 Jun 2011 11:55:07 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 24 Jun 2011 11:55:07 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 24 Jun 2011 11:55:06 +0200 Thread-Topic: Minutes Thread-Index: AcwyVMusGWXwsJTfQFGRCcWFRAOteg== 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: [siprec] Minutes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 09:55:10 -0000 Below are the draft minutes from yesterday. Also on the Wiki, along with th= e recording: http://trac.tools.ietf.org/wg/siprec/trac/wiki/WikiStart Please let me have any corrections by 2011-07-07. John #### Minutes of the SIPREC WG Interim Virtual Meeting 2011-06-23, 13.00-14.00 GMT/UTC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting chaired by Brian Rosen and John Elwell. Participants: Brian Rosen, John Elwell, Ken Rehor, Leon Portman, Henry Lum,= Ram Mohan, Andy Hutton, Paul Kyzivat, Parthasarathi, Dan Romascanu, Charle= s Eckel, Cullen Jennings Minutes produced by John Elwell based on notes from Charles Eckel. Jabber log: There was no Jabber activity. Recording: https://workgreen.webex.com/workgreen/ldr.php?AT=3Dpb&SP=3DMC&rI= D=3D10441082&rKey=3Da52c98b76fc9f083=20 Meeting started at 13.05 GMT. Topic - Administrivia (chairs) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart= /SIPREC_Chairs_20110623.ppt=20 There were no changes to the published agenda, except for allowing Charles = a brief slot at the end on draft-eckel-siprec-rtp-rec-00. Topic - Protocol (Henry Lum) draft-portman-siprec-protocol-04 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart= /SIPREC%20Protocol%20-%20Virtual%20Interim%20-%2020110623.ppt Slide 3: Referring to the removal of INFO, authors to scrub document for st= ray references to INFO, including occurrences in figures. Slide 5: On the recording SDP attribute, it was clarified that this is just= declarative. Cullen thought more is needed. For example, if a B2BUA needs = to indicate recording, it would need to send an SDP offer in each direction= . Also, does it mean media being sent or media being received is being reco= rded, or both? Cullen will send comments to the list. Also Paul mentioned t= he case of two separate SRCs on the CS path - a user may need to know which= SRC, e.g., own or other party's. Again this comment should be raised and d= iscussed on the list. Slide 6: On the recordpref SDP attribute, it was noted that this would need= to be in an offer. There had been a question on the list concerning whethe= r a "no preference" value should be added, or whether this is to be conside= red the default if the atttribute is not present. Paul was doubtful, partic= ularly for the case of non SIPREC-aware UAs. The authors should refresh the= list discussion. Henry asked whether people are happy with this mechanism for expressing re= cording preference? That was the past decision (from Prague). No views were= expressed to the contrary. Slide 7: On the option tag, Cullen stressed the need for us, in accordance = with our charter, to specify that the user must be notified, regardless of = whether the UA has expressed support for this option. There was discussion = as to whether the sending of a recording SDP attribute to a UA that has ind= icated support for this option is sufficient to replace any in-band notific= ation of recording. In other words, whether a UA is obliged to use receipt = of such a notification to render an appropriate indication to the user (inc= luding a PSTN gateway UA, which would need to send an in-band tone or annou= ncement to the PSTN). The authors should follow this up on the list, to get= the right text. Slide 8: Concerning the nature of a snapshot request, Charles thought this = could be just a simple request, with no parameters. The discussion seemed t= o lean towards something in the header, rather than in the body. To be cont= inued on the list. Slide 9: The WG is not yet in a position to adopt this draft, in particular= because information on RTP needs to be added (see last agenda item). The i= ssues raised today need to be followed up, and perhaps the next revision wi= ll be ready for adoption. Topic - Metadata model(Ram Mohan) draft-ietf-siprec-metadata-01 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart= /SIPREC%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx Side 5: On the issue of whether a CSG element needs a start/stop time, Ram = explained that the information could be derived from the start/stop times o= f the CSs that form part of that group (although he was concerned about the= complications of overlapping CSs), or could be explicitly indicated for th= e group. Leon and John thought that implicit should be sufficient. Partha t= ried to express a point concerning termination of a CSG, but this needs to = be raised on the list. Slide 6: The question is whether an MS needs a global ID or an ID local to = a CS. This depends on whether an MS can have a lifetime outside that of a s= ingle CS. Henry and Leon were fine with a global ID, but were somewhat unco= mfortable with an MS having an extended lifetime. Paul and Ram described si= tuations where the same MS would be recorded from two different SRCs or for= two different CSs, and one example would be a multicast stream such as mus= ic on hold played to two or more CSs at the same time - labelling it as the= same MS might avoid having to store the recording twice. Leon asked whethe= r the fact that the two MSs come from the same Participant would be suffici= ent to imply they are the same MS, but others doubted that would be the cas= e, particularly for automata. After much discussion, John asked whether people could live with making the= identifier global, notwithstanding the fact that we don't see any likely c= ases where an MS would have a lifetime beyond a single CS. This would leave= the door open for an MS to have an extended lifetime for any corner cases = that arise in the future. The meeting seemed to be in agreement with this. = John will put out a consensus call on the list. Slide 7: On the question of how to describe the content of an MS, there was= no objection to basing this on the types in the RFC 4796 registry (new val= ues could be specified via the appropriate means if needed). Paul had a sli= ght concern that you might be mixing multiple CS MSs into a single RS media= stream and whether this might result in cases not describable in this way,= but in the end accepted the consensus. It needs to be discussed on the lis= t whether this is conveyed in XML or in the RS SDP a=3Dcontent attribute. Slide 8: Concerning Participant lifetime and start/stop times, it was felt= that considerations are similar to those for CSG, so likewise this needs t= o be taken to the list. Topic - Metadata format(Parthasarasi R) draft-ram-siprec-metadata-format-02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata-format/ Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart= /SIPREC%20Metamodel%20Format-Interim-Jun23-2011.ppt Charles had raised on the list the question of whether consideration had be= en given to non-SIP means (e.g., HTTP) of transporting metadata. It was exp= lained that the issue had been discussed in the past and had been closed. C= harles stated that he accepted the past agreements and understands the reas= ons. Slide 6: Concerning MS unique ID, discussions on the metadata model draft h= ad already led to agreement that this needs to be global. This leaves the q= uestion of format. Similar considerations apply to all elements that requir= e a unique ID. Paul explained that it could, for example, be a UUID but not= necessarily in URN format. Or it could be a URN, without specifying conten= t. Specifying a UUID limits the size, at the cost of constraining things in= the future. Specifying just a URN is very flexible but does not limit the = size. This needs to be brought to the list. Slide 7: Participant ID is the same issue. Paul says we don't HAVE TO use t= he same for each element type, but would need good justification for being = different. Charles pointed out push-back at IETF80, concerning implications= for back-end systems, and perhaps we don't need to specify it in too much = detail. But Paul was of the opinion that keeping things open actually makes= things more difficult for the SRS to map to whatever scheme is used in the= back-end, and might force use of a mapping table rather than algorithmic m= eans. Brian asked about other URN forms that might be candidates. Partha wi= ll propose some options and identify pros and cons on the list. Slide 8: Concerning extension data, Leon wants this to be part of the paren= t element, not a separate element. After some discussion, there was no obje= ction to making extension data part of the parent element (e.g., if extensi= on data relates to a CS element, it would be part of the CS element). Slide 9: The issue of a unique ID for extension data can be closed as a res= ult of the decision above. Slide 10: There was no time for discussion of codec parameters in stream el= ements - to continue on list. Slide 11: John had already put out a call for adoption of the metadata form= at material from this draft into the WG metadata draft. The only list comme= nt to date had been addressed, and there were no objections at the meeting.= John will get this confirmed on the list in the next few days and ask the = authors of the two drafts to work on the next revision of draft-ietf-siprec= -metadata with the format material (updated in accordance with today's disc= ussions) incorporated. This should be available, if possible, before the cu= t-off date (2011-07-11). Topic - RTP Model (Charles Eckel) draft-eckel-siprec-rtp-rec-00 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-eckel-siprec-rtp-rec/ Slides: none There had been only limited discussion on the list, and so far there had be= en no input from AVTCORE members, who had been invited to comment. There wa= s agreement in the meeting that it is heading in the right direction. Howev= er, it needs greater scrutiny, and Charles asked that in particular people = should look at Section 4o on roles. Wrap-up =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D The meeting was closed at 14.55 GMT. = From john.elwell@siemens-enterprise.com Fri Jun 24 02:58:25 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA75111E81BB for ; Fri, 24 Jun 2011 02:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn0cO9i4Mf8G for ; Fri, 24 Jun 2011 02:58:25 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id C5DD411E8089 for ; Fri, 24 Jun 2011 02:58:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1308909503!22560637!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 12429 invoked from network); 24 Jun 2011 09:58:23 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-12.tower-174.messagelabs.com with SMTP; 24 Jun 2011 09:58:23 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 6FB551EB83ED for ; Fri, 24 Jun 2011 11:58:23 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 24 Jun 2011 11:58:23 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 24 Jun 2011 11:58:21 +0200 Thread-Topic: Consensus calls arising from interim meeting - closes 2011-06-30 Thread-Index: AcwyVUA12HIIy9OESf+IyDInOZp1ZQ== 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: [siprec] Consensus calls arising from interim meeting - closes 2011-06-30 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 09:58:25 -0000 On yesterday's call there was consensus on a number of items. These need to= be confirmed. Please say by 2011-06-30 if you object to any of the followi= ng: 1. We will use a globally unique identifier for a MS object. Although some = people felt that an MS would not normally have a lifetime outside the lifet= ime of a CS, and therefore a local ID might suffice, some felt that there m= ight be some corner cases that might benefit from a global ID. So the conse= nsus on the call was for a global ID, although most anticipated uses of an = MS element would be in the context of a single CS. Note that the nature of = the globally unique ID is still open. 2. The content of an MS object will be described in terms of value from the= RFC 4796 registry. Note that how this is conveyed (in metadata XML or in R= S SDP) is still open. Note also that if additional values are found to be n= ecessary, these could be defined by the appropriate means. 3. Extension data will be made part of the parent element, and not a separa= te element. Therefore it will not require its own unique ID. John = From john.elwell@siemens-enterprise.com Fri Jun 24 02:58:45 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561F511E81C5 for ; Fri, 24 Jun 2011 02:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJKWHxO8OpVb for ; Fri, 24 Jun 2011 02:58:44 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 67EA611E8089 for ; Fri, 24 Jun 2011 02:58:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1308909523!21128801!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 12910 invoked from network); 24 Jun 2011 09:58:43 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-174.messagelabs.com with SMTP; 24 Jun 2011 09:58:43 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 7014E1EB83EE for ; Fri, 24 Jun 2011 11:58:43 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 24 Jun 2011 11:58:43 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 24 Jun 2011 11:58:42 +0200 Thread-Topic: Items needing more discussion Thread-Index: AcwyVUyKbLXV9ErQSgqeX+UiHu1VQA== 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: [siprec] Items needing more discussion X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 09:58:45 -0000 >From yesterday's meeting, the following items need to be brought to the lis= t or continued on the list: Protocol: - Usage of the SDP recording attribute in offer/answer (raised by Cullen) - Meaning of the SDP recording attribute (applicable to sending, receiving = or both) (raised by Cullen) - Impact on the SDP recording attribute of two SRCs on the CS path (raised = by Paul) - The need for a no preference value for the recordpref SDP attribute, and = the default value of that attribute (old discussion needs reviving) - Obligations of a UA that indicates Supported: record-aware, e.g., whether= a UA is obliged to provide some form of indication to the user when it rec= eives the recording SDP attribute (e.g., a PSTN gateway would need to provi= de an in-band tone or announcement). - Text needed on mandating that participants be notified of recording. - What to put in the message header to indicate that a snapshot is request. Metadata model: - The need for an explicit start and stop time in a CSG element (in particu= lar Partha had a concern). - The need for an explicit start and stop time in a Participant element. Metadata format: - Options for globally unique IDs, along with pros and cons (Partha to init= iate) - Codec parameters in stream elements (issues on metadata format slide 10). RTP - Continue discussion on draft-eckel-siprec-rtp-rec-00, with particular att= ention to Section 4 on roles. Documents authors should kick-off these discussions. John From pkyzivat@cisco.com Fri Jun 24 07:37:53 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C752A21F853A for ; Fri, 24 Jun 2011 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.446 X-Spam-Level: X-Spam-Status: No, score=-110.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mgyhhz6FaGk for ; Fri, 24 Jun 2011 07:37:53 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2B06121F8539 for ; Fri, 24 Jun 2011 07:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2608; q=dns/txt; s=iport; t=1308926273; x=1310135873; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=t/DCVJDZVv+MQmKPpAFS39EoPAq+Z1vUZrYi7vIJ5rc=; b=VCk0aaThAiQL8e95JPo23qHDmSEziAKDsbknu7zSQ59Kny6xaeVeLXcG RUwTomp6kBxF/umftUASuokLmTUdh+QtvbAC60nTzyhrgtADaigGR8twj VqdaAwHMn+e8RHWAKWyp0AETXn/SOrOI7iuGqsbhwtLv8n47iDkFfef5G w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooIABGgBE6tJXHA/2dsb2JhbABSmFSOYnesVJ4Rhi0EkXuEaItG X-IronPort-AV: E=Sophos;i="4.65,419,1304294400"; d="scan'208";a="238181450" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-2.cisco.com with ESMTP; 24 Jun 2011 14:37:52 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p5OEbpwi002481 for ; Fri, 24 Jun 2011 14:37:52 GMT Message-ID: <4E04A13F.8090506@cisco.com> Date: Fri, 24 Jun 2011 10:37:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [siprec] Format options for unique IDs X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 14:37:53 -0000 On 6/24/2011 5:58 AM, Elwell, John wrote: > - Options for globally unique IDs, along with pros and cons (Partha to initiate) I'm not Partha, but I'll comment. Some possibilities: A) A generic URN, with added constraint that equality is based only on lexical equivalence (as defined in rfc 2141) B) UUID URN (rfc 4122) C) UUID encoded more densely than the UUID URN (e.g. radix64 of the binary uuid form defined in 4122) Pros/cons of these: A) Pro: very flexible for the SRC. It has many options for how to create and encode IDs. Pro: ease of generation, assuming the SRC chooses wisely. Con: Difficult for the SRS. It must deal with variable unbounded length ID. Doesn't easily fit in databases. Con: Somewhat inefficient wire encoding: there is minimum length of "URN:" plus NID (namespace identifier). Pro/Con: Wire efficiency varies depending on SRC choices. Could be very good or very bad, depending on what NID is chosen. B) Pro: very flexible for the SRC. 4122 provides multiple ways of generating the UUID. One of them (the name based one) would allow generating a UUID from the same strings you might use for (A), so its at least as flexible as (A). Pro: easy of generation. Like (A), but then requires an SHA-1 computation. So not as easy as (A). Pro: Simple for SRS. The UUID can be easily extracted from the URN and converted to a fixed length (16 bytes) binary value. That value then can be stored in databases, compared, etc. Con: Somewhat inefficient wire encoding. The urn encoding is 45 bytes. Pro: Flexible to future extension to other sorts of URNs (e.g. (A)) due to the use of the URN syntax. C) Pro: very flexible for the SRC. (Identical to (B)) Pro: easy of generation. Virtually the same as (B). (The final textual formatting is different from (B), but similar (insignificant) computationally.) Pro: Simple for SRS. Virtually the same as (B). (The final textual formatting is different from (B), but similar (insignificant) computationally.) Pro: Efficient wire encoding. (Radix 64 takes 22 bytes to represent the 16 binary bytes.) For the metadata these would probably all be wrapped in XML in comparable ways, so none has an advantage over another in that respect. Please feel free to propose other alternatives. As a specific example, for the UUIDs, one could use the 4122 "name based" approach, where the "name" is just a binary integer counter. Thanks, Paul From partr@cisco.com Sun Jun 26 23:07:10 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8358C21F85B1 for ; Sun, 26 Jun 2011 23:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.584 X-Spam-Level: X-Spam-Status: No, score=-7.584 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OPI+Z4DmbPs for ; Sun, 26 Jun 2011 23:07:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2727421F85B3 for ; Sun, 26 Jun 2011 23:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=5880; q=dns/txt; s=iport; t=1309154829; x=1310364429; h=mime-version:subject:date:message-id:from:to:cc; bh=TU7zjkkyCNmg4X97Wb0ogILMqoGG1GWdrPmOhjnGvTs=; b=X5S65bwS6xaAi99DdTgIotePF6AQrLBKHkJlhpRf9yA4E3e4wzVS+hN0 OPsNpff4rvA/v1jkoEiSxXnqZH14hsTtJ5cnm3eXRBo3iPf/996rh6ZIb MYG3fKYwtmvKz33oppb7ZchdSjtTk4Qc2Sv1Y5ysyVPKCBumL75wFJctX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL8dCE5Io8US/2dsb2JhbABSp0N3qVadLIYwBIcqj1CLLA X-IronPort-AV: E=Sophos;i="4.65,431,1304294400"; d="scan'208,217";a="98303546" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 27 Jun 2011 06:07:07 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5R6750e026268; Mon, 27 Jun 2011 06:07:05 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 11:37:05 +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_01CC3490.7073923E" Date: Mon, 27 Jun 2011 11:36:58 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CSG start & stop time attribute requirement Thread-Index: Acw0kGxvAtp8hudRQFqbSwPv+BTXsQ== From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 27 Jun 2011 06:07:05.0897 (UTC) FILETIME=[70C7A990:01CC3490] Subject: [siprec] CSG start & stop time attribute requirement X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 06:07:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3490.7073923E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, =20 As per interim meeting, there is a need to explain the reason for having start/stop time in CSG group. Two reasons for having this attribute: =20 1) BYE will serve the purpose in case CSG is within single RS or ending at the end of some RS. In case CSG is terminated in the middle of RS session (persistent session), there is a need of an attribute. As it is middle of the RS, it is better to have the exact time. =20 2) In case partial-update of metadata format, there is an need of XML element to indicate the termination of CSG ("group") element. It shall be achieved by "stop-time" element within CSG. =20 Thanks Partha =20 Note: Topic - Metadata model(Ram Mohan) draft-ietf-siprec-metadata-01 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ =20 Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart/SIPR EC%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx =20 Side 5: On the issue of whether a CSG element needs a start/stop time, Ram explained that the information could be derived from the start/stop times of the CSs that form part of that group (although he was concerned about the complications of overlapping CSs), or could be explicitly indicated for the group. Leon and John thought that implicit should be sufficient. Partha tried to express a point concerning termination of a CSG, but this needs to be raised on the list. ------_=_NextPart_001_01CC3490.7073923E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
As per = interim=20 meeting, there is a need to explain the reason for having start/stop = time in CSG=20 group. Two reasons for having this = attribute:
 
1) BYE = will serve=20 the purpose in case CSG is within single RS or ending at the end of some = RS. In=20 case CSG is terminated in the middle of RS session (persistent session), = there=20 is a need of an attribute.  As it is middle of the RS, it is better = to have=20 the exact time.
 
2) In = case=20 partial-update of metadata format, there is an need of XML element to = indicate=20 the termination of CSG ("group") element. It shall be achieved by=20 "stop-time" element within CSG.
 
Thanks
Partha
 
Note:

Topic - Metadata model(Ram Mohan)

draft-ietf-siprec-metadata-01

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /P>

Draft: = https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/

Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiS= tart/SIPREC%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx

Side 5: On the issue of whether a CSG element needs a start/stop = time, Ram=20 explained that the information could be derived from the start/stop = times of the=20 CSs that form part of that group (although he was concerned about the=20 complications of overlapping CSs), or could be explicitly indicated for = the=20 group. Leon and John thought that implicit should be sufficient. Partha = tried to=20 express a point concerning termination of a CSG, but this needs to be = raised on=20 the list.

------_=_NextPart_001_01CC3490.7073923E-- From partr@cisco.com Mon Jun 27 00:08:11 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CFE11E808C for ; Mon, 27 Jun 2011 00:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.791 X-Spam-Level: X-Spam-Status: No, score=-8.791 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8KB3xLPfipi for ; Mon, 27 Jun 2011 00:08:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2D14521F858E for ; Mon, 27 Jun 2011 00:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=3357; q=dns/txt; s=iport; t=1309158490; x=1310368090; h=mime-version:subject:date:message-id:from:to:cc; bh=nQc1+rQ+MAlc0mu1JIxjS5mq0WSn7q34K+F4nrHO8gc=; b=aKztJddiEGetPN1XQk8PVQG7pJ+Tw3t9jGOXCsjNpyBhlLoqGzkjo3ri 199NgFr/CTHFeeva3UVtVkNPxeGShnWEA26iYM4FZphiNJ5w894Knczfv MGwS7d69/KaQn8HI/RFmG99fsA5gJtR0mbCOIcIE6DdcdrST3UQ3w2769 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALYrCE5Io8UQ/2dsb2JhbABSp0N3qjedM4YwBIcqj1CLLA X-IronPort-AV: E=Sophos;i="4.65,431,1304294400"; d="scan'208,217";a="39386677" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 27 Jun 2011 07:08:07 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5R786ha018569; Mon, 27 Jun 2011 07:08:06 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 12:38:06 +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_01CC3498.F6A0F240" Date: Mon, 27 Jun 2011 12:37:59 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7w== From: "Parthasarathi R (partr)" To: , "Elwell, John" X-OriginalArrivalTime: 27 Jun 2011 07:08:06.0866 (UTC) FILETIME=[F6E33320:01CC3498] Subject: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 07:08:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3498.F6A0F240 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, As per the last interim SIPREC meeting, there is a consensus to describe the content of an MS using RFC 4796 & its extension. As per RFC 4796, the multiple instance of content attribute is possible to exist in SDP which shall be used in RS SDP. SRS shall group the same media content types by "content" attribute in RS SDP. We are interested in knowing any specfic reason for this attribute to be duplicated in Metadata XML. Thanks Partha last Interim SIPREC meeting Note: Slide 7: On the question of how to describe the content of an MS, there was no objection to basing this on the types in the RFC 4796 registry (new values could be specified via the appropriate means if needed). Paul had a slight concern that you might be mixing multiple CS MSs into a single RS media stream and whether this might result in cases not describable in this way, but in the end accepted the consensus. It needs to be discussed on the list whether this is conveyed in XML or in the RS SDP a=3Dcontent attribute. ------_=_NextPart_001_01CC3498.F6A0F240 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi=20 all,

As per = the last=20 interim SIPREC meeting, there is a consensus to describe the content of = an MS=20 using RFC 4796 & its extension. As per RFC 4796, the multiple instance of = content=20 attribute is possible to exist in SDP which shall be used in = RS SDP.=20 SRS shall group the same media content types by "content" attribute in = RS SDP.=20 We are interested in knowing any specfic reason for this attribute to be = duplicated in Metadata XML.

Thanks

Partha

last = Interim=20 SIPREC meeting Note:

Slide 7: On the question of how to = describe the=20 content of an MS, there was no objection to basing this on the types in = the RFC=20 4796 registry (new values could be specified via the appropriate means = if=20 needed). Paul had a slight concern that you might be mixing multiple CS = MSs into=20 a single RS media stream and whether this might result in cases not = describable=20 in this way, but in the end accepted the consensus. It needs to be = discussed on=20 the list whether this is conveyed in XML or in the RS SDP a=3Dcontent=20 attribute.

------_=_NextPart_001_01CC3498.F6A0F240-- From john.elwell@siemens-enterprise.com Mon Jun 27 00:47:51 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC9921F8629 for ; Mon, 27 Jun 2011 00:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltwbdTZqn5+r for ; Mon, 27 Jun 2011 00:47:50 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 4E8B421F8626 for ; Mon, 27 Jun 2011 00:47:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1309160865!8384247!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 26569 invoked from network); 27 Jun 2011 07:47:45 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-8.tower-216.messagelabs.com with SMTP; 27 Jun 2011 07:47:45 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 498331EB83ED; Mon, 27 Jun 2011 09:47:45 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 27 Jun 2011 09:47:45 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Mon, 27 Jun 2011 09:47:43 +0200 Thread-Topic: Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXg Message-ID: References: In-Reply-To: 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: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 07:47:51 -0000 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 27 June 2011 08:08 > To: siprec@ietf.org; Elwell, John > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Subject: Content (RFC 4796) attribute in SDP or XML >=20 > Hi all, >=20 > As per the last interim SIPREC meeting, there is a consensus=20 > to describe the content of an MS using RFC 4796 & its=20 > extension. As per RFC 4796, the multiple instance of content=20 > attribute is possible to exist in SDP which shall be used in=20 > RS SDP. SRS shall group the same media content types by=20 > "content" attribute in RS SDP. We are interested in knowing=20 > any specfic reason for this attribute to be duplicated in=20 > Metadata XML. [JRE] I don't have a reason for **duplication**. However, I think there is = a valid question to be asked whether the content type of an MS should be re= presented: A) in XML; or B) in RS SDP as a=3Dcontent. The content type we are talking about is an MS content type, i.e., relating= to the CS. One could argue that the corresponding RS stream is NOT the sam= e content type. For example: - CS MS content type is "slides". - RS media stream content type is "recording of slides". On this basis, I think the correct option for conveying the MS content type= "slides" is A) (in the XML). Note that this would not involve duplication. The SDP a=3Dcontent attribute= is optional, so we need not use it for the RS. Perhaps my distinction is too theoretical, but I do feel a little more comf= ortable using the XML rather than the RS SDP. John (as individual) >=20 > Thanks >=20 > Partha >=20 > last Interim SIPREC meeting Note: >=20 > Slide 7: On the question of how to describe the content of an=20 > MS, there was no objection to basing this on the types in the=20 > RFC 4796 registry (new values could be specified via the=20 > appropriate means if needed). Paul had a slight concern that=20 > you might be mixing multiple CS MSs into a single RS media=20 > stream and whether this might result in cases not describable=20 > in this way, but in the end accepted the consensus. It needs=20 > to be discussed on the list whether this is conveyed in XML=20 > or in the RS SDP a=3Dcontent attribute. >=20 > = From john.elwell@siemens-enterprise.com Mon Jun 27 03:35:24 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BF421F8503 for ; Mon, 27 Jun 2011 03:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6LI6AF3s4lD for ; Mon, 27 Jun 2011 03:33:07 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 0155021F8668 for ; Mon, 27 Jun 2011 03:27:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1309170340!44948060!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 32083 invoked from network); 27 Jun 2011 10:25:40 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-10.tower-21.messagelabs.com with SMTP; 27 Jun 2011 10:25:40 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id D669523F03E2 for ; Mon, 27 Jun 2011 12:25:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 27 Jun 2011 12:25:49 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 27 Jun 2011 12:25:48 +0200 Thread-Topic: Agenda slot for IETF 81 Thread-Index: Acw0tJUhA3ZDDm1qT2mx3GMKX1eHzA== 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: [siprec] Agenda slot for IETF 81 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 10:36:45 -0000 X-List-Received-Date: Mon, 27 Jun 2011 10:36:45 -0000 X-List-Received-Date: Mon, 27 Jun 2011 10:36:45 -0000 X-List-Received-Date: Mon, 27 Jun 2011 10:36:45 -0000 SIPREC tentatively has a 2 hour slot on Thursday afternoon: https://datatracker.ietf.org/meeting/81/agenda.txt But there has been a suggestion to do a swap with SOC on Friday morning - s= o please await the final agenda. John = From rmohanr@cisco.com Mon Jun 27 08:02:52 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1951F0C42 for ; Mon, 27 Jun 2011 08:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX7NidTV4pHL for ; Mon, 27 Jun 2011 08:02:52 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C67D51F0C38 for ; Mon, 27 Jun 2011 08:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=13064; q=dns/txt; s=iport; t=1309186967; x=1310396567; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=oLKYjgF3g/sK6yEqLeO4uMQE3ryWR8yZ577YWieETtc=; b=XSBiBxYki3+HcWVFO2PwposcrH7OXIC0r4TigunVeWQbDPx3OgvgMnjv ksWFqq/itCNMKAeNosIJLWq+bUXZpGvQE/TiQmZ7PMH8qeMRGNJNaC3TR ck58I+McgQTdRp+ELXEYgG3+IJiCx9Ynr7tjGs0XgbCyDh/mdZQzgofuK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAABWbCE5Io8US/2dsb2JhbABSglGVRIcXiBZ3qzadaIYwBIcqj1CLLA X-IronPort-AV: E=Sophos;i="4.65,432,1304294400"; d="scan'208,217";a="39494270" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 27 Jun 2011 15:02:42 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5RF2gnP011080 for ; Mon, 27 Jun 2011 15:02:42 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 20:32:42 +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_01CC34DB.43404581" Date: Mon, 27 Jun 2011 20:32:40 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06D3323D@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] CSG start & stop time attribute requirement Thread-Index: Acw0kGxvAtp8hudRQFqbSwPv+BTXsQARfy2A References: From: "Ram Mohan R (rmohanr)" To: "Parthasarathi R (partr)" , X-OriginalArrivalTime: 27 Jun 2011 15:02:42.0175 (UTC) FILETIME=[437E88F0:01CC34DB] Subject: Re: [siprec] CSG start & stop time attribute requirement X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 15:02:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC34DB.43404581 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable To add more to what Partha has mentioned another use case is when multiple RSs are used for recording a CSG it is easy to determine start/ Stop time when explicitly indicated in CSG. So I would prefer to have Start/ Stop time explicitly indicated in CS-Group and which would indicate when a Group Starts/ End. =20 Ram =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Monday, June 27, 2011 11:37 AM To: siprec@ietf.org Subject: [siprec] CSG start & stop time attribute requirement =20 Hi all, =20 As per interim meeting, there is a need to explain the reason for having start/stop time in CSG group. Two reasons for having this attribute: =20 1) BYE will serve the purpose in case CSG is within single RS or ending at the end of some RS. In case CSG is terminated in the middle of RS session (persistent session), there is a need of an attribute. As it is middle of the RS, it is better to have the exact time. =20 2) In case partial-update of metadata format, there is an need of XML element to indicate the termination of CSG ("group") element. It shall be achieved by "stop-time" element within CSG. =20 Thanks Partha =20 Note: Topic - Metadata model(Ram Mohan) draft-ietf-siprec-metadata-01 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ =20 Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart/SIPR EC%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx =20 Side 5: On the issue of whether a CSG element needs a start/stop time, Ram explained that the information could be derived from the start/stop times of the CSs that form part of that group (although he was concerned about the complications of overlapping CSs), or could be explicitly indicated for the group. Leon and John thought that implicit should be sufficient. Partha tried to express a point concerning termination of a CSG, but this needs to be raised on the list. ------_=_NextPart_001_01CC34DB.43404581 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

To add more to what Partha has mentioned another use case is when = multiple RSs are used for recording a CSG it is easy to determine start/ = Stop time when explicitly indicated in CSG.

So I would prefer to have Start/ Stop time explicitly indicated in = CS-Group and which would indicate when a Group Starts/ = End.

 

Ram

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Parthasarathi R (partr)
Sent: Monday, June 27, 2011 11:37 = AM
To: siprec@ietf.org
Subject: [siprec] CSG start = & stop time attribute = requirement

 

Hi = all,

 

As per = interim meeting, there is a need to explain the reason for having = start/stop time in CSG group. Two reasons for having this = attribute:

 

1) BYE will = serve the purpose in case CSG is within single RS or ending at the end = of some RS. In case CSG is terminated in the middle of RS session = (persistent session), there is a need of an attribute.  As it is = middle of the RS, it is better to have the exact = time.

 

2) In case = partial-update of metadata format, there is an need of XML element to = indicate the termination of CSG ("group") element. It = shall be achieved by "stop-time" element within = CSG.

 

Thanks=

Partha=

 

Note:<= o:p>

Topic - = Metadata model(Ram Mohan)

draft-ietf-si= prec-metadata-01

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

Draft: = https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/

Slides: = http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiS= tart/SIPREC%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx

Side 5: On = the issue of whether a CSG element needs a start/stop time, Ram = explained that the information could be derived from the start/stop = times of the CSs that form part of that group (although he was concerned = about the complications of overlapping CSs), or could be explicitly = indicated for the group. Leon and John thought that implicit should be = sufficient. Partha tried to express a point concerning termination of a = CSG, but this needs to be raised on the = list.

------_=_NextPart_001_01CC34DB.43404581-- From partr@cisco.com Tue Jun 28 02:45:37 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007E521F8635 for ; Tue, 28 Jun 2011 02:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.395 X-Spam-Level: X-Spam-Status: No, score=-9.395 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJ1827lWDP9c for ; Tue, 28 Jun 2011 02:45:36 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4FC21F861B for ; Tue, 28 Jun 2011 02:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=3276; q=dns/txt; s=iport; t=1309254335; x=1310463935; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4FYxq0yeCPiAeVQT/G2RzTaaMAm3dHKyMeqAar+Sfzc=; b=UlaKt7kc4y2GjmsM6eb5Y3hul2GyVQMgIjSZS7GBCNRv5uxTvV8ULT0H jlUyQaUQHgpZN7tnBZluCr7vaeKoORK1MCrA1jLOJ8XsMQLXsbybEVtWO 7f2xR6kVeKcrqrCqGuD2uSDzp3jf9mExc19vaBAMqml3ZMtLCKMUQFx2K 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAEqhCU5Io8UT/2dsb2JhbABSmAyPL3eId6N0nkOGMASHMo9VizI X-IronPort-AV: E=Sophos;i="4.65,436,1304294400"; d="scan'208";a="39615088" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 28 Jun 2011 09:45:29 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5S9jSfK009476; Tue, 28 Jun 2011 09:45:28 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Jun 2011 15:15:28 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jun 2011 15:15:27 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfA= References: From: "Parthasarathi R (partr)" To: "Elwell, John" , X-OriginalArrivalTime: 28 Jun 2011 09:45:28.0760 (UTC) FILETIME=[1D1BA380:01CC3578] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 09:45:37 -0000 John, In case if it is the argument of whether CS MS content type or RS MS content type in the metadata, it is better for us to re-open ticket #71 (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). Please let me know your opinion here. The basic idea in metadata format is to re-use as much as SDP attribute (like direction, content) in media level for RS dialog (using SDP label attribute as a pointer) until otherwise there is a restriction in using in such manner. As per RFC 4796, there is no such restriction and so, I prefer to reuse as content SDP attribute rather than introducing the new element for this purpose. Thanks Partha=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, June 27, 2011 1:18 PM To: Parthasarathi R (partr); siprec@ietf.org Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Subject: RE: Content (RFC 4796) attribute in SDP or XML =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 27 June 2011 08:08 > To: siprec@ietf.org; Elwell, John > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Subject: Content (RFC 4796) attribute in SDP or XML >=20 > Hi all, >=20 > As per the last interim SIPREC meeting, there is a consensus to=20 > describe the content of an MS using RFC 4796 & its extension. As per=20 > RFC 4796, the multiple instance of content attribute is possible to=20 > exist in SDP which shall be used in RS SDP. SRS shall group the same=20 > media content types by "content" attribute in RS SDP. We are=20 > interested in knowing any specfic reason for this attribute to be=20 > duplicated in Metadata XML. [JRE] I don't have a reason for **duplication**. However, I think there is a valid question to be asked whether the content type of an MS should be represented: A) in XML; or B) in RS SDP as a=3Dcontent. The content type we are talking about is an MS content type, i.e., relating to the CS. One could argue that the corresponding RS stream is NOT the same content type. For example: - CS MS content type is "slides". - RS media stream content type is "recording of slides". On this basis, I think the correct option for conveying the MS content type "slides" is A) (in the XML). Note that this would not involve duplication. The SDP a=3Dcontent attribute is optional, so we need not use it for the RS. Perhaps my distinction is too theoretical, but I do feel a little more comfortable using the XML rather than the RS SDP. John (as individual) >=20 > Thanks >=20 > Partha >=20 > last Interim SIPREC meeting Note: >=20 > Slide 7: On the question of how to describe the content of an MS,=20 > there was no objection to basing this on the types in the RFC 4796=20 > registry (new values could be specified via the appropriate means if=20 > needed). Paul had a slight concern that you might be mixing multiple=20 > CS MSs into a single RS media stream and whether this might result in=20 > cases not describable in this way, but in the end accepted the=20 > consensus. It needs to be discussed on the list whether this is=20 > conveyed in XML or in the RS SDP a=3Dcontent attribute. >=20 >=20 From john.elwell@siemens-enterprise.com Tue Jun 28 03:11:25 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54DD21F859A for ; Tue, 28 Jun 2011 03:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpMuFh4RWo6C for ; Tue, 28 Jun 2011 03:11:25 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id CDB7E21F8599 for ; Tue, 28 Jun 2011 03:11:21 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1309255880!8713979!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 25269 invoked from network); 28 Jun 2011 10:11:20 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-3.tower-216.messagelabs.com with SMTP; 28 Jun 2011 10:11:20 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 7785C23F03E2; Tue, 28 Jun 2011 12:11:20 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 28 Jun 2011 12:11:20 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Tue, 28 Jun 2011 12:11:18 +0200 Thread-Topic: Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAA== Message-ID: References: In-Reply-To: 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: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 10:11:25 -0000 I would like other opinions on whether the SDP a=3Dcontent attribute in the= RS SDP has the correct semantics for representing the content type of the = recorded CS media stream. John=20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 28 June 2011 10:45 > To: Elwell, John; siprec@ietf.org > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Subject: RE: Content (RFC 4796) attribute in SDP or XML >=20 > John, >=20 > In case if it is the argument of whether CS MS content type or RS MS > content type in the metadata, it is better for us to re-open=20 > ticket #71 > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > Please let me know your opinion here. >=20 > The basic idea in metadata format is to re-use as much as SDP=20 > attribute > (like direction, content) in media level for RS dialog (using=20 > SDP label > attribute as a pointer) until otherwise there is a=20 > restriction in using > in such manner. As per RFC 4796, there is no such restriction=20 > and so, I > prefer to reuse as content SDP attribute rather than=20 > introducing the new > element for this purpose. >=20 > Thanks > Partha=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Monday, June 27, 2011 1:18 PM > To: Parthasarathi R (partr); siprec@ietf.org > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Subject: RE: Content (RFC 4796) attribute in SDP or XML >=20 > =20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 27 June 2011 08:08 > > To: siprec@ietf.org; Elwell, John > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Subject: Content (RFC 4796) attribute in SDP or XML > >=20 > > Hi all, > >=20 > > As per the last interim SIPREC meeting, there is a consensus to=20 > > describe the content of an MS using RFC 4796 & its=20 > extension. As per=20 > > RFC 4796, the multiple instance of content attribute is possible to=20 > > exist in SDP which shall be used in RS SDP. SRS shall group=20 > the same=20 > > media content types by "content" attribute in RS SDP. We are=20 > > interested in knowing any specfic reason for this attribute to be=20 > > duplicated in Metadata XML. > [JRE] I don't have a reason for **duplication**. However, I=20 > think there > is a valid question to be asked whether the content type of=20 > an MS should > be represented: > A) in XML; or > B) in RS SDP as a=3Dcontent. >=20 > The content type we are talking about is an MS content type, i.e., > relating to the CS. One could argue that the corresponding RS=20 > stream is > NOT the same content type. For example: > - CS MS content type is "slides". > - RS media stream content type is "recording of slides". >=20 > On this basis, I think the correct option for conveying the MS content > type "slides" is A) (in the XML). >=20 > Note that this would not involve duplication. The SDP a=3Dcontent > attribute is optional, so we need not use it for the RS. >=20 > Perhaps my distinction is too theoretical, but I do feel a little more > comfortable using the XML rather than the RS SDP. >=20 > John (as individual) >=20 >=20 > >=20 > > Thanks > >=20 > > Partha > >=20 > > last Interim SIPREC meeting Note: > >=20 > > Slide 7: On the question of how to describe the content of an MS,=20 > > there was no objection to basing this on the types in the RFC 4796=20 > > registry (new values could be specified via the appropriate=20 > means if=20 > > needed). Paul had a slight concern that you might be mixing=20 > multiple=20 > > CS MSs into a single RS media stream and whether this might=20 > result in=20 > > cases not describable in this way, but in the end accepted the=20 > > consensus. It needs to be discussed on the list whether this is=20 > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > >=20 > >=20 > = From Henry.Lum@alcatel-lucent.com Tue Jun 28 18:34:12 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621769E8009 for ; Tue, 28 Jun 2011 18:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h9g5y5+4jBy for ; Tue, 28 Jun 2011 18:34:11 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 983AA9E8004 for ; Tue, 28 Jun 2011 18:34:11 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p5T1YAvZ024637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 28 Jun 2011 20:34:10 -0500 (CDT) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5T1Y8pq000745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 28 Jun 2011 20:34:10 -0500 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id p5T1Y81D001919 for ; Tue, 28 Jun 2011 18:34:08 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Jun 2011 18:34:07 -0700 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_01CC35FC.A36FE444" Date: Tue, 28 Jun 2011 18:34:05 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74073E6CC6@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SDP recording attribute usages Thread-Index: Acw1/KIdhowHAKz5SweJ6G4hnLkgpA== From: "Henry Lum" To: X-OriginalArrivalTime: 29 Jun 2011 01:34:07.0973 (UTC) FILETIME=[A39A4950:01CC35FC] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [siprec] SDP recording attribute usages X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 01:34:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC35FC.A36FE444 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I want to explain how I see the a=3Drecord SDP attribute to be used to indicate recording.=20 =20 I see two main scenarios with party A and B where the SRC is one of the parties or the SRC is a B2BUA: =20 1) party A is the SRC =20 When party A as UAC is sending an offer, party A may indicate that recording is enabled and provide a=3Drecord:on in the SDP offer. Party B sees that Party A is declaring the media stream is being recorded. Party B is not an SRC and will not be recording so it sends an SDP answer with a=3Drecord:off. The SDP answer is telling party A that party B is not recording even though party A as an SRC will record. =20 When a reINVITE is sent by party A or B, the offer/answer should indicate which party is continuing recording. For example, party B sends reINVITE for whatever reason, party B sends offer with a=3Drecord:off; when party A answers, party A will send a=3Drecord:on to indicate that recording is still in progress. =20 2) SRC is a B2BUA between party A and B =20 This is similar to the above scenario, except that when party A is sending an SDP offer, party A sets a=3Drecord:off since party A is not recording. When the B2BUA gets the request and forwards to party B, the B2BUA is also trying to record as an SRC, the B2BUA rewrites the offer with a=3Drecord:on towards party B. Party B sees that the media stream is= being recorded and sends SDP answer with a=3Drecord:off since party B is not recording. The B2BUA then passes the SDP answer but rewrites a=3Drecord:on to indicate to party A that the call is being recorded. =20 When the B2BUA needs to perform some 3rd party call control, B2BUA initiates a reINVITE to party A with no offer. Party A sends 200 OK answer with a=3Drecord:off to B2BUA. B2BUA sends reINVITE SDP offer to party B and sets a=3Drecord:on to indicate that the recording is still in= progress. Party B responds 200 OK with SDP answer a=3Drecord:off. B2BUA rewrites the answer with a=3Drecord:on as ACK to party A. =20 =20 I think these two scenarios should cover the main cases. =20 Regards, Henry =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CC35FC.A36FE444 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I wa= nt to explain how I see the a=3Drecord SDP attribute to be used to indica= te recording.

 

I see two main scenarios with party A and B where the = SRC is one of the parties or the SRC is a B2BUA:

 

1) &n= bsp;    party A is the SRC

 

Whe= n party A as UAC is sending an offer, party A may indicate that recording= is enabled and provide a=3Drecord:on in the SDP offer. Party B sees that= Party A is declaring the media stream is being recorded. Party B is not = an SRC and will not be recording so it sends an SDP answer with a=3Drecor= d:off. The SDP answer is telling party A that party B is not recording ev= en though party A as an SRC will record.

 

When a reINVITE is sent by p= arty A or B, the offer/answer should indicate which party is continuing r= ecording. For example, party B sends reINVITE for whatever reason, party = B sends offer with a=3Drecord:off; when party A answers, party A will sen= d a=3Drecord:on to indicate that recording is still in progress.

 

2)      SRC is = a B2BUA between party A and B

&nb= sp;

This is similar to the above scenario, = except that when party A is sending an SDP offer, party A sets a=3Drecord= :off since party A is not recording. When the B2BUA gets the request and = forwards to party B, the B2BUA is also trying to record as an SRC, the B2= BUA rewrites the offer with a=3Drecord:on towards party B. Party B sees t= hat the media stream is being recorded and sends SDP answer with a=3Dreco= rd:off since party B is not recording. The B2BUA then passes the SDP answ= er but rewrites a=3Drecord:on to indicate to party A that the call is bei= ng recorded.

 

When the B2BUA needs to perform some 3rd part= y call control, B2BUA initiates a reINVITE to party A with no offer. Part= y A sends 200 OK answer with a=3Drecord:off to B2BUA. B2BUA sends reINVIT= E SDP offer to party B and sets a=3Drecord:on to indicate that the record= ing is still in progress. Party B responds 200 OK with SDP answer a=3Drec= ord:off. B2BUA rewrites the answer with a=3Drecord:on as ACK to party A.<= o:p>

 

 

I think these two scenarios= should cover the main cases.

&nb= sp;

Regards,

Henry

 


CON= FIDENTIALITY NOTICE: This e-mail and any files attached may contain confi= dential and proprietary information of Alcatel-Lucent and/or its affiliat= ed entities. Access by the intended recipient only is authorized. Any lia= bility arising from any party acting, or refraining from acting, on any i= nformation contained in this e-mail is hereby excluded. If you are not th= e intended recipient, please notify the sender immediately, destroy the o= riginal transmission and its attachments and do not disclose the contents= to any other person, use it for any purpose, or store or copy the inform= ation in any medium. Copyright in this e-mail and any attachments belongs= to Alcatel-Lucent and/or its affiliated entities. ------_=_NextPart_001_01CC35FC.A36FE444-- From Henry.Lum@alcatel-lucent.com Tue Jun 28 18:48:27 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7719A9E8012 for ; Tue, 28 Jun 2011 18:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY95jHUNxc8x for ; Tue, 28 Jun 2011 18:48:26 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 262189E8004 for ; Tue, 28 Jun 2011 18:48:25 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p5T1mP1r016324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 28 Jun 2011 20:48:25 -0500 (CDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5T1mNA4031078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 28 Jun 2011 20:48:24 -0500 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p5T1mMNY010340 for ; Tue, 28 Jun 2011 18:48:22 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Jun 2011 18:48:22 -0700 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_01CC35FE.A1206B67" Date: Tue, 28 Jun 2011 18:48:20 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74073E6CCB@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a=recordpref:nopreference value? Thread-Index: Acw1/LwEw99bBbeYRn+z23aoGgpyRQ== From: "Henry Lum" To: X-OriginalArrivalTime: 29 Jun 2011 01:48:22.0921 (UTC) FILETIME=[A130FF90:01CC35FE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [siprec] a=recordpref:nopreference value? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 01:48:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC35FE.A1206B67 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 One of the questions in the interim meeting is about whether we need a separate value in recording preference to indicate "no preference". Currently we are assuming the absence of such attribute a=3Drecordpref means there is no indication. In the meeting it was brought up that not putting the indication can also mean the UA is unaware of this attribute. =20 If we add the value no preference to the attribute, I think this implies that a recording-aware UA must always include this attribute to indicate that it is recording-aware plus it is including the preference in all offer/answer. I don't feel too strongly about requiring this because this makes SDP a bit too chatty to indicate no preference. =20 What do others think? =20 Henry =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CC35FE.A1206B67 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One = of the questions in the interim meeting is about whether we need a separa= te value in recording preference to indicate “no preference”.= Currently we are assuming the absence of such attribute a=3Drecordpref m= eans there is no indication. In the meeting it was brought up that not pu= tting the indication can also mean the UA is unaware of this attribute.

 

If we add the value no preference to the attribute, I think this impli= es that a recording-aware UA must always include this attribute to indica= te that it is recording-aware plus it is including the preference in all = offer/answer. I don’t feel too strongly about requiring this becaus= e this makes SDP a bit too chatty to indicate no preference.

 

What do = others think?

 

Henry

 


CONFIDENTIALITY NOTICE: This e-mail and any files attached may = contain confidential and proprietary information of Alcatel-Lucent and/or= its affiliated entities. Access by the intended recipient only is author= ized. Any liability arising from any party acting, or refraining from act= ing, on any information contained in this e-mail is hereby excluded. If y= ou are not the intended recipient, please notify the sender immediately, = destroy the original transmission and its attachments and do not disclose= the contents to any other person, use it for any purpose, or store or co= py the information in any medium. Copyright in this e-mail and any attach= ments belongs to Alcatel-Lucent and/or its affiliated entities. ------_=_NextPart_001_01CC35FE.A1206B67-- From eckelcu@cisco.com Wed Jun 29 09:17:33 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B3B9E804C for ; Wed, 29 Jun 2011 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlMH3uL3d4U0 for ; Wed, 29 Jun 2011 09:17:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 208DD9E8058 for ; Wed, 29 Jun 2011 09:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4729; q=dns/txt; s=iport; t=1309364251; x=1310573851; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=V3Ctdn+0ZR3nTnPR7hDNyblStNwbFlgz1INCVzy/YF4=; b=XOpNATK9d+NqQ46aZmZO/XXbkqFBriuv3qFHq3qnhlJUaSs/YCneIiv6 Rd4cZmocKeyjujcqnBBqvvE0CYinSVrp/ujMQy5hERkCA8KQGDbBzGdme C//IVObeUeUTiGWC56yxbl4F/K6VIi4s5cZ3aBAkGF/oCwAHREga70zvJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAGVPC06rRDoH/2dsb2JhbABSmCSPOnesU54WhjAEhzaPX4tM X-IronPort-AV: E=Sophos;i="4.65,444,1304294400"; d="scan'208";a="472121062" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 29 Jun 2011 16:17:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5TGHRvK017837; Wed, 29 Jun 2011 16:17:27 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Jun 2011 09:17:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Jun 2011 09:17:13 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7w References: From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 29 Jun 2011 16:17:14.0505 (UTC) FILETIME=[02096F90:01CC3678] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:17:33 -0000 I think it is sufficient, especially since we can assign new values if necessary. Are there any examples of what people think they might want to capture in the SDP and/or metadata field? Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Tuesday, June 28, 2011 3:11 AM > To: Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > I would like other opinions on whether the SDP a=3Dcontent attribute = in the RS SDP has the correct > semantics for representing the content type of the recorded CS media stream. >=20 > John >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 28 June 2011 10:45 > > To: Elwell, John; siprec@ietf.org > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > John, > > > > In case if it is the argument of whether CS MS content type or RS MS > > content type in the metadata, it is better for us to re-open > > ticket #71 > > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > Please let me know your opinion here. > > > > The basic idea in metadata format is to re-use as much as SDP > > attribute > > (like direction, content) in media level for RS dialog (using > > SDP label > > attribute as a pointer) until otherwise there is a > > restriction in using > > in such manner. As per RFC 4796, there is no such restriction > > and so, I > > prefer to reuse as content SDP attribute rather than > > introducing the new > > element for this purpose. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Monday, June 27, 2011 1:18 PM > > To: Parthasarathi R (partr); siprec@ietf.org > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 27 June 2011 08:08 > > > To: siprec@ietf.org; Elwell, John > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > Hi all, > > > > > > As per the last interim SIPREC meeting, there is a consensus to > > > describe the content of an MS using RFC 4796 & its > > extension. As per > > > RFC 4796, the multiple instance of content attribute is possible to > > > exist in SDP which shall be used in RS SDP. SRS shall group > > the same > > > media content types by "content" attribute in RS SDP. We are > > > interested in knowing any specfic reason for this attribute to be > > > duplicated in Metadata XML. > > [JRE] I don't have a reason for **duplication**. However, I > > think there > > is a valid question to be asked whether the content type of > > an MS should > > be represented: > > A) in XML; or > > B) in RS SDP as a=3Dcontent. > > > > The content type we are talking about is an MS content type, i.e., > > relating to the CS. One could argue that the corresponding RS > > stream is > > NOT the same content type. For example: > > - CS MS content type is "slides". > > - RS media stream content type is "recording of slides". > > > > On this basis, I think the correct option for conveying the MS content > > type "slides" is A) (in the XML). > > > > Note that this would not involve duplication. The SDP a=3Dcontent > > attribute is optional, so we need not use it for the RS. > > > > Perhaps my distinction is too theoretical, but I do feel a little more > > comfortable using the XML rather than the RS SDP. > > > > John (as individual) > > > > > > > > > > Thanks > > > > > > Partha > > > > > > last Interim SIPREC meeting Note: > > > > > > Slide 7: On the question of how to describe the content of an MS, > > > there was no objection to basing this on the types in the RFC 4796 > > > registry (new values could be specified via the appropriate > > means if > > > needed). Paul had a slight concern that you might be mixing > > multiple > > > CS MSs into a single RS media stream and whether this might > > result in > > > cases not describable in this way, but in the end accepted the > > > consensus. It needs to be discussed on the list whether this is > > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Wed Jun 29 09:42:15 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB00A21F8655 for ; Wed, 29 Jun 2011 09:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzXf-cLkZFuG for ; Wed, 29 Jun 2011 09:42:13 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 383C821F8653 for ; Wed, 29 Jun 2011 09:42:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1309365730!23134547!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 23220 invoked from network); 29 Jun 2011 16:42:10 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-4.tower-174.messagelabs.com with SMTP; 29 Jun 2011 16:42:10 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id B20741EB83ED; Wed, 29 Jun 2011 18:42:10 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 29 Jun 2011 18:42:10 +0200 From: "Elwell, John" To: Henry Lum , "siprec@ietf.org" Date: Wed, 29 Jun 2011 18:42:09 +0200 Thread-Topic: SDP recording attribute usages Thread-Index: Acw1/KIdhowHAKz5SweJ6G4hnLkgpAAfqARA Message-ID: References: <059AF07365DC474393A19A3AF187DF74073E6CC6@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74073E6CC6@NAHALD.us.int.genesyslab.com> 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: [siprec] SDP recording attribute usages X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:42:16 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > Sent: 29 June 2011 02:34 > To: siprec@ietf.org > Subject: [siprec] SDP recording attribute usages >=20 > Hi, >=20 > =20 >=20 > I want to explain how I see the a=3Drecord SDP attribute to be=20 > used to indicate recording.=20 >=20 > =20 >=20 > I see two main scenarios with party A and B where the SRC is=20 > one of the parties or the SRC is a B2BUA: >=20 > =20 >=20 > 1) party A is the SRC >=20 > =20 >=20 > When party A as UAC is sending an offer, party A may indicate=20 > that recording is enabled and provide a=3Drecord:on in the SDP=20 > offer. Party B sees that Party A is declaring the media=20 > stream is being recorded. Party B is not an SRC and will not=20 > be recording so it sends an SDP answer with a=3Drecord:off. The=20 > SDP answer is telling party A that party B is not recording=20 > even though party A as an SRC will record. >=20 > =20 >=20 > When a reINVITE is sent by party A or B, the offer/answer=20 > should indicate which party is continuing recording. For=20 > example, party B sends reINVITE for whatever reason, party B=20 > sends offer with a=3Drecord:off; when party A answers, party A=20 > will send a=3Drecord:on to indicate that recording is still in progress. >=20 > =20 >=20 > 2) SRC is a B2BUA between party A and B >=20 > =20 >=20 > This is similar to the above scenario, except that when party=20 > A is sending an SDP offer, party A sets a=3Drecord:off since=20 > party A is not recording. When the B2BUA gets the request and=20 > forwards to party B, the B2BUA is also trying to record as an=20 > SRC, the B2BUA rewrites the offer with a=3Drecord:on towards=20 > party B. Party B sees that the media stream is being recorded=20 > and sends SDP answer with a=3Drecord:off since party B is not=20 > recording. The B2BUA then passes the SDP answer but rewrites=20 > a=3Drecord:on to indicate to party A that the call is being recorded. >=20 > =20 >=20 > When the B2BUA needs to perform some 3rd party call control,=20 > B2BUA initiates a reINVITE to party A with no offer. Party A=20 > sends 200 OK answer with a=3Drecord:off to B2BUA. B2BUA sends=20 > reINVITE SDP offer to party B and sets a=3Drecord:on to=20 > indicate that the recording is still in progress. Party B=20 > responds 200 OK with SDP answer a=3Drecord:off. B2BUA rewrites=20 > the answer with a=3Drecord:on as ACK to party A. [JRE] There is another use case. The B2BUA turns recording on or off for so= me reason during the course of the CS. Presumably it would do similar to ab= ove, i.e., issue an offerless INVITE request to one of the parties. John >=20 > =20 >=20 > =20 >=20 > I think these two scenarios should cover the main cases. >=20 > =20 >=20 > Regards, >=20 > Henry >=20 > =20 >=20 >=20 > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain confidential and proprietary information of=20 > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > intended recipient only is authorized. Any liability arising=20 > from any party acting, or refraining from acting, on any=20 > information contained in this e-mail is hereby excluded. If=20 > you are not the intended recipient, please notify the sender=20 > immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other=20 > person, use it for any purpose, or store or copy the=20 > information in any medium. Copyright in this e-mail and any=20 > attachments belongs to Alcatel-Lucent and/or its affiliated entities.=20 > = From john.elwell@siemens-enterprise.com Wed Jun 29 09:46:56 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DACC21F86C1 for ; Wed, 29 Jun 2011 09:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.074 X-Spam-Level: X-Spam-Status: No, score=-106.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH6329-ZCKsM for ; Wed, 29 Jun 2011 09:46:55 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 471A621F8652 for ; Wed, 29 Jun 2011 09:46:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1309366007!50830982!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 11779 invoked from network); 29 Jun 2011 16:46:47 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-21.messagelabs.com with SMTP; 29 Jun 2011 16:46:47 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B10581EB83D3; Wed, 29 Jun 2011 18:46:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 29 Jun 2011 18:46:52 +0200 From: "Elwell, John" To: Henry Lum , "siprec@ietf.org" Date: Wed, 29 Jun 2011 18:46:51 +0200 Thread-Topic: a=recordpref:nopreference value? Thread-Index: Acw1/LwEw99bBbeYRn+z23aoGgpyRQAfwSeg Message-ID: References: <059AF07365DC474393A19A3AF187DF74073E6CCB@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74073E6CCB@NAHALD.us.int.genesyslab.com> 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: [siprec] a=recordpref:nopreference value? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:46:56 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > Sent: 29 June 2011 02:48 > To: siprec@ietf.org > Subject: [siprec] a=3Drecordpref:nopreference value? >=20 > Hi, >=20 > =20 >=20 > One of the questions in the interim meeting is about whether=20 > we need a separate value in recording preference to indicate=20 > "no preference". Currently we are assuming the absence of=20 > such attribute a=3Drecordpref means there is no indication. In=20 > the meeting it was brought up that not putting the indication=20 > can also mean the UA is unaware of this attribute. >=20 > =20 >=20 > If we add the value no preference to the attribute, I think=20 > this implies that a recording-aware UA must always include=20 > this attribute to indicate that it is recording-aware plus it=20 > is including the preference in all offer/answer. I don't feel=20 > too strongly about requiring this because this makes SDP a=20 > bit too chatty to indicate no preference. [JRE] We will have a SIP option tag to indicate recording-aware, won't we? = So I don't think needing to distinguish between aware and unaware is a vali= d argument. Having said that, I don't object to having a 'no preference' va= lue, but I don't have a strong opinion. John (as individual) >=20 > =20 >=20 > What do others think? >=20 > =20 >=20 > Henry >=20 > =20 >=20 >=20 > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain confidential and proprietary information of=20 > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > intended recipient only is authorized. Any liability arising=20 > from any party acting, or refraining from acting, on any=20 > information contained in this e-mail is hereby excluded. If=20 > you are not the intended recipient, please notify the sender=20 > immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other=20 > person, use it for any purpose, or store or copy the=20 > information in any medium. Copyright in this e-mail and any=20 > attachments belongs to Alcatel-Lucent and/or its affiliated entities.=20 > = From pkyzivat@cisco.com Wed Jun 29 12:15:14 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3027911E80E4 for ; Wed, 29 Jun 2011 12:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zMP6RxHkaHZ for ; Wed, 29 Jun 2011 12:15:13 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4881F11E80E2 for ; Wed, 29 Jun 2011 12:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4192; q=dns/txt; s=iport; t=1309374913; x=1310584513; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=N+cFd4MgpCC4/ey8oriDmiyItcoiLaCiEyxg8mXGlJI=; b=TvXA+IMzPJeWcXOAjvTI9FqhscGKAqWalglCUsWZKFc61IhFUclxRVD7 TMI5vyZGERDPP+wCPy6xvwgLu/tg+X7TvJtwlkvUotA95sy6ghu1/+jzo GDWHsWeOnqAkqfI96KQxISNyjwnejtvDjqUGiExy8WRL+N1L5I9yN6IAL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIx5C06rRDoG/2dsb2JhbABSp2B3rF6eCYYwBJIXhHWLUQ Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 29 Jun 2011 19:06:31 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5TJ6UQQ011510 for ; Wed, 29 Jun 2011 19:06:30 GMT Message-ID: <4E0B77B6.5050204@cisco.com> Date: Wed, 29 Jun 2011 15:06:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: siprec@ietf.org References: <059AF07365DC474393A19A3AF187DF74073E6CC6@NAHALD.us.int.genesyslab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] SDP recording attribute usages X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 19:15:14 -0000 inline On 6/29/2011 12:42 PM, Elwell, John wrote: >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum >> Sent: 29 June 2011 02:34 >> To: siprec@ietf.org >> Subject: [siprec] SDP recording attribute usages >> >> Hi, >> >> I want to explain how I see the a=record SDP attribute to be >> used to indicate recording. >> >> I see two main scenarios with party A and B where the SRC is >> one of the parties or the SRC is a B2BUA: >> >> 1) party A is the SRC >> >> When party A as UAC is sending an offer, party A may indicate >> that recording is enabled and provide a=record:on in the SDP >> offer. Party B sees that Party A is declaring the media >> stream is being recorded. Party B is not an SRC and will not >> be recording so it sends an SDP answer with a=record:off. The >> SDP answer is telling party A that party B is not recording >> even though party A as an SRC will record. >> >> When a reINVITE is sent by party A or B, the offer/answer >> should indicate which party is continuing recording. For >> example, party B sends reINVITE for whatever reason, party B >> sends offer with a=record:off; when party A answers, party A >> will send a=record:on to indicate that recording is still in progress. As a continuation to the scenario, where B is not an SRC, this seems fine. It gets tricky if B is also capable of being an SRC. It might want to do its own recording, rather than relying on the recording A is doing. Or it might not. Does it respond based on whether it decides to record? Or based on whether it *could* record? Assume it responds based on whether it does record. Then at the reinvite, does it respond with a=record:no on the assumption that A will continue recording? It has no way to know that. This seems similar to the issues around o/a for comedia. >> 2) SRC is a B2BUA between party A and B >> >> This is similar to the above scenario, except that when party >> A is sending an SDP offer, party A sets a=record:off since >> party A is not recording. When the B2BUA gets the request and >> forwards to party B, the B2BUA is also trying to record as an >> SRC, the B2BUA rewrites the offer with a=record:on towards >> party B. Party B sees that the media stream is being recorded >> and sends SDP answer with a=record:off since party B is not >> recording. The B2BUA then passes the SDP answer but rewrites >> a=record:on to indicate to party A that the call is being recorded. Do we also have the possibility of a b2bua that *isn't* an SRC, but wants recording??? If so then we can get into situations more like what is done for session timer. >> When the B2BUA needs to perform some 3rd party call control, >> B2BUA initiates a reINVITE to party A with no offer. Party A >> sends 200 OK answer with a=record:off to B2BUA. B2BUA sends >> reINVITE SDP offer to party B and sets a=record:on to >> indicate that the recording is still in progress. Party B >> responds 200 OK with SDP answer a=record:off. B2BUA rewrites >> the answer with a=record:on as ACK to party A. This works ok as long as the b2bua is an src, and neither A nor B are. If either A or B is a recorder, does the b2bua continue to record? Or does it adjust its behavior? If it wants to adjust its behavior, how does it get enough info to know that the recording being done by A and/or B is sufficient? > [JRE] There is another use case. The B2BUA turns recording on or off for some reason during the course of the CS. Presumably it would do similar to above, i.e., issue an offerless INVITE request to one of the parties. I don't think this last case adds anything fundamentally new to the conveyance of the record flag. *If* the goal of this attribute is just to ensure that all are aware recording is proceeding, and not *who* is doing the recording, and not *negotiating* who is doing the recording, then something like the above is about right. I think that must be the goal. If we want to introduce negotiation over who will do recording, things will be much more complex. Thanks, Paul