From pkyzivat@alum.mit.edu Sun Oct 2 10:20: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 2296E21F85AE for ; Sun, 2 Oct 2011 10:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNVHjnNtUVBF for ; Sun, 2 Oct 2011 10:20:47 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id B440D21F85A8 for ; Sun, 2 Oct 2011 10:20:46 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta12.westchester.pa.mail.comcast.net with comcast id fqwv1h0031YDfWL5CtPlUn; Sun, 02 Oct 2011 17:23:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id ftPk1h00V0tdiYw3gtPksi; Sun, 02 Oct 2011 17:23:45 +0000 Message-ID: <4E889E1E.7090709@alum.mit.edu> Date: Sun, 02 Oct 2011 13:23:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: siprec@ietf.org References: <35BCE99A477D6A4986FB2216D8CF2CFD07CF22E6@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07CF22E6@XMB-BGL-417.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Consensus calls from session 2 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, 02 Oct 2011 17:20:48 -0000 On 9/26/11 10:39 AM, Ram Mohan R (rmohanr) wrote: > Hadriel, > > As John mentioned below, the consensus call was for avoiding the > unnecessary level of sequence as defined in ver 04 and go with simple > approach of putting the xs:any construct within any sequence where > extension data is needed [ e.g. session, group, participant and stream > sequences]. Also we agreed in the call(Monday session) that extension > data is not needed to be modeled in UML. Please note this schema is > inline with technique used in RFC 6120 (XMPP related RFC) for extension > data. I agree with this approach. I *don't* think it is good to expect recipients to ignore unknown elements in places where there is no "any" in the schema to match them. IOW, I think the message should be expected to validate according to the specified schema. It should be acceptable for a recipient to reject any message that doesn't. (But it should also be acceptable for a recipient to ignore unknown elements.) I know that is typically used to accomplish this. But I have wondered about the ##other in that construction. IIUC it means that you can't have anything from *this* namespace matching that. But that means that any extensions we might want to incorporate later would *require* a different namespace. While that is certainly possible, it might be inconvenient/annoying. Is there any reason to forbid things from this namespace being used? Thanks, Paul > The schema for, for example, with the above approach will be: > > > > minOccurs="0"/> > minOccurs="0"/> > minOccurs="0"/> > minOccurs="0" maxOccurs="1"/> > minOccurs='0' > maxOccurs='unbounded' > processContents='lax'/> > > use="required"/> > > > Let me know if you still have any concerns. > > Regards, > Ram > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Elwell, John >> Sent: Monday, September 26, 2011 12:41 PM >> To: Hadriel Kaplan >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Consensus calls from session 2 >> >> >> >> >>> -----Original Message----- >>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>> Sent: 24 September 2011 04:11 >>> To: Elwell, John >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] Consensus calls from session 2 >>> >>> >>> On Sep 23, 2011, at 11:59 AM, Elwell, John wrote: >>> >>>> Please raise any objections by 2011-10-03 to the following >>> conclusions from today's call: >>>> - Extension data representation in XML as proposed on >>> metadata slide 19. >> [JRE] What slide 19 does is get rid of an unnecessary level of >> . In metadata-04 the schema defines an element type >> extensiondata and uses it in various places. This type is defined as >> being a complexType consisting of the "xs:any" construct. This is not >> valid syntax, and to make it valid xs:any would need to be embedded >> within a element, e.g.: >> >> >> >> > minOccurs='0' >> maxOccurs='unbounded' >> processContents='lax'/> >> >> >> This can be avoided simply by putting the xs:any construct within any >> sequence where extension data is needed, such as within the session, >> group, participant and stream sequences. Defining a separate type >> extensiondata seems to force an additional level of sequence on the >> wire. >> >> So this change is merely about making our schema valid and doing so >> without forcing an unnecessary level of sequence on the wire. We can >> have a separate discussion on whether the xs:any construct is needed > at >> all, but that is not what this consensus call is about. >> >>> >>> I don't understand what slide 19 means (ie, what it's >>> changing), but I will re-iterate again that the extensionData >>> container element is completely unnecessary, and potentially >>> dangerous. >>> >>> It's unnecessary because XML doesn't need this type of thing. >>> All you need to do is have the RFC say "Unknown elements at >>> any level MUST be ignored, and MUST NOT cause protocol >>> failure". That's what we do in other SIP RFCs. Why? Because >>> that's what xmlns namespaces are for. You can extend it with >>> vendor-proprietary and future-standard extensions at any time >>> in the future, without backwards compatibility problems. >>> This is not some new concept for XML. >>> >>> It's dangerous because we can only extend the XML document in >>> future specs in the places where we happened to put the >>> extensionData element. And what happens if/when we do extend >>> this XML in a future spec by putting a newly defined XML >>> container element inside extensionData? Do we have to put >>> another extensionData inside that new container too, just in >>> case we want to extend it again in the future? >> [JRE] No, I don't think so. That is why the maximum number of > instances >> of xs:any is unbounded. >> >> John >> >> >>> >>> What would a future spec do about vendor-proprietary elements >>> which happen to be sharing the same extensionData container >>> defined by this metadata document? The future spec would >>> say: "you have to implement XML, which has namespaces, and >>> ignore any elements not using this new spec's namespace or >>> one you understand". Well gee, that's what we can do right >>> now without using an extensionData container to begin with. >>> >>> -hadriel >>> p.s. sorry for the rant. :( >>> >>> >> _______________________________________________ >> 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@alum.mit.edu Sun Oct 2 15:32: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 4AA1C21F84D5 for ; Sun, 2 Oct 2011 15:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB3GyIfiWdII for ; Sun, 2 Oct 2011 15:32:23 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 055DF21F84D3 for ; Sun, 2 Oct 2011 15:32:22 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id fx7S1h0021ei1Bg51ybNRy; Sun, 02 Oct 2011 22:35:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id fybM1h00M0tdiYw3kybMsY; Sun, 02 Oct 2011 22:35:22 +0000 Message-ID: <4E88E727.6010009@alum.mit.edu> Date: Sun, 02 Oct 2011 18:35:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: siprec@ietf.org References: <07465C1D981ABC41A344374066AE1A2C38B066C6FC@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E311F7B7CD35@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C38B066D0F5@TLVMBX01.nice.com> <2E239D6FCD033C4BAF15F386A979BF510F0F56@sonusinmail02.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E311F7B7CFC3@MCHP058A.global-ad.net> <2E239D6FCD033C4BAF15F386A979BF510F0F84@sonusinmail02.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E311F7B7D168@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E311F7B7D168@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [siprec] SRS-initiated initial INVITE 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, 02 Oct 2011 22:32:25 -0000 On 9/23/11 5:13 AM, Hutton, Andrew wrote: > Hi, > > I think Friso is correct this is covered in the protocol draft and it works like this. > > 1. The SRS includes a Require header field with the option tag "recording-session". This means that the UAS that receives the INVITE has to understand SIPREC or it will reject the INVITE. > > 2. The SRS also includes the feature tag "SRS" in the contact so that the UAS that receives it knows that it is an SRS that initiated the INVITE for the purpose of creating a recording session so it has to become the SRC. Therefore if the UAS is an SRC that does not handle SRS initiated INVITE's it should reject the INVITE at this point. Maybe we could say something about this in the protocol draft. IMO this isn't sufficient. SIP feature tags in Contact encode "callee capabilities". They don't say anything about what the recipient should do. I think there are a couple of choices here: - we can require that an SRC and an SRS have a unique URI, that behaves only as an SRC/SRS, never any other way. And only when addressed by such a URI does it support the siprec option and advertise support for the corresponding capability/feature-tag. - we can permit the same URI to be used for an RS or a CS. In this case it can support siprec all the time, and announce an SRC or SRS feature tag all the time. But then we need something to indicate "behave as an SRC" or "behave as an SRS". Thanks, Paul > The only issue I see is possible in the naming of the "recording-session" option tag as this should not be used as an indication that this is a recording session it is only used to indicate to the UAS that it should reject the INVITE if it does not understand SIPREC extensions. However this is just a naming issue. > > Regards > Andy > > >> -----Original Message----- >> From: Elwell, John >> Sent: 23 September 2011 09:42 >> To: Feenstra, Friso; Ravindran Parthasarathi; Hutton, Andrew; Leon >> Portman; siprec@ietf.org >> Subject: RE: [siprec] SRS-initiated initial INVITE >> >> Friso, >> >> Quite right, it is not yet covered, and the whole purpose of this >> thread is to discuss whether something needs to go into the protocol >> draft to cover the SRS-initiated case, to align with the architecture >> draft. >> >> John >> >> >>> -----Original Message----- >>> From: Feenstra, Friso [mailto:friso.feenstra@logica.com] >>> Sent: 23 September 2011 09:23 >>> To: Elwell, John; Ravindran Parthasarathi; Hutton, Andrew; >>> Leon Portman; siprec@ietf.org >>> Subject: RE: [siprec] SRS-initiated initial INVITE >>> >>> Hi John, >>> >>> Please excuse me as being relative new to this, but is this >>> not covered by the current description in Session Recording >>> Protocol draft-ietf-siprec-protocol-00 paragraph 5.1 and 5.2? >>> >>> Friso ( as individual) >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: vrijdag 23 september 2011 10:04 >>> To: Ravindran Parthasarathi; Hutton, Andrew; Leon Portman; >>> Feenstra, Friso; siprec@ietf.org >>> Subject: RE: [siprec] SRS-initiated initial INVITE >>> >>> I think we need to avoid violating the semantics of Require. >>> The Require header field just means reject the request if you >>> don't understand this extension. If you want a >>> SIPREC-compliant UAS to act as an SRC, I think you also need >>> to put something in the INVITE request to this effect. This >>> could simply be the srs feature tag. So we could specify that >>> if an entity receives an INVITE request with an srs feature >>> tag this is to be interpreted as a request to become an SRC. >>> If the UAS is not prepared to do this it can reject it >>> somehow (e.g., 403 Forbidden). >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] >>>> Sent: 23 September 2011 07:46 >>>> To: Hutton, Andrew; Leon Portman; Elwell, John; Feenstra, >>>> Friso; siprec@ietf.org >>>> Subject: RE: [siprec] SRS-initiated initial INVITE >>>> >>>> Hi Andrew, >>>> >>>> Thanks for correction. I assumed that softswitch as B2BUA. >>>> So, the scenario is that SIP proxy which does not want to >>>> push the intelligence to its UA but push it to some-other server. >>>> >>>> I'm fine as long as there is no extra normative statement for >>>> SRC. Let us also spell out the error-code for recording >>>> request rejection by SRC in case of INVITE without offer. >>>> >>>> Thanks >>>> Partha >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >>>>> Sent: Friday, September 23, 2011 1:37 AM >>>>> To: Ravindran Parthasarathi; Leon Portman; Elwell, John; Feenstra, >>>>> Friso; siprec@ietf.org >>>>> Subject: RE: [siprec] SRS-initiated initial INVITE >>>>> >>>>> Hi Partha, >>>>> >>>>> But in Friso's scenario the "softswitch" is really acting >>> just a SIP >>>>> Proxy so it cannot be the case that the SIP Proxy and the >>> SIP UA are >>>>> acting as a kind of decomposed SRC. >>>>> >>>>> Of course whether a given SRC implements the capability to receive >>>>> INVITE's from the SRS is an implementation option if it does >>>> not the SRC >>>>> will reject the INVITE due to the recording-session option >>> tag in the >>>>> Require header. >>>>> >>>>> Regards >>>>> >>>>> Andy (As an individual). >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] >>>>>> Sent: 22 September 2011 18:43 >>>>>> To: Leon Portman; Hutton, Andrew; Elwell, John; Feenstra, Friso; >>>>>> siprec@ietf.org >>>>>> Subject: RE: [siprec] SRS-initiated initial INVITE >>>>>> >>>>>> >>>>>> I have earlier mentioned as a not good design because better >>>>>> alternative exists for the same recording topology within SIPREC >>>>>> solution. I look at Friso recording topology as decomposed >>>> SRC to SRS >>>>>> network topology and details are as follows: >>>>>> >>>>>> 1) Softswitch& Agent phone act as SRC wherein Softswitch is a >>>>>> signaling Entity (SIP) and Agent phone as media entity (RTP). >>>>>> 2) Softswitch communicates with SRS in the standard SIPREC >>>> RS session >>>>>> establishment (with extension data) to SRS. >>>>>> 3) Based on SRS negotiation, softswitch indicates to agent >>>> phone using >>>>>> proprietary SDP extension with m-line addition (to start >>> recording >>>>>> towards SRS). Here, Agent phone forks the media towards >>> SRS. I have >>>>>> mentioned proprietary SDP extension because the >>> interaction between >>>>>> decomposed SRC is outside the scope of SIPREC. (I know of >>>> the working >>>>>> solution in the fashion for the call center). >>>>>> >>>>>> The advantages in this decomposed SRC solution are >>>>>> 1) There is no need of extra CTI or equivalent channel between >>>>>> softswitch& SRS. >>>>>> 2) Agent phone has no need to handle multiple dialogs (CS& RS). >>>>>> 3) It is easy for tracking the session from Softswitch >>> during agent >>>>>> transfer as it is acting as SRC. >>>>>> 4) No need to use "join" or some unique session-id >>> between all the >>>>>> entities >>>>>> >>>>>> Any recording entity has to support multiple m-lines in >>> SDP and so, >>>>>> there is no difference for agent-phone between SRS-initiated >> and >>>>>> decomposed SRC media box. Please correct in case any other >>>> advantage >>>>> in >>>>>> SRS-initiated solution compare to decomposed-SRC. >>>>>> >>>>>> >>>>>> Having said that, I'm fine with SRS-initiated INVITE in >>>> case everybody >>>>>> is interested for some specific callflow but I'm not >>> interested to >>>>> hear >>>>>> more mandate in SRC to handle this callflow. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> PS: The proposed decomposed SRC solution may work in >>>> RTCWeb recording >>>>>> solution between RTCWebserver& browser ;-) >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf >>>>>>> Of Leon Portman >>>>>>> Sent: Thursday, September 22, 2011 7:34 PM >>>>>>> To: Hutton, Andrew; Elwell, John; Feenstra, Friso; >>> siprec@ietf.org >>>>>>> Subject: Re: [siprec] SRS-initiated initial INVITE >>>>>>> >>>>>>> Andy Hi >>>>>>> >>>>>>> I will update the drafts with below. I agree on the flow >>>>>>> >>>>>>> Leon >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hutton, Andrew >>> [mailto:andrew.hutton@siemens-enterprise.com] >>>>>>> Sent: Thursday, September 22, 2011 4:28 PM >>>>>>> To: Elwell, John; Feenstra, Friso; Leon Portman; >> siprec@ietf.org >>>>>>> Subject: RE: [siprec] SRS-initiated initial INVITE >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I think what Friso describes is a perfectly valid use >>> case and is >>>>>>> something that we intended to cover in SIPREC hence the >> existing >>>>>> section >>>>>>> in the architecture draft. >>>>>>> >>>>>>> I don't think we need to be concerned with how the SRS >>>> knows when to >>>>>>> start recording this could be via CTI, SIP Dialog Events or >> many >>>>>> others >>>>>>> means. This is I think out of scope of SIPREC. >>>>>>> >>>>>>> What I think we do need to do is tidy up the architecture draft >>>>>> (Section >>>>>>> 3.2.2) which covers this use SRS initiated recording. We >>>> need to say >>>>>>> more about how the CS that is to be recorded is >>>> identified. Currently >>>>>>> the arch draft says that one possibly way of doing this >>>> is using the >>>>>>> "Join" header which obviously only applies if the CS >>>> dialog already >>>>>>> exists and the SRS knows the dialog identifiers. >>>>>>> >>>>>>> Do people think that specifying the use of "Join" for >>>> this purpose is >>>>>>> useful or can we just say something generic about the >>> Request-URI >>>>>>> identifying what needs to be recorded? >>>>>>> >>>>>>> I also noticed a mistake in section 3.2.2 of the >>>> architecture draft >>>>> in >>>>>>> the 4th bullet "Session Recording Client" should be "Session >>>>> Recording >>>>>>> Server" as this refers to the case when the SRS >>> generates the SDP >>>>>> offer. >>>>>>> Leon as you have the pen can you fix this. >>>>>>> >>>>>>> Andy (As individual). >>>>>>> >>>>>>> Andrew Hutton >>>>>>> http://www.siemens-enterprise.com/uk/ >>>>>>> >>>>>>> Siemens Enterprise Communications Limited. >>>>>>> Registered office: Brickhill Street, Willen Lake, Milton >>>> Keynes, MK15 >>>>>>> 0DJ. >>>>>>> Registered No: 5903714, England. >>>>>>> >>>>>>> Siemens Enterprise Communications Limited is a Trademark >>>> Licensee of >>>>>>> Siemens AG. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>> Behalf Of Elwell, John >>>>>>>> Sent: 22 September 2011 08:47 >>>>>>>> To: Feenstra, Friso; Leon Portman; siprec@ietf.org >>>>>>>> Subject: Re: [siprec] SRS-initiated initial INVITE >>>>>>>> >>>>>>>> What Friso describes is fairly similar to what I had in mind. >>>>>>>> Basically the SRS knows, through some out-of-band means >>>> (e.g., CTI, >>>>>>>> human involvement), that it should record a CS or CSs (e.g., >>>>>>>> persistent recording of CSs involving a given user, >>>> recording the >>>>>>>> current CS of a particular user). Based on this it can >>>> construct a >>>>>> URI >>>>>>>> that identifies the SRC and instructs it what to record. >>>>>>>> >>>>>>>> Personally I am more interested in the case where the >>>> SRS is at a >>>>>>>> B2BUA. Although the UA case is also potentially of >>>> interest, that >>>>>>>> tends to have limited applicability for the following >> reasons: >>>>>>>> - requires SRC support at all UAs that might be >>> involved, rather >>>>>> than >>>>>>>> just in one or a few network entities; >>>>>>>> - bandwidth limitations, particularly for mobile >>> users and users >>>>>> with >>>>>>>> limited uplink speeds. >>>>>>>> >>>>>>>> Since SRS-initiated INVITEs do not require any new SIP >>>> mechanism, >>>>> it >>>>>>>> seems quite reasonable to me to allow them. >>>>>>>> >>>>>>>> John (as individual) >>>>>>>> >>>>>>>> John Elwell >>>>>>>> Tel: +44 1908 817801 (office and mobile) >>>>>>>> Email: john.elwell@siemens-enterprise.com >>>>>>>> http://www.siemens-enterprise.com/uk/ >>>>>>>> >>>>>>>> Siemens Enterprise Communications Limited. >>>>>>>> Registered office: Brickhill Street, Willen Lake, >>> Milton Keynes, >>>>>> MK15 >>>>>>>> 0DJ. >>>>>>>> Registered No: 5903714, England. >>>>>>>> >>>>>>>> Siemens Enterprise Communications Limited is a >>>> Trademark Licensee >>>>> of >>>>>>>> Siemens AG. >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of >>> Feenstra, Friso >>>>>>>>> Sent: 21 September 2011 08:31 >>>>>>>>> To: Leon Portman; siprec@ietf.org >>>>>>>>> Subject: Re: [siprec] SRS-initiated initial INVITE >>>>>>>>> >>>>>>>>> Leon, >>>>>>>>> >>>>>>>>> Yes, this is correct and this is how I would like >>> it to work. >>>>>>>>> >>>>>>>>> A few additional notes. >>>>>>>>> a. The implementation details of the CTI signalling between >>>>>>>>> softswitch and SRS is out of scope for the SIPREC >>>> standard, but >>>>>> most >>>>>>>>> softswitches offer a form of CTI signalling that can >>>> be used for >>>>>>>>> this signalling. >>>>>>>>> b. It is not defined how much info is send with the >>>> SDP from the >>>>>> SRS >>>>>>>>> to the SRC (via the softswitch). Worse case an >>>> offerless invite >>>>> is >>>>>>>>> send to start the RS session, next the SRC will >>> provide the CS >>>>>> info >>>>>>>>> in the OK with SDP and Metadata and the SRS will select the >>>>>> correct >>>>>>>>> streams with the ACK or through a re-Invite. >>>>>>>>> c. I anticipate that the forwarding by the softswitch >>>> of Invite >>>>>>>>> messages (CS and RS) is a 'standard' feature for the >>>> softswitch >>>>>>>>> acting as a SIP proxy server and as such can be left >>>> outside the >>>>>>>>> scope of the SIPREC standard. >>>>>>>>> >>>>>>>>> As an individual, >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Friso >>>>>>>>> >>>>>>>>> friso.feenstra@logica.com >>>>>>>>> +31 6 415 46 305 >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>>> Sent: dinsdag 20 september 2011 18:03 >>>>>>>>> To: Feenstra, Friso; siprec@ietf.org >>>>>>>>> Cc: Ravindran Parthasarathi; Paul Kyzivat >>>>>>>>> Subject: RE: [siprec] SRS-initiated initial INVITE >>>>>>>>> >>>>>>>>> Friso >>>>>>>>> >>>>>>>>> It is a very good discussion. Let me try to understand the >>>>>> proposed >>>>>>>>> sequence for example as incoming call from UA A to >>>> UA B, where >>>>> UA >>>>>> B >>>>>>>>> is SRC. >>>>>>>>> Actually UA B and softswitch are decomposed SRC. >>>>>>>>> >>>>>>>>> 1. UA A sends CS INVITE to softswitch 2. softswitch sends >> CS >>>>>> INVITE >>>>>>>>> to UA B (SRC) 3. softswitch reports via CTI to SRS >>>> about CS (UA A >>>>>>>>> calling UA B) 4. SRS decides to record and sends RS >>>> INVITE with >>>>>> SDP >>>>>>>>> to softswitch with some CS mapping info 5. >>> Softswitch sends RS >>>>>>>>> INVITE to UA B that acts as SRC 6. UA B send OK with >>>> its SDP via >>>>>>>>> softswitch to SRS >>>>>>>>> >>>>>>>>> This flow will require definition additional >>>> interface for step 3 >>>>>>>>> and for softswitch to implement step 5 Is it correct flow? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Leon >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Feenstra, Friso [mailto:friso.feenstra@logica.com] >>>>>>>>> Sent: Tuesday, September 20, 2011 6:34 PM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Cc: Leon Portman; Ravindran Parthasarathi; Paul Kyzivat >>>>>>>>> Subject: RE: [siprec] SRS-initiated initial INVITE >>>>>>>>> >>>>>>>>> Partha and Leon, >>>>>>>>> >>>>>>>>> The business intelligence (Policy Manager) in our >>> case is with >>>>> the >>>>>>>>> SRS and like the softswitch (acting as a SIP proxy) >>>> is deployed >>>>> on >>>>>> a >>>>>>>>> central location. >>>>>>>>> Agent handsets (UA's) are globally dispersed. So I am >>>> definitely >>>>>>>>> looking for a SIPREC solution where the SRC is >>>> implemented on the >>>>>> UA >>>>>>>>> (agent handset). >>>>>>>>> >>>>>>>>> When only the SRC can provide the RS Invite than additional >>>>>>>>> signalling is needed to initiate the recording between SRS >>>>> (Policy >>>>>>>>> Manager) and softswitch (CTI based API) and between >>> softswitch >>>>> and >>>>>>>>> agent handset (UA) (SIP?). So standards are needed for CTI >>>>>>>>> signalling from Policy Manager / SRS to softswitch and from >>>>>>>>> softswitch to the agent handset. >>>>>>>>> >>>>>>>>> Another reason why this is not a good idea, is that an >> extra >>>>>>>>> component (softswitch) is involved in the RS setup for the >>>>>>>>> conversion of the CTI message from the SRS into a SIP >>>>>>>>> message(?) towards the handset (SRC). >>>>>>>>> >>>>>>>>> With an SRS initiated flow the additional signalling >>>> definition >>>>> is >>>>>>>>> not needed and only minimal changes are needed on the >>>> softswitch >>>>>>>>> acting as a SIP proxy. >>>>>>>>> >>>>>>>>> Having all the agent handsets always start a RS >>>> session for each >>>>>> CS >>>>>>>>> would be quite a waste of SIP sessions, >>> specifically since the >>>>>>>>> softswitch is involved as SIP-proxy in all session setup >> and >>>>> since >>>>>>>>> only a limited number of sessions will need >>>>>>>> recording. >>>>>>>>> >>>>>>>>> As such I would appreciate the option of a SRS >>> based Invite in >>>>> the >>>>>>>>> standards. >>>>>>>>> >>>>>>>>> As an individual, >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Friso >>>>>>>>> friso.feenstra@logica.com >>>>>>>>> +31 6 415 46 305 >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ravindran Parthasarathi >>> [mailto:pravindran@sonusnet.com] >>>>>>>>> Sent: dinsdag 20 september 2011 16:22 >>>>>>>>> To: Feenstra, Friso; Paul Kyzivat; siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] SRS-initiated initial INVITE >>>>>>>>> >>>>>>>>> Friso, >>>>>>>>> >>>>>>>>> In case I remember correctly, the same SRS callflow >>>> was discussed >>>>>>>>> long back. The mentioned callflow is not good design in my >>>>> opinion >>>>>>>>> because extra channel is required between softswitch >>>> & SRS apart >>>>>>>>> from SIPREC framework. >>>>>>>>> >>>>>>>>> The alternative is to start the recording from agent >> handset >>>>>> towards >>>>>>>>> SRS with CS id. Please let me know the issue in this >>>> approach. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] >>>>> On >>>>>>>>>> Behalf Of Feenstra, Friso >>>>>>>>>> Sent: Tuesday, September 20, 2011 7:38 PM >>>>>>>>>> To: Paul Kyzivat; siprec@ietf.org >>>>>>>>>> Subject: Re: [siprec] SRS-initiated initial INVITE >>>>>>>>>> >>>>>>>>>> Paul, >>>>>>>>>> >>>>>>>>>> Business intelligence is in the SRS. SRS is informed >>>>>>>>> out-of-band that >>>>>>>>>> CS session is started. Based on the out-of-band provided >>>>>>>>>> information the SRS determines that RS is needed. >>> Part of the >>>>>> out- >>>>>>>>>> of-band information is the identification of the >>>> SRC. Based on >>>>>> this >>>>>>>>> information >>>>>>>>>> the (offerless) Invite is send to the SRC. >>>>>>>>>> >>>>>>>>>> The SRC intelligence is included in the UA (agent >>>> handset). This >>>>>>>>>> way only a limited implementation is needed on the >>>> controlling >>>>>>>>> softswitch. >>>>>>>>>> RS is managed between SRS recorder and agent handset. >>>>>>>>>> >>>>>>>>>> As an individual, >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Friso >>>>>>>>>> friso.feenstra@logica.com >>>>>>>>>> +31 6 415 46 305 >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] >>>>> On >>>>>>>>>> Behalf Of Paul Kyzivat >>>>>>>>>> Sent: dinsdag 20 september 2011 15:54 >>>>>>>>>> To: siprec@ietf.org >>>>>>>>>> Subject: Re: [siprec] SRS-initiated initial INVITE >>>>>>>>>> >>>>>>>>>> Friso, >>>>>>>>>> >>>>>>>>>> On 9/20/11 6:23 AM, Feenstra, Friso wrote: >>>>>>>>>>> As a new participant I would like to make the following >>>>> remark. >>>>>>>>>>> >>>>>>>>>>> We currently have a strong requirement for a >>>> ´intelligent´ SRS >>>>>>>>>>> capable >>>>>>>>>> of >>>>>>>>>>> >>>>>>>>>>> starting and stopping RS sessions. We want to deploy a >>>>>>>>> contact centre >>>>>>>>>>> >>>>>>>>>>> solution with agents dispersed around the globe. >>>> The business >>>>>>>>>> intelligence >>>>>>>>>>> >>>>>>>>>>> of what and when to record will be at the SRS, so the >> SRS >>>>>> should >>>>>>>> be >>>>>>>>>> capable >>>>>>>>>>> >>>>>>>>>>> determining what's to be recorded and of starting the >> RS. >>>>>>>>>> >>>>>>>>>> Could you explain more about how the intelligence is >>>>> distributed? >>>>>>>>>> How much does the SRS know a priori about the calls? >>>>>>>>>> And what is the granularity of the SRC? Are you imagining >>>>>>>>> that the SRC >>>>>>>>>> is on a per-agent basis? Or does an SRC cover many >>> agents and >>>>>> many >>>>>>>>>> concurrent calls? >>>>>>>>>> >>>>>>>>>>> An option could be that the SRS sends an offerless >>>> invite, as >>>>>>>>>> currently >>>>>>>>>>> >>>>>>>>>>> defined in the architecture. Next the SRC could provide >>>>>>>>> based on its >>>>>>>>>>> >>>>>>>>>>> knowledge of the current CS send the 200 OK with the SDP >>>>>>>>> and metadata >>>>>>>>>>> >>>>>>>>>>> describing the available sessions. With this >>> knowledge and >>>>>> based >>>>>>>> on >>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>> business intelligence in the SRS, the SRS could then >>>>>>>>> accept which of >>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>> available streams it would like for recording, >>> either in an >>>>> ACK >>>>>>>>>> response or >>>>>>>>>>> >>>>>>>>>>> through a re-Invite. >>>>>>>>>> >>>>>>>>>> I can see how this could at least scale right if >>> the SRC was >>>>>>>>> per-agent. >>>>>>>>>> But if the SRC was something like a PBX that >>> covered all the >>>>>>>>> agents in >>>>>>>>>> a facility, then it wouldn't scale reasonably, because the >>>>>>>>> offer would >>>>>>>>>> then contain perhaps hundreds of media streams. >>>>>>>>>> >>>>>>>>>>> I hope there will be room for this use case in the RFC. >>>>>>>>>>> >>>>>>>>>>> As an individual, >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Friso Feenstra >>>>>>>>>>> >>>>>>>>>>> Friso.feenstra@logica.com >>>> >>>>>>>>>>> >>>>>>>>>>> +31 6 415 46 305 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Think green - keep it on the screen. This e-mail and any >>>>>>>>> attachment >>>>>>>>>>> is for authorised use by the intended >>> recipient(s) only. It >>>>> may >>>>>>>>>>> contain proprietary material, confidential >>>> information and/or >>>>>> be >>>>>>>>>>> subject to legal privilege. It should not be >>>> copied, disclosed >>>>>>>>>>> to, retained or >>>>>>>>>> used >>>>>>>>>>> by, any other party. If you are not an intended >> recipient >>>>>>>>> then please >>>>>>>>>>> promptly delete this e-mail and any attachment and >>>> all copies >>>>>> and >>>>>>>>>> inform >>>>>>>>>>> the sender. Thank you. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Think green - keep it on the screen. >>>>>>>>>> >>>>>>>>>> This e-mail and any attachment is for authorised use by >> the >>>>>>>>>> intended >>>>>>>>>> recipient(s) only. It may contain proprietary material, >>>>>>>>>> confidential information and/or be subject to legal >>>> privilege. >>>>> It >>>>>>>>>> should not be copied, disclosed to, retained or >>> used by, any >>>>>> other >>>>>>> party. >>>>>>>>> If you are >>>>>>>>>> not an intended recipient then please promptly delete this >>>>>>>>> e-mail and >>>>>>>>>> any attachment and all copies and inform the sender. >>>> Thank you. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> siprec mailing list >>>>>>>>>> siprec@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>> >>>>>>>>> >>>>>>>>> Think green - keep it on the screen. >>>>>>>>> >>>>>>>>> This e-mail and any attachment is for authorised use by the >>>>>> intended >>>>>>>>> recipient(s) only. It may contain proprietary material, >>>>>> confidential >>>>>>>>> information and/or be subject to legal privilege. It >>>> should not >>>>> be >>>>>>>>> copied, disclosed to, retained or used by, any >>> other party. If >>>>> you >>>>>>>>> are not an intended recipient then please promptly >>> delete this >>>>>>>>> e-mail and any attachment and all copies and inform >>>> the sender. >>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Think green - keep it on the screen. >>>>>>>>> >>>>>>>>> This e-mail and any attachment is for authorised use by the >>>>>> intended >>>>>>>>> recipient(s) only. It may contain proprietary material, >>>>>> confidential >>>>>>>>> information and/or be subject to legal privilege. It >>>> should not >>>>> be >>>>>>>>> copied, disclosed to, retained or used by, any >>> other party. If >>>>> you >>>>>>>>> are not an intended recipient then please promptly >>> delete this >>>>>>>>> e-mail and any attachment and all copies and inform >>>> the sender. >>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>> >>> >>> >>> Think green - keep it on the screen. >>> >>> This e-mail and any attachment is for authorised use by the >>> intended recipient(s) only. It may contain proprietary >>> material, confidential information and/or be subject to legal >>> privilege. It should not be copied, disclosed to, retained or >>> used by, any other party. If you are not an intended >>> recipient then please promptly delete this e-mail and any >>> attachment and all copies and inform the sender. Thank you. >>> >>> >>> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pravindran@sonusnet.com Sun Oct 2 22:29: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 AEEFB21F86A0 for ; Sun, 2 Oct 2011 22:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRVqM7y-IQVp for ; Sun, 2 Oct 2011 22:29:45 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E77DC21F869E for ; Sun, 2 Oct 2011 22:29:44 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p935XHSF017360; Mon, 3 Oct 2011 01:33:17 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 01:32:44 -0400 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, 3 Oct 2011 11:02:40 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F12E8@sonusinmail02.sonusnet.com> In-Reply-To: <30452A56-0C9C-4311-844D-E892E7E8BAC8@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Consensus calls from session 2 Thread-Index: AQHMf7QSJK24++Wa60KuFSHyWSg79pVqGn7g References: <30452A56-0C9C-4311-844D-E892E7E8BAC8@acmepacket.com> From: "Ravindran Parthasarathi" To: "Hadriel Kaplan" , "Elwell, John" X-OriginalArrivalTime: 03 Oct 2011 05:32:44.0438 (UTC) FILETIME=[E0897B60:01CC818D] Cc: siprec@ietf.org Subject: Re: [siprec] Consensus calls from session 2 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, 03 Oct 2011 05:29:45 -0000 Hadriel, In case your intention of the below proposal normative statement is to avoid sending the error from SRS for the extension supported by SRC, then the normative statement is not required because the extension may be received in any place within namespace (not required in the specified xs:any location) and it is the basics of XML and nothing do with Metadata XML specifically. Please correct me in case every new XML (namespace) document has to have these extensions ignoring statement as per XML definition.=20 Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Hadriel Kaplan >Sent: Saturday, October 01, 2011 2:31 AM >To: Elwell, John >Cc: siprec@ietf.org >Subject: Re: [siprec] Consensus calls from session 2 > > >On Sep 26, 2011, at 3:10 AM, Elwell, John wrote: > >> [JRE] What slide 19 does is get rid of an unnecessary level of >. In metadata-04 the schema defines an element type >extensiondata and uses it in various places. This type is defined as >being a complexType consisting of the "xs:any" construct. This is not >valid syntax, and to make it valid xs:any would need to be embedded >within a element, e.g.: >> >> >> >> > minOccurs=3D'0' >> maxOccurs=3D'unbounded' >> processContents=3D'lax'/> >> >> >> This can be avoided simply by putting the xs:any construct within any >sequence where extension data is needed, such as within the session, >group, participant and stream sequences. Defining a separate type >extensiondata seems to force an additional level of sequence on the >wire. >> > >Ahhh - so what you're saying (I think) is that you *ARE* getting rid of >the "extensiondata" elements, and just using the xs:any schema extension >construct as per normal XML. Right? > >Sorry, that wasn't clear to me from the slides. >Good, so ignore my rant. Nothing to see here... move along. :) > >Oh, except I suggest the metadata document have this sentence in it >somewhere: > Other elements from different namespaces MAY be > present for the purposes of extensibility; elements or attributes > from unknown namespaces MUST be ignored. > >I didn't see that type of statement in it, but we should probably have >it. > >-hadriel > > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From internet-drafts@ietf.org Mon Oct 3 02:38:36 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 40B9A21F8B0D; Mon, 3 Oct 2011 02:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdngoo+ib5Ij; Mon, 3 Oct 2011 02:38:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E5F21F8AD6; Mon, 3 Oct 2011 02:38:35 -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.60 Message-ID: <20111003093835.12101.7822.idtracker@ietfa.amsl.com> Date: Mon, 03 Oct 2011 02:38:35 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-03.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, 03 Oct 2011 09:38:36 -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 : An Architecture for Media Recording using the Session In= itiation Protocol Author(s) : Andrew Hutton Leon Portman Rajnish Jain Ken Rehor Filename : draft-ietf-siprec-architecture-03.txt Pages : 16 Date : 2011-10-03 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 architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture-03.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-architecture-03.txt From Leon.Portman@nice.com Mon Oct 3 02:40: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 835C821F8AFF for ; Mon, 3 Oct 2011 02:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOKRgOq6e20U for ; Mon, 3 Oct 2011 02:40:10 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5F19021F8AED for ; Mon, 3 Oct 2011 02:40:09 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 3 Oct 2011 11:43:09 +0200 From: Leon Portman To: "siprec@ietf.org" , "Hutton, Andrew" , "rajnish.jain@ipc.com" , "Ken Rehor (krehor) (krehor@cisco.com)" Date: Mon, 3 Oct 2011 11:43:08 +0200 Thread-Topic: [siprec] New version of architecture draft Thread-Index: AcyBr+4wtwIoQzQNSiWSZBRVMNHq7g== Message-ID: <07465C1D981ABC41A344374066AE1A2C38B18C4709@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_07465C1D981ABC41A344374066AE1A2C38B18C4709TLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] New version of architecture draft 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, 03 Oct 2011 09:40:12 -0000 --_004_07465C1D981ABC41A344374066AE1A2C38B18C4709TLVMBX01nicec_ Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C38B18C4709TLVMBX01nicec_" --_000_07465C1D981ABC41A344374066AE1A2C38B18C4709TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Please see attached 03 version of architecture draft with changes from the = last interim meeting. Main changes: 1. Show one CS in SRC as B2BUA figure 1 2. Show generic decomposition of SRC by using mediactrl or RTC-web in= fig 4 3. Added acknowledge section. Who I am missing? 4. Fixed reference section Regards Leon --_000_07465C1D981ABC41A344374066AE1A2C38B18C4709TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello=

 

Please s= ee attached 03 version of architecture draft with changes from the last int= erim meeting.

Main changes:

1.       Show one CS in SRC as B2BUA figu= re 1

2.    =    Show generic de= composition of SRC by using mediactrl or RTC-web in fig 4

3.       Added acknowledge section. Who I am m= issing?

4.   &nb= sp;   Fixed refere= nce section

 

Regards

 <= /p>

Leon

= --_000_07465C1D981ABC41A344374066AE1A2C38B18C4709TLVMBX01nicec_-- --_004_07465C1D981ABC41A344374066AE1A2C38B18C4709TLVMBX01nicec_ Content-Type: text/plain; name="draft-ietf-siprec-architecture-03.txt" Content-Description: draft-ietf-siprec-architecture-03.txt Content-Disposition: attachment; filename="draft-ietf-siprec-architecture-03.txt"; size=33334; creation-date="Mon, 03 Oct 2011 09:30:51 GMT"; modification-date="Mon, 03 Oct 2011 09:30:51 GMT" Content-Transfer-Encoding: base64 CgoKU0lQUkVDICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEEuIEh1dHRvbiwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFNpZW1lbnMgRW50ZXJwcmlzZQpJbnRlbmRlZCBzdGF0dXM6ICBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29tbXVuaWNhdGlvbnMKRXhwaXJl czogIEFwcmlsIDUsIDIwMTIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTC4gUG9y dG1hbiwgRWQuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE5pY2UgU3lzdGVtcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEphaW4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElQQyBTeXN0ZW1z CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBLLiBSZWhvcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMsIEluYy4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAzLCAyMDExCgoKICAgIEFu IEFyY2hpdGVjdHVyZSBmb3IgTWVkaWEgUmVjb3JkaW5nIHVzaW5nIHRoZSBTZXNzaW9uIEluaXRp YXRpb24KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQcm90b2NvbAogICAgICAgICAg ICAgICAgICAgZHJhZnQtaWV0Zi1zaXByZWMtYXJjaGl0ZWN0dXJlLTAzCgpBYnN0cmFjdAoKICAg U2Vzc2lvbiByZWNvcmRpbmcgaXMgYSBjcml0aWNhbCByZXF1aXJlbWVudCBpbiBtYW55IGNvbW11 bmljYXRpb25zCiAgIGVudmlyb25tZW50cyBzdWNoIGFzIGNhbGwgY2VudGVycyBhbmQgZmluYW5j aWFsIHRyYWRpbmcuICBJbiBzb21lIG9mCiAgIHRoZXNlIGVudmlyb25tZW50cywgYWxsIGNhbGxz IG11c3QgYmUgcmVjb3JkZWQgZm9yIHJlZ3VsYXRvcnksCiAgIGNvbXBsaWFuY2UsIGFuZCBjb25z dW1lciBwcm90ZWN0aW9uIHJlYXNvbnMuICBSZWNvcmRpbmcgb2YgYSBzZXNzaW9uCiAgIGlzIHR5 cGljYWxseSBwZXJmb3JtZWQgYnkgc2VuZGluZyBhIGNvcHkgb2YgYSBtZWRpYSBzdHJlYW0gdG8g YQogICByZWNvcmRpbmcgZGV2aWNlLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYXJjaGl0ZWN0 dXJlcyBmb3IKICAgZGVwbG95aW5nIHNlc3Npb24gcmVjb3JkaW5nIHNvbHV0aW9ucyBpbiBhbiBl bnZpcm9ubWVudCB3aGljaCBpcwogICBiYXNlZCBvbiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFBy b3RvY29sIChTSVApLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFm dCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25z IG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRv Y3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURiku ICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBk b2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5l dC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3Vy cmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3Ig YSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwg b3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJp YWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAg VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBBcHJpbCA1LCAyMDEyLgoKQ29weXJp Z2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJz b25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJl c2VydmVkLgoKCgpIdXR0b24sIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgNSwgMjAx MiAgICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFyY2hpdGVj dHVyZSBmb3IgTWVkaWEgUmVjb3JkaW5nICAgICAgICBPY3RvYmVyIDIwMTEKCgogICBUaGlzIGRv Y3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAg IFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVl LmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1Ymxp Y2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwog ICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9u cyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRy YWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBM aWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBM ZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBk ZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgoKVGFibGUgb2YgQ29udGVu dHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMwogICAyLiAgRGVmaW5pdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgMy4gIFNlc3Npb24gUmVjb3Jk aW5nIEFyY2hpdGVjdHVyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAg My4xLiAgTG9jYXRpb24gb2YgdGhlIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCAuIC4gLiAuIC4g LiAuIC4gLiAgNQogICAgICAgMy4xLjEuICBCMkJVQSBhY3RzIGFzIGEgU2Vzc2lvbiBSZWNvcmRp bmcgQ2xpZW50IC4gLiAuIC4gLiAuIC4gIDUKICAgICAgIDMuMS4yLiAgRW5kcG9pbnQgYWN0cyBh cyBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgIC4gLiAuIC4gLiAuICA3CiAgICAgICAzLjEuMy4g IEEgU0lQIFByb3h5IGNhbm5vdCBiZSBhIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCAuIC4gLiAg NwogICAgICAgMy4xLjQuICBJbnRlcmFjdGlvbiB3aXRoIE1FRElBQ1RSTCAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDgKICAgICAgIDMuMS41LiAgSW50ZXJhY3Rpb24gd2l0aCBDb25mZXJl bmNlIEZvY3VzICAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgICAgMy4yLiAgRXN0YWJsaXNoaW5n IHRoZSBSZWNvcmRpbmcgU2Vzc2lvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAogICAgICAg My4yLjEuICBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgSW5pdGlhdGVkIFJlY29yZGluZyAuIC4g LiAuIC4gMTEKICAgICAgIDMuMi4yLiAgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyIEluaXRpYXRl ZCBSZWNvcmRpbmcgLiAuIC4gLiAuIDExCiAgICAgICAzLjIuMy4gIFBhdXNlL1Jlc3VtZSBSZWNv cmRpbmcgU2Vzc2lvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMgogICAgICAgMy4yLjQuICBN ZWRpYSBTdHJlYW0gTWl4aW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTIK ICAgICAgIDMuMi41LiAgTWVkaWEgVHJhbnNjb2RpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDEyCiAgICAgMy4zLiAgTWVkaWEgUmVjb3JkaW5nIE1ldGFkYXRhIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMgogICAgICAgMy4zLjEuICBDb250ZW50cyBv ZiByZWNvcmRpbmcgbWV0YWRhdGEgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgICAgIDMu My4yLiAgTWVjaGFuaXNtcyBmb3IgZGVsaXZlcnkgb2YgbWV0YWRhdGEgdG8gU2Vzc2lvbgogICAg ICAgICAgICAgICBSZWNvcmRpbmcgU2VydmVyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTMKICAgICAzLjQuICBOb3RpZmljYXRpb25zIHRvIHRoZSBSZWNvcmRlZCBVc2Vy IEFnZW50cyAgLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgMy41LiAgUHJldmVudGluZyB0aGUgcmVj b3JkaW5nIG9mIGEgU0lQIHNlc3Npb24gIC4gLiAuIC4gLiAuIC4gLiAxMwogICA0LiAgSUFOQSBj b25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTMKICAgNS4gIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEzCiAgIDYuICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAogICA3LiAgSW5mb3JtYXRpdmUgUmVm ZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQKICAgQXV0 aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDE1CgoKCgoKCgoKCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBB cHJpbCA1LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAg ICAgQXJjaGl0ZWN0dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgIE9jdG9iZXIgMjAxMQoK CjEuICBJbnRyb2R1Y3Rpb24KCiAgIFNlc3Npb24gcmVjb3JkaW5nIGlzIGEgY3JpdGljYWwgcmVx dWlyZW1lbnQgaW4gbWFueSBjb21tdW5pY2F0aW9ucwogICBlbnZpcm9ubWVudHMgc3VjaCBhcyBj YWxsIGNlbnRlcnMgYW5kIGZpbmFuY2lhbCB0cmFkaW5nLiAgSW4gc29tZSBvZgogICB0aGVzZSBl bnZpcm9ubWVudHMsIGFsbCBjYWxscyBtdXN0IGJlIHJlY29yZGVkIGZvciByZWd1bGF0b3J5LAog ICBjb21wbGlhbmNlLCBhbmQgY29uc3VtZXIgcHJvdGVjdGlvbiByZWFzb25zLiAgUmVjb3JkaW5n IG9mIGEgc2Vzc2lvbgogICBpcyB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IHNlbmRpbmcgYSBjb3B5 IG9mIGEgbWVkaWEgc3RyZWFtIHRvIGEKICAgcmVjb3JkaW5nIGRldmljZS4gIFRoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIGFyY2hpdGVjdHVyZXMgZm9yCiAgIGRlcGxveWluZyBzZXNzaW9uIHJlY29y ZGluZyBzb2x1dGlvbnMgaW4gYW4gZW52aXJvbm1lbnQgd2hpY2ggaXMKICAgYmFzZWQgb24gdGhl IFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSB0aGUgcmVxdWlyZW1lbnRzIGZvcgog ICB3aGljaCBhcmUgZGVzY3JpYmVkIGluIFtSRkM2MzQxXS4KCiAgIFRoaXMgZG9jdW1lbnQgZm9j dXNlcyBvbiBob3cgc2Vzc2lvbnMgYXJlIGVzdGFibGlzaGVkIGJldHdlZW4gYQogICBTZXNzaW9u IFJlY29yZGluZyBDbGllbnQgKFNSQykgYW5kIHRoZSBTZXNzaW9uIFJlY29yZGluZyBTZXJ2ZXIg KFNSUykKICAgZm9yIHRoZSBwdXJwb3NlIG9mIGNvbnZleWluZyB0aGUgUmVwbGljYXRlZCBNZWRp YSBhbmQgTWVkaWEgUmVjb3JkaW5nCiAgIE1ldGFkYXRhIChlLmcuICBJZGVudGl0eSBvZiBwYXJ0 aWVzIGludm9sdmVkKSByZWxhdGluZyB0byB0aGUKICAgQ29tbXVuaWNhdGlvbiBTZXNzaW9uLgoK ICAgT25jZSB0aGUgUmVwbGljYXRlZCBNZWRpYSBhbmQgTWVkaWEgUmVjb3JkaW5nIE1ldGFkYXRh IGhhdmUgYmVlbgogICByZWNlaXZlZCBieSB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyIHRo ZXkgd2lsbCB0eXBpY2FsbHkgYmUKICAgYXJjaGl2ZWQgZm9yIHJldHJpZXZhbCBhdCBhIGxhdGVy IHRpbWUuICBUaGUgcHJvY2VkdXJlcyByZWxhdGluZyB0bwogICB0aGUgYXJjaGl2aW5nIGFuZCBy ZXRyaWV2YWwgb2YgdGhpcyBpbmZvcm1hdGlvbiBpbiBvdXRzaWRlIHRoZSBzY29wZQogICBvZiB0 aGlzIGRvY3VtZW50LgoKICAgVGhpcyBkb2N1bWVudCBvbmx5IGNvbnNpZGVycyBhY3RpdmUgcmVj b3JkaW5nLCB3aGVyZSB0aGUgU2Vzc2lvbgogICBSZWNvcmRpbmcgQ2xpZW50IHB1cnBvc2VmdWxs eSBzdHJlYW1zIG1lZGlhIHRvIGEgU2Vzc2lvbiBSZWNvcmRpbmcKICAgU2VydmVyLiAgUGFzc2l2 ZSByZWNvcmRpbmcsIHdoZXJlIGEgcmVjb3JkaW5nIGRldmljZSBkZXRlY3RzIG1lZGlhCiAgIGRp cmVjdGx5IGZyb20gdGhlIG5ldHdvcmsgKEUuZy4gdXNpbmcgcG9ydCBtaXJyb3JpbmcgdGVjaG5p cXVlcyksIGlzCiAgIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICBJbiBhZGRp dGlvbiwgbGF3ZnVsIGludGVyY2VwdCBpcwogICBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRv Y3VtZW50IHdoaWNoIHRha2VzIGFjY291bnQgb2YgdGhlIElFVEYKICAgcG9saWN5IG9uIHdpcmV0 YXBwaW5nIFtSRkMyODA0XS4KCiAgIFRoZSBSZWNvcmRpbmcgU2Vzc2lvbiB0aGF0IGlzIGVzdGFi bGlzaGVkIGJldHdlZW4gdGhlIFNlc3Npb24KICAgUmVjb3JkaW5nIENsaWVudCBhbmQgdGhlIFNl c3Npb24gUmVjb3JkaW5nIFNlcnZlciB1c2VzIHRoZSBub3JtYWwKICAgcHJvY2VkdXJlcyBmb3Ig ZXN0YWJsaXNoaW5nIElOVklURSBpbml0aWF0ZWQgZGlhbG9ncyBhcyBzcGVjaWZpZWQgaW4KICAg W1JGQzMyNjFdIGFuZCB1c2VzIFNEUCBmb3IgZGVzY3JpYmluZyB0aGUgbWVkaWEgdG8gYmUgdXNl ZCBkdXJpbmcgdGhlCiAgIHNlc3Npb24gYXMgc3BlY2lmaWVkIGluIFtSRkM0NTY2XS4gIEhvd2V2 ZXIgaXQgaXMgaW50ZW5kZWQgdGhhdCBzb21lCiAgIGV4dGVuc2lvbnMgdG8gU0lQIChFLmcuICBI ZWFkZXJzLCBPcHRpb24gVGFncywgRXRjLikgd2lsbCBiZSBkZWZpbmVkCiAgIHRvIHN1cHBvcnQg dGhlIHJlcXVpcmVtZW50cyBmb3IgbWVkaWEgcmVjb3JkaW5nLiAgVGhlIFJlcGxpY2F0ZWQKICAg TWVkaWEgaXMgcmVxdWlyZWQgdG8gYmUgc2VudCBpbiByZWFsLXRpbWUgdG8gdGhlIFNlc3Npb24g UmVjb3JkaW5nCiAgIFNlcnZlciBhbmQgaXMgbm90IGJ1ZmZlcmVkIGJ5IHRoZSBTZXNzaW9uIFJl Y29yZGluZyBDbGllbnQgdG8gYWxsb3cKICAgZm9yIHJlYWwtdGltZSBhbmFseXNpcyBvZiB0aGUg bWVkaWEgYnkgdGhlIFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlci4KCgoKCgoKCgoKSHV0dG9uLCBl dCBhbC4gICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAgICAgICAgICAgICAgIFtQ YWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBBcmNoaXRlY3R1cmUgZm9yIE1lZGlhIFJlY29y ZGluZyAgICAgICAgT2N0b2JlciAyMDExCgoKMi4gIERlZmluaXRpb25zCgogICBTZXNzaW9uIFJl Y29yZGluZyBTZXJ2ZXIgKFNSUyk6ICBBIFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlciAoU1JTKSBp cwogICBhIFNJUCBVc2VyIEFnZW50IChVQSkgdGhhdCBhY3RzIGFzIHRoZSBzaW5rIG9mIHRoZSBy ZWNvcmRlZCBtZWRpYS4KICAgQW4gU1JTIGlzIGEgbG9naWNhbCBmdW5jdGlvbiB0aGF0IHR5cGlj YWxseSBhcmNoaXZlcyBtZWRpYSBmb3IKICAgZXh0ZW5kZWQgZHVyYXRpb25zIG9mIHRpbWUgYW5k IHByb3ZpZGVzIGludGVyZmFjZXMgZm9yIHNlYXJjaCBhbmQKICAgcmV0cmlldmFsIG9mIHRoZSBh cmNoaXZlZCBtZWRpYS4gIEFuIFNSUyBpcyB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgYXMKICAgYSBt dWx0aS1wb3J0IGRldmljZSB0aGF0IGlzIGNhcGFibGUgb2YgcmVjZWl2aW5nIG1lZGlhIGZyb20g c2V2ZXJhbAogICBzb3VyY2VzIHNpbXVsdGFuZW91c2x5LiAgQW4gU1JTIGlzIHRoZSBzaW5rIG9m IHRoZSByZWNvcmRlZCBzZXNzaW9uCiAgIG1ldGFkYXRhLiAgTm90ZSB0aGF0IHRoZSB0ZXJtICJT ZXJ2ZXIiIGRvZXMgbm90IGltcGx5IHRoZSBTUlMgaXMgdGhlCiAgIHNlcnZlciBzaWRlIG9mIGEg c2lnbmFsaW5nIHByb3RvY29sIGFzIHRoZSBTUlMgbWF5IGJlIHRoZSBpbml0aWF0b3IKICAgb2Yg cmVjb3JkaW5nIHJlcXVlc3RzLgoKICAgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50IChTUkMpOiAg QSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgKFNSQykgaXMKICAgYSBTSVAgVXNlciBBZ2VudCAo VUEpIHRoYXQgYWN0cyBhcyB0aGUgc291cmNlIG9mIHRoZSByZWNvcmRlZCBtZWRpYSwKICAgc2Vu ZGluZyBpdCB0byB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyLiAgQSBTZXNzaW9uIFJlY29y ZGluZwogICBDbGllbnQgaXMgYSBsb2dpY2FsIGZ1bmN0aW9uLiAgSXRzIGNhcGFiaWxpdGllcyBt YXkgYmUgaW1wbGVtZW50ZWQKICAgYWNyb3NzIG9uZSBvciBtb3JlIHBoeXNpY2FsIGRldmljZXMu ICBJbiBwcmFjdGljZSwgYSBTZXNzaW9uCiAgIFJlY29yZGluZyBDbGllbnQgY291bGQgYmUgYSBw ZXJzb25hbCBkZXZpY2UgKHN1Y2ggYXMgYSBTSVAgcGhvbmUpLCBhCiAgIFNJUCBNZWRpYSBHYXRl d2F5IChNRyksIGEgU2Vzc2lvbiBCb3JkZXIgQ29udHJvbGxlciAoU0JDKSwgTWVkaWEKICAgU2Vy dmVyLCBvciBhbiBBcHBsaWNhdGlvbiBTZXJ2ZXIuICBUaGUgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xp ZW50IGlzCiAgIGFsc28gdGhlIHNvdXJjZSBvZiB0aGUgcmVjb3JkZWQgc2Vzc2lvbiBtZXRhZGF0 YS4KCiAgIENvbW11bmljYXRpb24gU2Vzc2lvbiAoQ1MpOiAgQSBTSVAgc2Vzc2lvbiBjcmVhdGVk IGJldHdlZW4gdHdvIG9yCiAgIG1vcmUgVUEncyBmb3IgdGhlIHB1cnBvc2Ugb2YgY29tbXVuaWNh dGlvbiB3aGljaCBtYXkgYmUgcmVjb3JkZWQuCgogICBSZWNvcmRpbmcgU2Vzc2lvbiAoUlMpOiAg VGhlIHNlc3Npb24gY3JlYXRlZCBiZXR3ZWVuIGFuIFNlc3Npb24KICAgUmVjb3JkaW5nIENsaWVu dCBhbmQgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyIGZvciB0aGUgcHVycG9zZSBvZgogICByZWNv cmRpbmcgYSBDb21tdW5pY2F0aW9uIFNlc3Npb24uCgogICBSZWNvcmRpbmcgYXdhcmUgVUE6ICBB IFNJUCBVc2VyIEFnZW50IHRoYXQgaXMgYXdhcmUgb2YgU0lQIGV4dGVuc2lvbnMKICAgYXNzb2Np YXRlZCB3aXRoIHRoZSBDb21tdW5pY2F0aW9uIFNlc3Npb24uICBTdWNoIGV4dGVuc2lvbnMgbWF5 IGJlCiAgIHVzZWQgdG8gbm90aWZ5IHRoZSBTSVAgVUEgdGhhdCBhIHNlc3Npb24gaXMgYmVpbmcg cmVjb3JkZWQgb3IgdG8gYWxsCiAgIHRoZSBTSVAgVUEgdG8gZXhwcmVzcyBwcmVmZXJlbmNlcyBh cyB0byB3aGV0aGVyIGEgcmVjb3JkaW5nIHNob3VsZCBiZQogICBzdGFydGVkLCBwYXVzZWQsIHJl c3VtZWQgb3Igc3RvcHBlZC4KCiAgIE1lZGlhIFJlY29yZGluZyBNZXRhZGF0YSAoTVJNKTogIFRo ZSBtZXRhZGF0YSBkZXNjcmliaW5nIHRoZQogICBjb21tdW5pY2F0aW9uIHNlc3Npb24gdGhhdCBp cyByZXF1aXJlZCBieSB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcKICAgU2VydmVyLiAgVGhpcyB3aWxs IGluY2x1ZGUgZm9yIGV4YW1wbGUgdGhlIGlkZW50aXR5IG9mIHVzZXJzIHRoYXQKICAgcGFydGlj aXBhdGUgaW4gdGhlIENvbW11bmljYXRpb24gU2Vzc2lvbiBhbmQgZGlhbG9nIHN0YXRlLiAgVHlw aWNhbGx5CiAgIHRoaXMgbWV0YWRhdGEgaXMgYXJjaGl2ZWQgd2l0aCB0aGUgcmVwbGljYXRlZCBt ZWRpYSBhdCB0aGUgU2Vzc2lvbgogICBSZWNvcmRpbmcgU2VydmVyLiAgVGhlIG1lZGlhIHJlY29y ZGluZyBtZXRhZGF0YSBpcyBkZWxpdmVyZWQgaW4gcmVhbC0KICAgdGltZSB0byB0aGUgU2Vzc2lv biBSZWNvcmRpbmcgU2VydmVyLgoKICAgUmVwbGljYXRlZCBNZWRpYTogIEEgY29weSBvZiB0aGUg bWVkaWEgYXNzb2NpYXRlZCB3aXRoIHRoZQogICBDb21tdW5pY2F0aW9uIFNlc3Npb24gY3JlYXRl ZCBieSB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50IGFuZAogICBzZW50IHRvIHRoZSBTZXNz aW9uIFJlY29yZGluZyBTZXJ2ZXIuICBJdCBtYXkgY29udGFpbiBhbGwgdGhlIG1lZGlhCiAgIGFz c29jaWF0ZWQgd2l0aCB0aGUgY29tbXVuaWNhdGlvbiBzZXNzaW9uIChFLmcuICBBdWRpbyBhbmQg VmlkZW8pIG9yCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAy MDEyICAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgQXJjaGl0 ZWN0dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgIE9jdG9iZXIgMjAxMQoKCiAgIGp1c3Qg YSBzdWJzZXQgKEUuZy4gIEF1ZGlvKS4KCgozLiAgU2Vzc2lvbiBSZWNvcmRpbmcgQXJjaGl0ZWN0 dXJlCgozLjEuICBMb2NhdGlvbiBvZiB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50CgogICBU aGlzIHNlY3Rpb24gY29udGFpbnMgc29tZSBleGFtcGxlIHNlc3Npb24gcmVjb3JkaW5nIGFyY2hp dGVjdHVyZXMKICAgc2hvd2luZyBob3cgdGhlIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCBpcyBh IGxvZ2ljYWwgZnVuY3Rpb24gdGhhdAogICBjYW4gYmUgbG9jYXRlZCBpbiBvciBzcGxpdCBiZXR3 ZWVuIHZhcmlvdXMgcGh5c2ljYWwgY29tcG9uZW50cy4KCjMuMS4xLiAgQjJCVUEgYWN0cyBhcyBh IFNlc3Npb24gUmVjb3JkaW5nIENsaWVudAoKICAgQSBTSVAgQjJCVUEgd2hpY2ggaGFzIGFjY2Vz cyB0byB0aGUgbWVkaWEgdGhhdCBpcyB0byBiZSByZWNvcmRlZCBtYXkKICAgYWN0IGFzIGEgU2Vz c2lvbiBSZWNvcmRpbmcgQ2xpZW50LiAgVGhlIEIyQlVBIG1heSBhbHJlYWR5IGJlIGF3YXJlCiAg IHRoYXQgYSBzZXNzaW9uIG5lZWRzIHRvIGJlIHJlY29yZGVkIGJlZm9yZSB0aGUgaW5pdGlhbCBl c3RhYmxpc2htZW50CiAgIG9mIHRoZSBjb21tdW5pY2F0aW9uIHNlc3Npb24gb3IgdGhlIGRlY2lz aW9uIHRvIHJlY29yZCB0aGUgc2Vzc2lvbgogICBtYXkgb2NjdXIgYWZ0ZXIgdGhlIHNlc3Npb24g aGFzIGJlZW4gZXN0YWJsaXNoZWQuCgogICBJZiB0aGUgQjJCVUEvU1JDIG1ha2VzIHRoZSBkZWNp c2lvbiB0byBpbml0aWF0ZSB0aGUgUmVjb3JkaW5nIFNlc3Npb24KICAgKFJTKSB0aGVuIGl0IHdp bGwgaW5pdGlhdGUgdGhlIGVzdGFibGlzaG1lbnQgb2YgYSBTSVAgU2Vzc2lvbiBieQogICBzZW5k aW5nIGFuIElOVklURSB0byB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyLgoKICAgSWYgdGhl IFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlciBtYWtlcyB0aGUgZGVjaXNpb24gdG8gaW5pdGlhdGUg dGhlCiAgIHJlY29yZGluZyBzZXNzaW9uIHRoZW4gaXQgd2lsbCBpbml0aWF0ZSB0aGUgZXN0YWJs aXNobWVudCBvZiBhIFNJUAogICBTZXNzaW9uIGJ5IHNlbmRpbmcgYW4gSU5WSVRFIHRvIHRoZSBC MkJVQS9TZXNzaW9uIFJlY29yZGluZyBDbGllbnQuCgogICBUaGUgUlMgSU5WSVRFIHdpbGwgbmVl ZCB0byBjb250YWluIGluZm9ybWF0aW9uIHdoaWNoIGlkZW50aWZpZXMgdGhlCiAgIHNlc3Npb24g YXMgYmVpbmcgZXN0YWJsaXNoZWQgZm9yIHRoZSBwdXJwb3NlcyBvZiByZWNvcmRpbmcgYW5kCiAg IHByZXZlbnRzIHRoZSBzZXNzaW9uIGZyb20gYmVpbmcgYWNjaWRlbnRseSByZXJvdXRlZCB0byBh IFVBIHdoaWNoIGlzCiAgIG5vdCBhIFNSUy4KCiAgIFRoZSBCMkJVQS9TUkMgaXMgcmVzcG9uc2li bGUgZm9yIG5vdGlmeWluZyB0aGUgVUEncyBpbnZvbHZlZCBpbiB0aGUKICAgY29tbXVuaWNhdGlv biBzZXNzaW9uIHRoYXQgdGhlIHNlc3Npb24gaXMgYmVpbmcgcmVjb3JkZWQuCgogICBUaGUgQjJC VUEvU1JDIGlzIHJlc3BvbnNpYmxlIGZvciBob25vcmluZyBhbnkgaW5kaWNhdGlvbiBmcm9tCiAg IHJlY29yZGluZyBhd2FyZSBVQSdzIG9yIHRocm91Z2ggc29tZSBjb25maWd1cmVkIHBvbGljaWVz IHRoYXQgdGhlCiAgIGNvbW11bmljYXRpb24gc2Vzc2lvbiBtdXN0IG5vdCBiZSByZWNvcmRlZC4K CgoKCgoKCgoKCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAy MDEyICAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgQXJjaGl0 ZWN0dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgIE9jdG9iZXIgMjAxMQoKCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rCiAgICAg ICAgICAgICAgICAgICAgICAgICAgKFJlY29yZGluZyBTZXNzaW9uKSB8ICBTZXNzaW9uICB8CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLVNJUC0tLS0tLT58IFJlY29yZGluZyB8 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICBTZXJ2ZXIg ICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgKy0tUlRQL1JUQ1AtLT58ICAoU1JT KSAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgfCAgICAgICAgICAgICArLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgViAgfCAgICAgICAgICAgICAg ICAgICBeCiAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAg ICB8CiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8 CiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfC0tIE1ldGFEYXRhIC0rCiAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAg ICAgICB8ICAgIEIyQlVBICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8CiAgICAgICAgICAgICAgICAgICAgICAgIHwgICBTZXNzaW9uICAgfAogICAgICstLS0tLS0t LSsgICAgICAgICB8ICBSZWNvcmRpbmcgIHwgICAgICAgICArLS0tLS0tLS0tKwogICAgIHwgICAg ICAgIHw8LSBTSVAgLT58ICAgQ2xpZW50ICAgIHw8LSBTSVAgLT58ICAgICAgICAgfAogICAgIHwg IFVBLUEgIHwgICAgICAgICB8ICAgKFNSQykgICAgIHwgICAgICAgICB8ICBVQS1CICAgfAogICAg IHwgICAgICAgIHw8LSBSVFAgLT58ICAgICAgICAgICAgIHw8LSBSVFAgLT58ICAgICAgICAgfAog ICAgICstLS0tLS0tLSsgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICArLS0tLS0tLS0t KwogICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsKICAgICB8X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX3wKICAgICAgICAgICAg ICAgICAgICAoQ29tbXVuaWNhdGlvbiBTZXNzaW9uKQoKICAgICAgICAgIEZpZ3VyZSAxOiBCMkJV QSBBY3RzIGFzIHRoZSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQuCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAyMDEy ICAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgQXJjaGl0ZWN0 dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgIE9jdG9iZXIgMjAxMQoKCjMuMS4yLiAgRW5k cG9pbnQgYWN0cyBhcyBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQKCiAgIEEgU0lQIEVuZHBvaW50 IC8gVXNlciBBZ2VudCBtYXkgYWN0IGFzIGEgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50IGluCiAg IHdoaWNoIGNhc2UgdGhlIGVuZHBvaW50IHNlbmRzIHRoZSBSZXBsaWNhdGVkIE1lZGlhIHRvIHRo ZSBTZXNzaW9uCiAgIFJlY29yZGluZyBTZXJ2ZXIKCiAgIElmIHRoZSBlbmRwb2ludCBtYWtlcyB0 aGUgZGVjaXNpb24gdG8gaW5pdGlhdGUgdGhlIFJlY29yZGluZyBTZXNzaW9uCiAgIHRoZW4gaXQg d2lsbCBpbml0aWF0ZSB0aGUgZXN0YWJsaXNobWVudCBvZiBhIFNJUCBTZXNzaW9uIGJ5IHNlbmRp bmcKICAgYW4gSU5WSVRFIHRvIHRoZSBTZXNzaW9uIFJlY29yZGluZyBTZXJ2ZXIuCgogICBJZiB0 aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyIG1ha2VzIHRoZSBkZWNpc2lvbiB0byBpbml0aWF0 ZSB0aGUKICAgUmVjb3JkaW5nIFNlc3Npb24gdGhlbiBpdCB3aWxsIGluaXRpYXRlIHRoZSBlc3Rh Ymxpc2htZW50IG9mIGEgU0lQCiAgIFNlc3Npb24gYnkgc2VuZGluZyBhbiBJTlZJVEUgdG8gdGhl IGVuZHBvaW50LgoKCgogICAgICAgICAgKFJlY29yZGluZyBTZXNzaW9uKSArLS0tLS0tLS0tLS0r CiAgICAgICAgICstLS0tLS0tLS0tU0lQLS0tLS0tPnwgICAgICAgICAgIHwKICAgICAgICAgfCAg Ky0tLS1SVFAvUlRDUC0tLS0+fCAgU2Vzc2lvbiAgfAogICAgICAgICB8ICB8ICAgICAgICAgICAg ICAgICB8IFJlY29yZGluZyB8CiAgICAgICAgIHwgIHwgICAgICAgICAgICAgICAgIHwgIFNlcnZl ciAgIHwKICAgICAgICAgfCAgfCArLS0gTWV0YWRhdGEgLS0+fCAgIChTUlMpICAgfAogICAgICAg ICB8ICB8IHwgICAgICAgICAgICAgICB8ICAgICAgICAgICB8CiAgICAgICAgIHwgIHwgfCAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLSsKICAgICAgICAgfCAgfCB8CiAgICAgICAgIHwgIHwgfAog ICAgICAgICB8ICB8IHwKICAgICAgICAgfCAgfCB8CiAgICAgICAgIFYgIHwgfCAgKENvbW11bmlj YXRpb24gU2Vzc2lvbikKICAgICAgKy0tKy0tLS0tLSsgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tKwogICAgICB8ICAgICAgICAgfDwtLS0tLS0tU0lQLS0tLS0tLS0tPnwgICAgICAgICB8 CiAgICAgIHwgIFVBLUEgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgVUEtQiAgIHwKICAgICAg fCAgKFNSQykgIHw8LS0tLS1SVFAvUlRDUC0tLS0tLT58ICAgICAgICAgfAogICAgICArLS0tLS0t LS0tKyAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rCgoKICAgICAgRmlndXJlIDI6IFNJ UCBFbmRwb2ludCBhY3RzIGFzIHRoZSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQKCgoKMy4xLjMu ICBBIFNJUCBQcm94eSBjYW5ub3QgYmUgYSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQKCiAgIEEg U0lQIFByb3h5IGlzIHVuYWJsZSB0byBhY3QgYXMgYW4gU1JDIGJlY2F1c2UgaXQgZG9lcyBub3Qg aGF2ZQogICBhY2Nlc3MgdG8gdGhlIG1lZGlhIGFuZCB0aGVyZWZvcmUgaGFzIG5vIHdheSBvZiBl bmFibGluZyB0aGUgZGVsaXZlcnkKICAgb2YgdGhlIHJlcGxpY2F0ZWQgbWVkaWEgdG8gdGhlIFNS UwoKCgoKCgpIdXR0b24sIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgNSwgMjAxMiAg ICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFyY2hpdGVjdHVy ZSBmb3IgTWVkaWEgUmVjb3JkaW5nICAgICAgICBPY3RvYmVyIDIwMTEKCgozLjEuNC4gIEludGVy YWN0aW9uIHdpdGggTUVESUFDVFJMCgogICBUaGUgbWVkaWFjdHJsIGFyY2hpdGVjdHVyZSBbUkZD NTU2N10gZGVzY3JpYmVzIGFuIGFyY2hpdGVjdXJlIGluCiAgIHdoaWNoIGFuIGFwcGxpY2F0aW9u IHNlcnZlciAoQVMpIGNvbnRyb2xzIGEgTWVkaWEgU2VydmVyIChNUykgd2hpY2gKICAgbWF5IGJl IHVzZWQgZm9yIHB1cnBvc2VzIHN1Y2ggYXMgY29uZmVyZW5jaW5nIGFuZCByZWNvcmRpbmcgbWVk aWEKICAgc3RyZWFtcy4gIEluIHRoZSBbUkZDNTU2N10gYXJjaGl0ZWN1cmUgdGhlIEFTIHR5cGlj YWxseSB1c2VzIFNJUAogICBUaGlyZCBQYXJ0eSBDYWxsIENvbnRyb2wgKDNQQ0MpIHRvIGluc3Ry dWN0IHRoZSBTSVAgVUEncyB0byBkaXJlY3QKICAgdGhlaXIgbWVkaWEgdG8gdGhlIE1lZGlhIFNl cnZlci4KCiAgIFRoZSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgYW5kIFNlc3Npb24gUmVjb3Jk aW5nIFNlcnZlciBkZXNjcmliZWQKICAgaW4gdGhpcyBkb2N1bWVudCBtYXkgYWN0IGFzIGFuIGFw cGxpY2F0aW9uIHNlcnZlciBhcyBkZXNjcmliZWQgaW4KICAgW1JGQzU1NjddIGFuZCB0aGVyZWZv cmUgbWF5IHdoZW4gZnVydGhlciBkZWNvbXBvc2VkIGJlIG1hZGUgdXAgb2YgYW4KICAgYXBwbGlj YXRpb24gc2VydmVyIHdoaWNoIHVzZXMgYSBtZWRpYWN0cmwgaW50ZXJmYWNlIHRvIGNvbnRyb2wg YQogICBtZWRpYSBzZXJ2ZXIgZm9yIHRoZSBwdXJwb3NlIG9mIHJlY29yZGluZyB0aGUgbWVkaWEg c3RyZWFtcyBob3dldmVyCiAgIHRoaXMgaW50ZXJmYWNlIGlzIGNvbnNpZGVyZWQgb3V0c2lkZSB0 aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCiAgIEluIGFkZGl0aW9uLCBhbnkgYXBwcm9wcmlh dGUgY29udHJvbCBwcm90b2NvbHMgc3VjaCBhcyBSVEMtV2ViIGNhbiBiZQogICB1c2VkIGZvciBz dWNoIGRlY29tcG9zaXRpb24uCgoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlciAoU1JTKQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgICAgICAoUmVjb3JkaW5nIFNlc3Npb24pIHwgICstLS0tLS0tLS0tLSsgICAg ICAgICAgKy0tLS0tLS0tLS0tLSsgfAogICAgICAgICAgKy0tLS0tLS0tLS0tLVNJUC0tLS18LT58 ICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgICB8IHwKICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgfCAgfCBNZWRpYUN0cmwgfE1FRElBQ1RSTCB8ICAgTWVkaWEgICAgfCB8CiAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwgIHxBcHBsaWNhdGlvbnw8LS0tLS0tLS0+fCAg IFNlcnZlciAgIHwgfAogICAgICAgICAgfCAgICArLS0tLS1NZXRhZGF0YS0tLT58ICBTZXJ2ZXIg ICB8ICAgICAgICAgIHwgIChSZWNvcmRlcil8IHwKICAgICAgICAgIHwgICAgfCAgICAgICAgICAg ICAgfCAgfCAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgfCB8CiAgICAgICAgICB8 ICAgIHwgICAgICAgICAgICAgIHwgICstLS0tLS0tLS0tLSsgICAgICAgICAgKy0tLS0tLS0tLS0t LSsgfAogICAgICAgICAgfCAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgXiAgICAgICAgIHwKICAgICAgICAgIHwgICAgfCAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwtLS0tLS0tLS0rCiAgICAgICAgICB8ICAgIHwgICst LS0tLS0tLS0tLS0tLS0gUlRQL1JUQ1AgLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICB8ICAg IHwgIHwKICAgICAgICAgIFYgICAgfCAgVgogICAgICAgICstLS0rLS0tLS0tKyAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLSsKICAgICAgICB8ICAgICAgICAgIHw8LS0tLS0tLVNJ UC0tLS0tLS0tLS0tLS0tPnwgICAgICAgICB8CiAgICAgICAgfCAgIFVBLUEgICB8IChDb21tdW5p Y2F0aW9uIFNlc3Npb24pICB8ICBVQS1CICAgfAogICAgICAgIHwgICAoU1JDKSAgfDwtLS0tLS0t UlRQL1JUQ1AtLS0tLS0tLS0+fCAgICAgICAgIHwKICAgICAgICArLS0tLS0tLS0tLSsgICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rCgogICAgICAgICAgIEZpZ3VyZSAzOiBFeGFt cGxlIG9mIFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlciB1c2luZyBNRURJQUNUUkwKCgoKCgoKCgoK SHV0dG9uLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAgICAgICAg ICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBBcmNoaXRlY3R1cmUgZm9yIE1l ZGlhIFJlY29yZGluZyAgICAgICAgT2N0b2JlciAyMDExCgoKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKwogICAgICAgICAgICAg ICAgIChSZWNvcmRpbmcgU2Vzc2lvbikgICAgICAgICAgICAgICAgfCBTZXNzaW9uICB8CiAgICAg ICAgICAgKy0tLS0tLS0tLS0tU0lQLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58UmVjb3JkaW5n IHwKICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg IFNlcnZlciAgfAogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgIChTUlMpICB8CiAgICAgICAgICAgfCAgVUEtQSBTZXNzaW9uIFJlY29yZGluZyBD bGllbnQgKFNSQykgICArLS0tLS0tLS0tLSsKICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKyAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgIHwKICAgIHwgICstLS0tLS0tLS0tLSsgICAgICAgICAg Ky0tLS0tLS0tLS0tLSsgfCAgICAgICAgIHwKICAgIHwgIHwgICAgICAgICAgIHwgQ29udHJvbCAg fCAgICAgICAgICAgIHw8LS0tLVJUUC0tLSsgICAgKy0tLS0tLS0tLSsKICAgIHwgIHwgICAgVUEg ICAgIHwgUHJvdG9jb2wgfCAgIE1lZGlhICAgIHwgfCAgICAgICAgICAgICAgfCAgICAgICAgIHwK ICAgIHwgIHxBcHBsaWNhdGlvbnw8LS0tLS0tLS0+fCAgU2VydmVyICAgIHwgfDwtLS0tU0lQLS0t LS0+fCAgVUEtQiAgIHwKICAgIHwgIHwgIFNlcnZlciAgIHwgICAgICAgICAgfCAgICAgICAgICAg IHw8LS0tLS1SVFAtLS0tLS0+fCAgICAgICAgIHwKICAgIHwgIHwgICAgICAgICAgIHwgICAgICAg ICAgfCAgICAgICAgICAgIHwgfCAgICAgICAgICAgICAgKy0tLS0tLS0tLSsKICAgIHwgICstLS0t LS0tLS0tLSsgICAgICAgICAgKy0tLS0tLS0tLS0tLSsgfAogICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsKICAgICAgICAgICBGaWd1cmUgNDogRXhhbXBsZSBvZiBTZXNzaW9uIFJl Y29yZGluZyBDbGllbnQgZGVjb21wb3NpdGlvbgoKCjMuMS41LiAgSW50ZXJhY3Rpb24gd2l0aCBD b25mZXJlbmNlIEZvY3VzCgogICBJbiB0aGUgY2FzZSBvZiBhIGNlbnRyYWxpc2VkIGNvbmZlcmVu Y2UgYSBjb21iaW5hdGlvbiBvZiB0aGUKICAgY29uZmVyZW5jZSBmb2N1cyBhbmQgbWl4ZXIgW1JG QzQzNTNdIG1heSBhY3QgYXMgYSBTUkMgYW5kIHRoZXJlZm9yZQogICBwcm92aWRlIHRoZSBTUlMg d2l0aCB0aGUgcmVwbGljYXRlZCBtZWRpYSBhbmQgYXNzb2NpYXRlZCBtZWRpYQogICByZWNvcmRp bmcgbWV0YWRhdGEuICBJbiB0aGlzIGFycmFuZ2VtZW50IHRoZSBTUkMgaXMgYWJsZSB0byBwcm92 aWRlCiAgIG1lZGlhIGFuZCBtZXRhZGF0YSByZWxhdGluZyB0byBlYWNoIG9mIHRoZSBwYXJ0aWNp cGFudHMsIGluY2x1ZGluZywKICAgZm9yIGV4YW1wbGUsIGFueSBzaWRlIGNvbnZlcnNhdGlvbnMg d2hlcmUgdGhlIG1lZGlhIHBhc3NlcyB0aHJvdWdoCiAgIHRoZSBtaXhlcgoKICAgVGhlIGNvbmZl cmVuY2UgZm9jdXMgbWF5IGFsc28gYWN0IGFzIGEgUmVjb3JkaW5nIEF3YXJlIFVBIGluIHRoZSBj YXNlCiAgIHdoZW4gb25lIG9mIHRoZSBwYXJ0aWNpcGFudHMgYWN0cyBhcyBhIFNSQy4KCiAgIElu IGFuIGFsdGVybmF0aXZlIGFycmFuZ2VtZW50IGEgU0lQIGVuZHBvaW50IHdoaWNoIGlzIGEgY29u ZmVyZW5jZQogICBwYXJ0aWNpcGFudCBjYW4gYWN0IGFzIGFuIFNSQy4gIFRoZSBTUkMgd2lsbCBp biB0aGlzIGNhc2UgaGF2ZSBhY2Nlc3MKICAgdG8gdGhlIG1lZGlhIGFuZCBtZXRhZGF0YSByZWxh dGluZyB0byB0aGF0IHBhcnRpY3VsYXIgcGFydGljaXBhbnQgYW5kCiAgIG1heSBiZSBhYmxlIHRv IG9idGFpbiBhZGRpdGlvbmFsIG1ldGFkYXRhIGZyb20gdGhlIGNvbmZlcmVuY2UgZm9jdXMuCiAg IFRoZSBTUkMgbWF5IGZvciBleGFtcGxlIHVzZSB0aGUgY29uZmVyZW5jZSBldmVudCBwYWNrYWdl IGFzIGRlc2NyaWJlZAogICBpbiBbUkZDNDU3NV0gdG8gb2J0YWluIGluZm9ybWF0aW9uIGFib3V0 IG90aGVyIHBhcnRpY2lwYW50cyB3aGljaCBpdAogICBwcm92aWRlcyB0byB0aGUgU1JTIHdpdGhp biB0aGUgbWVkaWEgcmVjb3JkaW5nIG1ldGFkYXRhLgoKICAgVGhlIFNSQyBtYXkgYmUgaW52b2x2 ZWQgaW4gdGhlIGNvbmZlcmVuY2UgZnJvbSB0aGUgdmVyeSBiZWdpbm5pbmcgb3IKICAgbWF5IGpv aW4gYXQgc29tZSBsYXRlciBwb2ludCBvZiB0aW1lLgoKCgoKCgoKCkh1dHRvbiwgZXQgYWwuICAg ICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSA5XQoM CkludGVybmV0LURyYWZ0ICAgICAgQXJjaGl0ZWN0dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcgICAg ICAgIE9jdG9iZXIgMjAxMQoKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVXNlciAx CiAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8UGFydGljaXBhbnR8CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAxICAgICB8CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8U0lQCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8RGlhbG9nCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8MQogICAgICAgVXNlciAyICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg UmVjb3JkaW5nCiAgICArLS0tLS0tLS0tLS0rICAgICAgICAgICArLS0tLS0tLS0tLS0rICBTZXNz aW9uICAgICAqKioqKioqKioqKioqCiAgICB8ICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAg ICAgICB8LS0tLS0tLS0tLS0tLS0qICAgICAgICAgICAqCiAgICB8ICAgICAgICAgICB8ICAgICAg ICAgICB8ICAgICAgICAgICB8LS0tLVJUUCAxIC0tLT4qICAgICAgICAgICAqCiAgICB8UGFydGlj aXBhbnR8LS0tLS0tLS0tLS18IEZvY3VzL1NSQyB8LS0tLVJUUCAyIC0tLT4qICAgIFNSUyAgICAq CiAgICB8ICAgICAyICAgICB8ICBTSVAgICAgICB8ICAgICAgICAgICB8LS0tLVJUUCAzIC0tLT4q ICAgICAgICAgICAqCiAgICB8ICAgICAgICAgICB8ICBEaWFsb2cgICB8ICAgICAgICAgICB8ICAg ICAgICAgICAgICAqICAgICAgICAgICAqCiAgICArLS0tLS0tLS0tLS0rICAyICAgICAgICArLS0t LS0tLS0tLS0rICAgICAgICAgICAgICAqKioqKioqKioqKioqCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8U0lQCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8RGlhbG9nCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8MwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgfFBhcnRpY2lwYW50fAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAzICAgICAgfAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVXNlciAzCgogICAgICAgICAg IEZpZ3VyZSA1OiBDb25mZXJlbmNlIEZvY3VzIGFjdGluZyBhcyBhbiBTUkMuCgoKMy4yLiAgRXN0 YWJsaXNoaW5nIHRoZSBSZWNvcmRpbmcgU2Vzc2lvbgoKICAgVGhlIFNlc3Npb24gUmVjb3JkaW5n IENsaWVudCBvciB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyIG1heQogICBpbml0aWF0ZSB0 aGUgUmVjb3JkaW5nIFNlc3Npb24uCgogICBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCB0aGUgUmVj b3JkaW5nIFNlc3Npb24gaXMgaW5kZXBlbmRlbnQgZnJvbSB0aGUKICAgQ29tbXVuaWNhdGlvbiBT ZXNzaW9uIHRoYXQgaXMgYmVpbmcgcmVjb3JkZWQgYXQgYm90aCB0aGUgU0lQIGRpYWxvZwogICBs ZXZlbCBhbmQgYXQgdGhlIHNlc3Npb24gbGV2ZWwuCgogICBDb25jZXJuaW5nIG1lZGlhIG5lZ290 aWF0aW9uLCByZWd1bGFyIFNJUC9TRFAgY2FwYWJpbGl0aWVzIHNob3VsZCBiZQogICB1c2VkLCBh bmQgZXhpc3RpbmcgdHJhbnNjb2RpbmcgY2FwYWJpbGl0aWVzIHNob3VsZCBub3QgYmUgcHJlY2x1 ZGVkCgoKCgpIdXR0b24sIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgNSwgMjAxMiAg ICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFyY2hpdGVjdHVy ZSBmb3IgTWVkaWEgUmVjb3JkaW5nICAgICAgICBPY3RvYmVyIDIwMTEKCgozLjIuMS4gIFNlc3Np b24gUmVjb3JkaW5nIENsaWVudCBJbml0aWF0ZWQgUmVjb3JkaW5nCgogICBXaGVuIHRoZSBTZXNz aW9uIFJlY29yZGluZyBDbGllbnQgaW5pdGlhdGVzIHRoZSBSZWNvcmRpbmcgU2Vzc2lvbiBmb3IK ICAgdGhlIHB1cnBvc2Ugb2YgY29udmV5aW5nIG1lZGlhIHRvIHRoZSBTZXNzaW9uIFJlY29yZGlu ZyBTZXJ2ZXIgaXQKICAgcGVyZm9ybXMgdGhlIGZvbGxvd2luZyBhY3Rpb25zLgoKICAgbyAgVGhl IFNSQyBpcyBwcm92aXNpb25lZCB3aXRoIGEgVVJJIGZvciB0aGUgU1JTLCB3aGljaCBpcyByZXNv bHZlZAogICAgICB0aHJvdWdoIG5vcm1hbCBbUkZDMzI2M10gcHJvY2VkdXJlcy4KCiAgIG8gIElu aXRpYXRlcyB0aGUgZGlhbG9nIGJ5IHNlbmRpbmcgYW4gSU5WSVRFIHJlcXVlc3QgdG8gdGhlIFNl c3Npb24KICAgICAgUmVjb3JkaW5nIFNlcnZlci4gIFRoZSBkaWFsb2cgaXMgZXN0YWJsaXNoZWQg YWNjb3JkaW5nIHRvIHRoZQogICAgICBub3JtYWwgcHJvY2VkdXJlcyBmb3IgZXN0YWJsaXNoaW5n IGFuIElOVklURSBpbml0aWF0ZWQgZGlhbG9nIGFzCiAgICAgIHNwZWNpZmllZCBpbiBbUkZDMzI2 MV0uCgogICBvICBJbmNsdWRlIGluIHRoZSBJTlZJVEUgYW4gaW5kaWNhdGlvbiB0aGF0IHRoZSBz ZXNzaW9uIGlzCiAgICAgIGVzdGFibGlzaGVkIGZvciB0aGUgcHVycG9zZSBvZiByZWNvcmRpbmcg dGhlIGFzc29jaWF0ZWQgbWVkaWEuCiAgICAgIFBvc3NpYmxlIG1lY2hhbmlzbXMgZm9yIHRoaXMg aW5jbHVkZSB1c2luZyB0aGUgUmVxdWlyZSBoZWFkZXIKICAgICAgYW5kL29yIGEgbmV3IG1lZGlh IGZlYXR1cmUgdGFnIHNpbWlsYXIgdG8gdGhlIHVzZSBvZiAiaXNmb2N1cyIgYXMKICAgICAgZGVm aW5lZCBpbiBbUkZDMzg0MF0KCiAgIG8gIElmIHRoZSBSZXBsaWNhdGVkIE1lZGlhIGlzIHRvIGJl IHN0YXJ0ZWQgaW1tZWRpYXRlbHkgdGhlbiB0aGUKICAgICAgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xp ZW50IHdpbGwgaW5jbHVkZSBhbiBTRFAgYXR0cmlidXRlIG9mCiAgICAgICJhPXNlbmRvbmx5IiBm b3IgZWFjaCBtZWRpYSBsaW5lIG9yICJhPWluYWN0aXZlIiBpZiBpdCBpcyBub3QKICAgICAgcmVh ZHkgdG8gdHJhbnNtaXQgdGhlIG1lZGlhLgoKICAgbyAgVGhlIFJlY29yZGluZyBTZXNzaW9uIG1h eSByZXBsaWNhdGUgYWxsIG1lZGlhIGFzc29jaWF0ZWQgd2l0aCB0aGUKICAgICAgQ29tbXVuaWNh dGlvbiBTZXNzaW9uIG9yIG9ubHkgYSBzdWJzZXQuCgogICBvICBSZXBsaWNhdGUgdGhlIG1lZGlh IHN0cmVhbXMgdGhhdCBhcmUgdG8gYmUgcmVjb3JkZWQgYW5kIHRyYW5zbWl0CiAgICAgIHRoZSBt ZWRpYSB0byB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyLgoKMy4yLjIuICBTZXNzaW9uIFJl Y29yZGluZyBTZXJ2ZXIgSW5pdGlhdGVkIFJlY29yZGluZwoKICAgV2hlbiB0aGUgU2Vzc2lvbiBS ZWNvcmRpbmcgU2VydmVyIGluaXRpYXRlcyB0aGUgbWVkaWEgcmVjb3JkaW5nCiAgIHNlc3Npb24g d2l0aCB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50IGl0IHBlcmZvcm1zIHRoZSBmb2xsb3dp bmcKICAgYWN0aW9ucy4KCiAgIG8gIFNlbmQgYW4gSU5WSVRFIHJlcXVlc3QgdG8gdGhlIFNlc3Np b24gUmVjb3JkaW5nIENsaWVudAoKICAgbyAgSW5jbHVkZSBpbiB0aGUgSU5WSVRFIGFuIGluZGlj YXRpb24gdGhhdCB0aGUgc2Vzc2lvbiBpcwogICAgICBlc3RhYmxpc2hlZCBmb3IgdGhlIHB1cnBv c2Ugb2YgcmVjb3JkaW5nIHRoZSBhc3NvY2lhdGVkIG1lZGlhLgogICAgICBQb3NzaWJsZSBtZWNo YW5pc21zIGZvciB0aGlzIGluY2x1ZGUgdXNpbmcgdGhlIFJlcXVpcmUgaGVhZGVyIG9yIGEKICAg ICAgbWVkaWEgZmVhdHVyZSB0YWcgc2ltaWxhciB0byB0aGUgdXNlIG9mICJpc2ZvY3VzIiBhcyBk ZWZpbmVkIGluCiAgICAgIFtSRkMzODQwXQoKICAgbyAgSWRlbnRpZnkgdGhlIHNlc3Npb24gdGhh dCBpcyB0byBiZSByZWNvcmRlZCAtIFBvc3NpYmx5IHVzaW5nIHRoZQogICAgICBKb2luIGhlYWRl ciBbUkZDMzkxMV0KCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1 LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAgICAgQXJj aGl0ZWN0dXJlIGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgIE9jdG9iZXIgMjAxMQoKCiAgIG8g IElmIHRoZSBSZWNvcmRpbmcgU2Vzc2lvbiBpcyB0byBiZSBzdGFydGVkIGltbWVkaWF0ZWx5IHRo ZW4gdGhlCiAgICAgIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCB3aWxsIGluY2x1ZGUgYW4gU0RQ IGF0dHJpYnV0ZSBvZgogICAgICAiYT1yZWN2b25seSIgZm9yIGVhY2ggbWVkaWEgbGluZSBvciAi YT1pbmFjdGl2ZSIgaWYgaXQgaXMgbm90CiAgICAgIHJlYWR5IHRvIHJlY2VpdmUgdGhlIG1lZGlh CgogICBJZiB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2VydmVyIGRvZXMgbm90IGhhdmUgcHJpb3Ig a25vd2xlZGdlIG9mIHdoYXQKICAgbWVkaWEgc3RyZWFtcyBhcmUgYXZhaWxhYmxlIHRvIGJlIHJl Y29yZGVkIGl0IGNhbiBtYWtlIHVzZSBvZiBhbgogICBvZmZlcmxlc3MgSU5WSVRFIHdoaWNoIGFs bG93cyB0aGUgU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50IHRvIG1ha2UKICAgdGhlIGluaXRpYWwg U0RQIG9mZmVyLgoKMy4yLjMuICBQYXVzZS9SZXN1bWUgUmVjb3JkaW5nIFNlc3Npb24KCiAgIFRo ZSBTZXNzaW9uIFJlY29yZGluZyBTZXJ2ZXIgb3IgdGhlIFNlc3Npb24gUmVjb3JkaW5nIENsaWVu dCBtYXkKICAgcGF1c2UgdGhlIHJlY29yZGluZyBieSBjaGFuZ2luZyB0aGUgU0RQIGRpcmVjdGlv biBhdHRyaWJ1dGUgdG8KICAgImluYWN0aXZlIiBhbmQgcmVzdW1lIHRoZSByZWNvcmRpbmcgYnkg Y2hhbmdpbmcgdGhlIGRpcmVjdGlvbiBiYWNrIHRvCiAgICJyZWN2b25seSIgb3IgInNlbmRvbmx5 Ii4KCjMuMi40LiAgTWVkaWEgU3RyZWFtIE1peGluZwoKICAgSW4gYSBiYXNpYyBzZXNzaW9uIGlu dm9sdmluZyBvbmx5IGF1ZGlvIHRoZXJlIGFyZSB0eXBpY2FsbHkgdHdvCiAgIGF1ZGlvL1JUUCBz dHJlYW1zIGJldHdlZW4gdGhlIHR3byBVQSdzIGludm9sdmVkIHRyYW5zcG9ydGluZyBtZWRpYSBp bgogICBlYWNoIGRpcmVjdGlvbi4gIFdoZW4gcmVjb3JkaW5nIHRoaXMgbWVkaWEgdGhlIHR3byBz dHJlYW1zIG1heSBiZQogICBtaXhlZCBhdCB0aGUgU1JDIGJlZm9yZSBiZWluZyB0cmFuc21pdHRl ZCB0byB0aGUgU1JTIG9yIGl0IG1heSBiZSBhCiAgIHJlcXVpcmVtZW50IG9mIHRoZSByZWNvcmRp bmcgc2VydmVyIHRoYXQgdGhlIG1lZGlhIHN0cmVhbXMgYXJlIG5vdAogICBtaXhlZCBhbmQgYXJl IHNlbnQgdG8gdGhlIFNSUyBhcyB0d28gc2VwYXJhdGUgc3RyZWFtcy4gIFRoZSBjYXNlIHdoZW4K ICAgbWVkaWEgaXMgbWl4ZWQgYXQgdGhlIFNSQyBpcyBzaW1wbGUgYXMgb25seSBhIHNpbmdsZSBt ZWRpYSBzdHJlYW0gaXMKICAgcmVxdWlyZWQgdG8gYmUgc2VudCB0byB0aGUgU1JTLiAgSG93ZXZl ciBpbiB0aGUgY2FzZSB3aGVuIHRoZSBtZWRpYQogICBzdHJlYW1zIGFyZSBub3QgbWl4ZWQgdGhl biB0aGUgU0RQIG9mZmVyIHNlbnQgdG8gdGhlIFNSUyBtdXN0CiAgIGRlc2NyaWJlIHR3byBzZXBh cmF0ZSBtZWRpYSBzdHJlYW1zLgoKMy4yLjUuICBNZWRpYSBUcmFuc2NvZGluZwoKICAgVGhlIGNv bW11bmljYXRpb24gc2Vzc2lvbiAoQ1MpIGFuZCB0aGUgcmVjb3JkaW5nIHNlc3Npb24gKFJTKSBh cmUKICAgbmVnb3RpYXRlZCBzZXBhcmF0ZWx5IHVzaW5nIGEgc3RhbmRhcmQgU0RQIG9mZmVyL2Fu c3dlciBleGNoYW5nZQogICB3aGljaCBtYXkgcmVzdWx0IGluIHRoZSBTUkMgaGF2aW5nIHRvIHBl cmZvcm0gbWVkaWEgdHJhbnNjb2RpbmcKICAgYmV0d2VlbiB0aGUgdHdvIHNlc3Npb25zLiAgSWYg dGhlIFNSQyBpcyBub3QgY2FwYWJsZSBvZiBwZXJmb3JtaW5nCiAgIG1lZGlhIHRyYW5zY29kaW5n IGl0IG1heSBsaW1pdCB0aGUgbWVkaWEgZm9ybWF0cyBpbiB0aGUgb2ZmZXIgdG8gdGhlCiAgIFNS UyBkZXBlbmRpbmcgb24gd2hhdCBtZWRpYSBpcyBuZWdvdGlhdGVkIG9uIHRoZSBDUyBvciBtYXkg bGltaXQgd2hhdAogICBpdCBpbmNsdWRlcyBpbiB0aGUgb2ZmZXIgb24gdGhlIENTIGlmIGl0IGhh cyBwcmlvciBrbm93bGVkZ2Ugb2YgdGhlCiAgIG1lZGlhIGZvcm1hdHMgc3VwcG9ydGVkIGJ5IHRo ZSBTUlMuICBIb3dldmVyIHR5cGljYWxseSB0aGUgU1JTIHdpbGwKICAgYmUgdGhlIG1vcmUgY2Fw YWJsZSBkZXZpY2Ugd2hpY2ggY2FuIHByb3ZpZGUgYSB3aWRlIHJhbmdlIG9mIG1lZGlhCiAgIGZv cm1hdCBvcHRpb25zIHRvIHRoZSBTUkMgYW5kIG1heSBhbHNvIGJlIGFibGUgdG8gbWFrZSB1c2Ug b2YgYSBtZWRpYQogICB0cmFuc2NvZGVyIGFzIGRldGFpbGVkIGluIFtSRkM1MzY5XS4KCjMuMy4g IE1lZGlhIFJlY29yZGluZyBNZXRhZGF0YQoKCgoKCgpIdXR0b24sIGV0IGFsLiAgICAgICAgICAg IEV4cGlyZXMgQXByaWwgNSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5l dC1EcmFmdCAgICAgIEFyY2hpdGVjdHVyZSBmb3IgTWVkaWEgUmVjb3JkaW5nICAgICAgICBPY3Rv YmVyIDIwMTEKCgozLjMuMS4gIENvbnRlbnRzIG9mIHJlY29yZGluZyBtZXRhZGF0YQoKICAgVGhl IG1ldGFkYXRhIG1vZGVsIGlzIGRlZmluZWQgaW4gW0ktRC5pZXRmLXNpcHJlYy1tZXRhZGF0YV0u CgozLjMuMi4gIE1lY2hhbmlzbXMgZm9yIGRlbGl2ZXJ5IG9mIG1ldGFkYXRhIHRvIFNlc3Npb24g UmVjb3JkaW5nIFNlcnZlcgoKICAgVGhlIFNSUyBvYnRhaW5zIHNlc3Npb24gcmVjb3JkaW5nIG1l dGFkYXRhIGZyb20gdGhlIFNSQy4gIFRoZQogICBtZXRhZGF0YSBpcyB0cmFuc3BvcnRlZCB2aWEg U0lQIGJhc2VkIG1lY2hhbmlzbXMgYXMgc3BlY2lmaWVkIGluCiAgIFtJLUQuaWV0Zi1zaXByZWMt cHJvdG9jb2xdCgogICBJdCBpcyBhbHNvIHBvc3NpYmxlIHRoYXQgbWV0YWRhdGEgaXMgdHJhbnNw b3J0ZWQgdmlhIG5vbiBTSVAgYmFzZWQKICAgbWVjaGFuaXNtcyBidXQgdGhlc2UgYXJlIGNvbnNp ZGVyZWQgb3V0IG9mIHNjb3BlLgoKMy40LiAgTm90aWZpY2F0aW9ucyB0byB0aGUgUmVjb3JkZWQg VXNlciBBZ2VudHMKCiAgIFR5cGljYWxseSBhIHVzZXIgdGhhdCBpcyBpbnZvbHZlZCBpbiBhIHNl c3Npb24gdGhhdCBpcyB0byBiZSByZWNvcmRlZAogICBpcyBub3RpZmllZCBieSBhbiBhbm5vdW5j ZW1lbnQgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgc2Vzc2lvbiBvciBtYXkKICAgcmVjZWl2ZSBz b21lIHdhcm5pbmcgdG9uZXMgd2l0aGluIHRoZSBtZWRpYS4gIEhvd2V2ZXIgdGhlCiAgIHN0YW5k YXJkaXphdGlvbiBvZiBtZWRpYSByZWNvcmRpbmcgcHJvdG9jb2xzIHdoZW4gdXNpbmcgU0lQIGVu YWJsZSBhbgogICBpbmRpY2F0aW9uIHRoYXQgdGhlIGNhbGwgaXMgYmVpbmcgcmVjb3JkZWQgdG8g YmUgaW5jbHVkZWQgaW4gdGhlIFNJUAogICByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIGFzc29jaWF0 ZWQgd2l0aCB0aGF0IGNvbW11bmljYXRpb24gc2Vzc2lvbi4KCiAgIEl0IGlzIHRoZSBTZXNzaW9u IFJlY29yZGluZyBDbGllbnQgdGhhdCBwcm92aWRlcyB0aGUgbm90aWZpY2F0aW9uIHRvCiAgIGFs bCBTSVAgVUEncyBmb3Igd2hpY2ggaXQgaXMgcmVwbGljYXRpbmcgcmVjZWl2ZWQgbWVkaWEgZm9y IHRoZQogICBwdXJwb3NlIG9mIHJlY29yZGluZyBpbmNsdWRpbmcgdGhlIGxvY2FsIHVzZXIgaWYg dGhlIFNlc3Npb24KICAgUmVjb3JkaW5nIENsaWVudCBpcyBhIFNJUCBlbmRwb2ludC4KCjMuNS4g IFByZXZlbnRpbmcgdGhlIHJlY29yZGluZyBvZiBhIFNJUCBzZXNzaW9uCgogICBBIFJlY29yZGlu ZyBBd2FyZSBVQSBtYXkgZHVyaW5nIHRoZSBpbml0aWFsIHNlc3Npb24gZXN0YWJsaXNobWVudCBv cgogICBkdXJpbmcgYW4gZXN0YWJsaXNoZWQgc2Vzc2lvbiBwcm92aWRlIGFuIGluZGljYXRpb24g b2YgdGhlaXIKICAgcHJlZmVyZW5jZSB3aXRoIHJlZ2FyZCB0byByZWNvcmRpbmcgdGhlIG1lZGlh IGluIHRoZSBjb21tdW5pY2F0aW9uCiAgIHNlc3Npb24uICBUaGUgbWVjaGFuaXNtIGZvciB0aGlz IGFyZSBzcGVjaWZpZWQgaW4KICAgW0ktRC5pZXRmLXNpcHJlYy1wcm90b2NvbF0KCgo0LiAgSUFO QSBjb25zaWRlcmF0aW9ucwoKICAgTm9uZS4KCgo1LiAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMK CiAgIFRoZSBSZWNvcmRpbmcgU2Vzc2lvbiBpcyBmdW5kYW1lbnRhbGx5IGEgc3RhbmRhcmQgU0lQ IGRpYWxvZyBhbmQKICAgbWVkaWEgc2Vzc2lvbiBhbmQgdGhlcmVmb3JlIG1ha2UgdXNlIG9mIGV4 aXN0aW5nIFNJUCBzZWN1cml0eQogICBtZWNoYW5pc21zIGZvciBzZWN1cmluZyB0aGUgUmVjb3Jk aW5nIFNlc3Npb24gYW5kIE1lZGlhIFJlY29yZGluZwogICBNZXRhZGF0YS4KCgoKCkh1dHRvbiwg ZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAyMDEyICAgICAgICAgICAgICAgIFtQ YWdlIDEzXQoMCkludGVybmV0LURyYWZ0ICAgICAgQXJjaGl0ZWN0dXJlIGZvciBNZWRpYSBSZWNv cmRpbmcgICAgICAgIE9jdG9iZXIgMjAxMQoKCiAgIFRoZSBpbnRlbmRlZCB1c2Ugb2YgdGhpcyBh cmNoaXRlY3R1cmUgaXMgb25seSBmb3IgdGhlIGNhc2Ugd2hlcmUgdGhlCiAgIHVzZXJzIGFyZSBh d2FyZSBvZiB0aGF0IHRoZXkgYXJlIGJlaW5nIHJlY29yZGVkIGFuZCB0aGUgYXJjaGl0ZWN0dXJl CiAgIHByb3ZpZGVzIHRoZSBtZWFucyBmb3IgdGhlIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCB0 byBub3RpZnkgdXNlcnMKICAgdGhhdCB0aGV5IGFyZSBiZWluZyByZWNvcmRlZC4KCiAgIFRoaXMg YXJjaGl0ZWN0dXJhbCBzb2x1dGlvbiBpcyBub3QgaW50ZW5kZWQgdG8gc3VwcG9ydCBsYXdmdWwK ICAgaW50ZXJjZXB0IHdoaWNoIGluIGNvbnRyYXN0IHJlcXVpcmVzIHRoYXQgdXNlcnMgYXJlIG5v dCBpbmZvcm1lZC4KCiAgIEl0IGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgU2Vzc2lvbiBS ZWNvcmRpbmcgU2VydmVyIHRvIHByb3RlY3QKICAgdGhlIFJlcGxpY2F0ZWQgTWVkaWEgYW5kIE1l ZGlhIFJlY29yZGluZyBNZXRhZGF0YSBvbmNlIGl0IGhhcyBiZWVuCiAgIHJlY2VpdmVkIGFuZCBh cmNoaXZlZC4KCgo2LiAgQWNrbm93bGVkZ2VtZW50cwoKICAgVGhhbmtzIHRvIEpvaG4gRWx3ZWxs LCBBbGFuIEpvaG5zb24sIEN1bGxlbiBKZW5uaW5ncywgSGFkcmllbCBLYXBsYW4sCiAgIEhlbnJ5 IEx1bSwgUGF1bCBLeXppdmF0LCBQYXJ0aGFzYXJhdGhpIFIsIFJhbSBNb2hhbiBSLCBhbmQgQ2hh cmxlcwogICBFY2tlbCBmb3IgdGhlaXIgc2lnbmlmaWNhbnQgY29udHJpYnV0aW9ucyBhbmQgYXNz aXN0YW5jZSB3aXRoIHRoaXMKICAgZG9jdW1lbnQgYW5kIFdvcmtpbmcgR3JvdXAsIGFuZCB0byBh bGwgdGhlIG1lbWJlcnMgb2YgdGhlIFNJUFJFQyBXRwogICBtYWlsaW5nIGxpc3QgZm9yIHByb3Zp ZGluZyB2YWx1YWJsZSBpbnB1dCB0byB0aGlzIHdvcmsuCgoKNy4gIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMKCiAgIFtSRkMzMjYxXSAgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBDYW1h cmlsbG8sIEcuLCBKb2huc3RvbiwKICAgICAgICAgICAgICBBLiwgUGV0ZXJzb24sIEouLCBTcGFy a3MsIFIuLCBIYW5kbGV5LCBNLiwgYW5kIEUuCiAgICAgICAgICAgICAgU2Nob29sZXIsICJTSVA6 IFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCIsIFJGQyAzMjYxLAogICAgICAgICAgICAgIEp1 bmUgMjAwMi4KCiAgIFtSRkMzMjYzXSAgUm9zZW5iZXJnLCBKLiBhbmQgSC4gU2NodWx6cmlubmUs ICJTZXNzaW9uIEluaXRpYXRpb24KICAgICAgICAgICAgICBQcm90b2NvbCAoU0lQKTogTG9jYXRp bmcgU0lQIFNlcnZlcnMiLCBSRkMgMzI2MywKICAgICAgICAgICAgICBKdW5lIDIwMDIuCgogICBb UkZDNDU2Nl0gIEhhbmRsZXksIE0uLCBKYWNvYnNvbiwgVi4sIGFuZCBDLiBQZXJraW5zLCAiU0RQ OiBTZXNzaW9uCiAgICAgICAgICAgICAgRGVzY3JpcHRpb24gUHJvdG9jb2wiLCBSRkMgNDU2Niwg SnVseSAyMDA2LgoKICAgW1JGQzM5MTFdICBNYWh5LCBSLiBhbmQgRC4gUGV0cmllLCAiVGhlIFNl c3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbAogICAgICAgICAgICAgIChTSVApICJKb2luIiBIZWFk ZXIiLCBSRkMgMzkxMSwgT2N0b2JlciAyMDA0LgoKICAgW1JGQzYzNDFdICBSZWhvciwgSy4sIFBv cnRtYW4sIEwuLCBIdXR0b24sIEEuLCBhbmQgUi4gSmFpbiwgIlVzZQogICAgICAgICAgICAgIENh c2VzIGFuZCBSZXF1aXJlbWVudHMgZm9yIFNJUC1CYXNlZCBNZWRpYSBSZWNvcmRpbmcKICAgICAg ICAgICAgICAoU0lQUkVDKSIsIFJGQyA2MzQxLCBBdWd1c3QgMjAxMS4KCiAgIFtJLUQuaWV0Zi1z aXByZWMtbWV0YWRhdGFdCiAgICAgICAgICAgICAgUiwgUi4sIFJhdmluZHJhbiwgUC4sIGFuZCBQ LiBLeXppdmF0LCAiU2Vzc2lvbiBJbml0aWF0aW9uCiAgICAgICAgICAgICAgUHJvdG9jb2wgKFNJ UCkgUmVjb3JkaW5nIE1ldGFkYXRhIiwKICAgICAgICAgICAgICBkcmFmdC1pZXRmLXNpcHJlYy1t ZXRhZGF0YS0wNCAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAgU2VwdGVtYmVyIDIw MTEuCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAyMDEyICAg ICAgICAgICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgQXJjaGl0ZWN0dXJl IGZvciBNZWRpYSBSZWNvcmRpbmcgICAgICAgIE9jdG9iZXIgMjAxMQoKCiAgIFtJLUQuaWV0Zi1z aXByZWMtcHJvdG9jb2xdCiAgICAgICAgICAgICAgUG9ydG1hbiwgTC4sIEx1bSwgSC4sIEpvaG5z dG9uLCBBLiwgYW5kIEEuIEh1dHRvbiwKICAgICAgICAgICAgICAiU2Vzc2lvbiBSZWNvcmRpbmcg UHJvdG9jb2wiLAogICAgICAgICAgICAgIGRyYWZ0LWlldGYtc2lwcmVjLXByb3RvY29sLTAwICh3 b3JrIGluIHByb2dyZXNzKSwKICAgICAgICAgICAgICBBdWd1c3QgMjAxMS4KCiAgIFtSRkMzMjY1 XSAgUm9hY2gsIEEuLCAiU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApLVNwZWNpZmlj CiAgICAgICAgICAgICAgRXZlbnQgTm90aWZpY2F0aW9uIiwgUkZDIDMyNjUsIEp1bmUgMjAwMi4K CiAgIFtSRkMzODQwXSAgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBhbmQgUC4gS3l6 aXZhdCwKICAgICAgICAgICAgICAiSW5kaWNhdGluZyBVc2VyIEFnZW50IENhcGFiaWxpdGllcyBp biB0aGUgU2Vzc2lvbgogICAgICAgICAgICAgIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkiLCBS RkMgMzg0MCwgQXVndXN0IDIwMDQuCgogICBbUkZDNDM1M10gIFJvc2VuYmVyZywgSi4sICJBIEZy YW1ld29yayBmb3IgQ29uZmVyZW5jaW5nIHdpdGggdGhlCiAgICAgICAgICAgICAgU2Vzc2lvbiBJ bml0aWF0aW9uIFByb3RvY29sIChTSVApIiwgUkZDIDQzNTMsCiAgICAgICAgICAgICAgRmVicnVh cnkgMjAwNi4KCiAgIFtSRkM0NTc1XSAgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBh bmQgTy4gTGV2aW4sICJBIFNlc3Npb24KICAgICAgICAgICAgICBJbml0aWF0aW9uIFByb3RvY29s IChTSVApIEV2ZW50IFBhY2thZ2UgZm9yIENvbmZlcmVuY2UKICAgICAgICAgICAgICBTdGF0ZSIs IFJGQyA0NTc1LCBBdWd1c3QgMjAwNi4KCiAgIFtSRkM1NTY3XSAgTWVsYW5jaHVrLCBULiwgIkFu IEFyY2hpdGVjdHVyYWwgRnJhbWV3b3JrIGZvciBNZWRpYQogICAgICAgICAgICAgIFNlcnZlciBD b250cm9sIiwgUkZDIDU1NjcsIEp1bmUgMjAwOS4KCiAgIFtSRkM1MzY5XSAgQ2FtYXJpbGxvLCBH LiwgIkZyYW1ld29yayBmb3IgVHJhbnNjb2Rpbmcgd2l0aCB0aGUgU2Vzc2lvbgogICAgICAgICAg ICAgIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkiLCBSRkMgNTM2OSwgT2N0b2JlciAyMDA4LgoK ICAgW1JGQzI4MDRdICBJQUIgYW5kIElFU0csICJJRVRGIFBvbGljeSBvbiBXaXJldGFwcGluZyIs IFJGQyAyODA0LAogICAgICAgICAgICAgIE1heSAyMDAwLgoKCkF1dGhvcnMnIEFkZHJlc3NlcwoK ICAgQW5kcmV3IEh1dHRvbiAoZWRpdG9yKQogICBTaWVtZW5zIEVudGVycHJpc2UgQ29tbXVuaWNh dGlvbnMKICAgSG9mbWFubnN0cmFzc2UgNTEKICAgTXVuaWNoIEQtODEzNzkKICAgR2VybWFueQoK ICAgRW1haWw6ICBhbmRyZXcuaHV0dG9uQHNpZW1lbnMtZW50ZXJwcmlzZS5jb20KCgoKCgoKCgoK CgpIdXR0b24sIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgNSwgMjAxMiAgICAgICAg ICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgIEFyY2hpdGVjdHVyZSBmb3Ig TWVkaWEgUmVjb3JkaW5nICAgICAgICBPY3RvYmVyIDIwMTEKCgogICBMZW9uIFBvcnRtYW4gKGVk aXRvcikKICAgTmljZSBTeXN0ZW1zCiAgIDggSGFwbmluYQogICBSYSdhbmFuYSAgNDMwMTcKICAg SXNyYWVsCgogICBFbWFpbDogIGxlb24ucG9ydG1hbkBuaWNlLmNvbQoKCiAgIFJham5pc2ggSmFp bgogICBJUEMgU3lzdGVtcwogICA3NzcgQ29tbWVyY2UgRHJpdmUKICAgRmFpcmZpZWxkLCBDVCAg MDY4MjUKICAgVVNBCgogICBFbWFpbDogIHJham5pc2guamFpbkBpcGMuY29tCgoKICAgS2VuIFJl aG9yCiAgIENpc2NvIFN5c3RlbXMsIEluYy4KICAgMTcwIFdlc3QgVGFzbWFuIERyaXZlCiAgIFNh biBKb3NlLCBDQSAgOTUxMzQtMTcwNgogICBVU0EKCiAgIEVtYWlsOiAga3JlaG9yQGNpc2NvLmNv bQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkh1dHRvbiwgZXQgYWwuICAgICAgICAgICAgRXhw aXJlcyBBcHJpbCA1LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDE2XQoMCg== --_004_07465C1D981ABC41A344374066AE1A2C38B18C4709TLVMBX01nicec_-- From andrew.hutton@siemens-enterprise.com Mon Oct 3 08:42: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 1BFEB21F8514 for ; Mon, 3 Oct 2011 08:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItRmZNyQZcWM for ; Mon, 3 Oct 2011 08:42:01 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0AD21F84AE for ; Mon, 3 Oct 2011 08:42:01 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CC2011EB842E for ; Mon, 3 Oct 2011 17:45:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 3 Oct 2011 17:45:02 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Mon, 3 Oct 2011 17:45:01 +0200 Thread-Topic: Consensus calls from session 1 of interim - Successful Thread-Index: Acx3c4nyu64hNtQWTsOO3+foFjE0IQKb1UaA Message-ID: <101C6067BEC68246B0C3F6843BCCC1E311F7CC68C7@MCHP058A.global-ad.net> 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] Consensus calls from session 1 of interim - Successful 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, 03 Oct 2011 15:42:02 -0000 Hi, I have seen no objections to these items so can the editors go ahead and in= corporate these changes in their next update. I see Leon as already done this in the 03 architecture draft.=20 Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: 20 September 2011 09:59 > To: siprec@ietf.org > Subject: [siprec] Consensus calls from session 1 of interim >=20 > There were no objections on the call to the following. If anyone else > has objections, please raise within one week (by 2011-09-27). >=20 > Architecture: > - Modifications to figure 1 (show RTCP, show as a single CS) > - Make figure 4 more generic, to cover any decomposed SIP UA acting as > SRC (e.g., RTC-Web, MEDIACTRL). >=20 > Protocol: > - Text improvements along the lines described in slide 5. >=20 > Metadata: > - Keep UML in the document, but make it clear it is non-normative. Also > make clear how XML relates to the model. > - Remove ExtensionData from the model, since the model is not an on- > the-wire protocol and does not need a compatibility mechanism. > - Include associate and dissociate times for a CS. > - Allow zero or more participants in a CS. > - Have a single XML element to represent both name and address > (structure to be determined). > - Model associate/dissociate times for participants with media streams > as attributes of a UML association. > - Remove the redundant element. >=20 > John >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Mon Oct 3 09:34: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 1D95821F8BB9 for ; Mon, 3 Oct 2011 09:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhLD5PfAZPzt for ; Mon, 3 Oct 2011 09:34:51 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0173921F8BAA for ; Mon, 3 Oct 2011 09:34:51 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 438F91EB8404; Mon, 3 Oct 2011 18:37:53 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 3 Oct 2011 18:37:53 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "siprec@ietf.org" Date: Mon, 3 Oct 2011 18:37:51 +0200 Thread-Topic: [siprec] Consensus calls from session 2 Thread-Index: AcyBKBIaqJ08qMtFT3WC30t/4M+0AgAwjfhQ Message-ID: <101C6067BEC68246B0C3F6843BCCC1E311F7CC6904@MCHP058A.global-ad.net> References: <35BCE99A477D6A4986FB2216D8CF2CFD07CF22E6@XMB-BGL-417.cisco.com> <4E889E1E.7090709@alum.mit.edu> In-Reply-To: <4E889E1E.7090709@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Consensus calls from session 2 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, 03 Oct 2011 16:34:52 -0000 I was also wondering why "" is specified= rather than "". Is there a good reason why we need to use "##other" rather than "##any" I m= ust admit I am not an XML guru. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 02 October 2011 18:24 > To: siprec@ietf.org > Subject: Re: [siprec] Consensus calls from session 2 >=20 > On 9/26/11 10:39 AM, Ram Mohan R (rmohanr) wrote: > > Hadriel, > > > > As John mentioned below, the consensus call was for avoiding the > > unnecessary level of sequence as defined in ver 04 and go with simple > > approach of putting the xs:any construct within any sequence where > > extension data is needed [ e.g. session, group, participant and > stream > > sequences]. Also we agreed in the call(Monday session) that extension > > data is not needed to be modeled in UML. Please note this schema is > > inline with technique used in RFC 6120 (XMPP related RFC) for > extension > > data. >=20 > I agree with this approach. I *don't* think it is good to expect > recipients to ignore unknown elements in places where there is no "any" > in the schema to match them. IOW, I think the message should be > expected > to validate according to the specified schema. It should be acceptable > for a recipient to reject any message that doesn't. (But it should also > be acceptable for a recipient to ignore unknown elements.) >=20 > I know that is typically used to > accomplish this. But I have wondered about the ##other in that > construction. IIUC it means that you can't have anything from *this* > namespace matching that. But that means that any extensions we might > want to incorporate later would *require* a different namespace. While > that is certainly possible, it might be inconvenient/annoying. Is there > any reason to forbid things from this namespace being used? >=20 > Thanks, > Paul >=20 > > The schema for, for example, with the above approach will > be: > > > > > > > > > minOccurs=3D"0"/> > > > minOccurs=3D"0"/> > > > minOccurs=3D"0"/> > > > minOccurs=3D"0" maxOccurs=3D"1"/> > > > minOccurs=3D'0' > > maxOccurs=3D'unbounded' > > processContents=3D'lax'/> > > > > > use=3D"required"/> > > > > > > Let me know if you still have any concerns. > > > > Regards, > > Ram > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Elwell, John > >> Sent: Monday, September 26, 2011 12:41 PM > >> To: Hadriel Kaplan > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] Consensus calls from session 2 > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > >>> Sent: 24 September 2011 04:11 > >>> To: Elwell, John > >>> Cc: siprec@ietf.org > >>> Subject: Re: [siprec] Consensus calls from session 2 > >>> > >>> > >>> On Sep 23, 2011, at 11:59 AM, Elwell, John wrote: > >>> > >>>> Please raise any objections by 2011-10-03 to the following > >>> conclusions from today's call: > >>>> - Extension data representation in XML as proposed on > >>> metadata slide 19. > >> [JRE] What slide 19 does is get rid of an unnecessary level of > >> . In metadata-04 the schema defines an element type > >> extensiondata and uses it in various places. This type is defined as > >> being a complexType consisting of the "xs:any" construct. This is > not > >> valid syntax, and to make it valid xs:any would need to be embedded > >> within a element, e.g.: > >> > >> > >> > >> >> minOccurs=3D'0' > >> maxOccurs=3D'unbounded' > >> processContents=3D'lax'/> > >> > >> > >> This can be avoided simply by putting the xs:any construct within > any > >> sequence where extension data is needed, such as within the session, > >> group, participant and stream sequences. Defining a separate type > >> extensiondata seems to force an additional level of sequence on the > >> wire. > >> > >> So this change is merely about making our schema valid and doing so > >> without forcing an unnecessary level of sequence on the wire. We can > >> have a separate discussion on whether the xs:any construct is needed > > at > >> all, but that is not what this consensus call is about. > >> > >>> > >>> I don't understand what slide 19 means (ie, what it's > >>> changing), but I will re-iterate again that the extensionData > >>> container element is completely unnecessary, and potentially > >>> dangerous. > >>> > >>> It's unnecessary because XML doesn't need this type of thing. > >>> All you need to do is have the RFC say "Unknown elements at > >>> any level MUST be ignored, and MUST NOT cause protocol > >>> failure". That's what we do in other SIP RFCs. Why? Because > >>> that's what xmlns namespaces are for. You can extend it with > >>> vendor-proprietary and future-standard extensions at any time > >>> in the future, without backwards compatibility problems. > >>> This is not some new concept for XML. > >>> > >>> It's dangerous because we can only extend the XML document in > >>> future specs in the places where we happened to put the > >>> extensionData element. And what happens if/when we do extend > >>> this XML in a future spec by putting a newly defined XML > >>> container element inside extensionData? Do we have to put > >>> another extensionData inside that new container too, just in > >>> case we want to extend it again in the future? > >> [JRE] No, I don't think so. That is why the maximum number of > > instances > >> of xs:any is unbounded. > >> > >> John > >> > >> > >>> > >>> What would a future spec do about vendor-proprietary elements > >>> which happen to be sharing the same extensionData container > >>> defined by this metadata document? The future spec would > >>> say: "you have to implement XML, which has namespaces, and > >>> ignore any elements not using this new spec's namespace or > >>> one you understand". Well gee, that's what we can do right > >>> now without using an extensionData container to begin with. > >>> > >>> -hadriel > >>> p.s. sorry for the rant. :( > >>> > >>> > >> _______________________________________________ > >> 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 > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Wed Oct 5 02:55: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 C4F7A21F8B92 for ; Wed, 5 Oct 2011 02:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=-4.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFn1PO7FEtyb for ; Wed, 5 Oct 2011 02:55:31 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7857921F8B8F for ; Wed, 5 Oct 2011 02:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=8739; q=dns/txt; s=iport; t=1317808718; x=1319018318; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=NycLmdXcUohjr39M21XX67RdDIlw2+1Nl1vfV8IpT3g=; b=dGnfEPso5o8JjuS07P/iR0joaQgxNC+jZ7+5b/dPfxjTIoioCN6EWyfG CGaMTf7CQAau+x+KzinkfnrjVMAvz7M5mMh5RIaClc9/DcyF2WWAVg60L M++8uMp9MPWS6DhHieHJBV4fjSIxCVWeCvSVwdE+2m2BZr5xB2r9jD4Qb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwAANgpjE5Io8US/2dsb2JhbABCDphvjxOBBYFTAQEBBAEBAQ8BHQo0FwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBCggIGodhmQsBngYDhkhhBId6kSOLXT8 X-IronPort-AV: E=Sophos;i="4.68,490,1312156800"; d="scan'208";a="358441" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-3.cisco.com with ESMTP; 05 Oct 2011 09:58:26 +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 p959wBOg009924; Wed, 5 Oct 2011 09:58: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); Wed, 5 Oct 2011 15:28:17 +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, 5 Oct 2011 15:28:15 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07DF8375@XMB-BGL-417.cisco.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E311F7CC6904@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Consensus calls from session 2 Thread-Index: AcyBKBIaqJ08qMtFT3WC30t/4M+0AgAwjfhQAFa3g8A= References: <35BCE99A477D6A4986FB2216D8CF2CFD07CF22E6@XMB-BGL-417.cisco.com><4E889E1E.7090709@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E311F7CC6904@MCHP058A.global-ad.net> From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , "Paul Kyzivat" , X-OriginalArrivalTime: 05 Oct 2011 09:58:17.0420 (UTC) FILETIME=[4E2918C0:01CC8345] Subject: Re: [siprec] Consensus calls from session 2 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, 05 Oct 2011 09:55:31 -0000 Andy, I just followed the same approach as it is defined in RFC 6120. RFC 6120 uses -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Monday, October 03, 2011 10:08 PM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Consensus calls from session 2 >=20 > I was also wondering why "" is > specified rather than "". >=20 > Is there a good reason why we need to use "##other" rather than "##any" > I must admit I am not an XML guru. >=20 > Regards > Andy >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: 02 October 2011 18:24 > > To: siprec@ietf.org > > Subject: Re: [siprec] Consensus calls from session 2 > > > > On 9/26/11 10:39 AM, Ram Mohan R (rmohanr) wrote: > > > Hadriel, > > > > > > As John mentioned below, the consensus call was for avoiding the > > > unnecessary level of sequence as defined in ver 04 and go with > simple > > > approach of putting the xs:any construct within any sequence where > > > extension data is needed [ e.g. session, group, participant and > > stream > > > sequences]. Also we agreed in the call(Monday session) that > extension > > > data is not needed to be modeled in UML. Please note this schema is > > > inline with technique used in RFC 6120 (XMPP related RFC) for > > extension > > > data. > > > > I agree with this approach. I *don't* think it is good to expect > > recipients to ignore unknown elements in places where there is no > "any" > > in the schema to match them. IOW, I think the message should be > > expected > > to validate according to the specified schema. It should be > acceptable > > for a recipient to reject any message that doesn't. (But it should > also > > be acceptable for a recipient to ignore unknown elements.) > > > > I know that is typically used to > > accomplish this. But I have wondered about the ##other in that > > construction. IIUC it means that you can't have anything from *this* > > namespace matching that. But that means that any extensions we might > > want to incorporate later would *require* a different namespace. > While > > that is certainly possible, it might be inconvenient/annoying. Is > there > > any reason to forbid things from this namespace being used? > > > > Thanks, > > Paul > > > > > The schema for, for example, with the above approach will > > be: > > > > > > > > > > > > > > minOccurs=3D"0"/> > > > > > minOccurs=3D"0"/> > > > > > minOccurs=3D"0"/> > > > > > minOccurs=3D"0" maxOccurs=3D"1"/> > > > > > minOccurs=3D'0' > > > maxOccurs=3D'unbounded' > > > processContents=3D'lax'/> > > > > > > > > use=3D"required"/> > > > > > > > > > Let me know if you still have any concerns. > > > > > > Regards, > > > Ram > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > >> Behalf Of Elwell, John > > >> Sent: Monday, September 26, 2011 12:41 PM > > >> To: Hadriel Kaplan > > >> Cc: siprec@ietf.org > > >> Subject: Re: [siprec] Consensus calls from session 2 > > >> > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > >>> Sent: 24 September 2011 04:11 > > >>> To: Elwell, John > > >>> Cc: siprec@ietf.org > > >>> Subject: Re: [siprec] Consensus calls from session 2 > > >>> > > >>> > > >>> On Sep 23, 2011, at 11:59 AM, Elwell, John wrote: > > >>> > > >>>> Please raise any objections by 2011-10-03 to the following > > >>> conclusions from today's call: > > >>>> - Extension data representation in XML as proposed on > > >>> metadata slide 19. > > >> [JRE] What slide 19 does is get rid of an unnecessary level of > > >> . In metadata-04 the schema defines an element type > > >> extensiondata and uses it in various places. This type is defined > as > > >> being a complexType consisting of the "xs:any" construct. This is > > not > > >> valid syntax, and to make it valid xs:any would need to be > embedded > > >> within a element, e.g.: > > >> > > >> > > >> > > >> > >> minOccurs=3D'0' > > >> maxOccurs=3D'unbounded' > > >> processContents=3D'lax'/> > > >> > > >> > > >> This can be avoided simply by putting the xs:any construct within > > any > > >> sequence where extension data is needed, such as within the > session, > > >> group, participant and stream sequences. Defining a separate type > > >> extensiondata seems to force an additional level of sequence on > the > > >> wire. > > >> > > >> So this change is merely about making our schema valid and doing > so > > >> without forcing an unnecessary level of sequence on the wire. We > can > > >> have a separate discussion on whether the xs:any construct is > needed > > > at > > >> all, but that is not what this consensus call is about. > > >> > > >>> > > >>> I don't understand what slide 19 means (ie, what it's > > >>> changing), but I will re-iterate again that the extensionData > > >>> container element is completely unnecessary, and potentially > > >>> dangerous. > > >>> > > >>> It's unnecessary because XML doesn't need this type of thing. > > >>> All you need to do is have the RFC say "Unknown elements at > > >>> any level MUST be ignored, and MUST NOT cause protocol > > >>> failure". That's what we do in other SIP RFCs. Why? Because > > >>> that's what xmlns namespaces are for. You can extend it with > > >>> vendor-proprietary and future-standard extensions at any time > > >>> in the future, without backwards compatibility problems. > > >>> This is not some new concept for XML. > > >>> > > >>> It's dangerous because we can only extend the XML document in > > >>> future specs in the places where we happened to put the > > >>> extensionData element. And what happens if/when we do extend > > >>> this XML in a future spec by putting a newly defined XML > > >>> container element inside extensionData? Do we have to put > > >>> another extensionData inside that new container too, just in > > >>> case we want to extend it again in the future? > > >> [JRE] No, I don't think so. That is why the maximum number of > > > instances > > >> of xs:any is unbounded. > > >> > > >> John > > >> > > >> > > >>> > > >>> What would a future spec do about vendor-proprietary elements > > >>> which happen to be sharing the same extensionData container > > >>> defined by this metadata document? The future spec would > > >>> say: "you have to implement XML, which has namespaces, and > > >>> ignore any elements not using this new spec's namespace or > > >>> one you understand". Well gee, that's what we can do right > > >>> now without using an extensionData container to begin with. > > >>> > > >>> -hadriel > > >>> p.s. sorry for the rant. :( > > >>> > > >>> > > >> _______________________________________________ > > >> 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 Ofir.Roth@nice.com Thu Oct 6 00:58: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 AACAB21F8CFA for ; Thu, 6 Oct 2011 00:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBcdUNjNq9kf for ; Thu, 6 Oct 2011 00:58:44 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id BD8D021F8CEC for ; Thu, 6 Oct 2011 00:58:43 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Thu, 6 Oct 2011 10:01:52 +0200 From: Ofir Roth To: "siprec@ietf.org" Date: Thu, 6 Oct 2011 10:01:50 +0200 Thread-Topic: Partial Metadata Update Thread-Index: AcyD/KI1/XD1GzDYQ8yGkS90ATPlww== Message-ID: 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: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E66555BA0535EATLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] Partial Metadata Update 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, 06 Oct 2011 07:58:44 -0000 --_000_D6FF53BFD24F6F448C70DEF68DB4E66555BA0535EATLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, What are the guidelines for partial metadata update sent from SRC to SRS in= respect to the elements included (sessions, participants etc.)? Is it acceptable to assume that all related elements will be included in th= e partial update as opposed to sending just the pointers (e.g. only stream = with no relative participant)? Thanks, Ofir. --_000_D6FF53BFD24F6F448C70DEF68DB4E66555BA0535EATLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

What ar= e the guidelines for partial metadata update sent from SRC to SRS in respec= t to the elements included (sessions, participants etc.)?

Is it acceptable to assume that all related elements will= be included in the partial update as opposed to sending just the pointers = (e.g. only stream with no relative participant)?

 

Thanks,

Ofir.

 

= --_000_D6FF53BFD24F6F448C70DEF68DB4E66555BA0535EATLVMBX01nicec_-- From andrew.hutton@siemens-enterprise.com Thu Oct 6 08:03: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 8159D21F8B75 for ; Thu, 6 Oct 2011 08:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.968 X-Spam-Level: X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMep-Zqi-NlS for ; Thu, 6 Oct 2011 08:03:37 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id A0BEC21F8CC5 for ; Thu, 6 Oct 2011 08:03:36 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0E9741EB84D4 for ; Thu, 6 Oct 2011 17:06:42 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 6 Oct 2011 17:06:42 +0200 From: "Hutton, Andrew" To: "Elwell, John" , "siprec@ietf.org" Date: Thu, 6 Oct 2011 17:06:40 +0200 Thread-Topic: Consensus calls from session 2 - Success Thread-Index: Acx6Cdf7zXd6cJd8T2+ObVeaFd4jlAKLgwHw Message-ID: <101C6067BEC68246B0C3F6843BCCC1E311F7D41C9D@MCHP058A.global-ad.net> 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: [siprec] Consensus calls from session 2 - Success 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, 06 Oct 2011 15:03:37 -0000 Hi, I believe there are no outstanding objections to these items so can the edi= tors go ahead and incorporate these changes in their next update. With regard to the discussion on extension data representatives I believe c= onsensus is to go with the approach as described in Ram's e-mail on the 201= 1-09-26 which gave this example: The issue of whether to include a statement indicating that elements from d= ifferent/unknown namespaces is a separate issue and so far I think the bala= nce is towards not including such a statement. Regards Andy Hutton (as chair). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: 23 September 2011 17:00 > To: siprec@ietf.org > Subject: [siprec] Consensus calls from session 2 >=20 > Please raise any objections by 2011-10-03 to the following conclusions > from today's call: >=20 > - List of SSRCs to be part of the association between participant and > session. > - Extension data representation in XML as proposed on metadata slide > 19. > - Structured element for use within a element > as shown on slide 20 (subject to clarification on need for language > attribute). > - Adoption of XML syntax from RFC 4235 for representation of > capabilities in metadata. >=20 > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu Oct 6 09:28: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 385A321F8B77 for ; Thu, 6 Oct 2011 09:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VWCgHosn3Zc for ; Thu, 6 Oct 2011 09:28:20 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id A0D2321F8B6E for ; Thu, 6 Oct 2011 09:28:20 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta09.westchester.pa.mail.comcast.net with comcast id hTgd1h03T1swQuc59UXYiE; Thu, 06 Oct 2011 16:31:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.westchester.pa.mail.comcast.net with comcast id hUXX1h00h0tdiYw3bUXXk1; Thu, 06 Oct 2011 16:31:32 +0000 Message-ID: <4E8DD7E2.4050803@alum.mit.edu> Date: Thu, 06 Oct 2011 12:31:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 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] Partial Metadata Update 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, 06 Oct 2011 16:28:21 -0000 On 10/6/11 4:01 AM, Ofir Roth wrote: > Hello, > > What are the guidelines for partial metadata update sent from SRC to SRS > in respect to the elements included (sessions, participants etc.)? > > Is it acceptable to assume that all related elements will be included in > the partial update as opposed to sending just the pointers (e.g. only > stream with no relative participant)? The expectation is that a partial update will include only those elements that have changed. A major reason for having "pointers" (IDs) is so that a new reference to a preexisting element can be sent without resending the preexisting element. Thanks, Paul From eckelcu@cisco.com Fri Oct 7 15:22: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 EBBD321F8515 for ; Fri, 7 Oct 2011 15:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.734 X-Spam-Level: X-Spam-Status: No, score=-2.734 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRz8SOmgyeg8 for ; Fri, 7 Oct 2011 15:22:26 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 596BF21F8558 for ; Fri, 7 Oct 2011 15:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5269; q=dns/txt; s=iport; t=1318026341; x=1319235941; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=QTNfazA+m9p8Hy5YX4urxVWSUQCGeBIwTZ1MaoqTG7E=; b=kkyQcyys0xQn9rhxtZE4MdPhHy+k0ZCrSp+T50OhoBTj/yNl+NLnlyeP qkLNOR2s0swvF0R4UcJjKHLJxK2y6LMMn1J5dZxVdFHu01GakDF24SQs3 vPQHdr4WPqa30+JHr3EbK0dfH15pJlGFqpXUiqNnNORPCrkx0BQV9fJqH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEZ7j06rRDoH/2dsb2JhbABEqBmBBYFVAQQSAR0KUQEqBgUTB1AHAQQbGqAKgSYBnjGEFoI5YQSHfZEjjDc X-IronPort-AV: E=Sophos;i="4.68,504,1312156800"; d="scan'208";a="6646830" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 07 Oct 2011 22:25:40 +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 p97MPdgk031153 for ; Fri, 7 Oct 2011 22:25:39 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, 7 Oct 2011 15:25:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: ATGQ BMtf BPeC B5hD ClqX Fifk F/X3 HXKh HuL/ H/Q9 JNxv JlFe KRAO KmrB Kw4u LtMG; 1; cwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {9A8D9650-D3BE-4397-B623-768F0434A99A}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Fri, 07 Oct 2011 22:25:36 GMT; cAByAG8AcABvAHMAZQBkACAAdABlAHgAdAAgAGYAbwByACAAZABlAGEAbABpAG4AZwAgAHcAaQB0AGgAIABwAGEAYwBrAGUAdAAgAGwAbwBzAHMA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {9A8D9650-D3BE-4397-B623-768F0434A99A} Content-class: urn:content-classes:message Date: Fri, 7 Oct 2011 15:25:36 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: proposed text for dealing with packet loss Thread-Index: AcyFQAjzFY55YKG7Tzm0ZW2LMCCpkA== From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 07 Oct 2011 22:25:39.0882 (UTC) FILETIME=[0B2D48A0:01CC8540] Subject: [siprec] proposed text for dealing with packet loss 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, 07 Oct 2011 22:22:31 -0000 During the last interim meeting, I accepted an action item to propose some text for draft-eckel-siprec-rtp-rec regarding SRC handling of packet loss. Here is text for the various RTP models with the proposed text added (look for "If packet loss occurs" within each model): ---------------- 4.1. SRC acting as an RTP Translator The SRC may act as a translator, as defined in [RFC3550]. A defining characteristic of a translator is that it forwards RTP packets with their SSRC identifier intact. There are two types of translators, one that simply forwards, and another that performs transcoding (e.g., from one codec to another) in addition to forwarding. 4.1.1. Forwarding Translator When acting as a forwarding translator, RTP received as separate streams from different sources (e.g., from different UAs with different SSRCs) cannot be mixed by the SRC and MUST be sent separately to the SRS. All RTCP reports MUST be passed by the SRC between the UAs and the SRS, such that the UAs and SRS are able to detect any SSRC collisions. RTCP Sender Reports generated by a UA sending a stream MUST be forwarded to the SRS. RTCP Receiver Reports generated by the SRS MUST be forwarded to the relevant UA. If SRTP is used on both the CS and the RS, decryption and/or re- encryption may occur. For example, if different keys are used, it will occur. If the same keys are used, it need not occur. If packet loss occurs, either from the UA to the SRC or from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss. The SRC does not play a role in this other than forwarding the associated RTP and RTCP packets. 4.1.2. Transcoding Translator When acting as a transcoding translator, an SRC MAY perform transcoding (e.g., from one codec to another), and this may result in a different rate of packets between what the SRC receives and what the sends. As when acting as a forwarding translator, RTP received as separate streams from different sources (e.g., from different UAs with different SSRCs) cannot be mixed by the SRC and MUST be sent separately to the SRS. All RTCP reports MUST passed by the SRC between the UAs and the SRS, such the UAs and SRS they are able to detect any SSRC collisions. RTCP Sender Reports generated by a UA sending a stream MUST be forwarded to the SRS. RTCP Receiver Reports generated by the SRS MUST be forwarded to the relevant UA. The SRC may need to manipulate the RTCP Receiver Reports to take account of any transcoding that has taken place. If SRTP is used on both the CS and the RS, decryption and/or re- encryption may occur. For example, if different keys are used, it will occur. If the same keys are used, it need not occur. If packet loss occurs, either from the UA to the SRC or from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss. The SRC does not play a role in this other than forwarding the associated RTP and RTCP packets. 4.2. SRC acting as an RTP Mixer In the case of the SRC acting as a RTP mixer, as defined in [RFC3550], the SRC combines RTP streams from different UA and sends them towards the SRS using its own SSRC. The SSRCs from the contributing UA SHOULD be conveyed as CSRCs identifiers within this stream. The SRC may make timing adjustments among the received streams and generate its own timing on the stream sent to the SRS. Optionally an SRC acting as a mixer can perform transcoding, and can even cope with different codings received from different UAs. RTCP Sender Reports and Receiver Reports are not forwarded by an SRC acting as mixer, but there are requirements for forwarding RTCP Source Description (SDES) packets. The SRC generates its own RTCP Sender and Receiver reports toward the associated UAs and SRS. The use of SRTP between the SRC and the SRS for the RS is independent of the use of SRTP between the UAs and SRC for the CS. If packet loss occurs from the UA to the SRC, the SRC SHOULD detect and attempt to recover from the loss. If packet loss occurs from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss. 4.3. SRC acting as an RTP Endpoint The case of the SRC acting as an RTP endpoint, as defined in [RFC3550], is similar to the mixer case, except that the RTP session between the SRC and the SRS is considered completely independent from the RTP session that is part of the CS. The SRC can, but need not, mix RTP streams from different participants prior to sending to the SRS. RTCP between the SRC and the SRS is completely independent of RTCP on the CS. The use of SRTP between the SRC and the SRS is independent of the use of SRTP on the CS. If packet loss occurs from the UA to the SRC, the SRC SHOULD detect and attempt to recover from the loss. If packet loss occurs from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss. ------------------ Comment on this are greatly appreciated. Thanks, Charles From rmohanr@cisco.com Tue Oct 11 22:48: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 BE72121F8C3C for ; Tue, 11 Oct 2011 22:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BylLYMFAC59P for ; Tue, 11 Oct 2011 22:48:17 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id BE36721F8C36 for ; Tue, 11 Oct 2011 22:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=13700; q=dns/txt; s=iport; t=1318398497; x=1319608097; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=F05Y2wfBPqMR6+cwZc7ILSQcyezTamLtvzPL2AZLv9Q=; b=kvGzQj3pwEEuEjnEg6R6RwHhTb96Rf9F8u6Zb1WxeK7ibMDiQo9xbOcI 8pTEH40JpN0rn+R/4KAc+zZMwG9tQI2D+5xBFlL6BMLhzEJcYPlRqrWkN osTxc18usNhaqA/rN/H5XpO0lIsqO27tIOZlTl627lv4gLPW/C0yqFzu5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMAAO4plU5Io8UQ/2dsb2JhbAA5CpkKjySBBYFTAQEBAQMBAQEPAR0KLgYXBAIBGQQBAQsGFwEGASYfCQgCBAsICAEZh2OZSgGeU4Qpgk5hBId9kSmMKg X-IronPort-AV: E=Sophos;i="4.69,332,1315180800"; d="scan'208";a="829061" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-3.cisco.com with ESMTP; 12 Oct 2011 05:48:14 +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 p9C5mCQq012501 for ; Wed, 12 Oct 2011 05:48: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, 12 Oct 2011 11:18:12 +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, 12 Oct 2011 11:18:09 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need Inputs: How to represent attributes of association in metadata Model and in XML ? Thread-Index: AcxpN2nvMrV1sN8uRu+Luw3VEq0S1gPwV65AAA/0UMAAA6GZIAAdZqPAAAKM0EADtQfg8A== References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 12 Oct 2011 05:48:12.0807 (UTC) FILETIME=[879B1970:01CC88A2] Subject: [siprec] Need Inputs: How to represent attributes of association in metadata Model and 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, 12 Oct 2011 05:48:18 -0000 (Sorry for lengthy e-mail) Hi All, In the last interim we discussed 4 approaches for representing attributes of association in XML. Here are some pros/cons for each of them: Approach 1:=20 ---------- Represent the association attribute as a property within one of the associated elements. Example given at http://www.ietf.org/mail-archive/web/siprec/current/msg02709.html Does not need another XML element and represents the association attributes as capability of one of the association element.=20 e.g. =20 sip:ram@blr.cisco.com 2010-12-16T23:41:07Z TBD 2010-12-16T23:41:07Z contributing SSRC-1 =20 In the above example the participant contributes a single streams. For each stream the association attribute (participant-stream) is shown with the stream ID nested in.=20 Approach 2: -----------=20 In this approach we have a new XML element for every association class. This xml element will NOT have a unique ID instead it references the ID of associated elements (shown below). With this approach it is easy to update as the association class is a separate XML element and not property. e.g. 2010-12-16T23:41:07Z TBD 2010-12-16T23:41:07Z contributing SSRC-1 =20 Approach 3 and 4 are in the below e-mail from John. Approach 3 defines a new Unique ID for every association XML elment. Also it creates alias for the other IDs. In the discussions in interim there was no strong support for this approach. Approach 4 is same as approach 1 where in the association element is encapsulated in one of the XML elements (to which it is associated). In addition to that it also has reference to the elements (alias of IDs) to which the association belongs. I prefer approach 2 as it is has a separate XML element to represent the association class. The only difference of this XML element from others is this does not need a unique ID. Instead it references the IDs of the elements to which the association belongs. Since association class is a special class meant to associate multiple classes, I see it ok to have a representation as in approach 2 where in the identifier is the concatenation of the classes to which the association belongs to. Please provide your comments on this and also suggest any other approaches to represent association classes in XML. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: Friday, September 23, 2011 1:32 PM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] #72: How to represent attributes of > associationinmetadata Model and in XML ? >=20 > John, >=20 > Lets discuss these two approaches along with the other two in today's > meeting. I have added these to the slides. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, September 23, 2011 1:01 PM > > To: Ram Mohan R (rmohanr); siprec issue tracker > > Cc: siprec@ietf.org > > Subject: RE: [siprec] #72: How to represent attributes of association > > inmetadata Model and in XML ? > > > > Ram, > > > > I don't like having to use the combination of participant unique ID > and > > session unique ID for uniquely identifying a element > as > > proposed in approach 1, and therefore of the two approaches here I > > prefer approach 2. > > > > Unfortunately approach 2 gets extremely verbose, particularly if we > > apply the same approach to associations between stream and > participant. > > Consider a 20 party conference with 2 streams, audio and video (not > an > > extreme example, but good enough to illustrate my point). Each > > participant is sending and receiving both streams. This means 80 > > associations between participant and stream. Each association element > > has its own unique ID, plus IDs referencing a element > > and a element. A total of 240 unique IDs on the wire just > to > > represent these associations. Taking the example unique ID below with > > 45 characters, this is 10800 characters for the IDs alone. I am not > > sure whether this is a problem of not. > > > > A couple of alternative approaches: > > > > Approach 3: Define local IDs as aliases for globally unique IDs. This > > approach reduces the number of unique IDs on the wire per association > > from 3 to 1, replacing them with local IDs. Of course, the local IDs > > have to be defined. This might marginally penalize the VERY simple > > cases, but saves significantly for more complex situations. > > e.g.: > > > id=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425" > > local=3D"123"> > > ... > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > local=3D"234"> > > ... > > > > > > > id=3D"urn:uuid:acdf43ee-1441-478d-4eca-4d4f555a896d" > > participant=3D"234" > > session=3D"123"> > > ... > > > > > > > Approach 4: Encapsulate associations within one of the object > elements > > concerned, e.g., encapsulate sequence of participants in the > > > element. This approach reduces the number of unique IDs on the wire > per > > association from 3 to 1. > > e.g.: > > > id=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > .... > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > .... > > > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > ... > > > > > > Or alternatively: > > > id=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > .... > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > .... > > > > > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > ... > > > > > > A further remark on approach 4. This means that you can't send a > > partial update conveying only an association - you have to send the > > whole element in which the association is embedded. So in the example > > above, if a participant drops out of a session you would have to send > > the whole element. So this might be a reason for embedding > > the associations in a element instead, if we consider > a > > given participant is unlikely to be in more than a handful of > sessions. > > > > John (as individual) > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 22 September 2011 17:57 > > > To: Elwell, John; siprec issue tracker > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] #72: How to represent attributes of > > > association inmetadata Model and in XML ? > > > > > > Hi John, > > > > > > Please see inline. > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Thursday, September 22, 2011 8:47 PM > > > > To: Ram Mohan R (rmohanr); siprec issue tracker > > > > Cc: siprec@ietf.org > > > > Subject: RE: [siprec] #72: How to represent attributes of > > > association > > > > inmetadata Model and in XML ? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > > > (rmohanr) > > > > > Sent: 22 September 2011 11:11 > > > > > To: siprec issue tracker > > > > > Cc: siprec@ietf.org > > > > > Subject: Re: [siprec] #72: How to represent attributes of > > > > > association in metadata Model and in XML ? > > > > > > > > > > I have not seen any inputs on this so far. In the last > > > > > discussion we had on Monday we discussed to ways to represent > > > > > attributes of association. Can folks look at these and > > > > > provide inputs and also other ways to represent attributes of > > > > > association ? > > > > > > > > > > Use-case: > > > > > --------- > > > > > A participant who is simultaneously in multiple sessions > > > > > having different capabilities(this attribute is an attribute > > > > > of association). > > > > > > > > > > Approach 1: > > > > > ----------- > > > > > Session 1 having participant 1: > > > > > > > > > = id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > > > > > > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > > > > sip:ram@blr.cisco.com > > > > > > 2010-12-16T23:41:07Z > > > time> > > > > > TBD > > > > > > > > > > Session 2 having the same participant 1: > > > > > > > > > > > > > > = id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > > > > > > > session=3D"urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103"> > > > > > sip:ram@blr.cisco.com > > > > > > 2010-12-16T23:41:07Z > > > time> > > > > > TBD > > > > > > > > > > > > > > > Here the session ID is different and it's the same > > > > > participant ID across both sessions. > > > > > > > > > > In this approach all the association attributes are encoded > > > > > within the element as the participant already > > > > > has session ID of the session to which it is associated. > > > > > > > > > > Pros: This is simple as we are just adding capabilities to > > > > > the existing participant element and hence it does not > > > > > require any additional ID. > > > > [JRE] If I understand the proposal correctly there is a possible > > > > problem. The example shows two elements with the > > same > > > > unique ID. If the SRC sends a partial update that contains a > > > > element, the SRS can't use its unique ID alone to > > > > identify the particular element that has changed. The SRS has to > > use > > > > the combination of the element's unique ID and the > > > referenced session > > > > unique ID. I am not sure this is a problem, but it is certainly a > > > > change from what we have discussed in the past, and it > > > means rules for > > > > matching become more complex. To some extent it defeats the > > > purpose of > > > > having a unique ID for a participant. > > > > > > True. I agree with your point. The last time this proposal was made > > by > > > Partha, I remember there was a feedback on the similar lines. > > > This issue > > > is going to be present for any attribute of participant not just > > > association attribute whenever a participant is simultaneously > > present > > > in multiple sessions. > > > > > > As you mentioned below the combination of participant ID and > > > session ID > > > (association) can serve as unique ID in cases where a participant > is > > > simultaneously in multiple sessions. > > > > > > Ram > > > > > > > > > > > Let's try another case. The SRC sends a partial update with a > > > > element whose referenced session is > > > different from that > > > > of any existing element with that same > > > unique ID. Does > > > > this mean the SRS has to add a new element to its > > > model? > > > > Again this seems to be contrary to my earlier understanding that > > you > > > > only add something if you receive something with a new unique ID. > > > > > > > > I believe up till now a complete XML document would never have > two > > > > elements with the same unique ID. This principle (if that > > > was people's > > > > understanding) now seems to be destroyed. > > > > > > > > Basically the combination of unique ID and > > > > > > unique ID becomes the unique ID for the association - not > > > necessarily > > > > wrong, but I do wonder whether having a unique ID for a > participant > > > > element is rather pointless when it alone is not usable as unique > > > > identification for an element. > > > > > > > > John (as individual) > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Tue Oct 11 23:20: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 1D11921F8BEB for ; Tue, 11 Oct 2011 23:20:10 -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=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpppB2YJqkSR for ; Tue, 11 Oct 2011 23:20:09 -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 BE97F21F8BCD for ; Tue, 11 Oct 2011 23:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1348; q=dns/txt; s=iport; t=1318400408; x=1319610008; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=VdXXJ5df6WUVshlCs540W6cmVm86G7woauTkZD1QrSc=; b=M9wEfEI4wXymNfjwdo82ZwA7BK1+OVTvo8apjFceXm0XKHUOGlh2R+cM 1dIUYYkUY64edIJ9jCbjOHUrCYorNbjTfepaqZonZzVh8qcUHYw1bCow5 0WgKFPOkXelSE/ivMT4t1YzTCZxIfxBN+lUotBsXzV2WY+J3NPFXwB62I w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAACoxlU5Io8US/2dsb2JhbABDmQpDjmGBBYFTAQEBAQMBAQEPAR0KNBcEAgEIEQQBAQEKBhcBBgEmHwkIAQEECwgIGodjmT4BnkcDhndhBId9kSmMKg X-IronPort-AV: E=Sophos;i="4.69,332,1315180800"; d="scan'208";a="57610089" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 12 Oct 2011 06:20: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 p9C6K6Tg010159 for ; Wed, 12 Oct 2011 06:20:06 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, 12 Oct 2011 11:50:06 +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, 12 Oct 2011 11:50:05 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07F6F927@XMB-BGL-417.cisco.com> In-Reply-To: <4E8DD7E2.4050803@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Partial Metadata Update Thread-Index: AcyERW2C1KkO02hzT8mgxUXnnf5fcAEYVjzg References: <4E8DD7E2.4050803@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 12 Oct 2011 06:20:06.0415 (UTC) FILETIME=[FC3481F0:01CC88A6] Subject: Re: [siprec] Partial Metadata Update 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, 12 Oct 2011 06:20:10 -0000 Ofir, As Paul mentioned only those elements that are changed will be sent in the partial update. There are some basic examples of partial update given in ver -04 of the draft. Please look at them for reference. Thanks, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, October 06, 2011 10:02 PM > To: siprec@ietf.org > Subject: Re: [siprec] Partial Metadata Update >=20 > On 10/6/11 4:01 AM, Ofir Roth wrote: > > Hello, > > > > What are the guidelines for partial metadata update sent from SRC to > SRS > > in respect to the elements included (sessions, participants etc.)? > > > > Is it acceptable to assume that all related elements will be included > in > > the partial update as opposed to sending just the pointers (e.g. only > > stream with no relative participant)? >=20 > The expectation is that a partial update will include only those > elements that have changed. >=20 > A major reason for having "pointers" (IDs) is so that a new reference > to > a preexisting element can be sent without resending the preexisting > element. >=20 > Thanks, > Paul >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Wed Oct 12 00:26: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 3237621F8BE9 for ; Wed, 12 Oct 2011 00:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tglh0U-FHAsf for ; Wed, 12 Oct 2011 00:26:53 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1E45021F8BBF for ; Wed, 12 Oct 2011 00:26:51 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Wed, 12 Oct 2011 09:25:16 +0200 From: Leon Portman To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Wed, 12 Oct 2011 09:25:15 +0200 Thread-Topic: Need Inputs: How to represent attributes of association in metadata Model and in XML ? Thread-Index: AcxpN2nvMrV1sN8uRu+Luw3VEq0S1gPwV65AAA/0UMAAA6GZIAAdZqPAAAKM0EADtQfg8AAErBHQ Message-ID: <07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com> References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@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 Cc: Ofir Roth Subject: Re: [siprec] Need Inputs: How to represent attributes of association in metadata Model and 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, 12 Oct 2011 07:26:54 -0000 Ram Hi I am ok with approaches 1 and however I do prefer approach one because it = will be easier for SRS to get decode - association is inside relevant eleme= nt. And it is more readable. Approach 2 will work as well, however it is important that if there will be= a change in association then to send to SRS not only updated association e= lement but also related elements: for example if stream was associated to p= articipant and session, send also participant and session latest state. Regards Leon=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: Wednesday, October 12, 2011 7:48 AM To: siprec@ietf.org Subject: [siprec] Need Inputs: How to represent attributes of association i= n metadata Model and in XML ? (Sorry for lengthy e-mail) Hi All, In the last interim we discussed 4 approaches for representing attributes o= f association in XML. Here are some pros/cons for each of them: Approach 1:=20 ---------- Represent the association attribute as a property within one of the associa= ted elements. Example given at http://www.ietf.org/mail-archive/web/siprec/= current/msg02709.html Does not need another XML element and represents the = association attributes as capability of one of the association element.=20 e.g. =20 sip:ram@blr.cisco.com 2010-12-16T23:41:07Z TBD 2010-12-16T23:41:07Z contributing SSRC-1 =20 In the above exa= mple the participant contributes a single streams. For each stream the asso= ciation attribute (participant-stream) is shown with the stream ID nested i= n.=20 Approach 2: ----------- In this approach we have a new XML element for every association class. This xml element will NOT have a unique ID instead it references the ID of = associated elements (shown below). With this approach it is easy to update = as the association class is a separate XML element and not property. e.g. 2010-12-16T23:41:07Z TBD 2010-12-16T23:41:07Z contributing SSRC-1 =20 Approach 3 and 4 are in the below e-mail from John. Approach 3 defines a new Unique ID for every association XML elment. Also it creates alias for the other IDs. In the discussions in interim ther= e was no strong support for this approach. Approach 4 is same as approach 1 where in the association element is encaps= ulated in one of the XML elements (to which it is associated). In addition= to that it also has reference to the elements (alias of IDs) to which the = association belongs. I prefer approach 2 as it is has a separate XML element to represent the as= sociation class. The only difference of this XML element from others is thi= s does not need a unique ID. Instead it references the IDs of the elements = to which the association belongs. Since association class is a special class meant to associate multiple clas= ses, I see it ok to have a representation as in approach 2 where in the ide= ntifier is the concatenation of the classes to which the association belong= s to. Please provide your comments on this and also suggest any other approaches = to represent association classes in XML. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Ram Mohan R (rmohanr) > Sent: Friday, September 23, 2011 1:32 PM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] #72: How to represent attributes of=20 > associationinmetadata Model and in XML ? >=20 > John, >=20 > Lets discuss these two approaches along with the other two in today's=20 > meeting. I have added these to the slides. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, September 23, 2011 1:01 PM > > To: Ram Mohan R (rmohanr); siprec issue tracker > > Cc: siprec@ietf.org > > Subject: RE: [siprec] #72: How to represent attributes of association > > inmetadata Model and in XML ? > > > > Ram, > > > > I don't like having to use the combination of participant unique ID > and > > session unique ID for uniquely identifying a element > as > > proposed in approach 1, and therefore of the two approaches here I=20 > > prefer approach 2. > > > > Unfortunately approach 2 gets extremely verbose, particularly if we=20 > > apply the same approach to associations between stream and > participant. > > Consider a 20 party conference with 2 streams, audio and video (not > an > > extreme example, but good enough to illustrate my point). Each=20 > > participant is sending and receiving both streams. This means 80=20 > > associations between participant and stream. Each association element > > has its own unique ID, plus IDs referencing a element=20 > > and a element. A total of 240 unique IDs on the wire just > to > > represent these associations. Taking the example unique ID below with > > 45 characters, this is 10800 characters for the IDs alone. I am not=20 > > sure whether this is a problem of not. > > > > A couple of alternative approaches: > > > > Approach 3: Define local IDs as aliases for globally unique IDs. This > > approach reduces the number of unique IDs on the wire per association > > from 3 to 1, replacing them with local IDs. Of course, the local IDs=20 > > have to be defined. This might marginally penalize the VERY simple=20 > > cases, but saves significantly for more complex situations. > > e.g.: > > > id=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425" > > local=3D"123"> > > ... > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > local=3D"234"> > > ... > > > > > > > id=3D"urn:uuid:acdf43ee-1441-478d-4eca-4d4f555a896d" > > participant=3D"234" > > session=3D"123"> > > ... > > > > > > > Approach 4: Encapsulate associations within one of the object > elements > > concerned, e.g., encapsulate sequence of participants in the > > > element. This approach reduces the number of unique IDs on the wire > per > > association from 3 to 1. > > e.g.: > > > id=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > .... > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > .... > > > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > ... > > > > > > Or alternatively: > > > id=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > .... > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > .... > > > > > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > ... > > > > > > A further remark on approach 4. This means that you can't send a=20 > > partial update conveying only an association - you have to send the=20 > > whole element in which the association is embedded. So in the example > > above, if a participant drops out of a session you would have to send > > the whole element. So this might be a reason for embedding > > the associations in a element instead, if we consider > a > > given participant is unlikely to be in more than a handful of > sessions. > > > > John (as individual) > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 22 September 2011 17:57 > > > To: Elwell, John; siprec issue tracker > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] #72: How to represent attributes of=20 > > > association inmetadata Model and in XML ? > > > > > > Hi John, > > > > > > Please see inline. > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Thursday, September 22, 2011 8:47 PM > > > > To: Ram Mohan R (rmohanr); siprec issue tracker > > > > Cc: siprec@ietf.org > > > > Subject: RE: [siprec] #72: How to represent attributes of > > > association > > > > inmetadata Model and in XML ? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > > > (rmohanr) > > > > > Sent: 22 September 2011 11:11 > > > > > To: siprec issue tracker > > > > > Cc: siprec@ietf.org > > > > > Subject: Re: [siprec] #72: How to represent attributes of=20 > > > > > association in metadata Model and in XML ? > > > > > > > > > > I have not seen any inputs on this so far. In the last=20 > > > > > discussion we had on Monday we discussed to ways to represent=20 > > > > > attributes of association. Can folks look at these and provide=20 > > > > > inputs and also other ways to represent attributes of=20 > > > > > association ? > > > > > > > > > > Use-case: > > > > > --------- > > > > > A participant who is simultaneously in multiple sessions=20 > > > > > having different capabilities(this attribute is an attribute=20 > > > > > of association). > > > > > > > > > > Approach 1: > > > > > ----------- > > > > > Session 1 having participant 1: > > > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > > > > > > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > > > > sip:ram@blr.cisco.com > > > > > > 2010-12-16T23:41:07Z > > > time> > > > > > TBD > > > > > > > > > > Session 2 having the same participant 1: > > > > > > > > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > > > > > > > session=3D"urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103"> > > > > > sip:ram@blr.cisco.com > > > > > > 2010-12-16T23:41:07Z > > > time> > > > > > TBD > > > > > > > > > > > > > > > Here the session ID is different and it's the same participant=20 > > > > > ID across both sessions. > > > > > > > > > > In this approach all the association attributes are encoded=20 > > > > > within the element as the participant already=20 > > > > > has session ID of the session to which it is associated. > > > > > > > > > > Pros: This is simple as we are just adding capabilities to the=20 > > > > > existing participant element and hence it does not require any=20 > > > > > additional ID. > > > > [JRE] If I understand the proposal correctly there is a possible=20 > > > > problem. The example shows two elements with the > > same > > > > unique ID. If the SRC sends a partial update that contains a=20 > > > > element, the SRS can't use its unique ID alone to=20 > > > > identify the particular element that has changed. The SRS has to > > use > > > > the combination of the element's unique ID and the > > > referenced session > > > > unique ID. I am not sure this is a problem, but it is certainly a > > > > change from what we have discussed in the past, and it > > > means rules for > > > > matching become more complex. To some extent it defeats the > > > purpose of > > > > having a unique ID for a participant. > > > > > > True. I agree with your point. The last time this proposal was made > > by > > > Partha, I remember there was a feedback on the similar lines. > > > This issue > > > is going to be present for any attribute of participant not just=20 > > > association attribute whenever a participant is simultaneously > > present > > > in multiple sessions. > > > > > > As you mentioned below the combination of participant ID and=20 > > > session ID > > > (association) can serve as unique ID in cases where a participant > is > > > simultaneously in multiple sessions. > > > > > > Ram > > > > > > > > > > > Let's try another case. The SRC sends a partial update with a=20 > > > > element whose referenced session is > > > different from that > > > > of any existing element with that same > > > unique ID. Does > > > > this mean the SRS has to add a new element to its > > > model? > > > > Again this seems to be contrary to my earlier understanding that > > you > > > > only add something if you receive something with a new unique ID. > > > > > > > > I believe up till now a complete XML document would never have > two > > > > elements with the same unique ID. This principle (if that > > > was people's > > > > understanding) now seems to be destroyed. > > > > > > > > Basically the combination of unique ID and > > > > > > unique ID becomes the unique ID for the association - not > > > necessarily > > > > wrong, but I do wonder whether having a unique ID for a > participant > > > > element is rather pointless when it alone is not usable as unique > > > > identification for an element. > > > > > > > > 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 From rmohanr@cisco.com Wed Oct 12 01:47: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 AECED21F8C14 for ; Wed, 12 Oct 2011 01:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkGB+LKDQQgq for ; Wed, 12 Oct 2011 01:47: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 B0A4821F8BB7 for ; Wed, 12 Oct 2011 01:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=4048; q=dns/txt; s=iport; t=1318409243; x=1319618843; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=62xNTxDHzz5DPD01Ij9o73YLZF4JMKm16FGe49rUcPs=; b=AMR25Pq0L2S1JIYXX+RYZ0jbMoMX5B3oJMsu0jmoet6CWKBdAGBPvl3+ rPMB2crX4e8JBPDdDJInbMoN7yjZzIkRnU1ooA/kL23LM2B0yNbDA2E37 pQb+mfGFRDCVvs8IGIk8Of6bM1tNrjaTk70zMVV8XV0yZkz3Jv8dyh3Dr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4AACdTlU5Io8US/2dsb2JhbABDmQuPH4EFgVMBAQEEAQEBCwQBHQorCQsMBAIBGQQBAQsGEwQBBgEmHwkIAQEEAQoICBqHZJlbAZ5dhndhBId9kSmMKw X-IronPort-AV: E=Sophos;i="4.69,333,1315180800"; d="scan'208";a="57623329" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 12 Oct 2011 08:47:20 +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 p9C8lInJ005302; Wed, 12 Oct 2011 08:47:18 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); Wed, 12 Oct 2011 14:17:18 +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, 12 Oct 2011 14:17:17 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9CC@XMB-BGL-417.cisco.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E311F7D41C9D@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xml:lang attribute for element ( was RE: [siprec] Consensus calls from session 2 - Success ) Thread-Index: Acx6Cdf7zXd6cJd8T2+ObVeaFd4jlAKLgwHwAR1icUA= References: <101C6067BEC68246B0C3F6843BCCC1E311F7D41C9D@MCHP058A.global-ad.net> From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , "Elwell, John" , X-OriginalArrivalTime: 12 Oct 2011 08:47:18.0852 (UTC) FILETIME=[8CBF7040:01CC88BB] Cc: "Peter Saint-Andre \(psaintan\)" Subject: [siprec] xml:lang attribute for element ( was RE: Consensus calls from session 2 - Success ) 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, 12 Oct 2011 08:47:23 -0000 In the last interim there was a *consensus* to have xml element (as shown below) in the metadata document to indicate multiple name/AoR pairs. However there was a comment to clarify on the need for language attribute in XML document.=20 Xml:lang is a special attribute may be inserted in documents to specify the language used in the contents and attribute values of any element in an XML document. More information at section 2.12 of http://www.w3.org/TR/REC-xml/ Some of the SIP RFC like RFC 3680 already uses xml:lang for display-name which is what we also need here. So I am planning to make this as optional attribute following the similar approach as done in RFC 3680. The schema for nameID would look as: Example is sip:alice@atlanta.com Alice Smith -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Thursday, October 06, 2011 8:37 PM > To: Elwell, John; siprec@ietf.org > Subject: [siprec] Consensus calls from session 2 - Success >=20 > Hi, >=20 > I believe there are no outstanding objections to these items so can the > editors go ahead and incorporate these changes in their next update. >=20 > With regard to the discussion on extension data representatives I > believe consensus is to go with the approach as described in Ram's e- > mail on the 2011-09-26 which gave this example: >=20 > > > minOccurs=3D"0"/> > minOccurs=3D"0"/> > minOccurs=3D"0"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D'0' > maxOccurs=3D'unbounded' > processContents=3D'lax'/> > > use=3D"required"/> > >=20 > The issue of whether to include a statement indicating that elements > from different/unknown namespaces is a separate issue and so far I > think the balance is towards not including such a statement. >=20 > Regards > Andy Hutton (as chair). >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: 23 September 2011 17:00 > > To: siprec@ietf.org > > Subject: [siprec] Consensus calls from session 2 > > > > Please raise any objections by 2011-10-03 to the following > conclusions > > from today's call: > > > > - List of SSRCs to be part of the association between participant and > > session. > > - Extension data representation in XML as proposed on metadata slide > > 19. > > - Structured element for use within a > element > > as shown on slide 20 (subject to clarification on need for language > > attribute). > > - Adoption of XML syntax from RFC 4235 for representation of > > capabilities in metadata. > > > > 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 rmohanr@cisco.com Wed Oct 12 01:52:03 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 8E7C121F8B08 for ; Wed, 12 Oct 2011 01:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.166 X-Spam-Level: X-Spam-Status: No, score=-5.166 tagged_above=-999 required=5 tests=[AWL=-2.567, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75HMB-7FoyXb for ; Wed, 12 Oct 2011 01:52:02 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCD421F8586 for ; Wed, 12 Oct 2011 01:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=5364; q=dns/txt; s=iport; t=1318409522; x=1319619122; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=/1l1wV1xGuIQ6rcluYFUjrR5FbDwBBXJeNU742NAfCA=; b=SRVCMtSGoqm+RvG6BslDFJFhlxlICo4sEjl+GsGJl8ElUCh7U7ICyUxN 59nNDPaj/qBGQMo2KuVBP4nCL5gSAe89ABJllpNH5iUu2VMihXIw7tPgD Ngm8zedaw2zQ1BihEDZEQyhwqL3lQJmEzP9c3LS3xuhb0rk5tYDTG/uH9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4AAClUlU5Io8UR/2dsb2JhbABDmQuPH4EFgVMBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgCBAEKCAgBGaFCAZ5ghndhBId9kSmEfIcv X-IronPort-AV: E=Sophos;i="4.69,333,1315180800"; d="scan'208";a="845098" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-3.cisco.com with ESMTP; 12 Oct 2011 08:51:59 +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 p9C8pwNm013988; Wed, 12 Oct 2011 08:51:58 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); Wed, 12 Oct 2011 14:21:58 +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, 12 Oct 2011 14:21:57 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need Inputs: How to represent attributes of association in Metadata Model and in XML ? Thread-Index: AcxpN2nvMrV1sN8uRu+Luw3VEq0S1gPwV65AAA/0UMAAA6GZIAAdZqPAAAKM0EADtQfg8AAErBHQAAN//xA= References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Leon Portman" , X-OriginalArrivalTime: 12 Oct 2011 08:51:58.0543 (UTC) FILETIME=[3374E5F0:01CC88BC] Cc: Ofir Roth Subject: Re: [siprec] Need Inputs: How to represent attributes of association in Metadata Model and 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, 12 Oct 2011 08:52:03 -0000 Leon, Thanks for your response. One of the adv with approach 2 is we can indicate only changes in the association without the need to indicating the elements ( of association). IOW for the below example, if there is a change in participant-stream association I can simply send the following in partial update: 2010-12-16T23:41:07Z Do you see a need to always indicate the related elements too ? In which case I see approach 1 as more suitable. Thanks, Ram > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Wednesday, October 12, 2011 12:55 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Cc: Ofir Roth > Subject: RE: Need Inputs: How to represent attributes of association > inmetadata Model and in XML ? >=20 > Ram Hi >=20 > I am ok with approaches 1 and however I do prefer approach one because > it will be easier for SRS to get decode - association is inside > relevant element. And it is more readable. > Approach 2 will work as well, however it is important that if there > will be a change in association then to send to SRS not only updated > association element but also related elements: for example if stream > was associated to participant and session, send also participant and > session latest state. >=20 > Regards >=20 > Leon >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: Wednesday, October 12, 2011 7:48 AM > To: siprec@ietf.org > Subject: [siprec] Need Inputs: How to represent attributes of > association in metadata Model and in XML ? >=20 > (Sorry for lengthy e-mail) >=20 > Hi All, >=20 > In the last interim we discussed 4 approaches for representing > attributes of association in XML. >=20 >=20 > Here are some pros/cons for each of them: > Approach 1: > ---------- > Represent the association attribute as a property within one of the > associated elements. Example given at http://www.ietf.org/mail- > archive/web/siprec/current/msg02709.html Does not need another XML > element and represents the association attributes as capability of one > of the association element. > e.g. > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > sip:ram@blr.cisco.com > 2010-12-16T23:41:07Z > TBD > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820- > d03a191fb76a > "> > 2010-12-16T23:41:07Z time> > contributing SSRC-1 > In the above > example the participant contributes a single streams. For each stream > the association attribute (participant-stream) is shown with the stream > ID nested in. >=20 >=20 > Approach 2: > ----------- > In this approach we have a new XML element for every association class. > This xml element will NOT have a unique ID instead it references the ID > of associated elements (shown below). With this approach it is easy to > update as the association class is a separate XML element and not > property. > e.g. > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > 2010-12-16T23:41:07Z > TBD > >=20 > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > 2010-12-16T23:41:07Z > contributing SSRC-1 > >=20 > Approach 3 and 4 are in the below e-mail from John. > Approach 3 defines a new Unique ID for every association XML elment. > Also it creates alias for the other IDs. In the discussions in interim > there was no strong support for this approach. >=20 > Approach 4 is same as approach 1 where in the association element is > encapsulated in one of the XML elements (to which it is associated). > In addition to that it also has reference to the elements (alias of > IDs) to which the association belongs. >=20 > I prefer approach 2 as it is has a separate XML element to represent > the association class. The only difference of this XML element from > others is this does not need a unique ID. Instead it references the IDs > of the elements to which the association belongs. > Since association class is a special class meant to associate multiple > classes, I see it ok to have a representation as in approach 2 where in > the identifier is the concatenation of the classes to which the > association belongs to. >=20 > Please provide your comments on this and also suggest any other > approaches to represent association classes in XML. >=20 > Regards, > Ram >=20 From Leon.Portman@nice.com Wed Oct 12 01:54: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 ADC9E21F8BF9 for ; Wed, 12 Oct 2011 01:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHraCzM9KXF3 for ; Wed, 12 Oct 2011 01:54:23 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 56D7221F8BA0 for ; Wed, 12 Oct 2011 01:54:22 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 12 Oct 2011 10:54:21 +0200 From: Leon Portman To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Wed, 12 Oct 2011 10:54:20 +0200 Thread-Topic: Need Inputs: How to represent attributes of association in Metadata Model and in XML ? Thread-Index: AcxpN2nvMrV1sN8uRu+Luw3VEq0S1gPwV65AAA/0UMAAA6GZIAAdZqPAAAKM0EADtQfg8AAErBHQAAN//xAAACI30A== Message-ID: <07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com> References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com> 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: Ofir Roth Subject: Re: [siprec] Need Inputs: How to represent attributes of association in Metadata Model and 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, 12 Oct 2011 08:54:23 -0000 We do prefer to receive related elements as well, it makes implementation m= uch easier. At least we should get relevant IDs. For example below, SRC should also s= end ParticipantId -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: Wednesday, October 12, 2011 10:52 AM To: Leon Portman; siprec@ietf.org Cc: Ofir Roth Subject: RE: Need Inputs: How to represent attributes of association in Met= adata Model and in XML ? Leon, Thanks for your response. One of the adv with approach 2 is we can indicate= only changes in the association without the need to indicating the element= s ( of association). IOW for the below example, if there is a change in par= ticipant-stream association I can simply send the following in partial upda= te: 2010-12-16T23:41:07Z Do you see a need to always indicate the related elements too ? In which ca= se I see approach 1 as more suitable. Thanks, Ram > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Wednesday, October 12, 2011 12:55 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Cc: Ofir Roth > Subject: RE: Need Inputs: How to represent attributes of association=20 > inmetadata Model and in XML ? >=20 > Ram Hi >=20 > I am ok with approaches 1 and however I do prefer approach one because > it will be easier for SRS to get decode - association is inside=20 > relevant element. And it is more readable. > Approach 2 will work as well, however it is important that if there=20 > will be a change in association then to send to SRS not only updated=20 > association element but also related elements: for example if stream=20 > was associated to participant and session, send also participant and=20 > session latest state. >=20 > Regards >=20 > Leon >=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Ram Mohan R (rmohanr) > Sent: Wednesday, October 12, 2011 7:48 AM > To: siprec@ietf.org > Subject: [siprec] Need Inputs: How to represent attributes of=20 > association in metadata Model and in XML ? >=20 > (Sorry for lengthy e-mail) >=20 > Hi All, >=20 > In the last interim we discussed 4 approaches for representing=20 > attributes of association in XML. >=20 >=20 > Here are some pros/cons for each of them: > Approach 1: > ---------- > Represent the association attribute as a property within one of the=20 > associated elements. Example given at http://www.ietf.org/mail-=20 > archive/web/siprec/current/msg02709.html Does not need another XML=20 > element and represents the association attributes as capability of one=20 > of the association element. > e.g. > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > sip:ram@blr.cisco.com > 2010-12-16T23:41:07Z > TBD > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820- > d03a191fb76a > "> > 2010-12-16T23:41:07Z time> > contributing SSRC-1 > In the above > example the participant contributes a single streams. For each stream=20 > the association attribute (participant-stream) is shown with the stream > ID nested in. >=20 >=20 > Approach 2: > ----------- > In this approach we have a new XML element for every association class. > This xml element will NOT have a unique ID instead it references the ID > of associated elements (shown below). With this approach it is easy to=20 > update as the association class is a separate XML element and not=20 > property. > e.g. > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > 2010-12-16T23:41:07Z > TBD > >=20 > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > 2010-12-16T23:41:07Z > contributing SSRC-1 > >=20 > Approach 3 and 4 are in the below e-mail from John. > Approach 3 defines a new Unique ID for every association XML elment. > Also it creates alias for the other IDs. In the discussions in interim=20 > there was no strong support for this approach. >=20 > Approach 4 is same as approach 1 where in the association element is=20 > encapsulated in one of the XML elements (to which it is associated). > In addition to that it also has reference to the elements (alias of > IDs) to which the association belongs. >=20 > I prefer approach 2 as it is has a separate XML element to represent=20 > the association class. The only difference of this XML element from=20 > others is this does not need a unique ID. Instead it references the IDs > of the elements to which the association belongs. > Since association class is a special class meant to associate multiple=20 > classes, I see it ok to have a representation as in approach 2 where in > the identifier is the concatenation of the classes to which the=20 > association belongs to. >=20 > Please provide your comments on this and also suggest any other=20 > approaches to represent association classes in XML. >=20 > Regards, > Ram >=20 From rmohanr@cisco.com Wed Oct 12 01:56: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 DDA4B21F8B1E for ; Wed, 12 Oct 2011 01:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=-1.925, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNrCo2E2reYF for ; Wed, 12 Oct 2011 01:56:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id BC0B921F8B1D for ; Wed, 12 Oct 2011 01:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=6898; q=dns/txt; s=iport; t=1318409818; x=1319619418; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BaNVNLWCpAOuJ6hI9KCjRkGlxKGFYsva1BjaCBie32E=; b=UUr0D61uFxtoX2GMsXZHL+iyT+X52Ix6aKyZGa1Zv+LCK/Lu1Mi3vhRN ys20/whjfpM6nck5jbvIevZd0iacWjL7Ay43iM0ui7kz9qkVjEw5mDwpF Yl9yja1qA6l0SuBjZsWxFK2EYzX5AlexBGgnzQTNos0cnKhNTKjJzO8Df w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4AABhVlU6rRDoJ/2dsb2JhbABDmQuPH4EFgVMBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgCBAEKCAgBGaFAAZ5ghndhBId9kSmEfIcv X-IronPort-AV: E=Sophos;i="4.69,333,1315180800"; d="scan'208";a="7385624" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 12 Oct 2011 08:56:58 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9C8utbh026937; Wed, 12 Oct 2011 08:56:57 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, 12 Oct 2011 14:26:55 +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, 12 Oct 2011 14:26:54 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need Inputs: How to represent attributes of association in Metadata Model and in XML ? Thread-Index: AcxpN2nvMrV1sN8uRu+Luw3VEq0S1gPwV65AAA/0UMAAA6GZIAAdZqPAAAKM0EADtQfg8AAErBHQAAN//xAAACI30AAAFh6A References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Leon Portman" , X-OriginalArrivalTime: 12 Oct 2011 08:56:55.0379 (UTC) FILETIME=[E4627A30:01CC88BC] Cc: Ofir Roth Subject: Re: [siprec] Need Inputs: How to represent attributes of association in Metadata Model and 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, 12 Oct 2011 08:57:00 -0000 My bad(typo) while sending the example. The correct partial update I intended to send is:=20 2010-12-16T23:41:07Z This is inline with approach 2 where in each association XML element will have the IDs of the related associated elements. Ram > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Wednesday, October 12, 2011 2:24 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Cc: Ofir Roth > Subject: RE: Need Inputs: How to represent attributes of association in > Metadata Model and in XML ? >=20 > We do prefer to receive related elements as well, it makes > implementation much easier. > At least we should get relevant IDs. For example below, SRC should > also send ParticipantId >=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Wednesday, October 12, 2011 10:52 AM > To: Leon Portman; siprec@ietf.org > Cc: Ofir Roth > Subject: RE: Need Inputs: How to represent attributes of association in > Metadata Model and in XML ? >=20 > Leon, > Thanks for your response. One of the adv with approach 2 is we can > indicate only changes in the association without the need to indicating > the elements ( of association). IOW for the below example, if there is > a change in participant-stream association I can simply send the > following in partial update: >=20 >=20 > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> > 2010-12-16T23:41:07Z > >=20 > Do you see a need to always indicate the related elements too ? In > which case I see approach 1 as more suitable. >=20 > Thanks, > Ram >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: Wednesday, October 12, 2011 12:55 PM > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > Cc: Ofir Roth > > Subject: RE: Need Inputs: How to represent attributes of association > > inmetadata Model and in XML ? > > > > Ram Hi > > > > I am ok with approaches 1 and however I do prefer approach one > because > > it will be easier for SRS to get decode - association is inside > > relevant element. And it is more readable. > > Approach 2 will work as well, however it is important that if there > > will be a change in association then to send to SRS not only updated > > association element but also related elements: for example if stream > > was associated to participant and session, send also participant and > > session latest state. > > > > Regards > > > > Leon > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ram Mohan R (rmohanr) > > Sent: Wednesday, October 12, 2011 7:48 AM > > To: siprec@ietf.org > > Subject: [siprec] Need Inputs: How to represent attributes of > > association in metadata Model and in XML ? > > > > (Sorry for lengthy e-mail) > > > > Hi All, > > > > In the last interim we discussed 4 approaches for representing > > attributes of association in XML. > > > > > > Here are some pros/cons for each of them: > > Approach 1: > > ---------- > > Represent the association attribute as a property within one of the > > associated elements. Example given at http://www.ietf.org/mail- > > archive/web/siprec/current/msg02709.html Does not need another XML > > element and represents the association attributes as capability of > one > > of the association element. > > e.g. > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > = session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > sip:ram@blr.cisco.com > > 2010-12-16T23:41:07Z time> > > TBD > > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820- > > d03a191fb76a > > "> > > 2010-12-16T23:41:07Z > time> > > contributing SSRC-1 > > In the > above > > example the participant contributes a single streams. For each stream > > the association attribute (participant-stream) is shown with the > stream > > ID nested in. > > > > > > Approach 2: > > ----------- > > In this approach we have a new XML element for every association > class. > > This xml element will NOT have a unique ID instead it references the > ID > > of associated elements (shown below). With this approach it is easy > to > > update as the association class is a separate XML element and not > > property. > > e.g. > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > 2010-12-16T23:41:07Z > > TBD > > > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > 2010-12-16T23:41:07Z > > contributing SSRC-1 > > > > > > Approach 3 and 4 are in the below e-mail from John. > > Approach 3 defines a new Unique ID for every association XML elment. > > Also it creates alias for the other IDs. In the discussions in > interim > > there was no strong support for this approach. > > > > Approach 4 is same as approach 1 where in the association element is > > encapsulated in one of the XML elements (to which it is associated). > > In addition to that it also has reference to the elements (alias of > > IDs) to which the association belongs. > > > > I prefer approach 2 as it is has a separate XML element to represent > > the association class. The only difference of this XML element from > > others is this does not need a unique ID. Instead it references the > IDs > > of the elements to which the association belongs. > > Since association class is a special class meant to associate > multiple > > classes, I see it ok to have a representation as in approach 2 where > in > > the identifier is the concatenation of the classes to which the > > association belongs to. > > > > Please provide your comments on this and also suggest any other > > approaches to represent association classes in XML. > > > > Regards, > > Ram > > From rmohanr@cisco.com Wed Oct 12 06:25: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 0F59E21F8CAA for ; Wed, 12 Oct 2011 06:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.839 X-Spam-Level: X-Spam-Status: No, score=-7.839 tagged_above=-999 required=5 tests=[AWL=2.160, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9EZ+U0xMxbe for ; Wed, 12 Oct 2011 06:25: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 4DA5021F8CA0 for ; Wed, 12 Oct 2011 06:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=4517; q=dns/txt; s=iport; t=1318425919; x=1319635519; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=vPx2pKxhbhVw/Q06D2lTO9/t0s0JMNS2nFv0Tfdn/vQ=; b=k2gxHVWJ4N7EUMAd7QYUwMLyTzJhIavZN+g6R28myZEpm13jEhvzVAhJ eOBoxcDwcdqg8Ubnhmq9a2fY+eYgHbUFRFlvt6T6O5KwDQR8fqg2ddGSF o4bKP5aVyR/9MV0fc4TC4N4ItxaGhPaE+8rjGQVmtIuKHjmuNpwAVoJkR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4AABiUlU5Io8UQ/2dsb2JhbABDmRCPH4EFgVMBAQEDAQEBAQ8BHQouBgQMBwQCAQgRAQMBAQsGFwEGASYfAwYIAQEECgEICBqHXAibOQGeZIZ3YQSHfZEpjCs X-IronPort-AV: E=Sophos;i="4.69,334,1315180800"; d="scan'208";a="118933075" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2011 13:25:14 +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 p9CDPD5j027942 for ; Wed, 12 Oct 2011 13:25:13 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, 12 Oct 2011 18:55:13 +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, 12 Oct 2011 18:55:10 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07F6FAD3@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Metadata-04 - comments on section 4 Thread-Index: Acx8LeCRZxuZ6O2nSXWxORtb4/gcrAMs49EA References: From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 12 Oct 2011 13:25:13.0572 (UTC) FILETIME=[5FA7CA40:01CC88E2] Subject: Re: [siprec] Metadata-04 - comments on section 4 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, 12 Oct 2011 13:25:28 -0000 Hi John, Thanks for your comments. Please see inline for my responses. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Monday, September 26, 2011 2:53 PM > To: siprec@ietf.org > Subject: [siprec] Metadata-04 - comments on section 4 >=20 > (as individual) >=20 > 1. "The Metadata model is a class diagram in Unified Modelling > Language(UML). The model is a structure diagram that describes the > structure of a recording's Metadata by showing the classes, their > attributes, and the relationships among the classes." > The two sentences seem to be in conflict - is it a class diagram or a > structure diagram? I will change it to class diagram to make it uniform. > Also, I believe the class diagram represents the structure of metadata > in general, not the structure of metadata for a particular recording. Agreed. >=20 > 2. "Session Recording Client (SRC) MAY initiate the > Recording Session." > This sounds like protocol to me. We should not have normative > statements about initiating an RS in a section describing the metadata > model. I will remove this statement from the document. >=20 > 3. "Here, Recording Session is a completely > independent from the Communication Session that is being recorded at > both the SIP dialog level and at the session level." > We should import definitions of CS and RS, and we should not need to > explain the difference in this section. Ok. I have given reference to architecture document that has definitions. So I will remove this statement. >=20 > 4. "The metadata > MUST be conveyed from SRC to SRS." > This too sounds like protocol. I don't think this is related to protocol. This tells from where to where the metadata has to be conveyed. I don't see any problems in having this.=20 >=20 > 5. "For example, if the call is transferred from > one participant to another, then the SRC conveys the changes in the > model ( In this instance change of participant and the properties of > the new media stream) to the SRS." > This is probably a bad example. Although call transfer could be > modelled as a change of participant in a CS, it could also be modelled > as a change of CS (where one of the Participants is common). Can we > pick an example where there is less scope for doing things differently > (e.g., a Participant joins a conference)? I agree that call transfer can be modeled as a change in participant or even a change in CS depending on type of transfer(INVITE based or REFER). I will try to give some other example. >=20 > 6. "Some of the metadata is not required to be conveyed explicitly from > the SRC to the SRS, if it can be obtained contextually by the SRS. > For instance, the timing of RS object changes(like Start / Stop > time) > may not be explicitly conveyed from the SRC to the SRS (The Date > header in RS dialog SIP message provides the timing, but it is > optional). In such cases the time a change occurred may be assumed > to be the same as the time when notification of the change is > received by the SRS. This is not true in cases where SRS requests a > snapshot of metadata from SRC." > The first sentence seems OK, but I worry about the example that > follows. It is getting into protocol, and the final sentence is > certainly protocol. Perhaps all that is needed is to cite SIP/SDP as an > example, e.g.: > "Some of the metadata is not required to be conveyed explicitly from > the SRC to the SRS, if it can be obtained contextually by the SRS > (e.g., from SIP or SDP signalling)." I will replace the above text with this text. Thanks, Ram > Even that is perhaps not relevant for section 4 - and I see section 5, > which might be more appropriate, already has something similar. >=20 > John >=20 >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 > 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG. >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Wed Oct 12 14:17: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 AF0DA21F8C82 for ; Wed, 12 Oct 2011 14:17:17 -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=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvcFF3we0cuw for ; Wed, 12 Oct 2011 14:17:17 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A582121F8B72 for ; Wed, 12 Oct 2011 14:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5088; q=dns/txt; s=iport; t=1318454235; x=1319663835; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=SllsZjkdMK4PXzgN14qRAyGGXvlQoGubULzJ0NAZ+hU=; b=EiY3aya6HO1WM4G4u6bEYUGxLGdl+fm/pG66ORJXCdENe97tdDiPeoUA MYasJDHJjGloBANhQ/gOO8wZO5juha64OHopJQoyx0JFz1g86VGVRVA7S 33vTUY2WvHExwVRoPlXUG1rf1uwNk9TyHOyQLHfhhL1+Nfo0Vz30DJBDO o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIAAAIDlk6rRDoJ/2dsb2JhbABDmRiPIYEFgVMBAQEBAwEBAQsEAR0KKwkLDAQCAQgRBAEBCwYTBAEGASYfCQgBAQQBEggah2SaUwGeRoZ3YQSHf5EnjEM X-IronPort-AV: E=Sophos;i="4.69,336,1315180800"; d="scan'208";a="7502004" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 12 Oct 2011 21:17:15 +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 p9CLHF8N004481; Wed, 12 Oct 2011 21:17:15 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, 12 Oct 2011 14:17: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: Wed, 12 Oct 2011 14:17:12 -0700 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9CC@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] xml:lang attribute for element ( was RE:Consensus calls from session 2 - Success ) Thread-Index: Acx6Cdf7zXd6cJd8T2+ObVeaFd4jlAKLgwHwAR1icUAAHY5qwA== References: <101C6067BEC68246B0C3F6843BCCC1E311F7D41C9D@MCHP058A.global-ad.net> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9CC@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "Hutton, Andrew" , "Elwell, John" , X-OriginalArrivalTime: 12 Oct 2011 21:17:15.0201 (UTC) FILETIME=[50A96B10:01CC8924] Cc: "Peter Saint-Andre \(psaintan\)" Subject: Re: [siprec] xml:lang attribute for element ( was RE:Consensus calls from session 2 - Success ) 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, 12 Oct 2011 21:17:17 -0000 Hi Ram, In your description and schema, it seems xml:lang is an attribute of "nameID"; however, I think the intent is to have it be an attribute of "name", isn't it? If this is true, then the example is fine, but the XML schema looks incorrect to me.=20 Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > Sent: Wednesday, October 12, 2011 1:47 AM > To: Hutton, Andrew; Elwell, John; siprec@ietf.org > Cc: Peter Saint-Andre (psaintan) > Subject: [siprec] xml:lang attribute for element ( was RE:Consensus calls from session 2 - > Success ) >=20 > In the last interim there was a *consensus* to have xml element > (as shown below) in the metadata document to indicate multiple name/AoR > pairs. However there was a comment to clarify on the need for language > attribute in XML document. >=20 > Xml:lang is a special attribute may be inserted in documents to specify > the language used in the contents and attribute values of any element in > an XML document. More information at section 2.12 of > http://www.w3.org/TR/REC-xml/ >=20 > Some of the SIP RFC like RFC 3680 already uses xml:lang for display-name > which is what we also need here. >=20 > So I am planning to make this as optional attribute following the > similar approach as done in RFC 3680. >=20 > The schema for nameID would look as: >=20 > > > minOccurs=3D"0" maxOccurs=3D"1"/> > maxOccurs=3D"1"/> > > > >=20 > Example is >=20 > > sip:alice@atlanta.com > Alice Smith > =20 > Regards, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: Thursday, October 06, 2011 8:37 PM > > To: Elwell, John; siprec@ietf.org > > Subject: [siprec] Consensus calls from session 2 - Success > > > > Hi, > > > > I believe there are no outstanding objections to these items so can > the > > editors go ahead and incorporate these changes in their next update. > > > > With regard to the discussion on extension data representatives I > > believe consensus is to go with the approach as described in Ram's e- > > mail on the 2011-09-26 which gave this example: > > > > > > > > > minOccurs=3D"0"/> > > > minOccurs=3D"0"/> > > > minOccurs=3D"0"/> > > > minOccurs=3D"0" maxOccurs=3D"1"/> > > > minOccurs=3D'0' > > maxOccurs=3D'unbounded' > > processContents=3D'lax'/> > > > > > use=3D"required"/> > > > > > > The issue of whether to include a statement indicating that elements > > from different/unknown namespaces is a separate issue and so far I > > think the balance is towards not including such a statement. > > > > Regards > > Andy Hutton (as chair). > > > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: 23 September 2011 17:00 > > > To: siprec@ietf.org > > > Subject: [siprec] Consensus calls from session 2 > > > > > > Please raise any objections by 2011-10-03 to the following > > conclusions > > > from today's call: > > > > > > - List of SSRCs to be part of the association between participant > and > > > session. > > > - Extension data representation in XML as proposed on metadata slide > > > 19. > > > - Structured element for use within a > > element > > > as shown on slide 20 (subject to clarification on need for language > > > attribute). > > > - Adoption of XML syntax from RFC 4235 for representation of > > > capabilities in metadata. > > > > > > 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 rmohanr@cisco.com Thu Oct 13 00:05:07 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 0C6F021F8B20 for ; Thu, 13 Oct 2011 00:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugi7PRchenhZ for ; Thu, 13 Oct 2011 00:05:05 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2970C21F8B1E for ; Thu, 13 Oct 2011 00:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=6509; q=dns/txt; s=iport; t=1318489505; x=1319699105; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jpXfRvcrpAgMXKJivsJkfQJzoKtlqXLUp66XU7fb9xE=; b=TKT4zRHgNke5ce3Qhf6ZJZ8n6bAhbIvuyIHqTf3Lymms5m2TJVX6uzA6 zLhMWA0b4p0GRHMsJoF6QC5nqy5N+UUccwcbRzKrJm+qK2bqHa4NlxMh+ XEXRwcuJZQOVxLnPc9IkDiumj4XdhivCzj+96Jup53sN+IDU+mOnKedaA Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4AAAONlk5Io8UT/2dsb2JhbABDmSuPIYEFgVMBAQEEAQEBCwQBHQorCQsMBAIBCBEEAQELBhMEAQYBJh8JCAEBBAEKCAgah2SZSgGeJ4cMYQSHf5EqjCw X-IronPort-AV: E=Sophos;i="4.69,338,1315180800"; d="scan'208";a="919543" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-3.cisco.com with ESMTP; 13 Oct 2011 07:05:03 +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 p9D752JG002173; Thu, 13 Oct 2011 07:05: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); Thu, 13 Oct 2011 12:34:58 +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, 13 Oct 2011 12:34:56 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD08091049@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] xml:lang attribute for element ( was RE:Consensus calls from session 2 - Success ) Thread-Index: Acx6Cdf7zXd6cJd8T2+ObVeaFd4jlAKLgwHwAR1icUAAHY5qwAAUY76Q References: <101C6067BEC68246B0C3F6843BCCC1E311F7D41C9D@MCHP058A.global-ad.net> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9CC@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "Hutton, Andrew" , X-OriginalArrivalTime: 13 Oct 2011 07:04:58.0804 (UTC) FILETIME=[6B683740:01CC8976] Cc: "Peter Saint-Andre \(psaintan\)" Subject: Re: [siprec] xml:lang attribute for element ( was RE:Consensus calls from session 2 - Success ) 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, 13 Oct 2011 07:05:07 -0000 Charles, You are right. The schema I pasted below has a error as it shows xml:lang as attribute of nameID. I will change it to as below(again referred 3680 to derive this): =20 Let me know if this schema is correct. Thanks, Ram > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Thursday, October 13, 2011 2:47 AM > To: Ram Mohan R (rmohanr); Hutton, Andrew; Elwell, John; > siprec@ietf.org > Cc: Peter Saint-Andre (psaintan) > Subject: RE: [siprec] xml:lang attribute for element ( was > RE:Consensus calls from session 2 - Success ) >=20 > Hi Ram, >=20 > In your description and schema, it seems xml:lang is an attribute of > "nameID"; however, I think the intent is to have it be an attribute of > "name", isn't it? > If this is true, then the example is fine, but the XML schema looks > incorrect to me. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > > Sent: Wednesday, October 12, 2011 1:47 AM > > To: Hutton, Andrew; Elwell, John; siprec@ietf.org > > Cc: Peter Saint-Andre (psaintan) > > Subject: [siprec] xml:lang attribute for element ( was > RE:Consensus calls from session 2 - > > Success ) > > > > In the last interim there was a *consensus* to have xml > element > > (as shown below) in the metadata document to indicate multiple > name/AoR > > pairs. However there was a comment to clarify on the need for > language > > attribute in XML document. > > > > Xml:lang is a special attribute may be inserted in documents to > specify > > the language used in the contents and attribute values of any element > in > > an XML document. More information at section 2.12 of > > http://www.w3.org/TR/REC-xml/ > > > > Some of the SIP RFC like RFC 3680 already uses xml:lang for display- > name > > which is what we also need here. > > > > So I am planning to make this as optional attribute following the > > similar approach as done in RFC 3680. > > > > The schema for nameID would look as: > > > > > > > > > minOccurs=3D"0" maxOccurs=3D"1"/> > > > maxOccurs=3D"1"/> > > > > > > > > > > Example is > > > > > > sip:alice@atlanta.com > > Alice Smith > > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Hutton, Andrew > > > Sent: Thursday, October 06, 2011 8:37 PM > > > To: Elwell, John; siprec@ietf.org > > > Subject: [siprec] Consensus calls from session 2 - Success > > > > > > Hi, > > > > > > I believe there are no outstanding objections to these items so can > > the > > > editors go ahead and incorporate these changes in their next > update. > > > > > > With regard to the discussion on extension data representatives I > > > believe consensus is to go with the approach as described in Ram's > e- > > > mail on the 2011-09-26 which gave this example: > > > > > > > > > > > > > > minOccurs=3D"0"/> > > > > > minOccurs=3D"0"/> > > > > > minOccurs=3D"0"/> > > > > > minOccurs=3D"0" maxOccurs=3D"1"/> > > > > > minOccurs=3D'0' > > > maxOccurs=3D'unbounded' > > > processContents=3D'lax'/> > > > > > > > > use=3D"required"/> > > > > > > > > > The issue of whether to include a statement indicating that > elements > > > from different/unknown namespaces is a separate issue and so far I > > > think the balance is towards not including such a statement. > > > > > > Regards > > > Andy Hutton (as chair). > > > > > > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Elwell, John > > > > Sent: 23 September 2011 17:00 > > > > To: siprec@ietf.org > > > > Subject: [siprec] Consensus calls from session 2 > > > > > > > > Please raise any objections by 2011-10-03 to the following > > > conclusions > > > > from today's call: > > > > > > > > - List of SSRCs to be part of the association between participant > > and > > > > session. > > > > - Extension data representation in XML as proposed on metadata > slide > > > > 19. > > > > - Structured element for use within a > > > element > > > > as shown on slide 20 (subject to clarification on need for > language > > > > attribute). > > > > - Adoption of XML syntax from RFC 4235 for representation of > > > > capabilities in metadata. > > > > > > > > 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 pkyzivat@alum.mit.edu Thu Oct 13 10:17: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 EAEBB21F8B39 for ; Thu, 13 Oct 2011 10:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkahf23Ghfll for ; Thu, 13 Oct 2011 10:17:42 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id D749F21F8ADE for ; Thu, 13 Oct 2011 10:17:41 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta10.westchester.pa.mail.comcast.net with comcast id kH691h0030Fqzac5AHHcc7; Thu, 13 Oct 2011 17:17:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta08.westchester.pa.mail.comcast.net with comcast id kHHb1h0090tdiYw3UHHc4X; Thu, 13 Oct 2011 17:17:36 +0000 Message-ID: <4E971D30.5090101@alum.mit.edu> Date: Thu, 13 Oct 2011 13:17:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Need Inputs: How to represent attributes of association in Metadata Model and 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, 13 Oct 2011 17:17:43 -0000 I like approach 2, as Ram has shown it. It deals with the problems John raised with the others. I didn't follow John's arithmetic on this one, using his 20 party conference example. As I count that, there are 21 participants when you include the focus. Each of the 20 has two stream/participant associations with the focus, for a total of 40. (The association is bidirectional. I can only get to 80 by assuming we had to represent an association in each direction.) And each has two ids, each of which is also the id of a stream or participant. So there are really only 23 distinct ids that need to be assigned for this. (One for each of the 21 participants, and one for each of the two streams.) The 40 associations, each carrying two ids, is still kind of a lot if its sent all at once. But when starting up a conference they will probably be added gradually as each participant joins. Same at the end if they drop off individually. But it could be a bunch together if the conference is forcibly dropped by the focus. But it does minimize what is sent when things happen incrementally. There may be some optimizations that can be done - e.g. a sort of "wildcard" for one of the the two ids in the association class. E.g. 2010-12-16T23:41:07Z (I'm not advocating that particular syntax. Its just something to make the point.) Thanks, Paul On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: > My bad(typo) while sending the example. The correct partial update I > intended to send is: > > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > 2010-12-16T23:41:07Z > > > This is inline with approach 2 where in each association XML element > will have the IDs of the related associated elements. > > Ram > >> -----Original Message----- >> From: Leon Portman [mailto:Leon.Portman@nice.com] >> Sent: Wednesday, October 12, 2011 2:24 PM >> To: Ram Mohan R (rmohanr); siprec@ietf.org >> Cc: Ofir Roth >> Subject: RE: Need Inputs: How to represent attributes of association > in >> Metadata Model and in XML ? >> >> We do prefer to receive related elements as well, it makes >> implementation much easier. >> At least we should get relevant IDs. For example below, SRC should >> also send ParticipantId >> >> -----Original Message----- >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> Sent: Wednesday, October 12, 2011 10:52 AM >> To: Leon Portman; siprec@ietf.org >> Cc: Ofir Roth >> Subject: RE: Need Inputs: How to represent attributes of association > in >> Metadata Model and in XML ? >> >> Leon, >> Thanks for your response. One of the adv with approach 2 is we can >> indicate only changes in the association without the need to > indicating >> the elements ( of association). IOW for the below example, if there is >> a change in participant-stream association I can simply send the >> following in partial update: >> >> >> > stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> >> 2010-12-16T23:41:07Z >> >> >> Do you see a need to always indicate the related elements too ? In >> which case I see approach 1 as more suitable. >> >> Thanks, >> Ram >> >>> -----Original Message----- >>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>> Sent: Wednesday, October 12, 2011 12:55 PM >>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>> Cc: Ofir Roth >>> Subject: RE: Need Inputs: How to represent attributes of association >>> inmetadata Model and in XML ? >>> >>> Ram Hi >>> >>> I am ok with approaches 1 and however I do prefer approach one >> because >>> it will be easier for SRS to get decode - association is inside >>> relevant element. And it is more readable. >>> Approach 2 will work as well, however it is important that if there >>> will be a change in association then to send to SRS not only updated >>> association element but also related elements: for example if stream >>> was associated to participant and session, send also participant and >>> session latest state. >>> >>> Regards >>> >>> Leon >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Ram Mohan R (rmohanr) >>> Sent: Wednesday, October 12, 2011 7:48 AM >>> To: siprec@ietf.org >>> Subject: [siprec] Need Inputs: How to represent attributes of >>> association in metadata Model and in XML ? >>> >>> (Sorry for lengthy e-mail) >>> >>> Hi All, >>> >>> In the last interim we discussed 4 approaches for representing >>> attributes of association in XML. >>> >>> >>> Here are some pros/cons for each of them: >>> Approach 1: >>> ---------- >>> Represent the association attribute as a property within one of the >>> associated elements. Example given at http://www.ietf.org/mail- >>> archive/web/siprec/current/msg02709.html Does not need another XML >>> element and represents the association attributes as capability of >> one >>> of the association element. >>> e.g. >>> >> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>> sip:ram@blr.cisco.com >>> 2010-12-16T23:41:07Z> time> >>> TBD >>> >> stream ="urn:uuid:f3373a7b-4958-4e55-8820- >>> d03a191fb76a >>> "> >>> 2010-12-16T23:41:07Z>> time> >>> contributing SSRC-1 >>> In the >> above >>> example the participant contributes a single streams. For each > stream >>> the association attribute (participant-stream) is shown with the >> stream >>> ID nested in. >>> >>> >>> Approach 2: >>> ----------- >>> In this approach we have a new XML element for every association >> class. >>> This xml element will NOT have a unique ID instead it references the >> ID >>> of associated elements (shown below). With this approach it is easy >> to >>> update as the association class is a separate XML element and not >>> property. >>> e.g. >>> >> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>> 2010-12-16T23:41:07Z >>> TBD >>> >>> >>> >> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>> 2010-12-16T23:41:07Z >>> contributing SSRC-1 >>> >>> >>> Approach 3 and 4 are in the below e-mail from John. >>> Approach 3 defines a new Unique ID for every association XML elment. >>> Also it creates alias for the other IDs. In the discussions in >> interim >>> there was no strong support for this approach. >>> >>> Approach 4 is same as approach 1 where in the association element is >>> encapsulated in one of the XML elements (to which it is > associated). >>> In addition to that it also has reference to the elements (alias of >>> IDs) to which the association belongs. >>> >>> I prefer approach 2 as it is has a separate XML element to represent >>> the association class. The only difference of this XML element from >>> others is this does not need a unique ID. Instead it references the >> IDs >>> of the elements to which the association belongs. >>> Since association class is a special class meant to associate >> multiple >>> classes, I see it ok to have a representation as in approach 2 where >> in >>> the identifier is the concatenation of the classes to which the >>> association belongs to. >>> >>> Please provide your comments on this and also suggest any other >>> approaches to represent association classes in XML. >>> >>> Regards, >>> Ram >>> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Thu Oct 13 10:38: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 7BC7421F8B62 for ; Thu, 13 Oct 2011 10:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOfWd2mqHYDe for ; Thu, 13 Oct 2011 10:38:14 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6931221F8B24 for ; Thu, 13 Oct 2011 10:38:14 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta06.westchester.pa.mail.comcast.net with comcast id kF5Q1h00A1YDfWL56HeECn; Thu, 13 Oct 2011 17:38:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id kHeD1h00p0tdiYw3gHeDEA; Thu, 13 Oct 2011 17:38:14 +0000 Message-ID: <4E972205.8070403@alum.mit.edu> Date: Thu, 13 Oct 2011 13:38:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E311F7D41C9D@MCHP058A.global-ad.net> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F9CC@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD08091049@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD08091049@XMB-BGL-417.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] xml:lang attribute for element ( was RE:Consensus calls from session 2 - Success ) 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, 13 Oct 2011 17:38:15 -0000 I think it would be possible to make the aor be an attribute of nameID, rather than an element. E.g. Alice Smith The xml experts will have to weigh in on the stylistic merits one one vs. the other. Regarding the specification of the xml language - is it really necessary? The value will presumably come out of a sip message, and AFAIK there is no way to specify the language used in the sip headers. (Accept-Language and Content-Language both apply to the *body* of the message, not the headers.) Thanks, Paul On 10/13/11 3:04 AM, Ram Mohan R (rmohanr) wrote: > Charles, > You are right. The schema I pasted below has a error as it shows > xml:lang as attribute of nameID. I will change it to as below(again > referred 3680 to derive this): > > > > > /> > > > > > > > > > > > > > Let me know if this schema is correct. > > Thanks, > Ram > >> -----Original Message----- >> From: Charles Eckel (eckelcu) >> Sent: Thursday, October 13, 2011 2:47 AM >> To: Ram Mohan R (rmohanr); Hutton, Andrew; Elwell, John; >> siprec@ietf.org >> Cc: Peter Saint-Andre (psaintan) >> Subject: RE: [siprec] xml:lang attribute for element ( was >> RE:Consensus calls from session 2 - Success ) >> >> Hi Ram, >> >> In your description and schema, it seems xml:lang is an attribute of >> "nameID"; however, I think the intent is to have it be an attribute of >> "name", isn't it? >> If this is true, then the example is fine, but the XML schema looks >> incorrect to me. >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ram Mohan R (rmohanr) >>> Sent: Wednesday, October 12, 2011 1:47 AM >>> To: Hutton, Andrew; Elwell, John; siprec@ietf.org >>> Cc: Peter Saint-Andre (psaintan) >>> Subject: [siprec] xml:lang attribute for element ( was >> RE:Consensus calls from session 2 - >>> Success ) >>> >>> In the last interim there was a *consensus* to have xml >> element >>> (as shown below) in the metadata document to indicate multiple >> name/AoR >>> pairs. However there was a comment to clarify on the need for >> language >>> attribute in XML document. >>> >>> Xml:lang is a special attribute may be inserted in documents to >> specify >>> the language used in the contents and attribute values of any > element >> in >>> an XML document. More information at section 2.12 of >>> http://www.w3.org/TR/REC-xml/ >>> >>> Some of the SIP RFC like RFC 3680 already uses xml:lang for display- >> name >>> which is what we also need here. >>> >>> So I am planning to make this as optional attribute following the >>> similar approach as done in RFC 3680. >>> >>> The schema for nameID would look as: >>> >>> >>> >>> >> minOccurs="0" maxOccurs="1"/> >>> >> maxOccurs="1"/> >>> >>> >>> >>> >>> Example is >>> >>> >>> sip:alice@atlanta.com >>> Alice Smith >>> >> >>> Regards, >>> Ram >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Hutton, Andrew >>>> Sent: Thursday, October 06, 2011 8:37 PM >>>> To: Elwell, John; siprec@ietf.org >>>> Subject: [siprec] Consensus calls from session 2 - Success >>>> >>>> Hi, >>>> >>>> I believe there are no outstanding objections to these items so > can >>> the >>>> editors go ahead and incorporate these changes in their next >> update. >>>> >>>> With regard to the discussion on extension data representatives I >>>> believe consensus is to go with the approach as described in Ram's >> e- >>>> mail on the 2011-09-26 which gave this example: >>>> >>>> >>>> >>>> >>> minOccurs="0"/> >>>> >>> minOccurs="0"/> >>>> >>> minOccurs="0"/> >>>> >>> minOccurs="0" maxOccurs="1"/> >>>> >>> minOccurs='0' >>>> maxOccurs='unbounded' >>>> processContents='lax'/> >>>> >>>> >>> use="required"/> >>>> >>>> >>>> The issue of whether to include a statement indicating that >> elements >>>> from different/unknown namespaces is a separate issue and so far I >>>> think the balance is towards not including such a statement. >>>> >>>> Regards >>>> Andy Hutton (as chair). >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On >>>>> Behalf Of Elwell, John >>>>> Sent: 23 September 2011 17:00 >>>>> To: siprec@ietf.org >>>>> Subject: [siprec] Consensus calls from session 2 >>>>> >>>>> Please raise any objections by 2011-10-03 to the following >>>> conclusions >>>>> from today's call: >>>>> >>>>> - List of SSRCs to be part of the association between > participant >>> and >>>>> session. >>>>> - Extension data representation in XML as proposed on metadata >> slide >>>>> 19. >>>>> - Structured element for use within a >>>> element >>>>> as shown on slide 20 (subject to clarification on need for >> language >>>>> attribute). >>>>> - Adoption of XML syntax from RFC 4235 for representation of >>>>> capabilities in metadata. >>>>> >>>>> 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 rmohanr@cisco.com Thu Oct 13 20:59: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 9F86321F8C26 for ; Thu, 13 Oct 2011 20:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.142 X-Spam-Level: X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbh4Ovi1+fWV for ; Thu, 13 Oct 2011 20:59:17 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 036B721F8C1F for ; Thu, 13 Oct 2011 20:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=9887; q=dns/txt; s=iport; t=1318564757; x=1319774357; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Zr6yME9H3i1K8cbRfao4c6wTBJOpkxt3eiQ2Lu0Idv8=; b=Xfc3QAaWk/kZyB0YHJWrMGM1E3gu/U/AiTsVTjBXf2PZ+P2D4PySOVsq WrjJlR4iFAB3mt8sm9vYMKFkHHNQhFPss54t7UBiV2E2D81pdH2i0TBtT iMWyVpufznsrVIX4g831buD99NVX1MNVJjpFchckmCxx3ritUZuTFiEGA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8AADCzl05Io8UT/2dsb2JhbABDDpknjyWBBYFTAQEBAQMBAQEPAR0KLgYXBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQBCggIARmHZJkAAZ4whwxhBId/kSmEfYZwPw X-IronPort-AV: E=Sophos;i="4.69,344,1315180800"; d="scan'208";a="992215" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-3.cisco.com with ESMTP; 14 Oct 2011 03:59:14 +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 p9E3xEwt004529; Fri, 14 Oct 2011 03:59:14 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, 14 Oct 2011 09:29:13 +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: Fri, 14 Oct 2011 09:29:12 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com> In-Reply-To: <4E971D30.5090101@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Need Inputs: How to represent attributes of association in Metadata Model and in XML ? Thread-Index: AcyJzAnx6nmGJ85NSxinaWr0J6PjtQAWXo3Q References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com> <4E971D30.5090101@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 14 Oct 2011 03:59:13.0865 (UTC) FILETIME=[A2EB3B90:01CC8A25] Subject: Re: [siprec] Need Inputs: How to represent attributes of association in Metadata Model and 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: Fri, 14 Oct 2011 03:59:18 -0000 Thanks Paul for your comments. I also prefer approach 2 as mentioned below in this thread. I will wait to hear for comments/opinion from others. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, October 13, 2011 10:48 PM > To: siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to represent attributes of > association in Metadata Model and in XML ? >=20 > I like approach 2, as Ram has shown it. It deals with the problems John > raised with the others. >=20 > I didn't follow John's arithmetic on this one, using his 20 party > conference example. As I count that, there are 21 participants when you > include the focus. Each of the 20 has two stream/participant > associations with the focus, for a total of 40. (The association is > bidirectional. I can only get to 80 by assuming we had to represent an > association in each direction.) And each has two ids, each of which is > also the id of a stream or participant. So there are really only 23 > distinct ids that need to be assigned for this. (One for each of the 21 > participants, and one for each of the two streams.) >=20 > The 40 associations, each carrying two ids, is still kind of a lot if > its sent all at once. But when starting up a conference they will > probably be added gradually as each participant joins. Same at the end > if they drop off individually. But it could be a bunch together if the > conference is forcibly dropped by the focus. But it does minimize what > is sent when things happen incrementally. >=20 > There may be some optimizations that can be done - e.g. a sort of > "wildcard" for one of the the two ids in the association class. E.g. >=20 > participant=3D"*" > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > 2010-12-16T23:41:07Z > >=20 > (I'm not advocating that particular syntax. Its just something to make > the point.) >=20 > Thanks, > Paul >=20 >=20 > On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: > > My bad(typo) while sending the example. The correct partial update I > > intended to send is: > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > 2010-12-16T23:41:07Z > > > > > > This is inline with approach 2 where in each association XML element > > will have the IDs of the related associated elements. > > > > Ram > > > >> -----Original Message----- > >> From: Leon Portman [mailto:Leon.Portman@nice.com] > >> Sent: Wednesday, October 12, 2011 2:24 PM > >> To: Ram Mohan R (rmohanr); siprec@ietf.org > >> Cc: Ofir Roth > >> Subject: RE: Need Inputs: How to represent attributes of association > > in > >> Metadata Model and in XML ? > >> > >> We do prefer to receive related elements as well, it makes > >> implementation much easier. > >> At least we should get relevant IDs. For example below, SRC > should > >> also send ParticipantId > >> > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >> Sent: Wednesday, October 12, 2011 10:52 AM > >> To: Leon Portman; siprec@ietf.org > >> Cc: Ofir Roth > >> Subject: RE: Need Inputs: How to represent attributes of association > > in > >> Metadata Model and in XML ? > >> > >> Leon, > >> Thanks for your response. One of the adv with approach 2 is we can > >> indicate only changes in the association without the need to > > indicating > >> the elements ( of association). IOW for the below example, if there > is > >> a change in participant-stream association I can simply send the > >> following in partial update: > >> > >> > >> >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> > >> 2010-12-16T23:41:07Z > >> > >> > >> Do you see a need to always indicate the related elements too ? In > >> which case I see approach 1 as more suitable. > >> > >> Thanks, > >> Ram > >> > >>> -----Original Message----- > >>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >>> Sent: Wednesday, October 12, 2011 12:55 PM > >>> To: Ram Mohan R (rmohanr); siprec@ietf.org > >>> Cc: Ofir Roth > >>> Subject: RE: Need Inputs: How to represent attributes of > association > >>> inmetadata Model and in XML ? > >>> > >>> Ram Hi > >>> > >>> I am ok with approaches 1 and however I do prefer approach one > >> because > >>> it will be easier for SRS to get decode - association is inside > >>> relevant element. And it is more readable. > >>> Approach 2 will work as well, however it is important that if there > >>> will be a change in association then to send to SRS not only > updated > >>> association element but also related elements: for example if > stream > >>> was associated to participant and session, send also participant > and > >>> session latest state. > >>> > >>> Regards > >>> > >>> Leon > >>> > >>> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Ram Mohan R (rmohanr) > >>> Sent: Wednesday, October 12, 2011 7:48 AM > >>> To: siprec@ietf.org > >>> Subject: [siprec] Need Inputs: How to represent attributes of > >>> association in metadata Model and in XML ? > >>> > >>> (Sorry for lengthy e-mail) > >>> > >>> Hi All, > >>> > >>> In the last interim we discussed 4 approaches for representing > >>> attributes of association in XML. > >>> > >>> > >>> Here are some pros/cons for each of them: > >>> Approach 1: > >>> ---------- > >>> Represent the association attribute as a property within one of the > >>> associated elements. Example given at http://www.ietf.org/mail- > >>> archive/web/siprec/current/msg02709.html Does not need another XML > >>> element and represents the association attributes as capability of > >> one > >>> of the association element. > >>> e.g. > >>> >>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- > 6da1eeaeb425"> > >>> sip:ram@blr.cisco.com > >>> 2010-12-16T23:41:07Z >> time> > >>> TBD > >>> >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820- > >>> d03a191fb76a > >>> "> > >>> 2010-12- > 16T23:41:07Z >>> time> > >>> contributing SSRC-1 > >>> In > the > >> above > >>> example the participant contributes a single streams. For each > > stream > >>> the association attribute (participant-stream) is shown with the > >> stream > >>> ID nested in. > >>> > >>> > >>> Approach 2: > >>> ----------- > >>> In this approach we have a new XML element for every association > >> class. > >>> This xml element will NOT have a unique ID instead it references > the > >> ID > >>> of associated elements (shown below). With this approach it is easy > >> to > >>> update as the association class is a separate XML element and not > >>> property. > >>> e.g. > >>> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > >>> 2010-12-16T23:41:07Z > >>> TBD > >>> > >>> > >>> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > >>> 2010-12-16T23:41:07Z > >>> contributing SSRC-1 > >>> > >>> > >>> Approach 3 and 4 are in the below e-mail from John. > >>> Approach 3 defines a new Unique ID for every association XML > elment. > >>> Also it creates alias for the other IDs. In the discussions in > >> interim > >>> there was no strong support for this approach. > >>> > >>> Approach 4 is same as approach 1 where in the association element > is > >>> encapsulated in one of the XML elements (to which it is > > associated). > >>> In addition to that it also has reference to the elements (alias of > >>> IDs) to which the association belongs. > >>> > >>> I prefer approach 2 as it is has a separate XML element to > represent > >>> the association class. The only difference of this XML element from > >>> others is this does not need a unique ID. Instead it references the > >> IDs > >>> of the elements to which the association belongs. > >>> Since association class is a special class meant to associate > >> multiple > >>> classes, I see it ok to have a representation as in approach 2 > where > >> in > >>> the identifier is the concatenation of the classes to which the > >>> association belongs to. > >>> > >>> Please provide your comments on this and also suggest any other > >>> approaches to represent association classes in XML. > >>> > >>> Regards, > >>> Ram > >>> > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Thu Oct 13 21:37: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 5DE2821F8797 for ; Thu, 13 Oct 2011 21:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1tbtT1HjOqs for ; Thu, 13 Oct 2011 21:37:07 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 756A221F8678 for ; Thu, 13 Oct 2011 21:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=8989; q=dns/txt; s=iport; t=1318567026; x=1319776626; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=4HhPK5+89EaaT6usSwTAzENaO3RW0AnlSb/TLZ+h6CQ=; b=gA5XJaecI8rK0Mu0ecp38UfJ9O9PhP4WTVKpR9PpHHf1jvPX4M3cp6GJ XrCpLjfJIv/841BAMhXDFdOoCNXlXDNaUNbzbz4XbZetftxFoSEgMUcvN 1ZfG9CQKplureoCjVwcz2uQ2n0xhB3n526tpsKHQlA4WuVqvra7Ac14fe U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8AAHK7l05Io8UT/2dsb2JhbABDDpknjyWBBYFTAQEBAQIBAQEBCwQBHQorBgMQBwQCAQgOAwQBAQEKBhMEAQYBJh8JCAEBBAEKCAgah1wImQUBnjKHDGEEh3+RKYttPw X-IronPort-AV: E=Sophos;i="4.69,344,1315180800"; d="scan'208";a="994117" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-3.cisco.com with ESMTP; 14 Oct 2011 04:37:04 +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 p9E4b3jX011488; Fri, 14 Oct 2011 04:37:03 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, 14 Oct 2011 10:07: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: Fri, 14 Oct 2011 10:07:02 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0809132B@XMB-BGL-417.cisco.com> In-Reply-To: <4E972205.8070403@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] xml:lang attribute for element ( was RE:Consensus calls from session 2 - Success ) Thread-Index: AcyJzubzgPnYx2iSQqiKF7stl8sfsQAWi8TA References: <101C6067BEC68246B0C3F6843BCCC1E311F7D41C9D@MCHP058A.global-ad.net><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9CC@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD08091049@XMB-BGL-417.cisco.com> <4E972205.8070403@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 14 Oct 2011 04:37:03.0269 (UTC) FILETIME=[EB96CD50:01CC8A2A] Subject: Re: [siprec] xml:lang attribute for element ( was RE:Consensus calls from session 2 - Success ) 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, 14 Oct 2011 04:37:08 -0000 Hi Paul, inline > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, October 13, 2011 11:08 PM > To: siprec@ietf.org > Subject: Re: [siprec] xml:lang attribute for element ( was > RE:Consensus calls from session 2 - Success ) >=20 > I think it would be possible to make the aor be an attribute of nameID, > rather than an element. E.g. >=20 > > Alice Smith > =20 This is nice suggestion and it optimizes the xml by a few bits. I am ok incorporate this. I am not sure about stylistic merits and guess we don't need to bother much. > This could then be shortened when there is no display name, to: >=20 > >=20 > The xml experts will have to weigh in on the stylistic merits one one > vs. the other. >=20 > Regarding the specification of the xml language - is it really > necessary? The value will presumably come out of a sip message, and > AFAIK there is no way to specify the language used in the sip headers. > (Accept-Language and Content-Language both apply to the *body* of the > message, not the headers.) I don't have any strong inclination to keep xml:lang. I looked at examples of RFC (like RFC 3680) that has encoded display-name in XML and found that they use xml:lang. As I mentioned below it gives an advantage in specifying the language used. Of course this is completely optional in the schema I proposed and If an SRC cannot determine it can always can choose not to have this attribute. Regards, Ram >=20 > Thanks, > Paul >=20 >=20 > On 10/13/11 3:04 AM, Ram Mohan R (rmohanr) wrote: > > Charles, > > You are right. The schema I pasted below has a error as it shows > > xml:lang as attribute of nameID. I will change it to as below(again > > referred 3680 to derive this): > > > > > > > > > > maxOccurs=3D"1" > > /> > > > > > > > > > > > > > > > > > > > > > > > > > > Let me know if this schema is correct. > > > > Thanks, > > Ram > > > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) > >> Sent: Thursday, October 13, 2011 2:47 AM > >> To: Ram Mohan R (rmohanr); Hutton, Andrew; Elwell, John; > >> siprec@ietf.org > >> Cc: Peter Saint-Andre (psaintan) > >> Subject: RE: [siprec] xml:lang attribute for element ( was > >> RE:Consensus calls from session 2 - Success ) > >> > >> Hi Ram, > >> > >> In your description and schema, it seems xml:lang is an attribute of > >> "nameID"; however, I think the intent is to have it be an attribute > of > >> "name", isn't it? > >> If this is true, then the example is fine, but the XML schema looks > >> incorrect to me. > >> > >> Cheers, > >> Charles > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Ram Mohan R (rmohanr) > >>> Sent: Wednesday, October 12, 2011 1:47 AM > >>> To: Hutton, Andrew; Elwell, John; siprec@ietf.org > >>> Cc: Peter Saint-Andre (psaintan) > >>> Subject: [siprec] xml:lang attribute for element ( was > >> RE:Consensus calls from session 2 - > >>> Success ) > >>> > >>> In the last interim there was a *consensus* to have xml > >> element > >>> (as shown below) in the metadata document to indicate multiple > >> name/AoR > >>> pairs. However there was a comment to clarify on the need for > >> language > >>> attribute in XML document. > >>> > >>> Xml:lang is a special attribute may be inserted in documents to > >> specify > >>> the language used in the contents and attribute values of any > > element > >> in > >>> an XML document. More information at section 2.12 of > >>> http://www.w3.org/TR/REC-xml/ > >>> > >>> Some of the SIP RFC like RFC 3680 already uses xml:lang for > display- > >> name > >>> which is what we also need here. > >>> > >>> So I am planning to make this as optional attribute following the > >>> similar approach as done in RFC 3680. > >>> > >>> The schema for nameID would look as: > >>> > >>> > >>> > >>> >>> minOccurs=3D"0" maxOccurs=3D"1"/> > >>> >>> maxOccurs=3D"1"/> > >>> > >>> > >>> > >>> > >>> Example is > >>> > >>> > >>> sip:alice@atlanta.com > >>> Alice Smith > >>> >>> > >>> Regards, > >>> Ram > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf Of Hutton, Andrew > >>>> Sent: Thursday, October 06, 2011 8:37 PM > >>>> To: Elwell, John; siprec@ietf.org > >>>> Subject: [siprec] Consensus calls from session 2 - Success > >>>> > >>>> Hi, > >>>> > >>>> I believe there are no outstanding objections to these items so > > can > >>> the > >>>> editors go ahead and incorporate these changes in their next > >> update. > >>>> > >>>> With regard to the discussion on extension data representatives I > >>>> believe consensus is to go with the approach as described in Ram's > >> e- > >>>> mail on the 2011-09-26 which gave this example: > >>>> > >>>> > >>>> > >>>> >>>> minOccurs=3D"0"/> > >>>> >>>> minOccurs=3D"0"/> > >>>> >>>> minOccurs=3D"0"/> > >>>> >>>> minOccurs=3D"0" maxOccurs=3D"1"/> > >>>> >>>> minOccurs=3D'0' > >>>> maxOccurs=3D'unbounded' > >>>> processContents=3D'lax'/> > >>>> > >>>> >>>> use=3D"required"/> > >>>> > >>>> > >>>> The issue of whether to include a statement indicating that > >> elements > >>>> from different/unknown namespaces is a separate issue and so far I > >>>> think the balance is towards not including such a statement. > >>>> > >>>> Regards > >>>> Andy Hutton (as chair). > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > > On > >>>>> Behalf Of Elwell, John > >>>>> Sent: 23 September 2011 17:00 > >>>>> To: siprec@ietf.org > >>>>> Subject: [siprec] Consensus calls from session 2 > >>>>> > >>>>> Please raise any objections by 2011-10-03 to the following > >>>> conclusions > >>>>> from today's call: > >>>>> > >>>>> - List of SSRCs to be part of the association between > > participant > >>> and > >>>>> session. > >>>>> - Extension data representation in XML as proposed on metadata > >> slide > >>>>> 19. > >>>>> - Structured element for use within a > >>>> element > >>>>> as shown on slide 20 (subject to clarification on need for > >> language > >>>>> attribute). > >>>>> - Adoption of XML syntax from RFC 4235 for representation of > >>>>> capabilities in metadata. > >>>>> > >>>>> 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 > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From bwinslow@acmepacket.com Fri Oct 14 06:49: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 5AF3D21F8C45 for ; Fri, 14 Oct 2011 06:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew9Giy-127U8 for ; Fri, 14 Oct 2011 06:49:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB0021F8558 for ; Fri, 14 Oct 2011 06:49:17 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 14 Oct 2011 09:49:15 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 09:49:15 -0400 From: Brad Winslow To: "siprec@ietf.org" Thread-Topic: [siprec] Need Inputs: How to represent attributes of association in Metadata Model and in XML ? Thread-Index: AQHMiiWopFVp9w/gGEmFgV/fmcyQM5V72d0A Date: Fri, 14 Oct 2011 13:49:14 +0000 Message-ID: <622B0E14298DDE47ACA9E16B292F22A40F2EACAD@Mail1.acmepacket.com> References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com> <4E971D30.5090101@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: Re: [siprec] Need Inputs: How to represent attributes of association in Metadata Model and 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: Fri, 14 Oct 2011 13:49:18 -0000 Hi Folks, I believe the association elements complicate the metadata model. It seems= to me, unless I'm being na=EFve, that the SRC would introduce the particip= ant and the steam elements into the CS at the same time. The association m= echanism as described doesn't seem to support the notion of side conversati= ons, as the and elements are capable of doing. If the and elements remain in the metadata, I'm not sure what benefit = the association elements provide. Thanks, Brad -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: Thursday, October 13, 2011 11:59 PM To: Paul Kyzivat; siprec@ietf.org Subject: Re: [siprec] Need Inputs: How to represent attributes of associati= on in Metadata Model and in XML ? Thanks Paul for your comments. I also prefer approach 2 as mentioned below = in this thread. I will wait to hear for comments/opinion from others. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: Thursday, October 13, 2011 10:48 PM > To: siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to represent attributes of=20 > association in Metadata Model and in XML ? >=20 > I like approach 2, as Ram has shown it. It deals with the problems John > raised with the others. >=20 > I didn't follow John's arithmetic on this one, using his 20 party=20 > conference example. As I count that, there are 21 participants when you > include the focus. Each of the 20 has two stream/participant=20 > associations with the focus, for a total of 40. (The association is=20 > bidirectional. I can only get to 80 by assuming we had to represent an=20 > association in each direction.) And each has two ids, each of which is=20 > also the id of a stream or participant. So there are really only 23=20 > distinct ids that need to be assigned for this. (One for each of the 21 > participants, and one for each of the two streams.) >=20 > The 40 associations, each carrying two ids, is still kind of a lot if=20 > its sent all at once. But when starting up a conference they will=20 > probably be added gradually as each participant joins. Same at the end=20 > if they drop off individually. But it could be a bunch together if the=20 > conference is forcibly dropped by the focus. But it does minimize what=20 > is sent when things happen incrementally. >=20 > There may be some optimizations that can be done - e.g. a sort of=20 > "wildcard" for one of the the two ids in the association class. E.g. >=20 > participant=3D"*" > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > 2010-12-16T23:41:07Z > >=20 > (I'm not advocating that particular syntax. Its just something to make=20 > the point.) >=20 > Thanks, > Paul >=20 >=20 > On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: > > My bad(typo) while sending the example. The correct partial update I=20 > > intended to send is: > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > 2010-12-16T23:41:07Z > > > > > > This is inline with approach 2 where in each association XML element=20 > > will have the IDs of the related associated elements. > > > > Ram > > > >> -----Original Message----- > >> From: Leon Portman [mailto:Leon.Portman@nice.com] > >> Sent: Wednesday, October 12, 2011 2:24 PM > >> To: Ram Mohan R (rmohanr); siprec@ietf.org > >> Cc: Ofir Roth > >> Subject: RE: Need Inputs: How to represent attributes of association > > in > >> Metadata Model and in XML ? > >> > >> We do prefer to receive related elements as well, it makes=20 > >> implementation much easier. > >> At least we should get relevant IDs. For example below, SRC > should > >> also send ParticipantId > >> > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >> Sent: Wednesday, October 12, 2011 10:52 AM > >> To: Leon Portman; siprec@ietf.org > >> Cc: Ofir Roth > >> Subject: RE: Need Inputs: How to represent attributes of association > > in > >> Metadata Model and in XML ? > >> > >> Leon, > >> Thanks for your response. One of the adv with approach 2 is we can=20 > >> indicate only changes in the association without the need to > > indicating > >> the elements ( of association). IOW for the below example, if there > is > >> a change in participant-stream association I can simply send the=20 > >> following in partial update: > >> > >> > >> >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> > >> 2010-12-16T23:41:07Z > >> > >> > >> Do you see a need to always indicate the related elements too ? In=20 > >> which case I see approach 1 as more suitable. > >> > >> Thanks, > >> Ram > >> > >>> -----Original Message----- > >>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >>> Sent: Wednesday, October 12, 2011 12:55 PM > >>> To: Ram Mohan R (rmohanr); siprec@ietf.org > >>> Cc: Ofir Roth > >>> Subject: RE: Need Inputs: How to represent attributes of > association > >>> inmetadata Model and in XML ? > >>> > >>> Ram Hi > >>> > >>> I am ok with approaches 1 and however I do prefer approach one > >> because > >>> it will be easier for SRS to get decode - association is inside=20 > >>> relevant element. And it is more readable. > >>> Approach 2 will work as well, however it is important that if there > >>> will be a change in association then to send to SRS not only > updated > >>> association element but also related elements: for example if > stream > >>> was associated to participant and session, send also participant > and > >>> session latest state. > >>> > >>> Regards > >>> > >>> Leon > >>> > >>> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > >>> Behalf Of Ram Mohan R (rmohanr) > >>> Sent: Wednesday, October 12, 2011 7:48 AM > >>> To: siprec@ietf.org > >>> Subject: [siprec] Need Inputs: How to represent attributes of=20 > >>> association in metadata Model and in XML ? > >>> > >>> (Sorry for lengthy e-mail) > >>> > >>> Hi All, > >>> > >>> In the last interim we discussed 4 approaches for representing=20 > >>> attributes of association in XML. > >>> > >>> > >>> Here are some pros/cons for each of them: > >>> Approach 1: > >>> ---------- > >>> Represent the association attribute as a property within one of the > >>> associated elements. Example given at http://www.ietf.org/mail-=20 > >>> archive/web/siprec/current/msg02709.html Does not need another XML=20 > >>> element and represents the association attributes as capability of > >> one > >>> of the association element. > >>> e.g. > >>> >>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- > 6da1eeaeb425"> > >>> sip:ram@blr.cisco.com > >>> 2010-12-16T23:41:07Z >> time> > >>> TBD > >>> >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820- > >>> d03a191fb76a > >>> "> > >>> 2010-12- > 16T23:41:07Z >>> time> > >>> contributing SSRC-1 > >>> In > the > >> above > >>> example the participant contributes a single streams. For each > > stream > >>> the association attribute (participant-stream) is shown with the > >> stream > >>> ID nested in. > >>> > >>> > >>> Approach 2: > >>> ----------- > >>> In this approach we have a new XML element for every association > >> class. > >>> This xml element will NOT have a unique ID instead it references > the > >> ID > >>> of associated elements (shown below). With this approach it is easy > >> to > >>> update as the association class is a separate XML element and not=20 > >>> property. > >>> e.g. > >>> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > >>> 2010-12-16T23:41:07Z > >>> TBD > >>> > >>> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > >>> 2010-12-16T23:41:07Z > >>> contributing SSRC-1 > >>> > >>> Approach 3 and 4 are in the below e-mail from John. > >>> Approach 3 defines a new Unique ID for every association XML > elment. > >>> Also it creates alias for the other IDs. In the discussions in > >> interim > >>> there was no strong support for this approach. > >>> > >>> Approach 4 is same as approach 1 where in the association element > is > >>> encapsulated in one of the XML elements (to which it is > > associated). > >>> In addition to that it also has reference to the elements (alias of > >>> IDs) to which the association belongs. > >>> > >>> I prefer approach 2 as it is has a separate XML element to > represent > >>> the association class. The only difference of this XML element from > >>> others is this does not need a unique ID. Instead it references the > >> IDs > >>> of the elements to which the association belongs. > >>> Since association class is a special class meant to associate > >> multiple > >>> classes, I see it ok to have a representation as in approach 2 > where > >> in > >>> the identifier is the concatenation of the classes to which the=20 > >>> association belongs to. > >>> > >>> Please provide your comments on this and also suggest any other=20 > >>> approaches to represent association classes in XML. > >>> > >>> Regards, > >>> Ram > >>> > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > 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 andrew.hutton@siemens-enterprise.com Fri Oct 14 07:48: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 23EA221F8CD5 for ; Fri, 14 Oct 2011 07:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOdUMh6mRn-U for ; Fri, 14 Oct 2011 07:48:04 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 68C7C21F8CD3 for ; Fri, 14 Oct 2011 07:48:04 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id EE9F423F0413 for ; Fri, 14 Oct 2011 16:48:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 14 Oct 2011 16:48:02 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 14 Oct 2011 16:48:00 +0200 Thread-Topic: SIPREC Session at IETF82 Thread-Index: AcyKgEVCjPHbmiqtQm6tAaDShSaTIg== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E311F7E2477F@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_101C6067BEC68246B0C3F6843BCCC1E311F7E2477FMCHP058Agloba_" MIME-Version: 1.0 Subject: [siprec] SIPREC Session at IETF82 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, 14 Oct 2011 14:48:05 -0000 --_000_101C6067BEC68246B0C3F6843BCCC1E311F7E2477FMCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, The SIPREC session at IETF 82 has been scheduled as follows. SIPREC Session 1 (2 hours) Thursday, Afternoon Session I 1300-1500 Room Name: 102 The full agenda can be found at http://www.ietf.org/meeting/82/index.html Regards Andy --_000_101C6067BEC68246B0C3F6843BCCC1E311F7E2477FMCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
The SIPREC session at IETF 82 has been scheduled as follows.
 
SIPREC Session 1 (2 hours)
    Thursday, Afternoon Session I 1300-1500
    Room Name: 102
 
The full agenda can be f= ound at http://www.ietf.org/meeting/82/index.html
 
Regards
Andy
 
 --_000_101C6067BEC68246B0C3F6843BCCC1E311F7E2477FMCHP058Agloba_-- From pkyzivat@alum.mit.edu Fri Oct 14 09:21: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 384FA21F8C65 for ; Fri, 14 Oct 2011 09:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xwCd2pEIUzK for ; Fri, 14 Oct 2011 09:21:47 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id A855221F8C60 for ; Fri, 14 Oct 2011 09:21:46 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id kfU11h0051ZXKqc55gMnlX; Fri, 14 Oct 2011 16:21:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id kgMm1h0210tdiYw3hgMmw9; Fri, 14 Oct 2011 16:21:47 +0000 Message-ID: <4E986198.1080408@alum.mit.edu> Date: Fri, 14 Oct 2011 12:21:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Need Inputs: How to represent attributes of association in metadata Model and 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: Fri, 14 Oct 2011 16:21:48 -0000 On 10/12/11 3:25 AM, Leon Portman wrote: > Ram Hi > > I am ok with approaches 1 and however I do prefer approach one because it will be easier for SRS to get decode - association is inside relevant element. And it is more readable. > Approach 2 will work as well, however it is important that if there will be a change in association then to send to SRS not only updated association element but also related elements: for example if stream was associated to participant and session, send also participant and session latest state. The intent is to send changed elements, including sufficient information to understand which element it is, and thus how it relates to previously sent and unchanged elements. At the same time the goal is to avoid transmitting unchanged elements. So current proposal is that "regular" elements have one ID that identifies them. So that has to be sent when sending an update to that element. Association Classes aren't identified by a single ID. Rather they are identified by the IDs of the two things they associate. Thus when updating them those two IDs need to be transmitted. (Doing it this way is a choice - there are other ways, but this so far seems a reasonable way.) Are you asking that additional redundant info be supplied when sending an update to an association class? Thanks, Paul > Regards > > Leon > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > Sent: Wednesday, October 12, 2011 7:48 AM > To: siprec@ietf.org > Subject: [siprec] Need Inputs: How to represent attributes of association in metadata Model and in XML ? > > (Sorry for lengthy e-mail) > > Hi All, > > In the last interim we discussed 4 approaches for representing attributes of association in XML. > > > Here are some pros/cons for each of them: > Approach 1: > ---------- > Represent the association attribute as a property within one of the associated elements. Example given at http://www.ietf.org/mail-archive/web/siprec/current/msg02709.html Does not need another XML element and represents the association attributes as capability of one of the association element. > e.g. > id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > sip:ram@blr.cisco.com > 2010-12-16T23:41:07Z > TBD > stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a > "> > 2010-12-16T23:41:07Z > contributing SSRC-1 > In the above example the participant contributes a single streams. For each stream the association attribute (participant-stream) is shown with the stream ID nested in. > > > Approach 2: > ----------- > In this approach we have a new XML element for every association class. > This xml element will NOT have a unique ID instead it references the ID of associated elements (shown below). With this approach it is easy to update as the association class is a separate XML element and not property. > e.g. > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > 2010-12-16T23:41:07Z > TBD > > > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > 2010-12-16T23:41:07Z > contributing SSRC-1 > > > Approach 3 and 4 are in the below e-mail from John. > Approach 3 defines a new Unique ID for every association XML elment. > Also it creates alias for the other IDs. In the discussions in interim there was no strong support for this approach. > > Approach 4 is same as approach 1 where in the association element is encapsulated in one of the XML elements (to which it is associated). In addition to that it also has reference to the elements (alias of IDs) to which the association belongs. > > I prefer approach 2 as it is has a separate XML element to represent the association class. The only difference of this XML element from others is this does not need a unique ID. Instead it references the IDs of the elements to which the association belongs. > Since association class is a special class meant to associate multiple classes, I see it ok to have a representation as in approach 2 where in the identifier is the concatenation of the classes to which the association belongs to. > > Please provide your comments on this and also suggest any other approaches to represent association classes in XML. > > Regards, > Ram > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ram Mohan R (rmohanr) >> Sent: Friday, September 23, 2011 1:32 PM >> To: Elwell, John; siprec@ietf.org >> Subject: Re: [siprec] #72: How to represent attributes of >> associationinmetadata Model and in XML ? >> >> John, >> >> Lets discuss these two approaches along with the other two in today's >> meeting. I have added these to the slides. >> >> Regards, >> Ram >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Friday, September 23, 2011 1:01 PM >>> To: Ram Mohan R (rmohanr); siprec issue tracker >>> Cc: siprec@ietf.org >>> Subject: RE: [siprec] #72: How to represent attributes of > association >>> inmetadata Model and in XML ? >>> >>> Ram, >>> >>> I don't like having to use the combination of participant unique ID >> and >>> session unique ID for uniquely identifying a element >> as >>> proposed in approach 1, and therefore of the two approaches here I >>> prefer approach 2. >>> >>> Unfortunately approach 2 gets extremely verbose, particularly if we >>> apply the same approach to associations between stream and >> participant. >>> Consider a 20 party conference with 2 streams, audio and video (not >> an >>> extreme example, but good enough to illustrate my point). Each >>> participant is sending and receiving both streams. This means 80 >>> associations between participant and stream. Each association > element >>> has its own unique ID, plus IDs referencing a element >>> and a element. A total of 240 unique IDs on the wire just >> to >>> represent these associations. Taking the example unique ID below > with >>> 45 characters, this is 10800 characters for the IDs alone. I am not >>> sure whether this is a problem of not. >>> >>> A couple of alternative approaches: >>> >>> Approach 3: Define local IDs as aliases for globally unique IDs. > This >>> approach reduces the number of unique IDs on the wire per > association >>> from 3 to 1, replacing them with local IDs. Of course, the local IDs >>> have to be defined. This might marginally penalize the VERY simple >>> cases, but saves significantly for more complex situations. >>> e.g.: >>> >> id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425" >>> local="123"> >>> ... >>> >>> >>> >> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>> local="234"> >>> ... >>> >>> >>> >> id="urn:uuid:acdf43ee-1441-478d-4eca-4d4f555a896d" >>> participant="234" >>> session="123"> >>> ... >>> >> >>> >>> Approach 4: Encapsulate associations within one of the object >> elements >>> concerned, e.g., encapsulate sequence of participants in the >> >>> element. This approach reduces the number of unique IDs on the wire >> per >>> association from 3 to 1. >>> e.g.: >>> >> id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>> .... >>> >> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >>> .... >>> >>> >>> >>> >> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >>> ... >>> >>> >>> Or alternatively: >>> >> id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>> .... >>> >>> >> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >>> .... >>> >>> >>> >>> >>> >> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >>> ... >>> >>> >>> A further remark on approach 4. This means that you can't send a >>> partial update conveying only an association - you have to send the >>> whole element in which the association is embedded. So in the > example >>> above, if a participant drops out of a session you would have to > send >>> the whole element. So this might be a reason for > embedding >>> the associations in a element instead, if we consider >> a >>> given participant is unlikely to be in more than a handful of >> sessions. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>> Sent: 22 September 2011 17:57 >>>> To: Elwell, John; siprec issue tracker >>>> Cc: siprec@ietf.org >>>> Subject: RE: [siprec] #72: How to represent attributes of >>>> association inmetadata Model and in XML ? >>>> >>>> Hi John, >>>> >>>> Please see inline. >>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Thursday, September 22, 2011 8:47 PM >>>>> To: Ram Mohan R (rmohanr); siprec issue tracker >>>>> Cc: siprec@ietf.org >>>>> Subject: RE: [siprec] #72: How to represent attributes of >>>> association >>>>> inmetadata Model and in XML ? >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R >>>> (rmohanr) >>>>>> Sent: 22 September 2011 11:11 >>>>>> To: siprec issue tracker >>>>>> Cc: siprec@ietf.org >>>>>> Subject: Re: [siprec] #72: How to represent attributes of >>>>>> association in metadata Model and in XML ? >>>>>> >>>>>> I have not seen any inputs on this so far. In the last >>>>>> discussion we had on Monday we discussed to ways to represent >>>>>> attributes of association. Can folks look at these and provide >>>>>> inputs and also other ways to represent attributes of >>>>>> association ? >>>>>> >>>>>> Use-case: >>>>>> --------- >>>>>> A participant who is simultaneously in multiple sessions >>>>>> having different capabilities(this attribute is an attribute >>>>>> of association). >>>>>> >>>>>> Approach 1: >>>>>> ----------- >>>>>> Session 1 having participant 1: >>>>>> >>>>> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>> >>>> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>>> sip:ram@blr.cisco.com >>>>>> >> 2010-12-16T23:41:07Z>>>> time> >>>>>> TBD >>>>>> >>>>>> Session 2 having the same participant 1: >>>>>> >>>>>> >>>>> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>> >>>> session="urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103"> >>>>>> sip:ram@blr.cisco.com >>>>>> >> 2010-12-16T23:41:07Z>>>> time> >>>>>> TBD >>>>>> >>>>>> >>>>>> Here the session ID is different and it's the same participant >>>>>> ID across both sessions. >>>>>> >>>>>> In this approach all the association attributes are encoded >>>>>> within the element as the participant already >>>>>> has session ID of the session to which it is associated. >>>>>> >>>>>> Pros: This is simple as we are just adding capabilities to the >>>>>> existing participant element and hence it does not require any >>>>>> additional ID. >>>>> [JRE] If I understand the proposal correctly there is a possible >>>>> problem. The example shows two elements with the >>> same >>>>> unique ID. If the SRC sends a partial update that contains a >>>>> element, the SRS can't use its unique ID alone to >>>>> identify the particular element that has changed. The SRS has to >>> use >>>>> the combination of the element's unique ID and the >>>> referenced session >>>>> unique ID. I am not sure this is a problem, but it is certainly > a >>>>> change from what we have discussed in the past, and it >>>> means rules for >>>>> matching become more complex. To some extent it defeats the >>>> purpose of >>>>> having a unique ID for a participant. >>>> >>>> True. I agree with your point. The last time this proposal was > made >>> by >>>> Partha, I remember there was a feedback on the similar lines. >>>> This issue >>>> is going to be present for any attribute of participant not just >>>> association attribute whenever a participant is simultaneously >>> present >>>> in multiple sessions. >>>> >>>> As you mentioned below the combination of participant ID and >>>> session ID >>>> (association) can serve as unique ID in cases where a participant >> is >>>> simultaneously in multiple sessions. >>>> >>>> Ram >>>> >>>>> >>>>> Let's try another case. The SRC sends a partial update with a >>>>> element whose referenced session is >>>> different from that >>>>> of any existing element with that same >>>> unique ID. Does >>>>> this mean the SRS has to add a new element to its >>>> model? >>>>> Again this seems to be contrary to my earlier understanding that >>> you >>>>> only add something if you receive something with a new unique > ID. >>>>> >>>>> I believe up till now a complete XML document would never have >> two >>>>> elements with the same unique ID. This principle (if that >>>> was people's >>>>> understanding) now seems to be destroyed. >>>>> >>>>> Basically the combination of unique ID and >>> >>>>> unique ID becomes the unique ID for the association - not >>>> necessarily >>>>> wrong, but I do wonder whether having a unique ID for a >> participant >>>>> element is rather pointless when it alone is not usable as > unique >>>>> identification for an element. >>>>> >>>>> 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 > From eckelcu@cisco.com Fri Oct 14 10:22:03 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 7265421F8C3A for ; Fri, 14 Oct 2011 10:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=2.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UU3mqbBtr04 for ; Fri, 14 Oct 2011 10:22:02 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 62AF221F8C37 for ; Fri, 14 Oct 2011 10:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5997; q=dns/txt; s=iport; t=1318612922; x=1319822522; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=fEhiFMtn2y0Oq/0c+fTDT2O9o2bSJL7RgFSmMgdKal8=; b=I4Q2XpO0XG0OQnn0JpZ95WJqWNFtNf+kpEkrMVwUG/xZvR4Aet1kKLHf dnZqovt8G0cve0krqMlxIOxUIZoS4iJzrvgl8AV3zHQRAkvdh4+ZDp4W/ vwgXzi8zjg3B7YomuL6JAwPu7f2+AQVBkSKCLPwyVxjVeLaTYzMSH/dzU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMAANhumE6rRDoI/2dsb2JhbABDmT+PKIEFgW4BAQEEEgEdCksGAQgRBAEBCwYFEwdOCQEEEwgan0SBJgGeUIRdgjthBIgBkSeMRA X-IronPort-AV: E=Sophos;i="4.69,347,1315180800"; d="scan'208";a="7922626" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 14 Oct 2011 17:22:02 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9EHM2lu024910 for ; Fri, 14 Oct 2011 17:22:02 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, 14 Oct 2011 10:22: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, 14 Oct 2011 10:22:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: proposed text for dealing with packet loss Thread-Index: AcyFQAjzFY55YKG7Tzm0ZW2LMCCpkAFVXwcg From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 14 Oct 2011 17:22:01.0903 (UTC) FILETIME=[C94E8BF0:01CC8A95] Subject: Re: [siprec] proposed text for dealing with packet loss 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, 14 Oct 2011 17:22:03 -0000 So far I have not received any comments in this text, good, bad, or otherwise. As such, I plan to incorporate it as is in the next version of the RTP recommendations draft. If you planned to comment but just need more time, let me know asap. Cheers, Charles > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Friday, October 07, 2011 3:26 PM > To: siprec@ietf.org > Subject: proposed text for dealing with packet loss >=20 > During the last interim meeting, I accepted an action item to propose some text for draft-eckel- > siprec-rtp-rec regarding SRC handling of packet loss. Here is text for the various RTP models with the > proposed text added (look for "If packet loss occurs" within each model): >=20 > ---------------- >=20 > 4.1. SRC acting as an RTP Translator >=20 > The SRC may act as a translator, as defined in [RFC3550]. A defining > characteristic of a translator is that it forwards RTP packets with > their SSRC identifier intact. There are two types of translators, > one that simply forwards, and another that performs transcoding > (e.g., from one codec to another) in addition to forwarding. >=20 > 4.1.1. Forwarding Translator >=20 > When acting as a forwarding translator, RTP received as separate > streams from different sources (e.g., from different UAs with > different SSRCs) cannot be mixed by the SRC and MUST be sent > separately to the SRS. All RTCP reports MUST be passed by the SRC > between the UAs and the SRS, such that the UAs and SRS are able to > detect any SSRC collisions. >=20 > RTCP Sender Reports generated by a UA sending a stream MUST be > forwarded to the SRS. RTCP Receiver Reports generated by the SRS > MUST be forwarded to the relevant UA. >=20 > If SRTP is used on both the CS and the RS, decryption and/or re- > encryption may occur. For example, if different keys are used, it > will occur. If the same keys are used, it need not occur. >=20 > If packet loss occurs, either from the UA to the SRC or from the SRC > to the SRS, the SRS SHOULD detect and attempt to recover from the > loss. The SRC does not play a role in this other than forwarding the > associated RTP and RTCP packets. >=20 > 4.1.2. Transcoding Translator >=20 > When acting as a transcoding translator, an SRC MAY perform > transcoding (e.g., from one codec to another), and this may result in > a different rate of packets between what the SRC receives and what > the sends. As when acting as a forwarding translator, RTP received > as separate streams from different sources (e.g., from different UAs > with different SSRCs) cannot be mixed by the SRC and MUST be sent > separately to the SRS. All RTCP reports MUST passed by the SRC > between the UAs and the SRS, such the UAs and SRS they are able to > detect any SSRC collisions. >=20 > RTCP Sender Reports generated by a UA sending a stream MUST be > forwarded to the SRS. RTCP Receiver Reports generated by the SRS > MUST be forwarded to the relevant UA. The SRC may need to manipulate > the RTCP Receiver Reports to take account of any transcoding that has > taken place. >=20 > If SRTP is used on both the CS and the RS, decryption and/or re- > encryption may occur. For example, if different keys are used, it > will occur. If the same keys are used, it need not occur. >=20 > If packet loss occurs, either from the UA to the SRC or from the SRC > to the SRS, the SRS SHOULD detect and attempt to recover from the > loss. The SRC does not play a role in this other than forwarding the > associated RTP and RTCP packets. >=20 > 4.2. SRC acting as an RTP Mixer >=20 > In the case of the SRC acting as a RTP mixer, as defined in > [RFC3550], the SRC combines RTP streams from different UA and sends > them towards the SRS using its own SSRC. The SSRCs from the > contributing UA SHOULD be conveyed as CSRCs identifiers within this > stream. The SRC may make timing adjustments among the received > streams and generate its own timing on the stream sent to the SRS. > Optionally an SRC acting as a mixer can perform transcoding, and can > even cope with different codings received from different UAs. RTCP > Sender Reports and Receiver Reports are not forwarded by an SRC > acting as mixer, but there are requirements for forwarding RTCP > Source Description (SDES) packets. The SRC generates its own RTCP > Sender and Receiver reports toward the associated UAs and SRS. The > use of SRTP between the SRC and the SRS for the RS is independent of > the use of SRTP between the UAs and SRC for the CS. >=20 > If packet loss occurs from the UA to the SRC, the SRC SHOULD detect > and attempt to recover from the loss. If packet loss occurs from the > SRC to the SRS, the SRS SHOULD detect and attempt to recover from the > loss. >=20 > 4.3. SRC acting as an RTP Endpoint >=20 > The case of the SRC acting as an RTP endpoint, as defined in > [RFC3550], is similar to the mixer case, except that the RTP session > between the SRC and the SRS is considered completely independent from > the RTP session that is part of the CS. The SRC can, but need not, > mix RTP streams from different participants prior to sending to the > SRS. RTCP between the SRC and the SRS is completely independent of > RTCP on the CS. The use of SRTP between the SRC and the SRS is > independent of the use of SRTP on the CS. >=20 > If packet loss occurs from the UA to the SRC, the SRC SHOULD detect > and attempt to recover from the loss. If packet loss occurs from the > SRC to the SRS, the SRS SHOULD detect and attempt to recover from the > loss. > ------------------ >=20 > Comment on this are greatly appreciated. > Thanks, > Charles From sireeshgandhi@gmail.com Sat Oct 15 01:07: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 877AE21F889A for ; Sat, 15 Oct 2011 01:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+qfZ7SVffMF for ; Sat, 15 Oct 2011 01:06:59 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE6821F8801 for ; Sat, 15 Oct 2011 01:06:59 -0700 (PDT) Received: by eyg24 with SMTP id 24so1816583eyg.31 for ; Sat, 15 Oct 2011 01:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=V/k01qmreSD5Jyz+fbBXmNtS7KjlDRqkCoBDb3cjdaU=; b=lzbCt8F+ansPS9jA8GvhOlA4itIL2m4UkN1T26K92dnMFI97q+Fjp9FCOYlPEuLjNB ZdXzp/Df8ck/3NfRPAxup2wOKGwkJtpWcVC5FJ40woYxTpqYtkoMHTmFaBwitX7wP7s+ ZRXt2tfrNoyw1ZB6njfSw97eTBzU7yaXIEMrg= MIME-Version: 1.0 Received: by 10.213.22.15 with SMTP id l15mr1534566ebb.77.1318666017270; Sat, 15 Oct 2011 01:06:57 -0700 (PDT) Received: by 10.213.31.80 with HTTP; Sat, 15 Oct 2011 01:06:57 -0700 (PDT) Date: Sat, 15 Oct 2011 09:06:57 +0100 Message-ID: From: Sirish To: siprec@ietf.org Content-Type: multipart/alternative; boundary=0015174c3d44896cf704af51db2f X-Mailman-Approved-At: Sat, 15 Oct 2011 14:46:02 -0700 Subject: [siprec] SIPREC Metadata 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, 15 Oct 2011 08:16:32 -0000 --0015174c3d44896cf704af51db2f Content-Type: text/plain; charset=ISO-8859-1 Hi, I am Sirish doing a small POC on SIPREC Metadata.Some errors coming while I was generating java classes using SCHEMA which was given in the RFC draft-ietf-siprec-metadata-04. Could you please let me know whethear the Schema which I had latest or not, if not Could you please provide me the latest working schema c:\sirish> xjc -p src.schema. SIPREC_metadata.xsd parsing a schema... [ERROR] src-resolve.4.1: Error resolving component 'recording'. It was detected that 'recording' has no namespace, but components with no target namespace are not referenceable from schema document 'file:/C:/Users/604897327/schema/SIPREC_metadata.xsd'. If 'recording' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'recording' has no namespace, then an 'import' without a "namespace" attribute should be added to 'file:/C:/Users/604897327/schema/SIPREC_metadata.xsd'. line 9 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd [ERROR] src-resolve: Cannot resolve the name 'urnuuid' to a(n) 'simpleType definition' component. line 36 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd [ERROR] src-resolve: Cannot resolve the name 'urnuuid' to a(n) 'simpleType definition' component. line 52 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd [ERROR] src-resolve: Cannot resolve the name 'urnuuid' to a(n) 'simpleType definition' component. line 72 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd [ERROR] src-resolve: Cannot resolve the name 'urnuuid' to a(n) 'simpleType definition' component. line 74 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd [ERROR] src-resolve: Cannot resolve the name 'urnuuid' to a(n) 'simpleType definition' component. line 86 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd [ERROR] src-resolve: Cannot resolve the name 'urnuuid' to a(n) 'simpleType definition' component. line 88 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd [ERROR] s4s-elt-invalid-content.1: The content of '#AnonType_extensiondata' is invalid. Element 'any' is invalid, misplaced, or occurs too often. line 95 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd [ERROR] s4s-elt-must-match.1: The content of 'extensiondata' must match (annotation?, (simpleType | complexType)?, (unique | key | keyref)*)). A problem was found starting at: attribute. line 98 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd Failed to parse a schema. Thanks in advance -- ---------------------------- Thanks & Regards, Sirish Gandhi --0015174c3d44896cf704af51db2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
I am Sirish doing a small POC on SIPREC Metadata.Some errors coming=A0= while I was generating java classes using SCHEMA which was given in the RFC= draft-= ietf-siprec-metadata-04.
Could you please=A0let me know whethear the Sch= ema which I had latest or not, if not Could you please provide me the lates= t working schema
=A0
c:\sirish>=A0xjc -p=A0src.schema. SIPREC_metadata.xsd
=A0parsing a schema...
[ERROR] src-resolve.4.1: Error resolving com= ponent 'recording'. It was detected that 'recording' has no= namespace, but components with no target namespace are not referenceable f= rom schema document 'file:/C:/Users/604897327/schema/SIPREC_metadata.xs= d'. If 'recording' is intended to have a namespace, perhaps a p= refix needs to be provided. If it is intended that 'recording' has = no namespace, then an 'import' without a "namespace" attr= ibute should be added to 'file:/C:/Users/604897327/schema/SIPREC_metada= ta.xsd'.
=A0 line 9 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd
[ERROR= ] src-resolve: Cannot resolve the name 'urnuuid' to a(n) 'simpl= eType definition' component.
=A0 line 36 of file:/C:/Users/604897327= /schema/SIPREC_metadata.xsd
[ERROR] src-resolve: Cannot resolve the name 'urnuuid' to a(n) '= ;simpleType definition' component.
=A0 line 52 of file:/C:/Users/604= 897327/schema/SIPREC_metadata.xsd
[ERROR] src-resolve: Cannot resolve th= e name 'urnuuid' to a(n) 'simpleType definition' component.=
=A0 line 72 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd
[ERRO= R] src-resolve: Cannot resolve the name 'urnuuid' to a(n) 'simp= leType definition' component.
=A0 line 74 of file:/C:/Users/60489732= 7/schema/SIPREC_metadata.xsd
[ERROR] src-resolve: Cannot resolve the name 'urnuuid' to a(n) '= ;simpleType definition' component.
=A0 line 86 of file:/C:/Users/604= 897327/schema/SIPREC_metadata.xsd
[ERROR] src-resolve: Cannot resolve th= e name 'urnuuid' to a(n) 'simpleType definition' component.=
=A0 line 88 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd
[ERRO= R] s4s-elt-invalid-content.1: The content of '#AnonType_extensiondata&#= 39; is invalid.=A0 Element 'any' is invalid, misplaced, or occurs t= oo often.
=A0 line 95 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd
[ERRO= R] s4s-elt-must-match.1: The content of 'extensiondata' must match = (annotation?, (simpleType | complexType)?, (unique | key | keyref)*)). A pr= oblem was found starting at: attribute.
=A0 line 98 of file:/C:/Users/604897327/schema/SIPREC_metadata.xsd
Faile= d to parse a schema.
Thanks in advance

--
----------------------------
Thanks & Regards,
Si= rish Gandhi

--0015174c3d44896cf704af51db2f-- From rmohanr@cisco.com Mon Oct 17 02:53:50 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 EA82D21F8AE1 for ; Mon, 17 Oct 2011 02:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.177 X-Spam-Level: X-Spam-Status: No, score=-8.177 tagged_above=-999 required=5 tests=[AWL=2.422, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg3xqAeU4eeQ for ; Mon, 17 Oct 2011 02:53:49 -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 C084C21F899F for ; Mon, 17 Oct 2011 02:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=13411; q=dns/txt; s=iport; t=1318845229; x=1320054829; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=6sjHQiFJYhAdNDcq5LKM00k+bDZ+Rucq02i2IQif15Y=; b=AmIhp0WgLst/eiPV82Hows6jH1R+Tnx1pftjPWx1EK2hAOG1sRPbwULu WJkbkOSeQUnsAjNPAMYqvZksIJnUVs61g2/5Xv78aNKDsoZL30POwz0Md 4ce0jh8DtF4kS0iZkoUjcOBW4mivp0ditldyNGUO3mdST1rC2tz5MAa3R g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMAACb6m05Io8US/2dsb2JhbABDmUKPIoEFgW4BAQEDAQEBAQ8BHTgGFwQCAQgOAwQBAQEKBhcBBgEmHwkIAgQBCggIARmHXQiUPQGeBIcnYQSHUi6RLIR9hy8 X-IronPort-AV: E=Sophos;i="4.69,358,1315180800"; d="scan'208";a="57925359" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 17 Oct 2011 09:53:46 +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 p9H9rhUv019043; Mon, 17 Oct 2011 09:53:46 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, 17 Oct 2011 15:23:43 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Oct 2011 15:23:42 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD08091919@XMB-BGL-417.cisco.com> In-Reply-To: <622B0E14298DDE47ACA9E16B292F22A40F2EACAD@Mail1.acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Need Inputs: How to represent attributesof association in Metadata Model and in XML ? Thread-Index: AQHMiiWopFVp9w/gGEmFgV/fmcyQM5V72d0AgARph6A= References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com> <622B0E14298DDE47ACA9E16B292F22A40F2EACAD@Mail1.acmepacket.com> From: "Ram Mohan R (rmohanr)" To: "Brad Winslow" , X-OriginalArrivalTime: 17 Oct 2011 09:53:43.0098 (UTC) FILETIME=[A79BE1A0:01CC8CB2] Subject: Re: [siprec] Need Inputs: How to represent attributesof association in Metadata Model and 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, 17 Oct 2011 09:53:51 -0000 Hi Brad, If I understand your question correct you are asking why association = class is needed right ? We had several discussions before and in IETF81 meeting we reached to a = consensus that certain attributes in the current model (e.g. attributes = of participant like callee capabilities, stream attributes like = association/disassociation time, csrc) which are attributes of = association and NOT attributes of the element.=20 See minutes - = http://www.ietf.org/mail-archive/web/siprec/current/msg02511.html More at = http://www.ietf.org/mail-archive/web/siprec/current/msg02692.html Hence we introduced association class and this mail is discussing the = possible representations in XML for the same. Some use-cases are: In case of mixed stream we can have multiple participants contributing = to the stream and a participant may be contributing to multiple streams = also. In these cases the attributes that link participant to stream like = time, csrc are association attributes Capabilities of participant are again attributes of association of = participant to a session as a participant may have different = capabilities (e.g. a participant may be a end point in session 1 and = then focus in session 2). Now regarding the representation for association class, we seem to be = narrowing down is approach 2=20 If you have other ways to represent association class in the metadata = XML document, Please suggest. Thanks, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Brad Winslow > Sent: Friday, October 14, 2011 7:19 PM > To: siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to represent attributesof > association in Metadata Model and in XML ? >=20 > Hi Folks, >=20 > I believe the association elements complicate the metadata model. It > seems to me, unless I'm being na=EFve, that the SRC would introduce = the > participant and the steam elements into the CS at the same time. The > association mechanism as described doesn't seem to support the notion > of side conversations, as the and elements are capable > of doing. If the and elements remain in the metadata, > I'm not sure what benefit the association elements provide. >=20 > Thanks, > Brad >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: Thursday, October 13, 2011 11:59 PM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to represent attributes of > association in Metadata Model and in XML ? >=20 > Thanks Paul for your comments. I also prefer approach 2 as mentioned > below in this thread. > I will wait to hear for comments/opinion from others. >=20 > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Thursday, October 13, 2011 10:48 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] Need Inputs: How to represent attributes of > > association in Metadata Model and in XML ? > > > > I like approach 2, as Ram has shown it. It deals with the problems > John > > raised with the others. > > > > I didn't follow John's arithmetic on this one, using his 20 party > > conference example. As I count that, there are 21 participants when > you > > include the focus. Each of the 20 has two stream/participant > > associations with the focus, for a total of 40. (The association is > > bidirectional. I can only get to 80 by assuming we had to represent > an > > association in each direction.) And each has two ids, each of which > is > > also the id of a stream or participant. So there are really only 23 > > distinct ids that need to be assigned for this. (One for each of the > 21 > > participants, and one for each of the two streams.) > > > > The 40 associations, each carrying two ids, is still kind of a lot = if > > its sent all at once. But when starting up a conference they will > > probably be added gradually as each participant joins. Same at the > end > > if they drop off individually. But it could be a bunch together if > the > > conference is forcibly dropped by the focus. But it does minimize > what > > is sent when things happen incrementally. > > > > There may be some optimizations that can be done - e.g. a sort of > > "wildcard" for one of the the two ids in the association class. E.g. > > > > > participant=3D"*" > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > 2010-12-16T23:41:07Z > > > > > > (I'm not advocating that particular syntax. Its just something to > make > > the point.) > > > > Thanks, > > Paul > > > > > > On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: > > > My bad(typo) while sending the example. The correct partial update > I > > > intended to send is: > > > > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > > 2010-12-16T23:41:07Z > > > > > > > > > This is inline with approach 2 where in each association XML > element > > > will have the IDs of the related associated elements. > > > > > > Ram > > > > > >> -----Original Message----- > > >> From: Leon Portman [mailto:Leon.Portman@nice.com] > > >> Sent: Wednesday, October 12, 2011 2:24 PM > > >> To: Ram Mohan R (rmohanr); siprec@ietf.org > > >> Cc: Ofir Roth > > >> Subject: RE: Need Inputs: How to represent attributes of > association > > > in > > >> Metadata Model and in XML ? > > >> > > >> We do prefer to receive related elements as well, it makes > > >> implementation much easier. > > >> At least we should get relevant IDs. For example below, SRC > > should > > >> also send ParticipantId > > >> > > >> -----Original Message----- > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >> Sent: Wednesday, October 12, 2011 10:52 AM > > >> To: Leon Portman; siprec@ietf.org > > >> Cc: Ofir Roth > > >> Subject: RE: Need Inputs: How to represent attributes of > association > > > in > > >> Metadata Model and in XML ? > > >> > > >> Leon, > > >> Thanks for your response. One of the adv with approach 2 is we = can > > >> indicate only changes in the association without the need to > > > indicating > > >> the elements ( of association). IOW for the below example, if > there > > is > > >> a change in participant-stream association I can simply send the > > >> following in partial update: > > >> > > >> > > >> > >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> > > >> 2010-12-16T23:41:07Z > > >> > > >> > > >> Do you see a need to always indicate the related elements too ? = In > > >> which case I see approach 1 as more suitable. > > >> > > >> Thanks, > > >> Ram > > >> > > >>> -----Original Message----- > > >>> From: Leon Portman [mailto:Leon.Portman@nice.com] > > >>> Sent: Wednesday, October 12, 2011 12:55 PM > > >>> To: Ram Mohan R (rmohanr); siprec@ietf.org > > >>> Cc: Ofir Roth > > >>> Subject: RE: Need Inputs: How to represent attributes of > > association > > >>> inmetadata Model and in XML ? > > >>> > > >>> Ram Hi > > >>> > > >>> I am ok with approaches 1 and however I do prefer approach one > > >> because > > >>> it will be easier for SRS to get decode - association is inside > > >>> relevant element. And it is more readable. > > >>> Approach 2 will work as well, however it is important that if > there > > >>> will be a change in association then to send to SRS not only > > updated > > >>> association element but also related elements: for example if > > stream > > >>> was associated to participant and session, send also participant > > and > > >>> session latest state. > > >>> > > >>> Regards > > >>> > > >>> Leon > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] = On > > >>> Behalf Of Ram Mohan R (rmohanr) > > >>> Sent: Wednesday, October 12, 2011 7:48 AM > > >>> To: siprec@ietf.org > > >>> Subject: [siprec] Need Inputs: How to represent attributes of > > >>> association in metadata Model and in XML ? > > >>> > > >>> (Sorry for lengthy e-mail) > > >>> > > >>> Hi All, > > >>> > > >>> In the last interim we discussed 4 approaches for representing > > >>> attributes of association in XML. > > >>> > > >>> > > >>> Here are some pros/cons for each of them: > > >>> Approach 1: > > >>> ---------- > > >>> Represent the association attribute as a property within one of > the > > >>> associated elements. Example given at http://www.ietf.org/mail- > > >>> archive/web/siprec/current/msg02709.html Does not need another > XML > > >>> element and represents the association attributes as capability > of > > >> one > > >>> of the association element. > > >>> e.g. > > >>> > >>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- > > 6da1eeaeb425"> > > >>> sip:ram@blr.cisco.com > > >>> 2010-12- > 16T23:41:07Z > >> time> > > >>> TBD > > >>> > >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820- > > >>> d03a191fb76a > > >>> "> > > >>> 2010-12- > > 16T23:41:07Z > >>> time> > > >>> contributing SSRC-1 > > >>> In > > the > > >> above > > >>> example the participant contributes a single streams. For each > > > stream > > >>> the association attribute (participant-stream) is shown with the > > >> stream > > >>> ID nested in. > > >>> > > >>> > > >>> Approach 2: > > >>> ----------- > > >>> In this approach we have a new XML element for every association > > >> class. > > >>> This xml element will NOT have a unique ID instead it references > > the > > >> ID > > >>> of associated elements (shown below). With this approach it is > easy > > >> to > > >>> update as the association class is a separate XML element and = not > > >>> property. > > >>> e.g. > > >>> > >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > >>> 2010-12-16T23:41:07Z > > >>> TBD > > >>> > > >>> > >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > >>> 2010-12-16T23:41:07Z > > >>> contributing SSRC-1 > > >>> > > >>> Approach 3 and 4 are in the below e-mail from John. > > >>> Approach 3 defines a new Unique ID for every association XML > > elment. > > >>> Also it creates alias for the other IDs. In the discussions in > > >> interim > > >>> there was no strong support for this approach. > > >>> > > >>> Approach 4 is same as approach 1 where in the association = element > > is > > >>> encapsulated in one of the XML elements (to which it is > > > associated). > > >>> In addition to that it also has reference to the elements (alias > of > > >>> IDs) to which the association belongs. > > >>> > > >>> I prefer approach 2 as it is has a separate XML element to > > represent > > >>> the association class. The only difference of this XML element > from > > >>> others is this does not need a unique ID. Instead it references > the > > >> IDs > > >>> of the elements to which the association belongs. > > >>> Since association class is a special class meant to associate > > >> multiple > > >>> classes, I see it ok to have a representation as in approach 2 > > where > > >> in > > >>> the identifier is the concatenation of the classes to which the > > >>> association belongs to. > > >>> > > >>> Please provide your comments on this and also suggest any other > > >>> approaches to represent association classes in XML. > > >>> > > >>> Regards, > > >>> Ram > > >>> > > > _______________________________________________ > > > 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 bwinslow@acmepacket.com Tue Oct 18 13:25: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 6B69221F8CB5 for ; Tue, 18 Oct 2011 13:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csNAr6ySLpWO for ; Tue, 18 Oct 2011 13:25:21 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id EAEC621F8CAF for ; Tue, 18 Oct 2011 13:25:20 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 18 Oct 2011 16:25:17 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 16:25:17 -0400 From: Brad Winslow To: "siprec@ietf.org" Thread-Topic: [siprec] Need Inputs: How to represent attributesof association in Metadata Model and in XML ? Thread-Index: AcyN1AtXW7Y0+LUrQ7yU8Qupj9XwYQ== Date: Tue, 18 Oct 2011 20:25:16 +0000 Message-ID: <622B0E14298DDE47ACA9E16B292F22A40F2EAF88@Mail1.acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: Re: [siprec] Need Inputs: How to represent attributesof association in Metadata Model and 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: Tue, 18 Oct 2011 20:25:22 -0000 Hi Ram, Thank you for the information, I must admit I have been away from the SIPRE= C mailing list for a while, my apologies to all. In the protocol specification the element has two attributes = "id" and "session". This element represents the relationship between the p= articipant and the session, hence the "id" and "session" attributes. The n= ested and elements might be reformatted as; 2011-10-18T14:59:53 Contributing CSRC etc.. extension data Where the "stream" attribute would reference the stream element in the CS (= since the has attributes of "id' and "session" as well). The association of this participant to the stream can be nested in the and elements as above. Since participants are added to the metad= ata with the required "session" attribute, I'm not sure I understand the ne= cessity of the element. One would assume if the = participant "id" attribute is identical across sessions, the participant is= the same, although I don't recall if this is formally declared in the prot= ocol draft. The element maps the XML metadata to the SDP media line, the and elements associate a participant with a stream, it seems to be= the logical place for the additional feature attributes. Presuming the SRS would use XPath or XQuery parsing, nesting the associate-= time, csrc, etc. attributes in the (and ) elements may simplif= y the logic. By not introducing new elements in the metadata, we might be = able to reduce the message bloat. Thanks, Brad -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: Monday, October 17, 2011 5:54 AM To: Brad Winslow; siprec@ietf.org Subject: RE: [siprec] Need Inputs: How to represent attributesof associatio= n in Metadata Model and in XML ? Hi Brad, If I understand your question correct you are asking why association class = is needed right ? We had several discussions before and in IETF81 meeting we reached to a co= nsensus that certain attributes in the current model (e.g. attributes of pa= rticipant like callee capabilities, stream attributes like association/disa= ssociation time, csrc) which are attributes of association and NOT attribut= es of the element.=20 See minutes - http://www.ietf.org/mail-archive/web/siprec/current/msg02511.= html More at http://www.ietf.org/mail-archive/web/siprec/current/msg02692.html Hence we introduced association class and this mail is discussing the possi= ble representations in XML for the same. Some use-cases are: In case of mixed stream we can have multiple participants contributing to t= he stream and a participant may be contributing to multiple streams also. I= n these cases the attributes that link participant to stream like time, csr= c are association attributes Capabilities of participant are again attribut= es of association of participant to a session as a participant may have dif= ferent capabilities (e.g. a participant may be a end point in session 1 and= then focus in session 2). Now regarding the representation for association class, we seem to be narro= wing down is approach 2=20 If you have other ways to represent association class in the metadata XML d= ocument, Please suggest. Thanks, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Brad Winslow > Sent: Friday, October 14, 2011 7:19 PM > To: siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to represent attributesof=20 > association in Metadata Model and in XML ? >=20 > Hi Folks, >=20 > I believe the association elements complicate the metadata model. It=20 > seems to me, unless I'm being na=EFve, that the SRC would introduce the=20 > participant and the steam elements into the CS at the same time. The=20 > association mechanism as described doesn't seem to support the notion=20 > of side conversations, as the and elements are capable=20 > of doing. If the and elements remain in the metadata,=20 > I'm not sure what benefit the association elements provide. >=20 > Thanks, > Brad >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Ram Mohan R (rmohanr) > Sent: Thursday, October 13, 2011 11:59 PM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to represent attributes of=20 > association in Metadata Model and in XML ? >=20 > Thanks Paul for your comments. I also prefer approach 2 as mentioned=20 > below in this thread. > I will wait to hear for comments/opinion from others. >=20 > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Paul Kyzivat > > Sent: Thursday, October 13, 2011 10:48 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] Need Inputs: How to represent attributes of=20 > > association in Metadata Model and in XML ? > > > > I like approach 2, as Ram has shown it. It deals with the problems > John > > raised with the others. > > > > I didn't follow John's arithmetic on this one, using his 20 party=20 > > conference example. As I count that, there are 21 participants when > you > > include the focus. Each of the 20 has two stream/participant=20 > > associations with the focus, for a total of 40. (The association is=20 > > bidirectional. I can only get to 80 by assuming we had to represent > an > > association in each direction.) And each has two ids, each of which > is > > also the id of a stream or participant. So there are really only 23=20 > > distinct ids that need to be assigned for this. (One for each of the > 21 > > participants, and one for each of the two streams.) > > > > The 40 associations, each carrying two ids, is still kind of a lot=20 > > if its sent all at once. But when starting up a conference they will=20 > > probably be added gradually as each participant joins. Same at the > end > > if they drop off individually. But it could be a bunch together if > the > > conference is forcibly dropped by the focus. But it does minimize > what > > is sent when things happen incrementally. > > > > There may be some optimizations that can be done - e.g. a sort of=20 > > "wildcard" for one of the the two ids in the association class. E.g. > > > > > participant=3D"*" > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > 2010-12-16T23:41:07Z > > > > > > (I'm not advocating that particular syntax. Its just something to > make > > the point.) > > > > Thanks, > > Paul > > > > > > On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: > > > My bad(typo) while sending the example. The correct partial update > I > > > intended to send is: > > > > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > > 2010-12-16T23:41:07Z > > > > > > > > > This is inline with approach 2 where in each association XML > element > > > will have the IDs of the related associated elements. > > > > > > Ram > > > > > >> -----Original Message----- > > >> From: Leon Portman [mailto:Leon.Portman@nice.com] > > >> Sent: Wednesday, October 12, 2011 2:24 PM > > >> To: Ram Mohan R (rmohanr); siprec@ietf.org > > >> Cc: Ofir Roth > > >> Subject: RE: Need Inputs: How to represent attributes of > association > > > in > > >> Metadata Model and in XML ? > > >> > > >> We do prefer to receive related elements as well, it makes=20 > > >> implementation much easier. > > >> At least we should get relevant IDs. For example below, SRC > > should > > >> also send ParticipantId > > >> > > >> -----Original Message----- > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >> Sent: Wednesday, October 12, 2011 10:52 AM > > >> To: Leon Portman; siprec@ietf.org > > >> Cc: Ofir Roth > > >> Subject: RE: Need Inputs: How to represent attributes of > association > > > in > > >> Metadata Model and in XML ? > > >> > > >> Leon, > > >> Thanks for your response. One of the adv with approach 2 is we=20 > > >> can indicate only changes in the association without the need to > > > indicating > > >> the elements ( of association). IOW for the below example, if > there > > is > > >> a change in participant-stream association I can simply send the=20 > > >> following in partial update: > > >> > > >> > > >> > >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> > > >> 2010-12-16T23:41:07Z > > >> > > >> > > >> Do you see a need to always indicate the related elements too ?=20 > > >> In which case I see approach 1 as more suitable. > > >> > > >> Thanks, > > >> Ram > > >> > > >>> -----Original Message----- > > >>> From: Leon Portman [mailto:Leon.Portman@nice.com] > > >>> Sent: Wednesday, October 12, 2011 12:55 PM > > >>> To: Ram Mohan R (rmohanr); siprec@ietf.org > > >>> Cc: Ofir Roth > > >>> Subject: RE: Need Inputs: How to represent attributes of > > association > > >>> inmetadata Model and in XML ? > > >>> > > >>> Ram Hi > > >>> > > >>> I am ok with approaches 1 and however I do prefer approach one > > >> because > > >>> it will be easier for SRS to get decode - association is inside=20 > > >>> relevant element. And it is more readable. > > >>> Approach 2 will work as well, however it is important that if > there > > >>> will be a change in association then to send to SRS not only > > updated > > >>> association element but also related elements: for example if > > stream > > >>> was associated to participant and session, send also participant > > and > > >>> session latest state. > > >>> > > >>> Regards > > >>> > > >>> Leon > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org]=20 > > >>> On Behalf Of Ram Mohan R (rmohanr) > > >>> Sent: Wednesday, October 12, 2011 7:48 AM > > >>> To: siprec@ietf.org > > >>> Subject: [siprec] Need Inputs: How to represent attributes of=20 > > >>> association in metadata Model and in XML ? > > >>> > > >>> (Sorry for lengthy e-mail) > > >>> > > >>> Hi All, > > >>> > > >>> In the last interim we discussed 4 approaches for representing=20 > > >>> attributes of association in XML. > > >>> > > >>> > > >>> Here are some pros/cons for each of them: > > >>> Approach 1: > > >>> ---------- > > >>> Represent the association attribute as a property within one of > the > > >>> associated elements. Example given at http://www.ietf.org/mail-=20 > > >>> archive/web/siprec/current/msg02709.html Does not need another > XML > > >>> element and represents the association attributes as capability > of > > >> one > > >>> of the association element. > > >>> e.g. > > >>> > >>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- > > 6da1eeaeb425"> > > >>> sip:ram@blr.cisco.com > > >>> 2010-12- > 16T23:41:07Z > >> time> > > >>> TBD > > >>> > >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820- > > >>> d03a191fb76a > > >>> "> > > >>> 2010-12- > > 16T23:41:07Z > >>> time> > > >>> contributing SSRC-1 > > >>> In > > the > > >> above > > >>> example the participant contributes a single streams. For each > > > stream > > >>> the association attribute (participant-stream) is shown with the > > >> stream > > >>> ID nested in. > > >>> > > >>> > > >>> Approach 2: > > >>> ----------- > > >>> In this approach we have a new XML element for every association > > >> class. > > >>> This xml element will NOT have a unique ID instead it references > > the > > >> ID > > >>> of associated elements (shown below). With this approach it is > easy > > >> to > > >>> update as the association class is a separate XML element and=20 > > >>> not property. > > >>> e.g. > > >>> > >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > >>> 2010-12-16T23:41:07Z > > >>> TBD > > >>> > > >>> > >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > >>> 2010-12-16T23:41:07Z > > >>> contributing SSRC-1 > > >>> > > >>> Approach 3 and 4 are in the below e-mail from John. > > >>> Approach 3 defines a new Unique ID for every association XML > > elment. > > >>> Also it creates alias for the other IDs. In the discussions in > > >> interim > > >>> there was no strong support for this approach. > > >>> > > >>> Approach 4 is same as approach 1 where in the association=20 > > >>> element > > is > > >>> encapsulated in one of the XML elements (to which it is > > > associated). > > >>> In addition to that it also has reference to the elements (alias > of > > >>> IDs) to which the association belongs. > > >>> > > >>> I prefer approach 2 as it is has a separate XML element to > > represent > > >>> the association class. The only difference of this XML element > from > > >>> others is this does not need a unique ID. Instead it references > the > > >> IDs > > >>> of the elements to which the association belongs. > > >>> Since association class is a special class meant to associate > > >> multiple > > >>> classes, I see it ok to have a representation as in approach 2 > > where > > >> in > > >>> the identifier is the concatenation of the classes to which the=20 > > >>> association belongs to. > > >>> > > >>> Please provide your comments on this and also suggest any other=20 > > >>> approaches to represent association classes in XML. > > >>> > > >>> Regards, > > >>> Ram > > >>> > > > _______________________________________________ > > > 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 Tue Oct 18 23:56: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 93FFF21F84DF for ; Tue, 18 Oct 2011 23:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.435 X-Spam-Level: X-Spam-Status: No, score=-8.435 tagged_above=-999 required=5 tests=[AWL=2.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4vImL7fZx0d for ; Tue, 18 Oct 2011 23:56:28 -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 0D00D21F84BB for ; Tue, 18 Oct 2011 23:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=7320; q=dns/txt; s=iport; t=1319007388; x=1320216988; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=nwm2gx3GT3COEg4f/x//LlYSGV2ahnTHZQJfPSUmdTE=; b=Vp8nRFjhClL4JJiDkXX4wz5e8ZXAuNmKcSQA3HRsyseYmX9IJqayDbbf 4RaDA/XUiLrd7gwBNFnHm8uhx8T4fnk7LdbgZxnlKaVe+qJFmCnq/7scp QjLtsFhSxjmdxmtOW3VRvmoxsO0ZFISAL9GOVmRRYGAo6k7nLTZWEC73Q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4AADF0nk5Io8UR/2dsb2JhbABEmT2PNYEFgW4BAQEDAQEBAQ8BHQo0FwQCAQgRBAEBCwYFEgEGASYfCQgBAQQBCggIGodeCJZJAZ4lBIR/gjthBIgAkTGMLA X-IronPort-AV: E=Sophos;i="4.69,370,1315180800"; d="scan'208";a="58078068" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 19 Oct 2011 06:56:23 +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 p9J6uI9Z023762 for ; Wed, 19 Oct 2011 06:56:22 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); Wed, 19 Oct 2011 12:26:12 +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, 19 Oct 2011 12:26:11 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD081A6EB0@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AcyFQAjzFY55YKG7Tzm0ZW2LMCCpkAI5aiYQ References: From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 19 Oct 2011 06:56:12.0765 (UTC) FILETIME=[305788D0:01CC8E2C] Subject: Re: [siprec] proposed text for dealing with packet loss 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, 19 Oct 2011 06:56:29 -0000 Hi Charles, Sorry for delay in reviewing this. Here are my comments/questions on the proposed text. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Saturday, October 08, 2011 3:56 AM > To: siprec@ietf.org > Subject: [siprec] proposed text for dealing with packet loss >=20 > During the last interim meeting, I accepted an action item to propose > some text for draft-eckel-siprec-rtp-rec regarding SRC handling of > packet loss. Here is text for the various RTP models with the proposed > text added (look for "If packet loss occurs" within each model): >=20 > ---------------- >=20 > 4.1. SRC acting as an RTP Translator >=20 > The SRC may act as a translator, as defined in [RFC3550]. A > defining > characteristic of a translator is that it forwards RTP packets with > their SSRC identifier intact. There are two types of translators, > one that simply forwards, and another that performs transcoding > (e.g., from one codec to another) in addition to forwarding. >=20 > 4.1.1. Forwarding Translator >=20 > When acting as a forwarding translator, RTP received as separate > streams from different sources (e.g., from different UAs with > different SSRCs) cannot be mixed by the SRC and MUST be sent > separately to the SRS. All RTCP reports MUST be passed by the SRC > between the UAs and the SRS, such that the UAs and SRS are able to > detect any SSRC collisions. >=20 > RTCP Sender Reports generated by a UA sending a stream MUST be > forwarded to the SRS. RTCP Receiver Reports generated by the SRS > MUST be forwarded to the relevant UA. Are you suggesting to replicate/fork the RTCP sender reports generated by an UAs (which may not be SRC) in CS as is to SRS ? I wonder if that is right since some of the fields may not be needed. For e.g. RTCP sender report may have zero or more reception report blocks. This has information about the number of other sources heard by this sender since the last report. I guess this may not make sense to SRS. Also in case of RTCP receiver report from SRS I see you mentioned that SRC forwards to UA. what action do we want the UA to take ? Should we leave it as a policy at the UA ? May be we need to add some text on this. Note that the UA here may be receiving two receiver report ( one from destination say UA2 who is in CS and other from SRS). >=20 > If SRTP is used on both the CS and the RS, decryption and/or re- > encryption may occur. For example, if different keys are used, it > will occur. If the same keys are used, it need not occur. >=20 > If packet loss occurs, either from the UA to the SRC or from the SRC > to the SRS, the SRS SHOULD detect and attempt to recover from the > loss. The SRC does not play a role in this other than forwarding > the > associated RTP and RTCP packets. >=20 > 4.1.2. Transcoding Translator >=20 > When acting as a transcoding translator, an SRC MAY perform > transcoding (e.g., from one codec to another), and this may result > in > a different rate of packets between what the SRC receives and what > the sends. As when acting as a forwarding translator, RTP received > as separate streams from different sources (e.g., from different UAs > with different SSRCs) cannot be mixed by the SRC and MUST be sent > separately to the SRS. All RTCP reports MUST passed by the SRC > between the UAs and the SRS, such the UAs and SRS they are able to > detect any SSRC collisions. >=20 > RTCP Sender Reports generated by a UA sending a stream MUST be > forwarded to the SRS. RTCP Receiver Reports generated by the SRS > MUST be forwarded to the relevant UA. =20 Why do we need to forward the RTCP reports from SRS back to UA here ? In this case the SRC is acting as an endpoint terminating and re-originating the media by doing transcoding. So the RTCP receiver report are for the packets originated by the transcoder.=20 The SRC may need to > manipulate > the RTCP Receiver Reports to take account of any transcoding that > has > taken place. >=20 > If SRTP is used on both the CS and the RS, decryption and/or re- > encryption may occur. For example, if different keys are used, it > will occur. If the same keys are used, it need not occur. >=20 > If packet loss occurs, either from the UA to the SRC or from the SRC > to the SRS, the SRS SHOULD detect and attempt to recover from the > loss. The SRC does not play a role in this other than forwarding > the > associated RTP and RTCP packets. >=20 > 4.2. SRC acting as an RTP Mixer >=20 > In the case of the SRC acting as a RTP mixer, as defined in > [RFC3550], the SRC combines RTP streams from different UA and sends > them towards the SRS using its own SSRC. The SSRCs from the > contributing UA SHOULD be conveyed as CSRCs identifiers within this > stream. The SRC may make timing adjustments among the received > streams and generate its own timing on the stream sent to the SRS. > Optionally an SRC acting as a mixer can perform transcoding, and can > even cope with different codings received from different UAs. RTCP > Sender Reports and Receiver Reports are not forwarded by an SRC > acting as mixer, but there are requirements for forwarding RTCP > Source Description (SDES) packets. The SRC generates its own RTCP > Sender and Receiver reports toward the associated UAs and SRS. The > use of SRTP between the SRC and the SRS for the RS is independent of > the use of SRTP between the UAs and SRC for the CS. >=20 > If packet loss occurs from the UA to the SRC, the SRC SHOULD detect > and attempt to recover from the loss. If packet loss occurs from > the > SRC to the SRS, the SRS SHOULD detect and attempt to recover from > the > loss. >=20 > 4.3. SRC acting as an RTP Endpoint >=20 > The case of the SRC acting as an RTP endpoint, as defined in > [RFC3550], is similar to the mixer case, except that the RTP session > between the SRC and the SRS is considered completely independent > from > the RTP session that is part of the CS. The SRC can, but need not, > mix RTP streams from different participants prior to sending to the > SRS. RTCP between the SRC and the SRS is completely independent of > RTCP on the CS. The use of SRTP between the SRC and the SRS is > independent of the use of SRTP on the CS. >=20 > If packet loss occurs from the UA to the SRC, the SRC SHOULD detect > and attempt to recover from the loss. If packet loss occurs from > the > SRC to the SRS, the SRS SHOULD detect and attempt to recover from > the > loss. Rest looks ok to me. In general we need some text on what UA/SRC MAY do on receiving these reports. We can simply mention that based on policy a UA/SRC may act on the reports. Regards, Ram > ------------------ >=20 > Comment on this are greatly appreciated. > Thanks, > Charles > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From trac+siprec@trac.tools.ietf.org Wed Oct 19 00:08:07 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 2249E21F8770 for ; Wed, 19 Oct 2011 00:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9q+s6l-4HaM for ; Wed, 19 Oct 2011 00:08:06 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEAC21F86A0 for ; Wed, 19 Oct 2011 00:08:06 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RGQFx-0006lb-Kq; Wed, 19 Oct 2011 03:08:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: rmohanr@cisco.com X-Trac-Project: siprec Date: Wed, 19 Oct 2011 07:08:05 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/77 Message-ID: <058.40bd2ad76f0bbaeee8ea367ea03f4689@trac.tools.ietf.org> X-Trac-Ticket-ID: 77 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 gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: [siprec] #77: Address terminology/language comments sent on metadata ver - 04 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: Wed, 19 Oct 2011 07:08:07 -0000 #77: Address terminology/language comments sent on metadata ver - 04 Address John Elwell comments sent on metadata ver 04 http://www.ietf.org/mail-archive/web/siprec/current/msg02747.html http://www.ietf.org/mail-archive/web/siprec/current/msg02776.html -- --------------------------------+----------------------- Reporter: rmohanr@… | Owner: rmohanr@… Type: defect | Status: new Priority: minor | Milestone: Component: Metadata Model | Version: Severity: Active WG Document | Keywords: --------------------------------+----------------------- Ticket URL: siprec From rmohanr@cisco.com Wed Oct 19 02:45: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 9B27621F8B9E for ; Wed, 19 Oct 2011 02:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.616 X-Spam-Level: X-Spam-Status: No, score=-6.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLyAV5u5tinO for ; Wed, 19 Oct 2011 02:45:39 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B4EB721F8B5B for ; Wed, 19 Oct 2011 02:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1182; q=dns/txt; s=iport; t=1319017538; x=1320227138; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=LrKYYhuZM2T7fnvOT3gdKnhKa8UTgYNHHTturrLdwhY=; b=QjVjPPyPIPjjw4sP99+8/R0iHHxBgOPiKmqt963+EG8/ef7Da8ogiU2R JhDr++818E7qXEGFKx5F6vgVHrpYPItFNfVyx1s82F3f9Dpw7n6kWWFhQ D6T113Cz2zHpuZE79JqAOjBTEIsdSjNYoKQJxbFGVHMQDlVj2tL1obbLU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMHAJKbnk5Io8UR/2dsb2JhbABEmgeOcoEFgXABBBIBHQpRARoQBhgHSA8BBAsQEwecaYEmAZ48hzphBIgAkTGMLA X-IronPort-AV: E=Sophos;i="4.69,371,1315180800"; d="scan'208";a="1314906" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-4.cisco.com with ESMTP; 19 Oct 2011 09:45:37 +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 p9J9jaTW023835 for ; Wed, 19 Oct 2011 09:45:36 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, 19 Oct 2011 15:15:36 +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, 19 Oct 2011 15:15:34 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD081A6F62@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-siprec-architecture-03 Thread-Index: AcyOQ9kVGwsNsb2/QzelMKamj0Ue7w== From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 19 Oct 2011 09:45:36.0383 (UTC) FILETIME=[DA5490F0:01CC8E43] Subject: [siprec] Comments on draft-ietf-siprec-architecture-03 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, 19 Oct 2011 09:45:39 -0000 I reviewed draft-ietf-siprec-architecture-03 and the document looks pretty good. Here are a few minor nits. I see that this draft uses Media Recording Metadata(MRM) to talk about metadata. Note that neither the requirement rfc or metadata draft uses this terminology for metadata. Is it better to change it to just Recording metadata to keep it consistent ? Section 1 ( Introduction) has " The Replicated Media is required to be sent in real-time to the Session Recording Server and is not buffered by the Session Recording Client to allow for real-time analysis of the media by the Session Recording Server"=20 This is more of a requirement and I see no need to have this text in architecture document. In case we still need to give guideless on how to do this, the solution draft can talk about it. In figure 4 the direction of RTP/RTCP arrow towards SRS should be reverse. In figure 5, the Focus/SRC may also record the mixed stream. Should we show that also in figure ? Section 3.2.1 to 3.2.3 talks about how an SRC should setup a session, what parameters to include e.t.c. I wonder if this should be part of protocol document ? Ram From leon.portman@gmail.com Wed Oct 19 09:12: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 700F021F8CA0 for ; Wed, 19 Oct 2011 09:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9t1OTg9ks1u for ; Wed, 19 Oct 2011 09:12:28 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7511E21F8C90 for ; Wed, 19 Oct 2011 09:12:22 -0700 (PDT) Received: by yxj19 with SMTP id 19so2237985yxj.31 for ; Wed, 19 Oct 2011 09:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=sScnIG2wO9LEJNjQvQwL6gaLrfYpL5A/JxiMUMbHmkI=; b=l7rWbb3G/X5uOiKhmVgY6Fll9lKnqTVddurcR63S0+LvFXo0j3yLw0D+caAVNU5PDm ADKN8WmBS6FvQzCggoyoxtjgHuB8EY5abKsIFKfbAFpvYCFlg7jQWf1EIJDzv6tmBwRg /+lXpZqbH30VfbXu7LyKInurXbuJQab6eKeGU= Received: by 10.223.17.11 with SMTP id q11mr12053042faa.13.1319040695400; Wed, 19 Oct 2011 09:11:35 -0700 (PDT) Received: from [192.168.1.104] ([212.150.140.190]) by mx.google.com with ESMTPS id c2sm10410041fam.14.2011.10.19.09.11.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Oct 2011 09:11:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Leon Portman In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD081A6F62@XMB-BGL-417.cisco.com> Date: Wed, 19 Oct 2011 18:11:29 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <35BCE99A477D6A4986FB2216D8CF2CFD081A6F62@XMB-BGL-417.cisco.com> To: Ram Mohan R (rmohanr) X-Mailer: Apple Mail (2.1251.1) Cc: siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-03 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, 19 Oct 2011 16:12:28 -0000 Thank you very much Ram Lets hear some opinions and i will update the document Regards Leon On Oct 19, 2011, at 11:45 AM, Ram Mohan R (rmohanr) wrote: > I reviewed draft-ietf-siprec-architecture-03 and the document looks > pretty good. Here are a few minor nits. > > I see that this draft uses Media Recording Metadata(MRM) to talk about > metadata. Note that neither the requirement rfc or metadata draft uses > this terminology for metadata. Is it better to change it to just > Recording metadata to keep it consistent ? > > Section 1 ( Introduction) has > " The Replicated > Media is required to be sent in real-time to the Session Recording > Server and is not buffered by the Session Recording Client to allow > for real-time analysis of the media by the Session Recording Server" > > This is more of a requirement and I see no need to have this text in > architecture document. In case we still need to give guideless on how to > do this, the solution draft can talk about it. > > In figure 4 the direction of RTP/RTCP arrow towards SRS should be > reverse. > > In figure 5, the Focus/SRC may also record the mixed stream. Should we > show that also in figure ? > > Section 3.2.1 to 3.2.3 talks about how an SRC should setup a session, > what parameters to include e.t.c. I wonder if this should be part of > protocol document ? > > Ram > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Wed Oct 19 10:36: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 996CB21F8AB9 for ; Wed, 19 Oct 2011 10:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kImt+vb8a2y1 for ; Wed, 19 Oct 2011 10:36:48 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5299C21F8AA8 for ; Wed, 19 Oct 2011 10:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=9136; q=dns/txt; s=iport; t=1319045808; x=1320255408; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=seW3g300wU0PZ88F6jM9DMK0qlh2lQHflzOwZR8rFhs=; b=Q0oGoVAvE1jl8ELqdQ7T/B0DmJ4UdJsie6ZHitdRKYFHKUEUBXtzGjgv yVBPOuECng40s6CJj/+DBmsnbyKOJW88v6YgWIqFF1bl/K6ofYRsaa5T8 U8EW3wJhb6XLvMtG1WBXCVwfkrbKKKZ6CD1wQtT+xjKRTh1Yrrz64rpk7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQAAKsJn06rRDoI/2dsb2JhbABEmUiPMIEFgW4BAQEDAQEBAQ8BHQo0EAcEAgEIEQQBAQsGBRIBBgEmHwkIAQEEARIIGodeCJc1AZ5KBIR/gjthBIgCkS+MRA X-IronPort-AV: E=Sophos;i="4.69,373,1315180800"; d="scan'208";a="8893999" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 19 Oct 2011 17:36:46 +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 p9JHak4S025379 for ; Wed, 19 Oct 2011 17:36:46 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); Wed, 19 Oct 2011 10:36:45 -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, 19 Oct 2011 10:36:45 -0700 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD081A6EB0@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AcyFQAjzFY55YKG7Tzm0ZW2LMCCpkAI5aiYQABdZl4A= References: <35BCE99A477D6A4986FB2216D8CF2CFD081A6EB0@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , X-OriginalArrivalTime: 19 Oct 2011 17:36:45.0989 (UTC) FILETIME=[AC541D50:01CC8E85] Subject: Re: [siprec] proposed text for dealing with packet loss 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, 19 Oct 2011 17:36:49 -0000 Hi Ram, Thanks for reviewing. Please see inline. > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Tuesday, October 18, 2011 11:56 PM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] proposed text for dealing with packet loss >=20 > Hi Charles, >=20 > Sorry for delay in reviewing this. Here are my comments/questions on the proposed text. >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Saturday, October 08, 2011 3:56 AM > > To: siprec@ietf.org > > Subject: [siprec] proposed text for dealing with packet loss > > > > During the last interim meeting, I accepted an action item to propose > > some text for draft-eckel-siprec-rtp-rec regarding SRC handling of > > packet loss. Here is text for the various RTP models with the proposed > > text added (look for "If packet loss occurs" within each model): > > > > ---------------- > > > > 4.1. SRC acting as an RTP Translator > > > > The SRC may act as a translator, as defined in [RFC3550]. A > > defining > > characteristic of a translator is that it forwards RTP packets with > > their SSRC identifier intact. There are two types of translators, > > one that simply forwards, and another that performs transcoding > > (e.g., from one codec to another) in addition to forwarding. > > > > 4.1.1. Forwarding Translator > > > > When acting as a forwarding translator, RTP received as separate > > streams from different sources (e.g., from different UAs with > > different SSRCs) cannot be mixed by the SRC and MUST be sent > > separately to the SRS. All RTCP reports MUST be passed by the SRC > > between the UAs and the SRS, such that the UAs and SRS are able to > > detect any SSRC collisions. > > > > RTCP Sender Reports generated by a UA sending a stream MUST be > > forwarded to the SRS. RTCP Receiver Reports generated by the SRS > > MUST be forwarded to the relevant UA. >=20 > Are you suggesting to replicate/fork the RTCP sender reports generated by an UAs (which may not be > SRC) in CS as is to SRS ? Yes. I wonder if that is right since some of the fields may not be needed. For > e.g. RTCP sender report may have zero or more reception report blocks. This has information about the > number of other sources heard by this sender since the last report. I guess this may not make sense to > SRS. True. If it is deemed important to do something more sophisticated, the SRC implementer may want to consider acting as a mixer instead. >=20 > Also in case of RTCP receiver report from SRS I see you mentioned that SRC forwards to UA. what action > do we want the UA to take ? Should we leave it as a policy at the UA ? May be we need to add some text > on this. Note that the UA here may be receiving two receiver report ( one from destination say UA2 who > is in CS and other from SRS). I was trying to avoid putting any requirements on the UA. Here as well, I see it a reason for the SRC to consider acting as a mixer. =20 > > > > If SRTP is used on both the CS and the RS, decryption and/or re- > > encryption may occur. For example, if different keys are used, it > > will occur. If the same keys are used, it need not occur. > > > > If packet loss occurs, either from the UA to the SRC or from the SRC > > to the SRS, the SRS SHOULD detect and attempt to recover from the > > loss. The SRC does not play a role in this other than forwarding > > the > > associated RTP and RTCP packets. > > > > 4.1.2. Transcoding Translator > > > > When acting as a transcoding translator, an SRC MAY perform > > transcoding (e.g., from one codec to another), and this may result > > in > > a different rate of packets between what the SRC receives and what > > the sends. As when acting as a forwarding translator, RTP received > > as separate streams from different sources (e.g., from different UAs > > with different SSRCs) cannot be mixed by the SRC and MUST be sent > > separately to the SRS. All RTCP reports MUST passed by the SRC > > between the UAs and the SRS, such the UAs and SRS they are able to > > detect any SSRC collisions. > > > > RTCP Sender Reports generated by a UA sending a stream MUST be > > forwarded to the SRS. RTCP Receiver Reports generated by the SRS > > MUST be forwarded to the relevant UA. >=20 > Why do we need to forward the RTCP reports from SRS back to UA here ? In this case the SRC is acting > as an endpoint terminating and re-originating the media by doing transcoding. So the RTCP receiver > report are for the packets originated by the transcoder. The SRC is not originating packets in this case, it is simply altering them as it they pass through it. What it needs to do is make sure that it accounts for the changes in makes such that the RTCP information is consistent with any changes it makes in the process. If the SRC wants to originate packets, it should consider the endpoint model. =20 =20 > The SRC may need to > > manipulate > > the RTCP Receiver Reports to take account of any transcoding that > > has > > taken place. > > > > If SRTP is used on both the CS and the RS, decryption and/or re- > > encryption may occur. For example, if different keys are used, it > > will occur. If the same keys are used, it need not occur. > > > > If packet loss occurs, either from the UA to the SRC or from the SRC > > to the SRS, the SRS SHOULD detect and attempt to recover from the > > loss. The SRC does not play a role in this other than forwarding > > the > > associated RTP and RTCP packets. > > > > 4.2. SRC acting as an RTP Mixer > > > > In the case of the SRC acting as a RTP mixer, as defined in > > [RFC3550], the SRC combines RTP streams from different UA and sends > > them towards the SRS using its own SSRC. The SSRCs from the > > contributing UA SHOULD be conveyed as CSRCs identifiers within this > > stream. The SRC may make timing adjustments among the received > > streams and generate its own timing on the stream sent to the SRS. > > Optionally an SRC acting as a mixer can perform transcoding, and can > > even cope with different codings received from different UAs. RTCP > > Sender Reports and Receiver Reports are not forwarded by an SRC > > acting as mixer, but there are requirements for forwarding RTCP > > Source Description (SDES) packets. The SRC generates its own RTCP > > Sender and Receiver reports toward the associated UAs and SRS. The > > use of SRTP between the SRC and the SRS for the RS is independent of > > the use of SRTP between the UAs and SRC for the CS. > > > > If packet loss occurs from the UA to the SRC, the SRC SHOULD detect > > and attempt to recover from the loss. If packet loss occurs from > > the > > SRC to the SRS, the SRS SHOULD detect and attempt to recover from > > the > > loss. > > > > 4.3. SRC acting as an RTP Endpoint > > > > The case of the SRC acting as an RTP endpoint, as defined in > > [RFC3550], is similar to the mixer case, except that the RTP session > > between the SRC and the SRS is considered completely independent > > from > > the RTP session that is part of the CS. The SRC can, but need not, > > mix RTP streams from different participants prior to sending to the > > SRS. RTCP between the SRC and the SRS is completely independent of > > RTCP on the CS. The use of SRTP between the SRC and the SRS is > > independent of the use of SRTP on the CS. > > > > If packet loss occurs from the UA to the SRC, the SRC SHOULD detect > > and attempt to recover from the loss. If packet loss occurs from > > the > > SRC to the SRS, the SRS SHOULD detect and attempt to recover from > > the > > loss. >=20 > Rest looks ok to me. In general we need some text on what UA/SRC MAY do on receiving these reports. We > can simply mention that based on policy a UA/SRC may act on the reports. What I was attempting to convey is that when acting as a translator, the SRC does not really do anything based on the reports. Acting on the reports is up to the UA. When acting as a mixer or endpoint, the SRC can and should act upon the reports. I can add something about the UA acting on them based on policy. This would be true for all cases, independent of the RTP role used by the SRC. I think that is not very useful and is outside of the recommendations described here. Let me know if you still think adding it to each case provides value, and if so, I can add it. Cheers, Charles > Regards, > Ram >=20 > > ------------------ > > > > Comment on this are greatly appreciated. > > Thanks, > > Charles > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Wed Oct 19 11:21: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 72E251F0C63 for ; Wed, 19 Oct 2011 11:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-mrgDfLaBSd for ; Wed, 19 Oct 2011 11:21:33 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3DA1F0C49 for ; Wed, 19 Oct 2011 11:21:33 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id miFv1h0011swQuc51iMZ3v; Wed, 19 Oct 2011 18:21:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.westchester.pa.mail.comcast.net with comcast id miMN1h03i0tdiYw3biMZnv; Wed, 19 Oct 2011 18:21:33 +0000 Message-ID: <4E9F1521.5020409@alum.mit.edu> Date: Wed, 19 Oct 2011 14:21:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <35BCE99A477D6A4986FB2216D8CF2CFD081A6EB0@XMB-BGL-417.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] proposed text for dealing with packet loss 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, 19 Oct 2011 18:21:34 -0000 Looking at this discussion, I wonder if it ever makes sense for the SRC to act as a translator? It seems that doing so will result in presenting the CS participants with information that would be confusing to them. Perhaps the SRC should always be a mixer or endpoint. Thanks, Paul On 10/19/11 1:36 PM, Charles Eckel (eckelcu) wrote: > Hi Ram, > > Thanks for reviewing. Please see inline. > >> -----Original Message----- >> From: Ram Mohan R (rmohanr) >> Sent: Tuesday, October 18, 2011 11:56 PM >> To: Charles Eckel (eckelcu); siprec@ietf.org >> Subject: RE: [siprec] proposed text for dealing with packet loss >> >> Hi Charles, >> >> Sorry for delay in reviewing this. Here are my comments/questions on > the proposed text. >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Charles Eckel (eckelcu) >>> Sent: Saturday, October 08, 2011 3:56 AM >>> To: siprec@ietf.org >>> Subject: [siprec] proposed text for dealing with packet loss >>> >>> During the last interim meeting, I accepted an action item to > propose >>> some text for draft-eckel-siprec-rtp-rec regarding SRC handling of >>> packet loss. Here is text for the various RTP models with the > proposed >>> text added (look for "If packet loss occurs" within each model): >>> >>> ---------------- >>> >>> 4.1. SRC acting as an RTP Translator >>> >>> The SRC may act as a translator, as defined in [RFC3550]. A >>> defining >>> characteristic of a translator is that it forwards RTP packets > with >>> their SSRC identifier intact. There are two types of > translators, >>> one that simply forwards, and another that performs transcoding >>> (e.g., from one codec to another) in addition to forwarding. >>> >>> 4.1.1. Forwarding Translator >>> >>> When acting as a forwarding translator, RTP received as separate >>> streams from different sources (e.g., from different UAs with >>> different SSRCs) cannot be mixed by the SRC and MUST be sent >>> separately to the SRS. All RTCP reports MUST be passed by the > SRC >>> between the UAs and the SRS, such that the UAs and SRS are able > to >>> detect any SSRC collisions. >>> >>> RTCP Sender Reports generated by a UA sending a stream MUST be >>> forwarded to the SRS. RTCP Receiver Reports generated by the SRS >>> MUST be forwarded to the relevant UA. >> >> Are you suggesting to replicate/fork the RTCP sender reports generated > by an UAs (which may not be >> SRC) in CS as is to SRS ? > > Yes. > > I wonder if that is right since some of the fields may not be needed. > For >> e.g. RTCP sender report may have zero or more reception report blocks. > This has information about the >> number of other sources heard by this sender since the last report. I > guess this may not make sense to >> SRS. > > True. If it is deemed important to do something more sophisticated, the > SRC implementer may want to consider acting as a mixer instead. > >> >> Also in case of RTCP receiver report from SRS I see you mentioned that > SRC forwards to UA. what action >> do we want the UA to take ? Should we leave it as a policy at the UA ? > May be we need to add some text >> on this. Note that the UA here may be receiving two receiver report ( > one from destination say UA2 who >> is in CS and other from SRS). > > I was trying to avoid putting any requirements on the UA. Here as well, > I see it a reason for the SRC to consider acting as a mixer. > >>> >>> If SRTP is used on both the CS and the RS, decryption and/or re- >>> encryption may occur. For example, if different keys are used, > it >>> will occur. If the same keys are used, it need not occur. >>> >>> If packet loss occurs, either from the UA to the SRC or from the > SRC >>> to the SRS, the SRS SHOULD detect and attempt to recover from the >>> loss. The SRC does not play a role in this other than forwarding >>> the >>> associated RTP and RTCP packets. >>> >>> 4.1.2. Transcoding Translator >>> >>> When acting as a transcoding translator, an SRC MAY perform >>> transcoding (e.g., from one codec to another), and this may > result >>> in >>> a different rate of packets between what the SRC receives and > what >>> the sends. As when acting as a forwarding translator, RTP > received >>> as separate streams from different sources (e.g., from different > UAs >>> with different SSRCs) cannot be mixed by the SRC and MUST be sent >>> separately to the SRS. All RTCP reports MUST passed by the SRC >>> between the UAs and the SRS, such the UAs and SRS they are able > to >>> detect any SSRC collisions. >>> >>> RTCP Sender Reports generated by a UA sending a stream MUST be >>> forwarded to the SRS. RTCP Receiver Reports generated by the SRS >>> MUST be forwarded to the relevant UA. >> >> Why do we need to forward the RTCP reports from SRS back to UA here ? > In this case the SRC is acting >> as an endpoint terminating and re-originating the media by doing > transcoding. So the RTCP receiver >> report are for the packets originated by the transcoder. > > The SRC is not originating packets in this case, it is simply altering > them as it they pass through it. What it needs to do is make sure that > it accounts for the changes in makes such that the RTCP information is > consistent with any changes it makes in the process. If the SRC wants to > originate packets, it should consider the endpoint model. > > >> The SRC may need to >>> manipulate >>> the RTCP Receiver Reports to take account of any transcoding that >>> has >>> taken place. >>> >>> If SRTP is used on both the CS and the RS, decryption and/or re- >>> encryption may occur. For example, if different keys are used, > it >>> will occur. If the same keys are used, it need not occur. >>> >>> If packet loss occurs, either from the UA to the SRC or from the > SRC >>> to the SRS, the SRS SHOULD detect and attempt to recover from the >>> loss. The SRC does not play a role in this other than forwarding >>> the >>> associated RTP and RTCP packets. >>> >>> 4.2. SRC acting as an RTP Mixer >>> >>> In the case of the SRC acting as a RTP mixer, as defined in >>> [RFC3550], the SRC combines RTP streams from different UA and > sends >>> them towards the SRS using its own SSRC. The SSRCs from the >>> contributing UA SHOULD be conveyed as CSRCs identifiers within > this >>> stream. The SRC may make timing adjustments among the received >>> streams and generate its own timing on the stream sent to the > SRS. >>> Optionally an SRC acting as a mixer can perform transcoding, and > can >>> even cope with different codings received from different UAs. > RTCP >>> Sender Reports and Receiver Reports are not forwarded by an SRC >>> acting as mixer, but there are requirements for forwarding RTCP >>> Source Description (SDES) packets. The SRC generates its own > RTCP >>> Sender and Receiver reports toward the associated UAs and SRS. > The >>> use of SRTP between the SRC and the SRS for the RS is independent > of >>> the use of SRTP between the UAs and SRC for the CS. >>> >>> If packet loss occurs from the UA to the SRC, the SRC SHOULD > detect >>> and attempt to recover from the loss. If packet loss occurs from >>> the >>> SRC to the SRS, the SRS SHOULD detect and attempt to recover from >>> the >>> loss. >>> >>> 4.3. SRC acting as an RTP Endpoint >>> >>> The case of the SRC acting as an RTP endpoint, as defined in >>> [RFC3550], is similar to the mixer case, except that the RTP > session >>> between the SRC and the SRS is considered completely independent >>> from >>> the RTP session that is part of the CS. The SRC can, but need > not, >>> mix RTP streams from different participants prior to sending to > the >>> SRS. RTCP between the SRC and the SRS is completely independent > of >>> RTCP on the CS. The use of SRTP between the SRC and the SRS is >>> independent of the use of SRTP on the CS. >>> >>> If packet loss occurs from the UA to the SRC, the SRC SHOULD > detect >>> and attempt to recover from the loss. If packet loss occurs from >>> the >>> SRC to the SRS, the SRS SHOULD detect and attempt to recover from >>> the >>> loss. >> >> Rest looks ok to me. In general we need some text on what UA/SRC MAY > do on receiving these reports. We >> can simply mention that based on policy a UA/SRC may act on the > reports. > > What I was attempting to convey is that when acting as a translator, the > SRC does not really do anything based on the reports. Acting on the > reports is up to the UA. When acting as a mixer or endpoint, the SRC can > and should act upon the reports. > I can add something about the UA acting on them based on policy. This > would be true for all cases, independent of the RTP role used by the > SRC. I think that is not very useful and is outside of the > recommendations described here. Let me know if you still think adding it > to each case provides value, and if so, I can add it. > > Cheers, > Charles > >> Regards, >> Ram >> >>> ------------------ >>> >>> Comment on this are greatly appreciated. >>> Thanks, >>> Charles >>> _______________________________________________ >>> 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 andrew.hutton@siemens-enterprise.com Fri Oct 21 12:11: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 7DBF221F8B23 for ; Fri, 21 Oct 2011 12:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvuFEAiWqgHb for ; Fri, 21 Oct 2011 12:11:42 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E868D21F8B1C for ; Fri, 21 Oct 2011 12:11:41 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 264D623F053A for ; Fri, 21 Oct 2011 21:11:40 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 21 Oct 2011 21:11:40 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 21 Oct 2011 21:11:38 +0200 Thread-Topic: SIPREC IETF82 - Preparation & Agenda. Thread-Index: AcyQJUHxCFbLknpMRJesuENTWch7LQ== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E311F7EEF2FD@MCHP058A.global-ad.net> 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] SIPREC IETF82 - Preparation & Agenda. 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, 21 Oct 2011 19:11:42 -0000 Hi All, IETF 82 is fast approaching. The cut-off date for draft submission is the 31st of October which is only = just over one week away so please can editors make sure they submit updates= before that if they need to do so. It does not look like we will be able to get draft-eckel-siprec-rtp-rec inc= orporated in to the protocol draft in time for IETF82. We also need to think about the agenda for IETF82 and I assume we will need= presentations on outstanding issues relating to the following. 1. http://tools.ietf.org/html/draft-ietf-siprec-architecture which we need = to get to WGLC before too long. 2. http://tools.ietf.org/html/draft-ietf-siprec-protocol 3. http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec 4. http://tools.ietf.org/html/draft-ietf-siprec-metadata It would be helpful if the editors could make sure outstanding issues/quest= ions are placed in the tracker. Regards Andy (As Co-Chair). From eckelcu@cisco.com Mon Oct 24 11:00:46 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 E09AF21F8B73 for ; Mon, 24 Oct 2011 11:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSUSQBU7Wks8 for ; Mon, 24 Oct 2011 11:00:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA1921F8B70 for ; Mon, 24 Oct 2011 11:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=11653; q=dns/txt; s=iport; t=1319479245; x=1320688845; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=iEKbPRLWEIgiNCnsp2cMqXW7u+SdjIERxxdAJwYnfSo=; b=fYDRVyrQkq6EXT/Y7eQvykL1as4dDQJSpshFw4wRtKqD9h21PtLlD4lr WpNEuptZWRW3hEEkNL5s2nwwBHAuim/ZTMlqwtR9rWlbax9XPq+FCXYUs zq2UN/3agalBlEK2LKepnsmtqUJYU0DLtGf2oaaLKTPwLPbheiG1y17c/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroAAAGnpU6tJXG9/2dsb2JhbABDDplDj0GBBYFuAQEBAQMBAQEPAR0KNBcEAgEIDgMEAQEBCgYFEgEGASYfCQgBAQQBEggah2aVWQGeGQSFJII7YQSIBpE4i29X X-IronPort-AV: E=Sophos;i="4.69,399,1315180800"; d="scan'208";a="30612620" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 24 Oct 2011 18:00:44 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9OI0hX6027211; Mon, 24 Oct 2011 18:00:44 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); Mon, 24 Oct 2011 11:00:35 -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, 24 Oct 2011 11:00:34 -0700 Message-ID: In-Reply-To: <4E9F1521.5020409@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AcyOi/FcR9temBEWTSeimMvsIY87zwD6fxvQ References: <35BCE99A477D6A4986FB2216D8CF2CFD081A6EB0@XMB-BGL-417.cisco.com> <4E9F1521.5020409@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 24 Oct 2011 18:00:35.0560 (UTC) FILETIME=[D47C1680:01CC9276] Subject: Re: [siprec] proposed text for dealing with packet loss 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, 24 Oct 2011 18:00:47 -0000 Hi Paul, I essentially agree with your analysis and conclusion. The main reason I see for discussing the translator models is to make people aware of the limitations of those models such that they use them only in cases in which they think those limitations will be acceptable. For example, if the SRC is collocated with the UA, it may be acceptable to have the SRC function an RTP translator. Or in an enterprise environment in which there is a set of homogenous UAs, the SRC may be able to act as a translator on behalf of a set of UAs that knows how to deal with the resulting RTP flows. While we could rule out, or not recommend, such models in general, I am thinking it is best to describe them and let implementers make an informed choice. But I am certainly open to other suggestions. Cheers, Charles=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, October 19, 2011 11:21 AM > To: siprec@ietf.org > Subject: Re: [siprec] proposed text for dealing with packet loss >=20 > Looking at this discussion, I wonder if it ever makes sense for the SRC > to act as a translator? It seems that doing so will result in presenting > the CS participants with information that would be confusing to them. > Perhaps the SRC should always be a mixer or endpoint. >=20 > Thanks, > Paul >=20 > On 10/19/11 1:36 PM, Charles Eckel (eckelcu) wrote: > > Hi Ram, > > > > Thanks for reviewing. Please see inline. > > > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) > >> Sent: Tuesday, October 18, 2011 11:56 PM > >> To: Charles Eckel (eckelcu); siprec@ietf.org > >> Subject: RE: [siprec] proposed text for dealing with packet loss > >> > >> Hi Charles, > >> > >> Sorry for delay in reviewing this. Here are my comments/questions on > > the proposed text. > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Charles Eckel (eckelcu) > >>> Sent: Saturday, October 08, 2011 3:56 AM > >>> To: siprec@ietf.org > >>> Subject: [siprec] proposed text for dealing with packet loss > >>> > >>> During the last interim meeting, I accepted an action item to > > propose > >>> some text for draft-eckel-siprec-rtp-rec regarding SRC handling of > >>> packet loss. Here is text for the various RTP models with the > > proposed > >>> text added (look for "If packet loss occurs" within each model): > >>> > >>> ---------------- > >>> > >>> 4.1. SRC acting as an RTP Translator > >>> > >>> The SRC may act as a translator, as defined in [RFC3550]. A > >>> defining > >>> characteristic of a translator is that it forwards RTP packets > > with > >>> their SSRC identifier intact. There are two types of > > translators, > >>> one that simply forwards, and another that performs transcoding > >>> (e.g., from one codec to another) in addition to forwarding. > >>> > >>> 4.1.1. Forwarding Translator > >>> > >>> When acting as a forwarding translator, RTP received as separate > >>> streams from different sources (e.g., from different UAs with > >>> different SSRCs) cannot be mixed by the SRC and MUST be sent > >>> separately to the SRS. All RTCP reports MUST be passed by the > > SRC > >>> between the UAs and the SRS, such that the UAs and SRS are able > > to > >>> detect any SSRC collisions. > >>> > >>> RTCP Sender Reports generated by a UA sending a stream MUST be > >>> forwarded to the SRS. RTCP Receiver Reports generated by the SRS > >>> MUST be forwarded to the relevant UA. > >> > >> Are you suggesting to replicate/fork the RTCP sender reports generated > > by an UAs (which may not be > >> SRC) in CS as is to SRS ? > > > > Yes. > > > > I wonder if that is right since some of the fields may not be needed. > > For > >> e.g. RTCP sender report may have zero or more reception report blocks. > > This has information about the > >> number of other sources heard by this sender since the last report. I > > guess this may not make sense to > >> SRS. > > > > True. If it is deemed important to do something more sophisticated, the > > SRC implementer may want to consider acting as a mixer instead. > > > >> > >> Also in case of RTCP receiver report from SRS I see you mentioned that > > SRC forwards to UA. what action > >> do we want the UA to take ? Should we leave it as a policy at the UA ? > > May be we need to add some text > >> on this. Note that the UA here may be receiving two receiver report ( > > one from destination say UA2 who > >> is in CS and other from SRS). > > > > I was trying to avoid putting any requirements on the UA. Here as well, > > I see it a reason for the SRC to consider acting as a mixer. > > > >>> > >>> If SRTP is used on both the CS and the RS, decryption and/or re- > >>> encryption may occur. For example, if different keys are used, > > it > >>> will occur. If the same keys are used, it need not occur. > >>> > >>> If packet loss occurs, either from the UA to the SRC or from the > > SRC > >>> to the SRS, the SRS SHOULD detect and attempt to recover from the > >>> loss. The SRC does not play a role in this other than forwarding > >>> the > >>> associated RTP and RTCP packets. > >>> > >>> 4.1.2. Transcoding Translator > >>> > >>> When acting as a transcoding translator, an SRC MAY perform > >>> transcoding (e.g., from one codec to another), and this may > > result > >>> in > >>> a different rate of packets between what the SRC receives and > > what > >>> the sends. As when acting as a forwarding translator, RTP > > received > >>> as separate streams from different sources (e.g., from different > > UAs > >>> with different SSRCs) cannot be mixed by the SRC and MUST be sent > >>> separately to the SRS. All RTCP reports MUST passed by the SRC > >>> between the UAs and the SRS, such the UAs and SRS they are able > > to > >>> detect any SSRC collisions. > >>> > >>> RTCP Sender Reports generated by a UA sending a stream MUST be > >>> forwarded to the SRS. RTCP Receiver Reports generated by the SRS > >>> MUST be forwarded to the relevant UA. > >> > >> Why do we need to forward the RTCP reports from SRS back to UA here ? > > In this case the SRC is acting > >> as an endpoint terminating and re-originating the media by doing > > transcoding. So the RTCP receiver > >> report are for the packets originated by the transcoder. > > > > The SRC is not originating packets in this case, it is simply altering > > them as it they pass through it. What it needs to do is make sure that > > it accounts for the changes in makes such that the RTCP information is > > consistent with any changes it makes in the process. If the SRC wants to > > originate packets, it should consider the endpoint model. > > > > > >> The SRC may need to > >>> manipulate > >>> the RTCP Receiver Reports to take account of any transcoding that > >>> has > >>> taken place. > >>> > >>> If SRTP is used on both the CS and the RS, decryption and/or re- > >>> encryption may occur. For example, if different keys are used, > > it > >>> will occur. If the same keys are used, it need not occur. > >>> > >>> If packet loss occurs, either from the UA to the SRC or from the > > SRC > >>> to the SRS, the SRS SHOULD detect and attempt to recover from the > >>> loss. The SRC does not play a role in this other than forwarding > >>> the > >>> associated RTP and RTCP packets. > >>> > >>> 4.2. SRC acting as an RTP Mixer > >>> > >>> In the case of the SRC acting as a RTP mixer, as defined in > >>> [RFC3550], the SRC combines RTP streams from different UA and > > sends > >>> them towards the SRS using its own SSRC. The SSRCs from the > >>> contributing UA SHOULD be conveyed as CSRCs identifiers within > > this > >>> stream. The SRC may make timing adjustments among the received > >>> streams and generate its own timing on the stream sent to the > > SRS. > >>> Optionally an SRC acting as a mixer can perform transcoding, and > > can > >>> even cope with different codings received from different UAs. > > RTCP > >>> Sender Reports and Receiver Reports are not forwarded by an SRC > >>> acting as mixer, but there are requirements for forwarding RTCP > >>> Source Description (SDES) packets. The SRC generates its own > > RTCP > >>> Sender and Receiver reports toward the associated UAs and SRS. > > The > >>> use of SRTP between the SRC and the SRS for the RS is independent > > of > >>> the use of SRTP between the UAs and SRC for the CS. > >>> > >>> If packet loss occurs from the UA to the SRC, the SRC SHOULD > > detect > >>> and attempt to recover from the loss. If packet loss occurs from > >>> the > >>> SRC to the SRS, the SRS SHOULD detect and attempt to recover from > >>> the > >>> loss. > >>> > >>> 4.3. SRC acting as an RTP Endpoint > >>> > >>> The case of the SRC acting as an RTP endpoint, as defined in > >>> [RFC3550], is similar to the mixer case, except that the RTP > > session > >>> between the SRC and the SRS is considered completely independent > >>> from > >>> the RTP session that is part of the CS. The SRC can, but need > > not, > >>> mix RTP streams from different participants prior to sending to > > the > >>> SRS. RTCP between the SRC and the SRS is completely independent > > of > >>> RTCP on the CS. The use of SRTP between the SRC and the SRS is > >>> independent of the use of SRTP on the CS. > >>> > >>> If packet loss occurs from the UA to the SRC, the SRC SHOULD > > detect > >>> and attempt to recover from the loss. If packet loss occurs from > >>> the > >>> SRC to the SRS, the SRS SHOULD detect and attempt to recover from > >>> the > >>> loss. > >> > >> Rest looks ok to me. In general we need some text on what UA/SRC MAY > > do on receiving these reports. We > >> can simply mention that based on policy a UA/SRC may act on the > > reports. > > > > What I was attempting to convey is that when acting as a translator, the > > SRC does not really do anything based on the reports. Acting on the > > reports is up to the UA. When acting as a mixer or endpoint, the SRC can > > and should act upon the reports. > > I can add something about the UA acting on them based on policy. This > > would be true for all cases, independent of the RTP role used by the > > SRC. I think that is not very useful and is outside of the > > recommendations described here. Let me know if you still think adding it > > to each case provides value, and if so, I can add it. > > > > Cheers, > > Charles > > > >> Regards, > >> Ram > >> > >>> ------------------ > >>> > >>> Comment on this are greatly appreciated. > >>> Thanks, > >>> Charles > >>> _______________________________________________ > >>> 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 > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Mon Oct 24 12:37: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 180A811E80FE for ; Mon, 24 Oct 2011 12:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFkugzF5o5i5 for ; Mon, 24 Oct 2011 12:37:22 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id BFBAD11E80FD for ; Mon, 24 Oct 2011 12:37:21 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta10.westchester.pa.mail.comcast.net with comcast id oiqv1h0061vXlb85AjdNhm; Mon, 24 Oct 2011 19:37:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.westchester.pa.mail.comcast.net with comcast id ojdM1h01C0tdiYw3djdMAM; Mon, 24 Oct 2011 19:37:22 +0000 Message-ID: <4EA5BE6F.6050104@alum.mit.edu> Date: Mon, 24 Oct 2011 15:37:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <35BCE99A477D6A4986FB2216D8CF2CFD081A6EB0@XMB-BGL-417.cisco.com> <4E9F1521.5020409@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] proposed text for dealing with packet loss 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, 24 Oct 2011 19:37:23 -0000 On 10/24/11 2:00 PM, Charles Eckel (eckelcu) wrote: > Hi Paul, > > I essentially agree with your analysis and conclusion. The main reason I > see for discussing the translator models is to make people aware of the > limitations of those models such that they use them only in cases in > which they think those limitations will be acceptable. For example, if > the SRC is collocated with the UA, it may be acceptable to have the SRC > function an RTP translator. Or in an enterprise environment in which > there is a set of homogenous UAs, the SRC may be able to act as a > translator on behalf of a set of UAs that knows how to deal with the > resulting RTP flows. > While we could rule out, or not recommend, such models in general, I am > thinking it is best to describe them and let implementers make an > informed choice. But I am certainly open to other suggestions. I agree with your thinking here. I don't think we need to ban this - just making it clear what the implications are should be sufficient. Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat >> Sent: Wednesday, October 19, 2011 11:21 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] proposed text for dealing with packet loss >> >> Looking at this discussion, I wonder if it ever makes sense for the > SRC >> to act as a translator? It seems that doing so will result in > presenting >> the CS participants with information that would be confusing to them. >> Perhaps the SRC should always be a mixer or endpoint. >> >> Thanks, >> Paul >> >> On 10/19/11 1:36 PM, Charles Eckel (eckelcu) wrote: >>> Hi Ram, >>> >>> Thanks for reviewing. Please see inline. >>> >>>> -----Original Message----- >>>> From: Ram Mohan R (rmohanr) >>>> Sent: Tuesday, October 18, 2011 11:56 PM >>>> To: Charles Eckel (eckelcu); siprec@ietf.org >>>> Subject: RE: [siprec] proposed text for dealing with packet loss >>>> >>>> Hi Charles, >>>> >>>> Sorry for delay in reviewing this. Here are my comments/questions > on >>> the proposed text. >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Charles Eckel (eckelcu) >>>>> Sent: Saturday, October 08, 2011 3:56 AM >>>>> To: siprec@ietf.org >>>>> Subject: [siprec] proposed text for dealing with packet loss >>>>> >>>>> During the last interim meeting, I accepted an action item to >>> propose >>>>> some text for draft-eckel-siprec-rtp-rec regarding SRC handling of >>>>> packet loss. Here is text for the various RTP models with the >>> proposed >>>>> text added (look for "If packet loss occurs" within each model): >>>>> >>>>> ---------------- >>>>> >>>>> 4.1. SRC acting as an RTP Translator >>>>> >>>>> The SRC may act as a translator, as defined in [RFC3550]. A >>>>> defining >>>>> characteristic of a translator is that it forwards RTP packets >>> with >>>>> their SSRC identifier intact. There are two types of >>> translators, >>>>> one that simply forwards, and another that performs > transcoding >>>>> (e.g., from one codec to another) in addition to forwarding. >>>>> >>>>> 4.1.1. Forwarding Translator >>>>> >>>>> When acting as a forwarding translator, RTP received as > separate >>>>> streams from different sources (e.g., from different UAs with >>>>> different SSRCs) cannot be mixed by the SRC and MUST be sent >>>>> separately to the SRS. All RTCP reports MUST be passed by the >>> SRC >>>>> between the UAs and the SRS, such that the UAs and SRS are > able >>> to >>>>> detect any SSRC collisions. >>>>> >>>>> RTCP Sender Reports generated by a UA sending a stream MUST be >>>>> forwarded to the SRS. RTCP Receiver Reports generated by the > SRS >>>>> MUST be forwarded to the relevant UA. >>>> >>>> Are you suggesting to replicate/fork the RTCP sender reports > generated >>> by an UAs (which may not be >>>> SRC) in CS as is to SRS ? >>> >>> Yes. >>> >>> I wonder if that is right since some of the fields may not be > needed. >>> For >>>> e.g. RTCP sender report may have zero or more reception report > blocks. >>> This has information about the >>>> number of other sources heard by this sender since the last report. > I >>> guess this may not make sense to >>>> SRS. >>> >>> True. If it is deemed important to do something more sophisticated, > the >>> SRC implementer may want to consider acting as a mixer instead. >>> >>>> >>>> Also in case of RTCP receiver report from SRS I see you mentioned > that >>> SRC forwards to UA. what action >>>> do we want the UA to take ? Should we leave it as a policy at the > UA ? >>> May be we need to add some text >>>> on this. Note that the UA here may be receiving two receiver report > ( >>> one from destination say UA2 who >>>> is in CS and other from SRS). >>> >>> I was trying to avoid putting any requirements on the UA. Here as > well, >>> I see it a reason for the SRC to consider acting as a mixer. >>> >>>>> >>>>> If SRTP is used on both the CS and the RS, decryption and/or > re- >>>>> encryption may occur. For example, if different keys are > used, >>> it >>>>> will occur. If the same keys are used, it need not occur. >>>>> >>>>> If packet loss occurs, either from the UA to the SRC or from > the >>> SRC >>>>> to the SRS, the SRS SHOULD detect and attempt to recover from > the >>>>> loss. The SRC does not play a role in this other than > forwarding >>>>> the >>>>> associated RTP and RTCP packets. >>>>> >>>>> 4.1.2. Transcoding Translator >>>>> >>>>> When acting as a transcoding translator, an SRC MAY perform >>>>> transcoding (e.g., from one codec to another), and this may >>> result >>>>> in >>>>> a different rate of packets between what the SRC receives and >>> what >>>>> the sends. As when acting as a forwarding translator, RTP >>> received >>>>> as separate streams from different sources (e.g., from > different >>> UAs >>>>> with different SSRCs) cannot be mixed by the SRC and MUST be > sent >>>>> separately to the SRS. All RTCP reports MUST passed by the > SRC >>>>> between the UAs and the SRS, such the UAs and SRS they are > able >>> to >>>>> detect any SSRC collisions. >>>>> >>>>> RTCP Sender Reports generated by a UA sending a stream MUST be >>>>> forwarded to the SRS. RTCP Receiver Reports generated by the > SRS >>>>> MUST be forwarded to the relevant UA. >>>> >>>> Why do we need to forward the RTCP reports from SRS back to UA here > ? >>> In this case the SRC is acting >>>> as an endpoint terminating and re-originating the media by doing >>> transcoding. So the RTCP receiver >>>> report are for the packets originated by the transcoder. >>> >>> The SRC is not originating packets in this case, it is simply > altering >>> them as it they pass through it. What it needs to do is make sure > that >>> it accounts for the changes in makes such that the RTCP information > is >>> consistent with any changes it makes in the process. If the SRC > wants to >>> originate packets, it should consider the endpoint model. >>> >>> >>>> The SRC may need to >>>>> manipulate >>>>> the RTCP Receiver Reports to take account of any transcoding > that >>>>> has >>>>> taken place. >>>>> >>>>> If SRTP is used on both the CS and the RS, decryption and/or > re- >>>>> encryption may occur. For example, if different keys are > used, >>> it >>>>> will occur. If the same keys are used, it need not occur. >>>>> >>>>> If packet loss occurs, either from the UA to the SRC or from > the >>> SRC >>>>> to the SRS, the SRS SHOULD detect and attempt to recover from > the >>>>> loss. The SRC does not play a role in this other than > forwarding >>>>> the >>>>> associated RTP and RTCP packets. >>>>> >>>>> 4.2. SRC acting as an RTP Mixer >>>>> >>>>> In the case of the SRC acting as a RTP mixer, as defined in >>>>> [RFC3550], the SRC combines RTP streams from different UA and >>> sends >>>>> them towards the SRS using its own SSRC. The SSRCs from the >>>>> contributing UA SHOULD be conveyed as CSRCs identifiers within >>> this >>>>> stream. The SRC may make timing adjustments among the > received >>>>> streams and generate its own timing on the stream sent to the >>> SRS. >>>>> Optionally an SRC acting as a mixer can perform transcoding, > and >>> can >>>>> even cope with different codings received from different UAs. >>> RTCP >>>>> Sender Reports and Receiver Reports are not forwarded by an > SRC >>>>> acting as mixer, but there are requirements for forwarding > RTCP >>>>> Source Description (SDES) packets. The SRC generates its own >>> RTCP >>>>> Sender and Receiver reports toward the associated UAs and SRS. >>> The >>>>> use of SRTP between the SRC and the SRS for the RS is > independent >>> of >>>>> the use of SRTP between the UAs and SRC for the CS. >>>>> >>>>> If packet loss occurs from the UA to the SRC, the SRC SHOULD >>> detect >>>>> and attempt to recover from the loss. If packet loss occurs > from >>>>> the >>>>> SRC to the SRS, the SRS SHOULD detect and attempt to recover > from >>>>> the >>>>> loss. >>>>> >>>>> 4.3. SRC acting as an RTP Endpoint >>>>> >>>>> The case of the SRC acting as an RTP endpoint, as defined in >>>>> [RFC3550], is similar to the mixer case, except that the RTP >>> session >>>>> between the SRC and the SRS is considered completely > independent >>>>> from >>>>> the RTP session that is part of the CS. The SRC can, but need >>> not, >>>>> mix RTP streams from different participants prior to sending > to >>> the >>>>> SRS. RTCP between the SRC and the SRS is completely > independent >>> of >>>>> RTCP on the CS. The use of SRTP between the SRC and the SRS > is >>>>> independent of the use of SRTP on the CS. >>>>> >>>>> If packet loss occurs from the UA to the SRC, the SRC SHOULD >>> detect >>>>> and attempt to recover from the loss. If packet loss occurs > from >>>>> the >>>>> SRC to the SRS, the SRS SHOULD detect and attempt to recover > from >>>>> the >>>>> loss. >>>> >>>> Rest looks ok to me. In general we need some text on what UA/SRC > MAY >>> do on receiving these reports. We >>>> can simply mention that based on policy a UA/SRC may act on the >>> reports. >>> >>> What I was attempting to convey is that when acting as a translator, > the >>> SRC does not really do anything based on the reports. Acting on the >>> reports is up to the UA. When acting as a mixer or endpoint, the SRC > can >>> and should act upon the reports. >>> I can add something about the UA acting on them based on policy. > This >>> would be true for all cases, independent of the RTP role used by the >>> SRC. I think that is not very useful and is outside of the >>> recommendations described here. Let me know if you still think > adding it >>> to each case provides value, and if so, I can add it. >>> >>> Cheers, >>> Charles >>> >>>> Regards, >>>> Ram >>>> >>>>> ------------------ >>>>> >>>>> Comment on this are greatly appreciated. >>>>> Thanks, >>>>> Charles >>>>> _______________________________________________ >>>>> 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 HKaplan@acmepacket.com Tue Oct 25 14:52: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 1B5281F0C6B for ; Tue, 25 Oct 2011 14:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiBYrjLBe8CU for ; Tue, 25 Oct 2011 14:52:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 68DD21F0C69 for ; Tue, 25 Oct 2011 14:52:11 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 25 Oct 2011 17:52:10 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 25 Oct 2011 17:52:11 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AQHMk2BYkUpzMAuqqU+j0WkccIsOAw== Date: Tue, 25 Oct 2011 21:52:10 +0000 Message-ID: <954B7A42-F19D-4799-82DF-D7B4196BD596@acmepacket.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD081A6EB0@XMB-BGL-417.cisco.com> <4E9F1521.5020409@alum.mit.edu> In-Reply-To: <4E9F1521.5020409@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <220198C7DA45734A8DB9DBBFDA9E603C@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [siprec] proposed text for dealing with packet loss 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, 25 Oct 2011 21:52:12 -0000 On Oct 19, 2011, at 2:21 PM, Paul Kyzivat wrote: > Looking at this discussion, I wonder if it ever makes sense for the SRC t= o act as a translator? It seems that doing so will result in presenting the= CS participants with information that would be confusing to them. Perhaps = the SRC should always be a mixer or endpoint. >=20 > Thanks, > Paul There are some very real cost/scale benefits to acting as a forwarding-tran= slator, and in practice it works fine today. The SRC translator simply doe= sn't forward the SRS' RTCP reports onto the CS UAs, and they're never aware= of the SRS' existence at an RTP/RTCP layer. -hadriel From HKaplan@acmepacket.com Tue Oct 25 14:58: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 C027D21F858C for ; Tue, 25 Oct 2011 14:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Iq2VntdOfNA for ; Tue, 25 Oct 2011 14:58:21 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 209D421F8564 for ; Tue, 25 Oct 2011 14:58:21 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 25 Oct 2011 17:58:19 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 25 Oct 2011 17:58:20 -0400 From: Hadriel Kaplan To: "Charles Eckel (eckelcu)" Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AQHMk2E0kUpzMAuqqU+j0WkccIsOAw== Date: Tue, 25 Oct 2011 21:58:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <5C0705C92C10F64E849DC0E8554B5B52@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [siprec] proposed text for dealing with packet loss 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, 25 Oct 2011 21:58:21 -0000 Hi Charles, sorry for not responding sooner. :( Comment below... On Oct 7, 2011, at 6:25 PM, Charles Eckel (eckelcu) wrote: > 4.1.1. Forwarding Translator >=20 > When acting as a forwarding translator, RTP received as separate > streams from different sources (e.g., from different UAs with > different SSRCs) cannot be mixed by the SRC and MUST be sent > separately to the SRS. All RTCP reports MUST be passed by the SRC > between the UAs and the SRS, such that the UAs and SRS are able to > detect any SSRC collisions. >=20 > RTCP Sender Reports generated by a UA sending a stream MUST be > forwarded to the SRS. RTCP Receiver Reports generated by the SRS > MUST be forwarded to the relevant UA. Generally we only put "MUST" statements in RFCs if the protocol/mechanism w= ould otherwise break or become insecure. Can you explain what exactly "breaks" if the SRC doesn't forward on the RTC= P reports from an SRS? I know what breaks if a translator doesn't do so fo= r multi-party calls, but this is not a true multi-party call. -hadriel From eckelcu@cisco.com Tue Oct 25 15:13: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 6912311E8083 for ; Tue, 25 Oct 2011 15:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lTAf+U0+Msp for ; Tue, 25 Oct 2011 15:13:05 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9145D11E807F for ; Tue, 25 Oct 2011 15:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2105; q=dns/txt; s=iport; t=1319580785; x=1320790385; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sTmboYmUd9gyaXaIsP3TJZ7Jsf9fx7u4eZE62Nt1kek=; b=K8edznFv+hen2Tzzm1Gd0AVUiVZcl8bUTLgw29UDlvqGG/CAQcWe28AC /b5+4mO5C4p+IgFUwSnOjA5z9gwSPiE2zaP0EAKUDBuCMb0bthnZS5pJ+ oA1gglF0vLOWwAcK/bbnNJmNx2fn5fJQSmStOZeVTV5KSSOtRi4kLF55W M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAALQzp06rRDoJ/2dsb2JhbABCmWCPQ4EFgW4BAQEDARIBHQo/DAQCAQgOAwQBAQEKBhcBBgFFCQgCBBMIGodelXABnlyHdWEEiAaROYxJ X-IronPort-AV: E=Sophos;i="4.69,406,1315180800"; d="scan'208";a="10252159" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 25 Oct 2011 22:13:05 +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 p9PMD2fi025705; Tue, 25 Oct 2011 22:13: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, 25 Oct 2011 15:13: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, 25 Oct 2011 15:13:03 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AQHMk2E0kUpzMAuqqU+j0WkccIsOA5WNnQ0Q References: From: "Charles Eckel (eckelcu)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 25 Oct 2011 22:13:04.0928 (UTC) FILETIME=[449FF200:01CC9363] Cc: siprec@ietf.org Subject: Re: [siprec] proposed text for dealing with packet loss 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, 25 Oct 2011 22:13:06 -0000 Please see inline. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Tuesday, October 25, 2011 2:58 PM > To: Charles Eckel (eckelcu) > Cc: > Subject: Re: [siprec] proposed text for dealing with packet loss >=20 > Hi Charles, > sorry for not responding sooner. :( > Comment below... No worries - better now than later, or never. >=20 > On Oct 7, 2011, at 6:25 PM, Charles Eckel (eckelcu) wrote: >=20 > > 4.1.1. Forwarding Translator > > > > When acting as a forwarding translator, RTP received as separate > > streams from different sources (e.g., from different UAs with > > different SSRCs) cannot be mixed by the SRC and MUST be sent > > separately to the SRS. All RTCP reports MUST be passed by the SRC > > between the UAs and the SRS, such that the UAs and SRS are able to > > detect any SSRC collisions. > > > > RTCP Sender Reports generated by a UA sending a stream MUST be > > forwarded to the SRS. RTCP Receiver Reports generated by the SRS > > MUST be forwarded to the relevant UA. >=20 >=20 > Generally we only put "MUST" statements in RFCs if the protocol/mechanism would otherwise break or > become insecure. > Can you explain what exactly "breaks" if the SRC doesn't forward on the RTCP reports from an SRS? I > know what breaks if a translator doesn't do so for multi-party calls, but this is not a true multi- > party call. >=20 > -hadriel If the SRC does not forward the RTCP reports from the SRS, the UA either: 1) receives no RTCP reports, in the case where is the SRS is the only recipient of the packets 2) receives RTCP reports from receivers other than the SRS receivers but does not receive any reports from the SRS. In case (1), the UA is not able to help in the recovery of media related issues between the UA and the SRS. In case (2), the UA may help in the recovery of media related issues between the UA and SRC (assuming another recipient's reports indicated the issue), but not those between the SRC and the SRS. Cheers, Charles From pkyzivat@alum.mit.edu Tue Oct 25 18:07: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 3962221F8B08 for ; Tue, 25 Oct 2011 18:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItqFPGlgFApN for ; Tue, 25 Oct 2011 18:07:37 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 9952A21F8B06 for ; Tue, 25 Oct 2011 18:07:37 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta09.westchester.pa.mail.comcast.net with comcast id pCtG1h00217dt5G59D7d97; Wed, 26 Oct 2011 01:07:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta13.westchester.pa.mail.comcast.net with comcast id pD7b1h01S0tdiYw3ZD7cs7; Wed, 26 Oct 2011 01:07:37 +0000 Message-ID: <4EA75D56.1080100@alum.mit.edu> Date: Tue, 25 Oct 2011 21:07:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <35BCE99A477D6A4986FB2216D8CF2CFD081A6EB0@XMB-BGL-417.cisco.com> <4E9F1521.5020409@alum.mit.edu> <954B7A42-F19D-4799-82DF-D7B4196BD596@acmepacket.com> In-Reply-To: <954B7A42-F19D-4799-82DF-D7B4196BD596@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [siprec] proposed text for dealing with packet loss 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, 26 Oct 2011 01:07:39 -0000 On 10/25/11 5:52 PM, Hadriel Kaplan wrote: > > On Oct 19, 2011, at 2:21 PM, Paul Kyzivat wrote: > >> Looking at this discussion, I wonder if it ever makes sense for the SRC to act as a translator? It seems that doing so will result in presenting the CS participants with information that would be confusing to them. Perhaps the SRC should always be a mixer or endpoint. >> >> Thanks, >> Paul > > There are some very real cost/scale benefits to acting as a forwarding-translator, and in practice it works fine today. The SRC translator simply doesn't forward the SRS' RTCP reports onto the CS UAs, and they're never aware of the SRS' existence at an RTP/RTCP layer. I'm a neophyte re RTP, so take what I say with a grain of salt... IIUC, forwarding the RTCP is obligatory for a translator. If it doesn't do it, it isn't behaving as a translator. (A quick look at 3550 tells me the behavior is indeed MUST strength.) While not conforming to that may "work" in some sense, I don't see how we can advocate that. And I see that Charles already commented. Thanks, Paul From internet-drafts@ietf.org Wed Oct 26 09:06: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 3204E21F853B; Wed, 26 Oct 2011 09:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qso68Paf-B1U; Wed, 26 Oct 2011 09:06:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B7121F84D6; Wed, 26 Oct 2011 09:06:21 -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.61 Message-ID: <20111026160621.10921.71789.idtracker@ietfa.amsl.com> Date: Wed, 26 Oct 2011 09:06:21 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-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: Wed, 26 Oct 2011 16:06:22 -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 Recording Protocol Author(s) : Leon Portman Henry Lum Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-01.txt Pages : 26 Date : 2011-10-26 This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a communication session to a recording device. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-protocol-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-protocol-01.txt From Henry.Lum@alcatel-lucent.com Wed Oct 26 09:10: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 7957221F84D6 for ; Wed, 26 Oct 2011 09:10:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfMzMD4V7rc2 for ; Wed, 26 Oct 2011 09:10:26 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 92BE121F8AB0 for ; Wed, 26 Oct 2011 09:10:23 -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 p9QG9ZVV002556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 26 Oct 2011 11:09:35 -0500 (CDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9QG9Xwa015261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Oct 2011 11:09:34 -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 p9QG9W2i014453 for ; Wed, 26 Oct 2011 09:09:32 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Oct 2011 09:09:32 -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, 26 Oct 2011 09:09:31 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7407BAA8DF@NAHALD.us.int.genesyslab.com> In-Reply-To: <20111026160621.10921.71789.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-01.txt Thread-Index: AcyT+TgVpd1VnMW6SdarPht6PCKvYwAAAyfg References: <20111026160621.10921.71789.idtracker@ietfa.amsl.com> From: "Henry Lum" To: X-OriginalArrivalTime: 26 Oct 2011 16:09:32.0468 (UTC) FILETIME=[A5CC6F40:01CC93F9] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-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: Wed, 26 Oct 2011 16:10:27 -0000 Hi, I restructured the document as per the consensus call, and also added a section (9) to discuss persistent recording. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: October-26-11 12:06 PM > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-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 Recording Protocol > Author(s) : Leon Portman > Henry Lum > Alan Johnston > Andrew Hutton > Filename : draft-ietf-siprec-protocol-01.txt > Pages : 26 > Date : 2011-10-26 >=20 > This document specifies the use of the Session Initiation Protocol > (SIP), the Session Description Protocol (SDP), and the Real Time > Protocol (RTP) for delivering real-time media and metadata from a > communication session to a recording device. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-siprec-protocol-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-protocol-01.txt > _______________________________________________ > 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 HKaplan@acmepacket.com Wed Oct 26 15:01: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 2A51A21F85B8 for ; Wed, 26 Oct 2011 15:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bRiSu15SVLM for ; Wed, 26 Oct 2011 15:01:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 23C5F21F85AA for ; Wed, 26 Oct 2011 15:01:45 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 26 Oct 2011 18:01:41 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 26 Oct 2011 18:01:42 -0400 From: Hadriel Kaplan To: "Charles Eckel (eckelcu)" Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AQHMlCrXyyj2zm2fFUyYADHXk3O11g== Date: Wed, 26 Oct 2011 22:01:41 +0000 Message-ID: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <336AFB735657524C8A76A900A274028B@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [siprec] proposed text for dealing with packet loss 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, 26 Oct 2011 22:01:47 -0000 Howdy, Sorry for the length of this email - it's a lot of text for a one-word chan= ge request. :) On Oct 25, 2011, at 6:13 PM, Charles Eckel (eckelcu) wrote: > If the SRC does not forward the RTCP reports from the SRS, the UA > either: > 1) receives no RTCP reports, in the case where is the SRS is the only > recipient of the packets The _other_ UA in the CS is the receiver of RTP packets, and generates RTCP= . In other words, both real UAs in the CS generate RTCP which gets to each= other. Though of course there are UAs in the real-world which generate no RTCP to = begin with, so in that case you wont get any - but that just provides examp= les that doing so doesn't necessarily break RTP, because calls work without= the RTCP today. (I should note I'm talking about audio, not video) > 2) receives RTCP reports from receivers other than the SRS receivers but > does not receive any reports from the SRS. >=20 > In case (1), the UA is not able to help in the recovery of media related > issues between the UA and the SRS. > In case (2), the UA may help in the recovery of media related issues > between the UA and SRC (assuming another recipient's reports indicated > the issue), but not those between the SRC and the SRS. Right, so assume the following diagram: +--------+ +--------+ +--------+ | | A | | B | | | UA-A |------| SRC |------| UA-B | | | | | | | +--------+ +--------+ +--------+ || C || D || +--------+ | | | SRS | | | +--------+ It is true that if C/D is congested, then for certain codecs the RTCP recei= ver reports can help improve the call quality to the SRS, but reduce the ca= ll quality for UA-A and UA-B. Frankly I think this is a corner case in the= real world, because I would expect people to (a) be able to control/manage= the SRC-SRS path to not be congested, and (b) in some cases even prefer to= keep the call quality of A-B regardless of the SRS's recording quality. I= recognize (b) is only for some folks and not others, but it is a real use-= case, and one whereby forwarding on the RTCP reports would be a bad thing. It's also true that if A is congested, then for certain codecs the SRS can = help improve the call quality from UA-A to UA-B if UA-B does not itself gen= erate RTCP reports; and vice-versa if B is congested, then for certain code= cs the SRS can help improve the call quality from UA-B to UA-A if UA-A does= not itself generate RTCP reports. BUT for other codecs (like G.711 which I believe is popular), such RTCP rec= eiver reports will not improve quality, because there isn't much you can do= to improve it in the send direction. (and frankly if both UA-A and UA-B s= upport dynamic codecs, then the odds are they both support RTCP) So... since (1) there's a use-case where forwarding the RTCP reports from S= RS is not what the customer wants, and (2) there're popular codecs which do= n't improve with it regardless, I propose we change this: > RTCP Receiver Reports generated by the SRS > MUST be forwarded to the relevant UA. To this: > RTCP Receiver Reports generated by the SRS > SHOULD be forwarded to the relevant UA. -hadriel From john.r.elwell@gmail.com Thu Oct 27 01:33: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 02C9321F85A1 for ; Thu, 27 Oct 2011 01:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRVRV4twNLKw for ; Thu, 27 Oct 2011 01:33:21 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9169421F858C for ; Thu, 27 Oct 2011 01:33:20 -0700 (PDT) Received: by wyh22 with SMTP id 22so2990303wyh.31 for ; Thu, 27 Oct 2011 01:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=C0PJPZhU2ljPbp3hQUIUWPxnjiWRYJ/Prv7H0GyDr8c=; b=IEx4XjXJJ/5oEDbGZtr8IRCZOWtE3uDwybCm7E/paszXZ1YGGGKOkvIhLp7r/H2AN5 FtcjIOH4Wp0r4sNdkNLHlpDQUrPHPGAsOndKbvtPe+gDPZjmsh9+iyescOYSaFPGkuaO DNqkwgEjek3XuTaPQwzkqaw61yTh2MxOOzoxo= Received: by 10.227.202.143 with SMTP id fe15mr14945084wbb.25.1319704397811; Thu, 27 Oct 2011 01:33:17 -0700 (PDT) Received: from JohnsComputer (cpc1-clif8-2-0-cust418.12-4.cable.virginmedia.com. [82.25.209.163]) by mx.google.com with ESMTPS id fr4sm7925408wbb.0.2011.10.27.01.33.15 (version=SSLv3 cipher=OTHER); Thu, 27 Oct 2011 01:33:16 -0700 (PDT) Message-ID: From: "John Elwell" To: "Ram Mohan R \(rmohanr\)" , "Paul Kyzivat" , References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com> Date: Thu, 27 Oct 2011 09:33:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: Re: [siprec] Need Inputs: How to represent attributes ofassociation in Metadata Model and 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, 27 Oct 2011 08:33:22 -0000 Approach 2 seems reasonable. Could we say that an association is implicitly deleted (gains a dissociate time) as soon as one of the associated elements is deleted (gains a dissociate time)? This would reduce the on-the wire document size for both partial and full metadata in some circumstances (e.g., conference termination by the focus). John ----- Original Message ----- From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat" ; Sent: Friday, October 14, 2011 4:59 AM Subject: Re: [siprec] Need Inputs: How to represent attributes ofassociation in Metadata Model and in XML ? > Thanks Paul for your comments. I also prefer approach 2 as mentioned > below in this thread. > I will wait to hear for comments/opinion from others. > > Ram > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Thursday, October 13, 2011 10:48 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Need Inputs: How to represent attributes of >> association in Metadata Model and in XML ? >> >> I like approach 2, as Ram has shown it. It deals with the problems > John >> raised with the others. >> >> I didn't follow John's arithmetic on this one, using his 20 party >> conference example. As I count that, there are 21 participants when > you >> include the focus. Each of the 20 has two stream/participant >> associations with the focus, for a total of 40. (The association is >> bidirectional. I can only get to 80 by assuming we had to represent an >> association in each direction.) And each has two ids, each of which is >> also the id of a stream or participant. So there are really only 23 >> distinct ids that need to be assigned for this. (One for each of the > 21 >> participants, and one for each of the two streams.) >> >> The 40 associations, each carrying two ids, is still kind of a lot if >> its sent all at once. But when starting up a conference they will >> probably be added gradually as each participant joins. Same at the end >> if they drop off individually. But it could be a bunch together if the >> conference is forcibly dropped by the focus. But it does minimize what >> is sent when things happen incrementally. >> >> There may be some optimizations that can be done - e.g. a sort of >> "wildcard" for one of the the two ids in the association class. E.g. >> >> > participant="*" >> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> 2010-12-16T23:41:07Z >> >> >> (I'm not advocating that particular syntax. Its just something to make >> the point.) >> >> Thanks, >> Paul >> >> >> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: >> > My bad(typo) while sending the example. The correct partial update I >> > intended to send is: >> > >> > > > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> > 2010-12-16T23:41:07Z >> > >> > >> > This is inline with approach 2 where in each association XML element >> > will have the IDs of the related associated elements. >> > >> > Ram >> > >> >> -----Original Message----- >> >> From: Leon Portman [mailto:Leon.Portman@nice.com] >> >> Sent: Wednesday, October 12, 2011 2:24 PM >> >> To: Ram Mohan R (rmohanr); siprec@ietf.org >> >> Cc: Ofir Roth >> >> Subject: RE: Need Inputs: How to represent attributes of > association >> > in >> >> Metadata Model and in XML ? >> >> >> >> We do prefer to receive related elements as well, it makes >> >> implementation much easier. >> >> At least we should get relevant IDs. For example below, SRC >> should >> >> also send ParticipantId >> >> >> >> -----Original Message----- >> >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> >> Sent: Wednesday, October 12, 2011 10:52 AM >> >> To: Leon Portman; siprec@ietf.org >> >> Cc: Ofir Roth >> >> Subject: RE: Need Inputs: How to represent attributes of > association >> > in >> >> Metadata Model and in XML ? >> >> >> >> Leon, >> >> Thanks for your response. One of the adv with approach 2 is we can >> >> indicate only changes in the association without the need to >> > indicating >> >> the elements ( of association). IOW for the below example, if there >> is >> >> a change in participant-stream association I can simply send the >> >> following in partial update: >> >> >> >> >> >> > >> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> >> >> 2010-12-16T23:41:07Z >> >> >> >> >> >> Do you see a need to always indicate the related elements too ? In >> >> which case I see approach 1 as more suitable. >> >> >> >> Thanks, >> >> Ram >> >> >> >>> -----Original Message----- >> >>> From: Leon Portman [mailto:Leon.Portman@nice.com] >> >>> Sent: Wednesday, October 12, 2011 12:55 PM >> >>> To: Ram Mohan R (rmohanr); siprec@ietf.org >> >>> Cc: Ofir Roth >> >>> Subject: RE: Need Inputs: How to represent attributes of >> association >> >>> inmetadata Model and in XML ? >> >>> >> >>> Ram Hi >> >>> >> >>> I am ok with approaches 1 and however I do prefer approach one >> >> because >> >>> it will be easier for SRS to get decode - association is inside >> >>> relevant element. And it is more readable. >> >>> Approach 2 will work as well, however it is important that if > there >> >>> will be a change in association then to send to SRS not only >> updated >> >>> association element but also related elements: for example if >> stream >> >>> was associated to participant and session, send also participant >> and >> >>> session latest state. >> >>> >> >>> Regards >> >>> >> >>> Leon >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >>> Behalf Of Ram Mohan R (rmohanr) >> >>> Sent: Wednesday, October 12, 2011 7:48 AM >> >>> To: siprec@ietf.org >> >>> Subject: [siprec] Need Inputs: How to represent attributes of >> >>> association in metadata Model and in XML ? >> >>> >> >>> (Sorry for lengthy e-mail) >> >>> >> >>> Hi All, >> >>> >> >>> In the last interim we discussed 4 approaches for representing >> >>> attributes of association in XML. >> >>> >> >>> >> >>> Here are some pros/cons for each of them: >> >>> Approach 1: >> >>> ---------- >> >>> Represent the association attribute as a property within one of > the >> >>> associated elements. Example given at http://www.ietf.org/mail- >> >>> archive/web/siprec/current/msg02709.html Does not need another XML >> >>> element and represents the association attributes as capability of >> >> one >> >>> of the association element. >> >>> e.g. >> >>> > >>> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> >>> session="urn:uuid:855a5ded-8420-456d-a70f- >> 6da1eeaeb425"> >> >>> sip:ram@blr.cisco.com >> >>> 2010-12-16T23:41:07Z> >> time> >> >>> TBD >> >>> > >>> stream ="urn:uuid:f3373a7b-4958-4e55-8820- >> >>> d03a191fb76a >> >>> "> >> >>> 2010-12- >> 16T23:41:07Z> >>> time> >> >>> contributing SSRC-1 >> >>> In >> the >> >> above >> >>> example the participant contributes a single streams. For each >> > stream >> >>> the association attribute (participant-stream) is shown with the >> >> stream >> >>> ID nested in. >> >>> >> >>> >> >>> Approach 2: >> >>> ----------- >> >>> In this approach we have a new XML element for every association >> >> class. >> >>> This xml element will NOT have a unique ID instead it references >> the >> >> ID >> >>> of associated elements (shown below). With this approach it is > easy >> >> to >> >>> update as the association class is a separate XML element and not >> >>> property. >> >>> e.g. >> >>> > >>> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> >>> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >> >>> 2010-12-16T23:41:07Z >> >>> TBD >> >>> >> >>> >> >>> > >>> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> >>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> >>> 2010-12-16T23:41:07Z >> >>> contributing SSRC-1 >> >>> >> >>> >> >>> Approach 3 and 4 are in the below e-mail from John. >> >>> Approach 3 defines a new Unique ID for every association XML >> elment. >> >>> Also it creates alias for the other IDs. In the discussions in >> >> interim >> >>> there was no strong support for this approach. >> >>> >> >>> Approach 4 is same as approach 1 where in the association element >> is >> >>> encapsulated in one of the XML elements (to which it is >> > associated). >> >>> In addition to that it also has reference to the elements (alias > of >> >>> IDs) to which the association belongs. >> >>> >> >>> I prefer approach 2 as it is has a separate XML element to >> represent >> >>> the association class. The only difference of this XML element > from >> >>> others is this does not need a unique ID. Instead it references > the >> >> IDs >> >>> of the elements to which the association belongs. >> >>> Since association class is a special class meant to associate >> >> multiple >> >>> classes, I see it ok to have a representation as in approach 2 >> where >> >> in >> >>> the identifier is the concatenation of the classes to which the >> >>> association belongs to. >> >>> >> >>> Please provide your comments on this and also suggest any other >> >>> approaches to represent association classes in XML. >> >>> >> >>> Regards, >> >>> Ram >> >>> >> > _______________________________________________ >> > 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.r.elwell@gmail.com Thu Oct 27 01:42: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 40BC721F84F9 for ; Thu, 27 Oct 2011 01:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUwgEupbomBL for ; Thu, 27 Oct 2011 01:42:32 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E3DFD21F84F5 for ; Thu, 27 Oct 2011 01:42:31 -0700 (PDT) Received: by wyh22 with SMTP id 22so3000056wyh.31 for ; Thu, 27 Oct 2011 01:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=hYETu6FoyoGBRORaNybPmPUVcRzDkqcD0Blq26i3rBo=; b=K5O9GSIpPvBdEWJONCFqctvZlD4KafvpJu8PlZ2GryGSAOuDsHAZQPE0oK6iKqWRFa owipu6ElAGKm4lOw8I88uyCA8Knc4Cf69qdcDeg/AsUJPMBcVf7fC54onX9IN3s5eoL5 zRBl3u8LfIAM0zf7eh4IbT2kJY5/OQ1oHpET0= Received: by 10.216.180.8 with SMTP id i8mr4777952wem.26.1319704950971; Thu, 27 Oct 2011 01:42:30 -0700 (PDT) Received: from JohnsComputer (cpc1-clif8-2-0-cust418.12-4.cable.virginmedia.com. [82.25.209.163]) by mx.google.com with ESMTPS id y38sm7386936wbm.2.2011.10.27.01.42.29 (version=SSLv3 cipher=OTHER); Thu, 27 Oct 2011 01:42:29 -0700 (PDT) Message-ID: <8B7375A5848E459C98E9B29AE41AD731@JohnsComputer> From: "John Elwell" To: "Charles Eckel \(eckelcu\)" , References: Date: Thu, 27 Oct 2011 09:42:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: Re: [siprec] proposed text for dealing with packet loss 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, 27 Oct 2011 08:42:33 -0000 Sorry I am late, but the text looks good to me. Perhaps we also need some text somewhere with a bit more discussion on the implications of using either of the translator models. Essentially a UA participating in a CS should not need to do anything special at the RTP/RTCP level to accommodate the fact that there is a an SRC somewhere on the path. With the endpoint and mixer models this is hidden, but with the translator models it is not hidden. I would hope that a SIPREC-unaware UA would not break as a result of a translator model being used, but would not be required to do anything special other than silently discard RTCP information that is not of relevance. John ----- Original Message ----- From: "Charles Eckel (eckelcu)" To: Sent: Friday, October 14, 2011 6:22 PM Subject: Re: [siprec] proposed text for dealing with packet loss > So far I have not received any comments in this text, good, bad, or > otherwise. As such, I plan to incorporate it as is in the next version > of the RTP recommendations draft. > If you planned to comment but just need more time, let me know asap. > > Cheers, > Charles > >> -----Original Message----- >> From: Charles Eckel (eckelcu) >> Sent: Friday, October 07, 2011 3:26 PM >> To: siprec@ietf.org >> Subject: proposed text for dealing with packet loss >> >> During the last interim meeting, I accepted an action item to propose > some text for draft-eckel- >> siprec-rtp-rec regarding SRC handling of packet loss. Here is text for > the various RTP models with the >> proposed text added (look for "If packet loss occurs" within each > model): >> >> ---------------- >> >> 4.1. SRC acting as an RTP Translator >> >> The SRC may act as a translator, as defined in [RFC3550]. A > defining >> characteristic of a translator is that it forwards RTP packets with >> their SSRC identifier intact. There are two types of translators, >> one that simply forwards, and another that performs transcoding >> (e.g., from one codec to another) in addition to forwarding. >> >> 4.1.1. Forwarding Translator >> >> When acting as a forwarding translator, RTP received as separate >> streams from different sources (e.g., from different UAs with >> different SSRCs) cannot be mixed by the SRC and MUST be sent >> separately to the SRS. All RTCP reports MUST be passed by the SRC >> between the UAs and the SRS, such that the UAs and SRS are able to >> detect any SSRC collisions. >> >> RTCP Sender Reports generated by a UA sending a stream MUST be >> forwarded to the SRS. RTCP Receiver Reports generated by the SRS >> MUST be forwarded to the relevant UA. >> >> If SRTP is used on both the CS and the RS, decryption and/or re- >> encryption may occur. For example, if different keys are used, it >> will occur. If the same keys are used, it need not occur. >> >> If packet loss occurs, either from the UA to the SRC or from the > SRC >> to the SRS, the SRS SHOULD detect and attempt to recover from the >> loss. The SRC does not play a role in this other than forwarding > the >> associated RTP and RTCP packets. >> >> 4.1.2. Transcoding Translator >> >> When acting as a transcoding translator, an SRC MAY perform >> transcoding (e.g., from one codec to another), and this may result > in >> a different rate of packets between what the SRC receives and what >> the sends. As when acting as a forwarding translator, RTP received >> as separate streams from different sources (e.g., from different > UAs >> with different SSRCs) cannot be mixed by the SRC and MUST be sent >> separately to the SRS. All RTCP reports MUST passed by the SRC >> between the UAs and the SRS, such the UAs and SRS they are able to >> detect any SSRC collisions. >> >> RTCP Sender Reports generated by a UA sending a stream MUST be >> forwarded to the SRS. RTCP Receiver Reports generated by the SRS >> MUST be forwarded to the relevant UA. The SRC may need to > manipulate >> the RTCP Receiver Reports to take account of any transcoding that > has >> taken place. >> >> If SRTP is used on both the CS and the RS, decryption and/or re- >> encryption may occur. For example, if different keys are used, it >> will occur. If the same keys are used, it need not occur. >> >> If packet loss occurs, either from the UA to the SRC or from the > SRC >> to the SRS, the SRS SHOULD detect and attempt to recover from the >> loss. The SRC does not play a role in this other than forwarding > the >> associated RTP and RTCP packets. >> >> 4.2. SRC acting as an RTP Mixer >> >> In the case of the SRC acting as a RTP mixer, as defined in >> [RFC3550], the SRC combines RTP streams from different UA and sends >> them towards the SRS using its own SSRC. The SSRCs from the >> contributing UA SHOULD be conveyed as CSRCs identifiers within this >> stream. The SRC may make timing adjustments among the received >> streams and generate its own timing on the stream sent to the SRS. >> Optionally an SRC acting as a mixer can perform transcoding, and > can >> even cope with different codings received from different UAs. RTCP >> Sender Reports and Receiver Reports are not forwarded by an SRC >> acting as mixer, but there are requirements for forwarding RTCP >> Source Description (SDES) packets. The SRC generates its own RTCP >> Sender and Receiver reports toward the associated UAs and SRS. The >> use of SRTP between the SRC and the SRS for the RS is independent > of >> the use of SRTP between the UAs and SRC for the CS. >> >> If packet loss occurs from the UA to the SRC, the SRC SHOULD detect >> and attempt to recover from the loss. If packet loss occurs from > the >> SRC to the SRS, the SRS SHOULD detect and attempt to recover from > the >> loss. >> >> 4.3. SRC acting as an RTP Endpoint >> >> The case of the SRC acting as an RTP endpoint, as defined in >> [RFC3550], is similar to the mixer case, except that the RTP > session >> between the SRC and the SRS is considered completely independent > from >> the RTP session that is part of the CS. The SRC can, but need not, >> mix RTP streams from different participants prior to sending to the >> SRS. RTCP between the SRC and the SRS is completely independent of >> RTCP on the CS. The use of SRTP between the SRC and the SRS is >> independent of the use of SRTP on the CS. >> >> If packet loss occurs from the UA to the SRC, the SRC SHOULD detect >> and attempt to recover from the loss. If packet loss occurs from > the >> SRC to the SRS, the SRS SHOULD detect and attempt to recover from > the >> loss. >> ------------------ >> >> Comment on this are greatly appreciated. >> Thanks, >> Charles > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.r.elwell@gmail.com Thu Oct 27 01:51: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 6D40121F8669 for ; Thu, 27 Oct 2011 01:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZepT+cXalb5 for ; Thu, 27 Oct 2011 01:51:44 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 52D2821F8672 for ; Thu, 27 Oct 2011 01:51:44 -0700 (PDT) Received: by wwn22 with SMTP id 22so533198wwn.1 for ; Thu, 27 Oct 2011 01:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=3gWbM9GQ/kq1N/iLRw8godeOlBdwttkkJIks1Pk/4c4=; b=W/lovUuyGw0IZonmQfOADFT88hLGrV35TG5Eh2IrHu1vRjSAiscufBryihjJEDndkZ 6GWM9IO+RNAkNf/yFxZwQW6TVgm7y+AH8YchkV8ke9UeyiQPvmJX1RbbLTkt3uN6zZWu kFHHyTadBD+LI5DhGvTjI9FLRy6hCTQLpJgBo= Received: by 10.216.134.7 with SMTP id r7mr883500wei.17.1319705502177; Thu, 27 Oct 2011 01:51:42 -0700 (PDT) Received: from JohnsComputer (cpc1-clif8-2-0-cust418.12-4.cable.virginmedia.com. [82.25.209.163]) by mx.google.com with ESMTPS id e7sm7983578wbh.12.2011.10.27.01.51.40 (version=SSLv3 cipher=OTHER); Thu, 27 Oct 2011 01:51:41 -0700 (PDT) Message-ID: <08D116FB1E7040A0BF953F77D190EAAA@JohnsComputer> From: "John Elwell" To: "Ram Mohan R \(rmohanr\)" , References: <35BCE99A477D6A4986FB2216D8CF2CFD07F6FAD3@XMB-BGL-417.cisco.com> Date: Thu, 27 Oct 2011 09:51:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: Re: [siprec] Metadata-04 - comments on section 4 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, 27 Oct 2011 08:51:45 -0000 Ram, Thanks for your reponses, and sorry about the delay on my part. I disagree with just one of your reponses: >> 4. "The metadata >> MUST be conveyed from SRC to SRS." >> This too sounds like protocol. > > I don't think this is related to protocol. This tells from where to > where the metadata has to be conveyed. I don't see any problems in > having this. [JRE] I would have not problem with an informative statement, but if we use MUST we need to say how an SRC would comply with this MUST, which to me gets into the realm of protocol. I would be happy with "The metadata is conveyed from SRC to SRS". John From rmohanr@cisco.com Thu Oct 27 01:54: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 B673321F86A5 for ; Thu, 27 Oct 2011 01:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.614 X-Spam-Level: X-Spam-Status: No, score=-8.614 tagged_above=-999 required=5 tests=[AWL=1.985, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZZLIuuuHMfY for ; Thu, 27 Oct 2011 01:54:02 -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 0590721F8672 for ; Thu, 27 Oct 2011 01:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1042; q=dns/txt; s=iport; t=1319705642; x=1320915242; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=uaumh9XIEUKlV9jd6R1pTNsFk4B/z8P2XljxOGUkJRE=; b=SOM8cqHB5m4dqccupNXmENOQXlHFmJ/eeLf5++vrsrMrUobImWSf2/0C OwhSRLYNRi/WmSq2q+YjRKhP55jZN2raIuizvJJruh1u7wqBoMj8Y7lMh 6sL/wm3zHdvkGP2bUrdVANljKX2YLYMNa7LaKW+iF42+VEIA7D3+XX/fH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAAIAbqU5Io8UQ/2dsb2JhbABCmgiPSIEFgXIBAQEBAxIBHQpLBAIBCBEEAQELBhcBBgEgJQkIAQEEAQoICBqeCQGeVogJYQSIBJE8hQCHMQ X-IronPort-AV: E=Sophos;i="4.69,412,1315180800"; d="scan'208";a="58640806" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 27 Oct 2011 08:53:58 +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 p9R8rwU5003666; Thu, 27 Oct 2011 08:53:58 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); Thu, 27 Oct 2011 14:23:57 +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, 27 Oct 2011 14:23:54 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B7C85@XMB-BGL-417.cisco.com> In-Reply-To: <08D116FB1E7040A0BF953F77D190EAAA@JohnsComputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Metadata-04 - comments on section 4 Thread-Index: AcyUha3Ud2kW2PFpQyueHCO1s6CkegAAC7aA References: <35BCE99A477D6A4986FB2216D8CF2CFD07F6FAD3@XMB-BGL-417.cisco.com> <08D116FB1E7040A0BF953F77D190EAAA@JohnsComputer> From: "Ram Mohan R (rmohanr)" To: "John Elwell" , X-OriginalArrivalTime: 27 Oct 2011 08:53:57.0754 (UTC) FILETIME=[F6B54DA0:01CC9485] Subject: Re: [siprec] Metadata-04 - comments on section 4 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, 27 Oct 2011 08:54:02 -0000 Hi John, I agree with you. I will make it an informative statement. Regards, Ram > -----Original Message----- > From: John Elwell [mailto:john.r.elwell@gmail.com] > Sent: Thursday, October 27, 2011 2:22 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Metadata-04 - comments on section 4 >=20 > Ram, >=20 > Thanks for your reponses, and sorry about the delay on my part. I > disagree > with just one of your reponses: >=20 >=20 > >> 4. "The metadata > >> MUST be conveyed from SRC to SRS." > >> This too sounds like protocol. > > > > I don't think this is related to protocol. This tells from where to > > where the metadata has to be conveyed. I don't see any problems in > > having this. > [JRE] I would have not problem with an informative statement, but if we > use > MUST we need to say how an SRC would comply with this MUST, which to me > gets > into the realm of protocol. I would be happy with "The metadata is > conveyed > from SRC to SRS". >=20 > John >=20 >=20 From pkyzivat@alum.mit.edu Thu Oct 27 09:47:07 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 3DE2A21F8B6C for ; Thu, 27 Oct 2011 09:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCNGjn3JSzo2 for ; Thu, 27 Oct 2011 09:47:06 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 0295121F8B1E for ; Thu, 27 Oct 2011 09:47:05 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA11.westchester.pa.mail.comcast.net with comcast id przS1h0011ZXKqc5Bsn65M; Thu, 27 Oct 2011 16:47:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id psn51h00B0tdiYw3hsn5Qj; Thu, 27 Oct 2011 16:47:06 +0000 Message-ID: <4EA98B07.5060701@alum.mit.edu> Date: Thu, 27 Oct 2011 12:47:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Elwell References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.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] Need Inputs: How to represent attributes ofassociation in Metadata Model and 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, 27 Oct 2011 16:47:07 -0000 On 10/27/11 4:33 AM, John Elwell wrote: > Approach 2 seems reasonable. Could we say that an association is > implicitly deleted (gains a dissociate time) as soon as one of the > associated elements is deleted (gains a dissociate time)? This would > reduce the on-the wire document size for both partial and full metadata > in some circumstances (e.g., conference termination by the focus). I *think* that would be reasonable. It would be good to have someone that is actively working on an implementation comment on it. Thanks, Paul > John > > > ----- Original Message ----- From: "Ram Mohan R (rmohanr)" > > To: "Paul Kyzivat" ; > Sent: Friday, October 14, 2011 4:59 AM > Subject: Re: [siprec] Need Inputs: How to represent attributes > ofassociation in Metadata Model and in XML ? > > >> Thanks Paul for your comments. I also prefer approach 2 as mentioned >> below in this thread. >> I will wait to hear for comments/opinion from others. >> >> Ram >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Thursday, October 13, 2011 10:48 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Need Inputs: How to represent attributes of >>> association in Metadata Model and in XML ? >>> >>> I like approach 2, as Ram has shown it. It deals with the problems >> John >>> raised with the others. >>> >>> I didn't follow John's arithmetic on this one, using his 20 party >>> conference example. As I count that, there are 21 participants when >> you >>> include the focus. Each of the 20 has two stream/participant >>> associations with the focus, for a total of 40. (The association is >>> bidirectional. I can only get to 80 by assuming we had to represent an >>> association in each direction.) And each has two ids, each of which is >>> also the id of a stream or participant. So there are really only 23 >>> distinct ids that need to be assigned for this. (One for each of the >> 21 >>> participants, and one for each of the two streams.) >>> >>> The 40 associations, each carrying two ids, is still kind of a lot if >>> its sent all at once. But when starting up a conference they will >>> probably be added gradually as each participant joins. Same at the end >>> if they drop off individually. But it could be a bunch together if the >>> conference is forcibly dropped by the focus. But it does minimize what >>> is sent when things happen incrementally. >>> >>> There may be some optimizations that can be done - e.g. a sort of >>> "wildcard" for one of the the two ids in the association class. E.g. >>> >>> >> participant="*" >>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>> 2010-12-16T23:41:07Z >>> >>> >>> (I'm not advocating that particular syntax. Its just something to make >>> the point.) >>> >>> Thanks, >>> Paul >>> >>> >>> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: >>> > My bad(typo) while sending the example. The correct partial update I >>> > intended to send is: >>> > >>> > >> > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>> > stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>> > 2010-12-16T23:41:07Z >>> > >>> > >>> > This is inline with approach 2 where in each association XML element >>> > will have the IDs of the related associated elements. >>> > >>> > Ram >>> > >>> >> -----Original Message----- >>> >> From: Leon Portman [mailto:Leon.Portman@nice.com] >>> >> Sent: Wednesday, October 12, 2011 2:24 PM >>> >> To: Ram Mohan R (rmohanr); siprec@ietf.org >>> >> Cc: Ofir Roth >>> >> Subject: RE: Need Inputs: How to represent attributes of >> association >>> > in >>> >> Metadata Model and in XML ? >>> >> >>> >> We do prefer to receive related elements as well, it makes >>> >> implementation much easier. >>> >> At least we should get relevant IDs. For example below, SRC >>> should >>> >> also send ParticipantId >>> >> >>> >> -----Original Message----- >>> >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>> >> Sent: Wednesday, October 12, 2011 10:52 AM >>> >> To: Leon Portman; siprec@ietf.org >>> >> Cc: Ofir Roth >>> >> Subject: RE: Need Inputs: How to represent attributes of >> association >>> > in >>> >> Metadata Model and in XML ? >>> >> >>> >> Leon, >>> >> Thanks for your response. One of the adv with approach 2 is we can >>> >> indicate only changes in the association without the need to >>> > indicating >>> >> the elements ( of association). IOW for the below example, if there >>> is >>> >> a change in participant-stream association I can simply send the >>> >> following in partial update: >>> >> >>> >> >>> >> >> >> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> >>> >> 2010-12-16T23:41:07Z >>> >> >>> >> >>> >> Do you see a need to always indicate the related elements too ? In >>> >> which case I see approach 1 as more suitable. >>> >> >>> >> Thanks, >>> >> Ram >>> >> >>> >>> -----Original Message----- >>> >>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>> >>> Sent: Wednesday, October 12, 2011 12:55 PM >>> >>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>> >>> Cc: Ofir Roth >>> >>> Subject: RE: Need Inputs: How to represent attributes of >>> association >>> >>> inmetadata Model and in XML ? >>> >>> >>> >>> Ram Hi >>> >>> >>> >>> I am ok with approaches 1 and however I do prefer approach one >>> >> because >>> >>> it will be easier for SRS to get decode - association is inside >>> >>> relevant element. And it is more readable. >>> >>> Approach 2 will work as well, however it is important that if >> there >>> >>> will be a change in association then to send to SRS not only >>> updated >>> >>> association element but also related elements: for example if >>> stream >>> >>> was associated to participant and session, send also participant >>> and >>> >>> session latest state. >>> >>> >>> >>> Regards >>> >>> >>> >>> Leon >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> >>> Behalf Of Ram Mohan R (rmohanr) >>> >>> Sent: Wednesday, October 12, 2011 7:48 AM >>> >>> To: siprec@ietf.org >>> >>> Subject: [siprec] Need Inputs: How to represent attributes of >>> >>> association in metadata Model and in XML ? >>> >>> >>> >>> (Sorry for lengthy e-mail) >>> >>> >>> >>> Hi All, >>> >>> >>> >>> In the last interim we discussed 4 approaches for representing >>> >>> attributes of association in XML. >>> >>> >>> >>> >>> >>> Here are some pros/cons for each of them: >>> >>> Approach 1: >>> >>> ---------- >>> >>> Represent the association attribute as a property within one of >> the >>> >>> associated elements. Example given at http://www.ietf.org/mail- >>> >>> archive/web/siprec/current/msg02709.html Does not need another XML >>> >>> element and represents the association attributes as capability of >>> >> one >>> >>> of the association element. >>> >>> e.g. >>> >>> >> >>> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>> >>> session="urn:uuid:855a5ded-8420-456d-a70f- >>> 6da1eeaeb425"> >>> >>> sip:ram@blr.cisco.com >>> >>> 2010-12-16T23:41:07Z>> >> time> >>> >>> TBD >>> >>> >> >>> stream ="urn:uuid:f3373a7b-4958-4e55-8820- >>> >>> d03a191fb76a >>> >>> "> >>> >>> 2010-12- >>> 16T23:41:07Z>> >>> time> >>> >>> contributing SSRC-1 >>> >>> In >>> the >>> >> above >>> >>> example the participant contributes a single streams. For each >>> > stream >>> >>> the association attribute (participant-stream) is shown with the >>> >> stream >>> >>> ID nested in. >>> >>> >>> >>> >>> >>> Approach 2: >>> >>> ----------- >>> >>> In this approach we have a new XML element for every association >>> >> class. >>> >>> This xml element will NOT have a unique ID instead it references >>> the >>> >> ID >>> >>> of associated elements (shown below). With this approach it is >> easy >>> >> to >>> >>> update as the association class is a separate XML element and not >>> >>> property. >>> >>> e.g. >>> >>> >> >>> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>> >>> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>> >>> 2010-12-16T23:41:07Z >>> >>> TBD >>> >>> >>> >>> >>> >>> >> >>> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>> >>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>> >>> 2010-12-16T23:41:07Z >>> >>> contributing SSRC-1 >>> >>> >>> >>> >>> >>> Approach 3 and 4 are in the below e-mail from John. >>> >>> Approach 3 defines a new Unique ID for every association XML >>> elment. >>> >>> Also it creates alias for the other IDs. In the discussions in >>> >> interim >>> >>> there was no strong support for this approach. >>> >>> >>> >>> Approach 4 is same as approach 1 where in the association element >>> is >>> >>> encapsulated in one of the XML elements (to which it is >>> > associated). >>> >>> In addition to that it also has reference to the elements (alias >> of >>> >>> IDs) to which the association belongs. >>> >>> >>> >>> I prefer approach 2 as it is has a separate XML element to >>> represent >>> >>> the association class. The only difference of this XML element >> from >>> >>> others is this does not need a unique ID. Instead it references >> the >>> >> IDs >>> >>> of the elements to which the association belongs. >>> >>> Since association class is a special class meant to associate >>> >> multiple >>> >>> classes, I see it ok to have a representation as in approach 2 >>> where >>> >> in >>> >>> the identifier is the concatenation of the classes to which the >>> >>> association belongs to. >>> >>> >>> >>> Please provide your comments on this and also suggest any other >>> >>> approaches to represent association classes in XML. >>> >>> >>> >>> Regards, >>> >>> Ram >>> >>> >>> > _______________________________________________ >>> > 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 Thu Oct 27 10:08: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 9EB5221F8BA9 for ; Thu, 27 Oct 2011 10:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.756 X-Spam-Level: X-Spam-Status: No, score=-6.756 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZGHWvNq28zC for ; Thu, 27 Oct 2011 10:08:29 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id AD7DC21F8AAC for ; Thu, 27 Oct 2011 10:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=12047; q=dns/txt; s=iport; t=1319735308; x=1320944908; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=yxupDJfoc6WCrFxf3WCAjMfAlwFlL5bCX4xdemCoWzk=; b=ec4cS+fmASBMUylJLozI+3QN+C88lAPF7WyvbEWvy9fFxTOLbIv0iEEB xb4nnXjKngPt+36rVn2jxyTBYrddryA6qpioXmX51OLT4f0kqlDyzcZKP qpOLSjSSfWfoIOq9Y5LbghDLdXPhY9wt9YpQlrR/vuBeZOdZ/VC7Zb+QH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8AAPeOqU5Io8UT/2dsb2JhbABDDpoAj1GBBYFyAQEBAwESAR0KLgQZBAIBCBEEAQEBCgYXAQYBICUJCAEBBAEKCAgBEAmHYJZBAZ5XiB1hBIgEkT+FAAGGcT8 X-IronPort-AV: E=Sophos;i="4.69,413,1315180800"; d="scan'208";a="1903370" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-4.cisco.com with ESMTP; 27 Oct 2011 17:08:26 +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 p9RH8Pxq009692; Thu, 27 Oct 2011 17:08: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); Thu, 27 Oct 2011 22:38:25 +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, 27 Oct 2011 22:38:22 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DD5@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Need Inputs: How to represent attributes ofassociation in Metadata Model and in XML ? Thread-Index: AcyUgxjabTGDwIsUSiGpf0vrcAQSAwARqD8g References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "John Elwell" , "Paul Kyzivat" , X-OriginalArrivalTime: 27 Oct 2011 17:08:25.0520 (UTC) FILETIME=[0A132300:01CC94CB] Subject: Re: [siprec] Need Inputs: How to represent attributes ofassociation in Metadata Model and 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, 27 Oct 2011 17:08:30 -0000 Hi John, Thanks for your comment on this. Yes several of us seem to be inclined towards approach 2. I like your point that once one of the elements in the association gets deleted, the association element life ends. SRC may choose to send the association element optionally or the SRS can still learn that as the way you mentioned.=20 We ( authors of metadata draft ) discussed internally on this open item and see some issues with adopting approach 2 as is with the current model /schema. I will start a separate mail thread for the issue as this thread is already too long. Thanks, Ram > -----Original Message----- > From: John Elwell [mailto:john.r.elwell@gmail.com] > Sent: Thursday, October 27, 2011 2:03 PM > To: Ram Mohan R (rmohanr); Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to represent attributes > ofassociation in Metadata Model and in XML ? >=20 > Approach 2 seems reasonable. Could we say that an association is > implicitly > deleted (gains a dissociate time) as soon as one of the associated > elements > is deleted (gains a dissociate time)? This would reduce the on-the wire > document size for both partial and full metadata in some circumstances > (e.g., conference termination by the focus). >=20 > John >=20 >=20 > ----- Original Message ----- > From: "Ram Mohan R (rmohanr)" > To: "Paul Kyzivat" ; > Sent: Friday, October 14, 2011 4:59 AM > Subject: Re: [siprec] Need Inputs: How to represent attributes > ofassociation > in Metadata Model and in XML ? >=20 >=20 > > Thanks Paul for your comments. I also prefer approach 2 as mentioned > > below in this thread. > > I will wait to hear for comments/opinion from others. > > > > Ram > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: Thursday, October 13, 2011 10:48 PM > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Need Inputs: How to represent attributes of > >> association in Metadata Model and in XML ? > >> > >> I like approach 2, as Ram has shown it. It deals with the problems > > John > >> raised with the others. > >> > >> I didn't follow John's arithmetic on this one, using his 20 party > >> conference example. As I count that, there are 21 participants when > > you > >> include the focus. Each of the 20 has two stream/participant > >> associations with the focus, for a total of 40. (The association is > >> bidirectional. I can only get to 80 by assuming we had to represent > an > >> association in each direction.) And each has two ids, each of which > is > >> also the id of a stream or participant. So there are really only 23 > >> distinct ids that need to be assigned for this. (One for each of the > > 21 > >> participants, and one for each of the two streams.) > >> > >> The 40 associations, each carrying two ids, is still kind of a lot > if > >> its sent all at once. But when starting up a conference they will > >> probably be added gradually as each participant joins. Same at the > end > >> if they drop off individually. But it could be a bunch together if > the > >> conference is forcibly dropped by the focus. But it does minimize > what > >> is sent when things happen incrementally. > >> > >> There may be some optimizations that can be done - e.g. a sort of > >> "wildcard" for one of the the two ids in the association class. E.g. > >> > >> >> participant=3D"*" > >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > >> 2010-12-16T23:41:07Z > >> > >> > >> (I'm not advocating that particular syntax. Its just something to > make > >> the point.) > >> > >> Thanks, > >> Paul > >> > >> > >> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: > >> > My bad(typo) while sending the example. The correct partial update > I > >> > intended to send is: > >> > > >> > >> > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >> > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > >> > 2010-12-16T23:41:07Z > >> > > >> > > >> > This is inline with approach 2 where in each association XML > element > >> > will have the IDs of the related associated elements. > >> > > >> > Ram > >> > > >> >> -----Original Message----- > >> >> From: Leon Portman [mailto:Leon.Portman@nice.com] > >> >> Sent: Wednesday, October 12, 2011 2:24 PM > >> >> To: Ram Mohan R (rmohanr); siprec@ietf.org > >> >> Cc: Ofir Roth > >> >> Subject: RE: Need Inputs: How to represent attributes of > > association > >> > in > >> >> Metadata Model and in XML ? > >> >> > >> >> We do prefer to receive related elements as well, it makes > >> >> implementation much easier. > >> >> At least we should get relevant IDs. For example below, SRC > >> should > >> >> also send ParticipantId > >> >> > >> >> -----Original Message----- > >> >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >> >> Sent: Wednesday, October 12, 2011 10:52 AM > >> >> To: Leon Portman; siprec@ietf.org > >> >> Cc: Ofir Roth > >> >> Subject: RE: Need Inputs: How to represent attributes of > > association > >> > in > >> >> Metadata Model and in XML ? > >> >> > >> >> Leon, > >> >> Thanks for your response. One of the adv with approach 2 is we > can > >> >> indicate only changes in the association without the need to > >> > indicating > >> >> the elements ( of association). IOW for the below example, if > there > >> is > >> >> a change in participant-stream association I can simply send the > >> >> following in partial update: > >> >> > >> >> > >> >> >> >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> > >> >> 2010-12-16T23:41:07Z > >> >> > >> >> > >> >> Do you see a need to always indicate the related elements too ? > In > >> >> which case I see approach 1 as more suitable. > >> >> > >> >> Thanks, > >> >> Ram > >> >> > >> >>> -----Original Message----- > >> >>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >> >>> Sent: Wednesday, October 12, 2011 12:55 PM > >> >>> To: Ram Mohan R (rmohanr); siprec@ietf.org > >> >>> Cc: Ofir Roth > >> >>> Subject: RE: Need Inputs: How to represent attributes of > >> association > >> >>> inmetadata Model and in XML ? > >> >>> > >> >>> Ram Hi > >> >>> > >> >>> I am ok with approaches 1 and however I do prefer approach one > >> >> because > >> >>> it will be easier for SRS to get decode - association is inside > >> >>> relevant element. And it is more readable. > >> >>> Approach 2 will work as well, however it is important that if > > there > >> >>> will be a change in association then to send to SRS not only > >> updated > >> >>> association element but also related elements: for example if > >> stream > >> >>> was associated to participant and session, send also participant > >> and > >> >>> session latest state. > >> >>> > >> >>> Regards > >> >>> > >> >>> Leon > >> >>> > >> >>> > >> >>> -----Original Message----- > >> >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >> >>> Behalf Of Ram Mohan R (rmohanr) > >> >>> Sent: Wednesday, October 12, 2011 7:48 AM > >> >>> To: siprec@ietf.org > >> >>> Subject: [siprec] Need Inputs: How to represent attributes of > >> >>> association in metadata Model and in XML ? > >> >>> > >> >>> (Sorry for lengthy e-mail) > >> >>> > >> >>> Hi All, > >> >>> > >> >>> In the last interim we discussed 4 approaches for representing > >> >>> attributes of association in XML. > >> >>> > >> >>> > >> >>> Here are some pros/cons for each of them: > >> >>> Approach 1: > >> >>> ---------- > >> >>> Represent the association attribute as a property within one of > > the > >> >>> associated elements. Example given at http://www.ietf.org/mail- > >> >>> archive/web/siprec/current/msg02709.html Does not need another > XML > >> >>> element and represents the association attributes as capability > of > >> >> one > >> >>> of the association element. > >> >>> e.g. > >> >>> >> >>> = id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >> >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- > >> 6da1eeaeb425"> > >> >>> sip:ram@blr.cisco.com > >> >>> 2010-12- > 16T23:41:07Z >> >> time> > >> >>> TBD > >> >>> >> >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820- > >> >>> d03a191fb76a > >> >>> "> > >> >>> 2010-12- > >> 16T23:41:07Z >> >>> time> > >> >>> contributing SSRC-1 > >> >>> In > >> the > >> >> above > >> >>> example the participant contributes a single streams. For each > >> > stream > >> >>> the association attribute (participant-stream) is shown with the > >> >> stream > >> >>> ID nested in. > >> >>> > >> >>> > >> >>> Approach 2: > >> >>> ----------- > >> >>> In this approach we have a new XML element for every association > >> >> class. > >> >>> This xml element will NOT have a unique ID instead it references > >> the > >> >> ID > >> >>> of associated elements (shown below). With this approach it is > > easy > >> >> to > >> >>> update as the association class is a separate XML element and > not > >> >>> property. > >> >>> e.g. > >> >>> >> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >> >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > >> >>> 2010-12-16T23:41:07Z > >> >>> TBD > >> >>> > >> >>> > >> >>> >> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >> >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > >> >>> 2010-12-16T23:41:07Z > >> >>> contributing SSRC-1 > >> >>> > >> >>> > >> >>> Approach 3 and 4 are in the below e-mail from John. > >> >>> Approach 3 defines a new Unique ID for every association XML > >> elment. > >> >>> Also it creates alias for the other IDs. In the discussions in > >> >> interim > >> >>> there was no strong support for this approach. > >> >>> > >> >>> Approach 4 is same as approach 1 where in the association > element > >> is > >> >>> encapsulated in one of the XML elements (to which it is > >> > associated). > >> >>> In addition to that it also has reference to the elements (alias > > of > >> >>> IDs) to which the association belongs. > >> >>> > >> >>> I prefer approach 2 as it is has a separate XML element to > >> represent > >> >>> the association class. The only difference of this XML element > > from > >> >>> others is this does not need a unique ID. Instead it references > > the > >> >> IDs > >> >>> of the elements to which the association belongs. > >> >>> Since association class is a special class meant to associate > >> >> multiple > >> >>> classes, I see it ok to have a representation as in approach 2 > >> where > >> >> in > >> >>> the identifier is the concatenation of the classes to which the > >> >>> association belongs to. > >> >>> > >> >>> Please provide your comments on this and also suggest any other > >> >>> approaches to represent association classes in XML. > >> >>> > >> >>> Regards, > >> >>> Ram > >> >>> From john.2.stafford@bt.com Thu Oct 27 10:44: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 4892721F8B37 for ; Thu, 27 Oct 2011 10:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3aB-t42yPbm for ; Thu, 27 Oct 2011 10:44:55 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCAA21F8BA7 for ; Thu, 27 Oct 2011 10:44:54 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 27 Oct 2011 18:44:54 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.227]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 27 Oct 2011 18:44:53 +0100 From: To: Date: Thu, 27 Oct 2011 18:44:53 +0100 Thread-Topic: [siprec] Need Inputs: How to represent attributes ofassociation in Metadata Model and in XML ? Thread-Index: AcyUgxjabTGDwIsUSiGpf0vrcAQSAwARqD8gAAB4gS4= Message-ID: References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com> , <35BCE99A477D6A4986FB2216D8CF2CFD082B7DD5@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DD5@XMB-BGL-417.cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Need Inputs: How to represent attributes ofassociation in Metadata Model and 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, 27 Oct 2011 17:44:56 -0000 I am not clear on the effect on the other XMl elements. I presume the participant - CS element will be replaced by the< = participantSessionAssoc>. I also presume and will no longer be needed, and that the <= participantStream Assoc> will include an attribute to say send or recv ? Is that correct ? I hope the rule will remain that, in the abscence of any recv elements by = default a stream is assumed to be recieved by all participants. Rgds John Stafford | Solution Architect 1 | BT Global Services=20 ________________________________________ From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Ram Mo= han R (rmohanr) [rmohanr@cisco.com] Sent: 27 October 2011 18:08 To: John Elwell; Paul Kyzivat; siprec@ietf.org Subject: Re: [siprec] Need Inputs: How to represent attributes ofassociatio= n in Metadata Model and in XML ? Hi John, Thanks for your comment on this. Yes several of us seem to be inclined towards approach 2. I like your point that once one of the elements in the association gets deleted, the association element life ends. SRC may choose to send the association element optionally or the SRS can still learn that as the way you mentioned. We ( authors of metadata draft ) discussed internally on this open item and see some issues with adopting approach 2 as is with the current model /schema. I will start a separate mail thread for the issue as this thread is already too long. Thanks, Ram > -----Original Message----- > From: John Elwell [mailto:john.r.elwell@gmail.com] > Sent: Thursday, October 27, 2011 2:03 PM > To: Ram Mohan R (rmohanr); Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to represent attributes > ofassociation in Metadata Model and in XML ? > > Approach 2 seems reasonable. Could we say that an association is > implicitly > deleted (gains a dissociate time) as soon as one of the associated > elements > is deleted (gains a dissociate time)? This would reduce the on-the wire > document size for both partial and full metadata in some circumstances > (e.g., conference termination by the focus). > > John > > > ----- Original Message ----- > From: "Ram Mohan R (rmohanr)" > To: "Paul Kyzivat" ; > Sent: Friday, October 14, 2011 4:59 AM > Subject: Re: [siprec] Need Inputs: How to represent attributes > ofassociation > in Metadata Model and in XML ? > > > > Thanks Paul for your comments. I also prefer approach 2 as mentioned > > below in this thread. > > I will wait to hear for comments/opinion from others. > > > > Ram > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: Thursday, October 13, 2011 10:48 PM > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Need Inputs: How to represent attributes of > >> association in Metadata Model and in XML ? > >> > >> I like approach 2, as Ram has shown it. It deals with the problems > > John > >> raised with the others. > >> > >> I didn't follow John's arithmetic on this one, using his 20 party > >> conference example. As I count that, there are 21 participants when > > you > >> include the focus. Each of the 20 has two stream/participant > >> associations with the focus, for a total of 40. (The association is > >> bidirectional. I can only get to 80 by assuming we had to represent > an > >> association in each direction.) And each has two ids, each of which > is > >> also the id of a stream or participant. So there are really only 23 > >> distinct ids that need to be assigned for this. (One for each of the > > 21 > >> participants, and one for each of the two streams.) > >> > >> The 40 associations, each carrying two ids, is still kind of a lot > if > >> its sent all at once. But when starting up a conference they will > >> probably be added gradually as each participant joins. Same at the > end > >> if they drop off individually. But it could be a bunch together if > the > >> conference is forcibly dropped by the focus. But it does minimize > what > >> is sent when things happen incrementally. > >> > >> There may be some optimizations that can be done - e.g. a sort of > >> "wildcard" for one of the the two ids in the association class. E.g. > >> > >> >> participant=3D"*" > >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > >> 2010-12-16T23:41:07Z > >> > >> > >> (I'm not advocating that particular syntax. Its just something to > make > >> the point.) > >> > >> Thanks, > >> Paul > >> > >> > >> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: > >> > My bad(typo) while sending the example. The correct partial update > I > >> > intended to send is: > >> > > >> > >> > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >> > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > >> > 2010-12-16T23:41:07Z > >> > > >> > > >> > This is inline with approach 2 where in each association XML > element > >> > will have the IDs of the related associated elements. > >> > > >> > Ram > >> > > >> >> -----Original Message----- > >> >> From: Leon Portman [mailto:Leon.Portman@nice.com] > >> >> Sent: Wednesday, October 12, 2011 2:24 PM > >> >> To: Ram Mohan R (rmohanr); siprec@ietf.org > >> >> Cc: Ofir Roth > >> >> Subject: RE: Need Inputs: How to represent attributes of > > association > >> > in > >> >> Metadata Model and in XML ? > >> >> > >> >> We do prefer to receive related elements as well, it makes > >> >> implementation much easier. > >> >> At least we should get relevant IDs. For example below, SRC > >> should > >> >> also send ParticipantId > >> >> > >> >> -----Original Message----- > >> >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >> >> Sent: Wednesday, October 12, 2011 10:52 AM > >> >> To: Leon Portman; siprec@ietf.org > >> >> Cc: Ofir Roth > >> >> Subject: RE: Need Inputs: How to represent attributes of > > association > >> > in > >> >> Metadata Model and in XML ? > >> >> > >> >> Leon, > >> >> Thanks for your response. One of the adv with approach 2 is we > can > >> >> indicate only changes in the association without the need to > >> > indicating > >> >> the elements ( of association). IOW for the below example, if > there > >> is > >> >> a change in participant-stream association I can simply send the > >> >> following in partial update: > >> >> > >> >> > >> >> >> >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> > >> >> 2010-12-16T23:41:07Z > >> >> > >> >> > >> >> Do you see a need to always indicate the related elements too ? > In > >> >> which case I see approach 1 as more suitable. > >> >> > >> >> Thanks, > >> >> Ram > >> >> > >> >>> -----Original Message----- > >> >>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >> >>> Sent: Wednesday, October 12, 2011 12:55 PM > >> >>> To: Ram Mohan R (rmohanr); siprec@ietf.org > >> >>> Cc: Ofir Roth > >> >>> Subject: RE: Need Inputs: How to represent attributes of > >> association > >> >>> inmetadata Model and in XML ? > >> >>> > >> >>> Ram Hi > >> >>> > >> >>> I am ok with approaches 1 and however I do prefer approach one > >> >> because > >> >>> it will be easier for SRS to get decode - association is inside > >> >>> relevant element. And it is more readable. > >> >>> Approach 2 will work as well, however it is important that if > > there > >> >>> will be a change in association then to send to SRS not only > >> updated > >> >>> association element but also related elements: for example if > >> stream > >> >>> was associated to participant and session, send also participant > >> and > >> >>> session latest state. > >> >>> > >> >>> Regards > >> >>> > >> >>> Leon > >> >>> > >> >>> > >> >>> -----Original Message----- > >> >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >> >>> Behalf Of Ram Mohan R (rmohanr) > >> >>> Sent: Wednesday, October 12, 2011 7:48 AM > >> >>> To: siprec@ietf.org > >> >>> Subject: [siprec] Need Inputs: How to represent attributes of > >> >>> association in metadata Model and in XML ? > >> >>> > >> >>> (Sorry for lengthy e-mail) > >> >>> > >> >>> Hi All, > >> >>> > >> >>> In the last interim we discussed 4 approaches for representing > >> >>> attributes of association in XML. > >> >>> > >> >>> > >> >>> Here are some pros/cons for each of them: > >> >>> Approach 1: > >> >>> ---------- > >> >>> Represent the association attribute as a property within one of > > the > >> >>> associated elements. Example given at http://www.ietf.org/mail- > >> >>> archive/web/siprec/current/msg02709.html Does not need another > XML > >> >>> element and represents the association attributes as capability > of > >> >> one > >> >>> of the association element. > >> >>> e.g. > >> >>> >> >>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >> >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- > >> 6da1eeaeb425"> > >> >>> sip:ram@blr.cisco.com > >> >>> 2010-12- > 16T23:41:07Z >> >> time> > >> >>> TBD > >> >>> >> >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820- > >> >>> d03a191fb76a > >> >>> "> > >> >>> 2010-12- > >> 16T23:41:07Z >> >>> time> > >> >>> contributing SSRC-1 > >> >>> In > >> the > >> >> above > >> >>> example the participant contributes a single streams. For each > >> > stream > >> >>> the association attribute (participant-stream) is shown with the > >> >> stream > >> >>> ID nested in. > >> >>> > >> >>> > >> >>> Approach 2: > >> >>> ----------- > >> >>> In this approach we have a new XML element for every association > >> >> class. > >> >>> This xml element will NOT have a unique ID instead it references > >> the > >> >> ID > >> >>> of associated elements (shown below). With this approach it is > > easy > >> >> to > >> >>> update as the association class is a separate XML element and > not > >> >>> property. > >> >>> e.g. > >> >>> >> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >> >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > >> >>> 2010-12-16T23:41:07Z > >> >>> TBD > >> >>> > >> >>> > >> >>> >> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >> >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > >> >>> 2010-12-16T23:41:07Z > >> >>> contributing SSRC-1 > >> >>> > >> >>> > >> >>> Approach 3 and 4 are in the below e-mail from John. > >> >>> Approach 3 defines a new Unique ID for every association XML > >> elment. > >> >>> Also it creates alias for the other IDs. In the discussions in > >> >> interim > >> >>> there was no strong support for this approach. > >> >>> > >> >>> Approach 4 is same as approach 1 where in the association > element > >> is > >> >>> encapsulated in one of the XML elements (to which it is > >> > associated). > >> >>> In addition to that it also has reference to the elements (alias > > of > >> >>> IDs) to which the association belongs. > >> >>> > >> >>> I prefer approach 2 as it is has a separate XML element to > >> represent > >> >>> the association class. The only difference of this XML element > > from > >> >>> others is this does not need a unique ID. Instead it references > > the > >> >> IDs > >> >>> of the elements to which the association belongs. > >> >>> Since association class is a special class meant to associate > >> >> multiple > >> >>> classes, I see it ok to have a representation as in approach 2 > >> where > >> >> in > >> >>> the identifier is the concatenation of the classes to which the > >> >>> association belongs to. > >> >>> > >> >>> Please provide your comments on this and also suggest any other > >> >>> approaches to represent association classes in XML. > >> >>> > >> >>> Regards, > >> >>> Ram > >> >>> _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec= From rmohanr@cisco.com Thu Oct 27 10:47:03 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 B83C121F8672 for ; Thu, 27 Oct 2011 10:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.746 X-Spam-Level: X-Spam-Status: No, score=-8.746 tagged_above=-999 required=5 tests=[AWL=1.853, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RkjBEdH7NAf for ; Thu, 27 Oct 2011 10:47:03 -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 91C1E21F8B48 for ; Thu, 27 Oct 2011 10:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3683; q=dns/txt; s=iport; t=1319737622; x=1320947222; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=YyFmk7xMUUw9KLAcSFeaUmXhbhC1tVOmSXN8AtyvbrY=; b=WwWY/LNq3KrvYNiFdiElNMXJVXq9Xg9aU0XZCRJZxqR5v/qXWS4phF9i zWvDVyIA48X749230LfIzc7n15RnUzWlfdt6nRP5ng0WbHeRUCgXlmnbK 6TPxgc7MRltSsJQqeUGf84yq1YoNy3jR0fydHXv/njr9PNxYp2UWGake8 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMyYqU5Io8UR/2dsb2JhbABDqWCBBYF0AQQSAR0KUQEqBhMFB1cBBAsICAEQCYdolRKBJgGeSogdYQSIBJE/jDE X-IronPort-AV: E=Sophos;i="4.69,414,1315180800"; d="scan'208";a="58684102" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 27 Oct 2011 17:46:59 +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 p9RHkxbJ028143 for ; Thu, 27 Oct 2011 17:46:59 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); Thu, 27 Oct 2011 23:16:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: JG0= A+YP Bo9O Bylt CMHq CrCz C0md EIYk EMPd EZwz Go+1 G9pn Ho6O H7w3 I8uA J6Pq; 1; cwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {BDC6B6A5-287C-4FE3-BDB8-49B4EB6B2FE7}; cgBtAG8AaABhAG4AcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Thu, 27 Oct 2011 17:46:55 GMT; SQBzAHMAdQBlACAAdwBpAHQAaAAgAHAAYQByAHQAaQBjAGkAcABhAG4AdAAgAHMAYwBvAHAAaQBuAGcAIABpAG4AIAB0AGgAZQAgAGMAdQByAHIAZQBuAHQAIABtAG8AZABlAGwAIABhAG4AZAAgAGkAdABzACAAaQBtAHAAbABpAGMAYQB0AGkAbwBuACAAbwBuACAAYQBzAHMAbwBjAGkAYQB0AGkAbwBuACAAYQB0AHQAcgAgAHIAZQBwAHIAZQBzAGUAbgB0AGEAdABpAG8AbgA= MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {BDC6B6A5-287C-4FE3-BDB8-49B4EB6B2FE7} Content-class: urn:content-classes:message Date: Thu, 27 Oct 2011 23:16:55 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue with participant scoping in the current model and its implication on association attr representation Thread-Index: AcyU0GsfbX9KhUmjQ4OxJW5Nxy1c+Q== From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 27 Oct 2011 17:46:58.0924 (UTC) FILETIME=[6CF892C0:01CC94D0] Subject: [siprec] Issue with participant scoping in the current model and its implication on association attr representation 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, 27 Oct 2011 17:47:03 -0000 (Sorry for lengthy e-mail) This is a follow up to the mail thread http://www.ietf.org/mail-archive/web/siprec/current/msg02810.html In the last IETF meeting there was a consensus that a participant can have a life outside of CS.=20 However the current model scopes participant to always a session. Should we have to change the model to have participant outside scope of session ? I think it may not make sense to model participants under RS as these are participants of Session. The only use case where we can have a participant in a RS with no CS is for Persistent recording sessions (e.g. setup from agent phone(SRC) to SRS) This RS will be setup even without any CS. If an SRC for this case sends a snapshot before a CS starts it may have participant information without any session.=20 Does the WG sees a value in such a use case or should we retain the model as is ? The current model (ver 04) also impacts the way association attributes are represented. Since the current draft (ver-04)the metadata model scopes participant and stream elements to session the schema also was designed the same way. The and attributes are scoped/associated to a session (see section 7.1 example). IOW the association attributes of to are already represented. Now if we have to go with approach 2 for representing association attributes, we will have to do one of the two ways: If we stick the current model/schema: ----------------------------------- We will have represent in the following way. Note this is a mix of approach 1 (existing representation which acheives participant session association) and approach 2 ( for part-stream association). The issue with this approach is if the same participant is simultaneously in multiple sessions( cases like participant goes on hold on one line and talks to another participant) and SRC sends a snapshot then we will have multiple elements each having different session IDs.=20 =20 sip:ram@blr.cisco.com 2010-12-16T23:41:07Z XXX And for participant-stream you will have a new element=20 2010-12-16T23:41:07Z contributing SSRC-1 =20 If we change the model to remove the scoping of participant/stream to session: ------------------------------------------------------------------------ ----- =20 sip:ram@blr.cisco.com=20 2010-12-16T23:41:07Z XXX=20 2010-12-16T23:41:07Z contributing SSRC-1 =20 Let me know your comments. Regards, Ram From eckelcu@cisco.com Thu Oct 27 11:45: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 D5AD221F8BA6 for ; Thu, 27 Oct 2011 11:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.726 X-Spam-Level: X-Spam-Status: No, score=-5.726 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08-h-x8izqgf for ; Thu, 27 Oct 2011 11:45:33 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBC221F8BA2 for ; Thu, 27 Oct 2011 11:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=6821; q=dns/txt; s=iport; t=1319741133; x=1320950733; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0e27sFq0nhPncNn7DAY63kOVnauc2GMLfAp7P1eRNi8=; b=LjzUyOsKjy08qvVxEQpha+ZpYi4NUv008HT1YerguOReMFMFTcCe5PN2 audXvmjUh/2Nr4Bc2K2GYlSYOxfSo8QNnex5hA8foUq4DH+JclLw6R2/D Vz4138tMRUMSVg+55oNhQ6sYGgvR/DYtSj6WtskFNvRwdNBnm3RYpbBh4 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AAFWmqU6rRDoI/2dsb2JhbABDmg+PUYEFgXIBAQEDARIBHQo/BQcEAgEIDgMEAQEBCgYXAQYBRQkIAgQTCBqHYJZDAZ5LiB1hBIgGkT2MSQ X-IronPort-AV: E=Sophos;i="4.69,414,1315180800"; d="scan'208";a="10728373" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 27 Oct 2011 18:45:32 +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 p9RIjWjE022137; Thu, 27 Oct 2011 18:45:32 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); Thu, 27 Oct 2011 11:45:32 -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: Thu, 27 Oct 2011 11:45:31 -0700 Message-ID: In-Reply-To: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AQHMlCrXyyj2zm2fFUyYADHXk3O11pWQeMYA References: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com> From: "Charles Eckel (eckelcu)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 27 Oct 2011 18:45:32.0751 (UTC) FILETIME=[9B6005F0:01CC94D8] Cc: siprec@ietf.org Subject: Re: [siprec] proposed text for dealing with packet loss 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, 27 Oct 2011 18:45:34 -0000 Please see additional inline comments. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Wednesday, October 26, 2011 3:02 PM > To: Charles Eckel (eckelcu) > Cc: > Subject: Re: [siprec] proposed text for dealing with packet loss >=20 > Howdy, > Sorry for the length of this email - it's a lot of text for a one-word change request. :) >=20 >=20 > On Oct 25, 2011, at 6:13 PM, Charles Eckel (eckelcu) wrote: >=20 > > If the SRC does not forward the RTCP reports from the SRS, the UA > > either: > > 1) receives no RTCP reports, in the case where is the SRS is the only > > recipient of the packets >=20 > The _other_ UA in the CS is the receiver of RTP packets, and generates RTCP. In other words, both > real UAs in the CS generate RTCP which gets to each other. >=20 > Though of course there are UAs in the real-world which generate no RTCP to begin with, so in that case > you wont get any - but that just provides examples that doing so doesn't necessarily break RTP, > because calls work without the RTCP today. > (I should note I'm talking about audio, not video) Okay, so we could call out that special case. However, since having the SRC forward the RTCP packets is required in the case of video, and should only help in the case of audio, the MUST seems appropriate and more straightforward to me. The UA receiving the multiple sets of RTCP receiver reports should at worst ignore the ones from the SRS, right? >=20 > > 2) receives RTCP reports from receivers other than the SRS receivers but > > does not receive any reports from the SRS. > > > > In case (1), the UA is not able to help in the recovery of media related > > issues between the UA and the SRS. > > In case (2), the UA may help in the recovery of media related issues > > between the UA and SRC (assuming another recipient's reports indicated > > the issue), but not those between the SRC and the SRS. >=20 > Right, so assume the following diagram: >=20 > +--------+ +--------+ +--------+ > | | A | | B | | > | UA-A |------| SRC |------| UA-B | > | | | | | | > +--------+ +--------+ +--------+ > || > C || D > || > +--------+ > | | > | SRS | > | | > +--------+ >=20 > It is true that if C/D is congested, then for certain codecs the RTCP receiver reports can help > improve the call quality to the SRS, but reduce the call quality for UA-A and UA-B.=20 I may be missing something here because I do not see how the RTCP receiver reports from the SRS would reduce the call quality of UA-A and UA-B. Is it because the recovery attempts by UA-A targeted for the SRS would waste bandwidth on the path to UA-B? > Frankly I think > this is a corner case in the real world, because I would expect people to (a) be able to > control/manage the SRC-SRS path to not be congested, and (b) in some cases even prefer to keep the > call quality of A-B regardless of the SRS's recording quality. I recognize (b) is only for some folks > and not others, but it is a real use-case, and one whereby forwarding on the RTCP reports would be a > bad thing. >=20 > It's also true that if A is congested, then for certain codecs the SRS can help improve the call > quality from UA-A to UA-B if UA-B does not itself generate RTCP reports; and vice-versa if B is > congested, then for certain codecs the SRS can help improve the call quality from UA-B to UA-A if UA-A > does not itself generate RTCP reports. >=20 > BUT for other codecs (like G.711 which I believe is popular), such RTCP receiver reports will not > improve quality, because there isn't much you can do to improve it in the send direction. (and > frankly if both UA-A and UA-B support dynamic codecs, then the odds are they both support RTCP) >=20 Here as well, it may be that the RTCP reports from the SRS do not help, but they should not hurt either. > So... since (1) there's a use-case where forwarding the RTCP reports from SRS is not what the customer > wants, and (2) there're popular codecs which don't improve with it regardless, I propose we change > this: >=20 > > RTCP Receiver Reports generated by the SRS > > MUST be forwarded to the relevant UA. >=20 > To this: > > RTCP Receiver Reports generated by the SRS > > SHOULD be forwarded to the relevant UA. >=20 > -hadriel I do not think changing this one word is an option. If we want to downgrade this MUST to a SHOULD, we need to provide some justification. The only justification I see so far is that forwarding the RTCP packets may cause problems for "badly" broken UAs, where a "somewhat" broken UA ignores RTCP receiver reports, and a "badly" broken UA chokes on rather than ignores unexpected RTCP receiver reports.=20 What if instead, I follow the suggestion Ram and John made that I add some text with a bit more discussion on the implications of using either of the translator models on the participating UAs, such as: ---------------------- 4.1.1. Forwarding Translator When acting as a forwarding translator, RTP received as separate streams from different sources (e.g., from different UAs with different SSRCs) cannot be mixed by the SRC and MUST be sent separately to the SRS. All RTCP reports MUST be passed by the SRC between the UAs and the SRS, such that the UAs and SRS are able to detect any SSRC collisions. RTCP Sender Reports generated by a UA sending a stream MUST be forwarded to the SRS. RTCP Receiver Reports generated by the SRS MUST be forwarded to the relevant UA. In such cases, UAs may receive multiple sets of RTCP Receiver Reports, one or more from other UAs participating in the CS, and one from the SRS participating in the RS. A SIPREC aware UA SHOULD be prepared to process the RTCP Receiver Reports from the SRS, whereas a SIPREC unaware UA may discard such RTCP packets as not of relevance. =20 If SRTP is used on both the CS and the RS, decryption and/or re- encryption may occur. For example, if different keys are used, it will occur. If the same keys are used, it need not occur. If packet loss occurs, either from the UA to the SRC or from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss. The SRC does not play a role in this other than forwarding the associated RTP and RTCP packets. -------------------------- If this is acceptable, I will update the Transcoding Translator section similarly. Cheers, Charles From pkyzivat@alum.mit.edu Thu Oct 27 14:12: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 50D2C21F8B9A for ; Thu, 27 Oct 2011 14:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKw8XvASP0mC for ; Thu, 27 Oct 2011 14:12:05 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 78E9721F8B7F for ; Thu, 27 Oct 2011 14:12:02 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id pvdY1h0091ei1Bg53xC2DR; Thu, 27 Oct 2011 21:12:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id pxC21h01L0tdiYw3kxC2PN; Thu, 27 Oct 2011 21:12:02 +0000 Message-ID: <4EA9C920.8000200@alum.mit.edu> Date: Thu, 27 Oct 2011 17:12:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Issue with participant scoping in the current model and its implication on association attr representation 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, 27 Oct 2011 21:12:06 -0000 On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote: > (Sorry for lengthy e-mail) > > This is a follow up to the mail thread > http://www.ietf.org/mail-archive/web/siprec/current/msg02810.html > > In the last IETF meeting there was a consensus that a participant can > have a life outside of CS. > > However the current model scopes participant to always a session. I don't think that is quite right. The *model* requires that each participant be associated with one or more sessions. It doesn't scope to a single session. > Should we have to change the model to have participant outside scope of > session ? I think it may not make sense to model participants under RS > as these are participants of Session. The only use case where we can > have a participant in a RS with no CS is for Persistent recording > sessions (e.g. setup from agent phone(SRC) to SRS) This RS will be setup > even without any CS. If an SRC for this case sends a snapshot before a > CS starts it may have participant information without any session. > Does the WG sees a value in such a use case or should we retain the > model as is ? IMO the change we would be talking about is that a participant can be associated with *zero* or more sessions, rather than one or more. In addition to the use case Ram mentions above, this would help with the mapping to xml. If we go with participantSessAssoc (as mentioned below) it becomes *possible* to define a participant with no associations to sessions. Allowing the same in the model at least makes them consistent. Thanks, Paul > The current model (ver 04) also impacts the way association attributes > are represented. Since the current draft (ver-04)the metadata model > scopes participant and stream elements to session the schema also was > designed the same way. The and attributes are > scoped/associated to a session (see section 7.1 example). IOW the > association attributes of to are already > represented. > > Now if we have to go with approach 2 for representing association > attributes, we will have to do one of the two ways: > > > If we stick the current model/schema: > ----------------------------------- > We will have represent in the following way. Note this is a mix of > approach 1 (existing representation which acheives participant session > association) and approach 2 ( for part-stream association). The issue > with this approach is if the same participant is simultaneously in > multiple sessions( cases like participant goes on hold on one line and > talks to another participant) and SRC sends a snapshot then we will have > multiple elements each having different session IDs. > id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > sip:ram@blr.cisco.com > 2010-12-16T23:41:07Z > XXX > > > And for participant-stream you will have a new element > > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > 2010-12-16T23:41:07Z > contributing SSRC-1 > > > If we change the model to remove the scoping of participant/stream to > session: > ------------------------------------------------------------------------ > ----- > > id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > sip:ram@blr.cisco.com > > > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425" > 2010-12-16T23:41:07Z > XXX > > > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > 2010-12-16T23:41:07Z > contributing SSRC-1 > > > Let me know your comments. > > Regards, > Ram > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From rmohanr@cisco.com Thu Oct 27 21: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 E943621F886A for ; Thu, 27 Oct 2011 21:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.861 X-Spam-Level: X-Spam-Status: No, score=-6.861 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwcqVTHyx81v for ; Thu, 27 Oct 2011 21:55:10 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABC421F87E2 for ; Thu, 27 Oct 2011 21:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=6492; q=dns/txt; s=iport; t=1319777709; x=1320987309; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=w1AeZQqt8Dt0lQllsOC/m+Lsyu1FrJZ97FH5nMMqKxU=; b=mZRrOCaayVLqN+x9rzZirVqzsOxm1GWfdJvCS4baBUL9N4PWy2EHA6/v qocFLlb5/w6r10ERIOZnHqHR9XDBwJD+75tbwhkSfZde6Se/n3V7c8Gdb 7yiYuhxmPsUBsnDLupocFbYpkPh3iQx1S+OQnaU9bghvgYRCjsPuGEngj 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgAAG41qk5Io8UQ/2dsb2JhbABCDpoDj1GBBYFyAQEBBAEBAQ8BHQo0FwQCAQgOAwQBAQEKBhMEAQYBJh8JCAEBBAEKCAgBEAmHaJZnAZ40iB1hBIgEkT+Lcj8 X-IronPort-AV: E=Sophos;i="4.69,416,1315180800"; d="scan'208";a="1930237" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-3.cisco.com with ESMTP; 28 Oct 2011 04:55:06 +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 p9S4sXg2010818; Fri, 28 Oct 2011 04:55:05 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); Fri, 28 Oct 2011 10:24:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: qEo= AgPe Ah2Q BCMk DIYT DSKQ DaxE DgnT IGmR Kb29 QehL Sk/M TgRu VdMt Vvkg aDnO; 2; cABrAHkAegBpAHYAYQB0AEAAYQBsAHUAbQAuAG0AaQB0AC4AZQBkAHUAOwBzAGkAcAByAGUAYwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {9E37E1E2-6F92-4B0A-BB55-799A6240E80E}; cgBtAG8AaABhAG4AcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Fri, 28 Oct 2011 04:54:27 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABJAHMAcwB1AGUAIAB3AGkAdABoACAAcABhAHIAdABpAGMAaQBwAGEAbgB0ACAAcwBjAG8AcABpAG4AZwAgAGkAbgAgAHQAaABlACAAYwB1AHIAcgBlAG4AdAAgAG0AbwBkAGUAbAAgAGEAbgBkACAAaQB0AHMAIABpAG0AcABsAGkAYwBhAHQAaQBvAG4AIABvAG4AIABhAHMAcwBvAGMAaQBhAHQAaQBvAG4AIABhAHQAdAByACAAcgBlAHAAcgBlAHMAZQBuAHQAYQB0AGkAbwBuAA== MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {9E37E1E2-6F92-4B0A-BB55-799A6240E80E} Content-class: urn:content-classes:message Date: Fri, 28 Oct 2011 10:24:26 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B7ECA@XMB-BGL-417.cisco.com> In-Reply-To: <4EA9C920.8000200@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Issue with participant scoping in the current model and its implication on association attr representation Thread-Index: AcyU7RrlTWgsLRZKRCCiCoFt7+E0oQAP4iYw References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com> <4EA9C920.8000200@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 28 Oct 2011 04:54:47.0134 (UTC) FILETIME=[B77C37E0:01CC952D] Subject: Re: [siprec] Issue with participant scoping in the current model and its implication on association attr representation 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, 28 Oct 2011 04:55:11 -0000 To add to Paul, with the proposed change, the model will look as below +-------------------------------+ | Communication Session (CS) | | | +-------------------------------+ | 0..* |1..* =20 | ^^^^^^^^ | =20 | 2..* |0..* =20 +-------------+ receives +----------------+ =20 | Participant |----------| Media Streams | | |0..* 0..*| |=20 | | | | | | | | | | sends | | | |----------| | | |1.* 0..*| | +-------------+ +----------------+ A participant can be associated with zero or more sessions. And with the above model we can have an approach to define a participant with no associations to sessions and have XML elements separate (like ) for association classes as in approach 2 mentioned below Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, October 28, 2011 2:42 AM > To: siprec@ietf.org > Subject: Re: [siprec] Issue with participant scoping in the current > model and its implication on association attr representation >=20 > On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote: > > (Sorry for lengthy e-mail) > > > > This is a follow up to the mail thread > > http://www.ietf.org/mail-archive/web/siprec/current/msg02810.html > > > > In the last IETF meeting there was a consensus that a participant can > > have a life outside of CS. > > > > However the current model scopes participant to always a session. >=20 > I don't think that is quite right. The *model* requires that each > participant be associated with one or more sessions. It doesn't scope > to > a single session. >=20 > > Should we have to change the model to have participant outside scope > of > > session ? I think it may not make sense to model participants under > RS > > as these are participants of Session. The only use case where we can > > have a participant in a RS with no CS is for Persistent recording > > sessions (e.g. setup from agent phone(SRC) to SRS) This RS will be > setup > > even without any CS. If an SRC for this case sends a snapshot before > a > > CS starts it may have participant information without any session. > > Does the WG sees a value in such a use case or should we retain the > > model as is ? >=20 > IMO the change we would be talking about is that a participant can be > associated with *zero* or more sessions, rather than one or more. >=20 > In addition to the use case Ram mentions above, this would help with > the > mapping to xml. If we go with participantSessAssoc (as mentioned below) > it becomes *possible* to define a participant with no associations to > sessions. Allowing the same in the model at least makes them > consistent. >=20 > Thanks, > Paul >=20 > > The current model (ver 04) also impacts the way association > attributes > > are represented. Since the current draft (ver-04)the metadata model > > scopes participant and stream elements to session the schema also was > > designed the same way. The and attributes are > > scoped/associated to a session (see section 7.1 example). IOW the > > association attributes of to are already > > represented. > > > > Now if we have to go with approach 2 for representing association > > attributes, we will have to do one of the two ways: > > > > > > If we stick the current model/schema: > > ----------------------------------- > > We will have represent in the following way. Note this is a mix of > > approach 1 (existing representation which acheives participant > session > > association) and approach 2 ( for part-stream association). The > issue > > with this approach is if the same participant is simultaneously in > > multiple sessions( cases like participant goes on hold on one line > and > > talks to another participant) and SRC sends a snapshot then we will > have > > multiple elements each having different session IDs. > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > = session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > sip:ram@blr.cisco.com > > 2010-12-16T23:41:07Z time> > > XXX > > > > > > And for participant-stream you will have a new element > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > 2010-12-16T23:41:07Z > > contributing SSRC-1 > > > > > > If we change the model to remove the scoping of participant/stream to > > session: > > --------------------------------------------------------------------- > --- > > ----- > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > sip:ram@blr.cisco.com > > > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > = session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425" > > 2010-12-16T23:41:07Z > > XXX > > > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > 2010-12-16T23:41:07Z > > contributing SSRC-1 > > > > > > Let me know your comments. > > > > Regards, > > Ram > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.r.elwell@gmail.com Fri Oct 28 01:07: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 6E18921F8AD3 for ; Fri, 28 Oct 2011 01:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bMyux3JFojf for ; Fri, 28 Oct 2011 01:07:01 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAE221F87E2 for ; Fri, 28 Oct 2011 01:07:01 -0700 (PDT) Received: by wwe6 with SMTP id 6so3818950wwe.13 for ; Fri, 28 Oct 2011 01:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=1VnzJNxCBPDQyWHn/Dr+pIRxECROrLMQ2VksX76f5NI=; b=U5BU72TVzQgmHq+QW1QoeYwEmmgi4CD5dJcez6Sglxze6POoqtKZJF9ZLaM8vbOmwp BFdowifc1SS+upW4RfAgxgLRWEJ796VrxA7NqZ2DXujvX8AQkkZZDjlYA4miqPhT3slG RUpzDCy40UDvLczFjz/fSW482Ttk0D+uf9xdE= Received: by 10.216.14.89 with SMTP id c67mr575171wec.32.1319789220379; Fri, 28 Oct 2011 01:07:00 -0700 (PDT) Received: from JohnsComputer (cpc1-clif8-2-0-cust418.12-4.cable.virginmedia.com. [82.25.209.163]) by mx.google.com with ESMTPS id gg13sm14002688wbb.8.2011.10.28.01.06.58 (version=SSLv3 cipher=OTHER); Fri, 28 Oct 2011 01:06:59 -0700 (PDT) Message-ID: From: "John Elwell" To: "Ram Mohan R \(rmohanr\)" , References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com> Date: Fri, 28 Oct 2011 09:07:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: Re: [siprec] Issue with participant scoping in the current model andits implication on association attr representation 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, 28 Oct 2011 08:07:02 -0000 A participant has various identification attributes (aor, name) that can be derived from different SIP header fields. So how does the SRC determine that two participants from different CSs are really the same participant? For example, they might have the same SIP URI but different display names, or in one case there might only be the From header field but in the other case there might also be the PAI header field. If the idea is to dump all the information we know about a participant (from the SIP signalling on the CS concerned), into the element, it seems to me the element really should be tied to a single CS. Any attempt to do otherwise is likely to lead to inconsistent results. John ----- Original Message ----- From: "Ram Mohan R (rmohanr)" To: Sent: Thursday, October 27, 2011 6:46 PM Subject: [siprec] Issue with participant scoping in the current model andits implication on association attr representation > (Sorry for lengthy e-mail) > > This is a follow up to the mail thread > http://www.ietf.org/mail-archive/web/siprec/current/msg02810.html > > In the last IETF meeting there was a consensus that a participant can > have a life outside of CS. > > However the current model scopes participant to always a session. > Should we have to change the model to have participant outside scope of > session ? I think it may not make sense to model participants under RS > as these are participants of Session. The only use case where we can > have a participant in a RS with no CS is for Persistent recording > sessions (e.g. setup from agent phone(SRC) to SRS) This RS will be setup > even without any CS. If an SRC for this case sends a snapshot before a > CS starts it may have participant information without any session. > Does the WG sees a value in such a use case or should we retain the > model as is ? > > The current model (ver 04) also impacts the way association attributes > are represented. Since the current draft (ver-04)the metadata model > scopes participant and stream elements to session the schema also was > designed the same way. The and attributes are > scoped/associated to a session (see section 7.1 example). IOW the > association attributes of to are already > represented. > > Now if we have to go with approach 2 for representing association > attributes, we will have to do one of the two ways: > > > If we stick the current model/schema: > ----------------------------------- > We will have represent in the following way. Note this is a mix of > approach 1 (existing representation which acheives participant session > association) and approach 2 ( for part-stream association). The issue > with this approach is if the same participant is simultaneously in > multiple sessions( cases like participant goes on hold on one line and > talks to another participant) and SRC sends a snapshot then we will have > multiple elements each having different session IDs. > id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > sip:ram@blr.cisco.com > 2010-12-16T23:41:07Z > XXX > > > And for participant-stream you will have a new element > > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > 2010-12-16T23:41:07Z > contributing SSRC-1 > > > If we change the model to remove the scoping of participant/stream to > session: > ------------------------------------------------------------------------ > ----- > > id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > sip:ram@blr.cisco.com > > > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425" > 2010-12-16T23:41:07Z > XXX > > > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > 2010-12-16T23:41:07Z > contributing SSRC-1 > > > Let me know your comments. > > Regards, > Ram > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Fri Oct 28 02:10:35 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 2EAF921F8551 for ; Fri, 28 Oct 2011 02:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGbYadZ+f-9n for ; Fri, 28 Oct 2011 02:10:33 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4908421F85AA for ; Fri, 28 Oct 2011 02:10:33 -0700 (PDT) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9S9AWNk020097; Fri, 28 Oct 2011 05:10:33 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 05:09:57 -0400 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, 28 Oct 2011 14:39:47 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159D3F@sonusinmail02.sonusnet.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD082B7ECA@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: participant & stream outside the scope of session thread-index: AcyU7RrlTWgsLRZKRCCiCoFt7+E0oQAP4iYwAAhV0+A= References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com><4EA9C920.8000200@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD082B7ECA@XMB-BGL-417.cisco.com> From: "Ravindran Parthasarathi" To: "Ram Mohan R (rmohanr)" , "Paul Kyzivat" , X-OriginalArrivalTime: 28 Oct 2011 09:09:57.0436 (UTC) FILETIME=[5D22E7C0:01CC9551] Subject: [siprec] participant & stream outside the scope of 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, 28 Oct 2011 09:10:35 -0000 I'm interested in knowing whether folks are interested in handling=20 participant, stream completely outside the scope of session.=20 In fact, we discussed this requirement as part of metadata model=20 discussion and come to the conclusion not to include. In case participant, stream are outside the scope of session, the following=20 recording metadata from SRC is valid: full sip:agent1@callcenter.com urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a Also, in the later partial update, session shall be added and associate=20 with the above participant & stream element. Here, SRS has to maintain participant, stream unique id as a separate flat Data (no hierarchy). Only issue is that SRS has to maintain flat database for Each of these elements. The current -04 draft is based on the assumption that participant and=20 stream are within a session and it is possible for participant & stream=20 to move across multiple sessions using unique id. The rationale of the=20 current draft approach is that commonly used callflow metadata is simple whereas specific corner case callflow like same participant in multiple=20 session will have complex mechanism. In case we see the strong usecases for going for independent stream, Participants which is outside the session, we will go for it. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Ram Mohan R (rmohanr) >Sent: Friday, October 28, 2011 10:24 AM >To: Paul Kyzivat; siprec@ietf.org >Subject: Re: [siprec] Issue with participant scoping in the current >modeland its implication on association attr representation > >To add to Paul, with the proposed change, the model will look as below > > +-------------------------------+ > | Communication Session (CS) | > | | > +-------------------------------+ > | 0..* |1..* > | ^^^^^^^^ | > | 2..* |0..* > +-------------+ receives +----------------+ > | Participant |----------| Media Streams | > | |0..* 0..*| | > | | | | > | | | | > | | sends | | > | |----------| | > | |1.* 0..*| | > +-------------+ +----------------+ > >A participant can be associated with zero or more sessions. > >And with the above model we can have an approach to define a participant >with no associations to sessions and have XML elements separate (like >) for association classes as in approach 2 >mentioned below > >Ram > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Friday, October 28, 2011 2:42 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] Issue with participant scoping in the current >> model and its implication on association attr representation >> >> On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote: >> > (Sorry for lengthy e-mail) >> > >> > This is a follow up to the mail thread >> > http://www.ietf.org/mail-archive/web/siprec/current/msg02810.html >> > >> > In the last IETF meeting there was a consensus that a participant >can >> > have a life outside of CS. >> > >> > However the current model scopes participant to always a session. >> >> I don't think that is quite right. The *model* requires that each >> participant be associated with one or more sessions. It doesn't scope >> to >> a single session. >> >> > Should we have to change the model to have participant outside scope >> of >> > session ? I think it may not make sense to model participants under >> RS >> > as these are participants of Session. The only use case where we can >> > have a participant in a RS with no CS is for Persistent recording >> > sessions (e.g. setup from agent phone(SRC) to SRS) This RS will be >> setup >> > even without any CS. If an SRC for this case sends a snapshot >before >> a >> > CS starts it may have participant information without any session. >> > Does the WG sees a value in such a use case or should we retain the >> > model as is ? >> >> IMO the change we would be talking about is that a participant can be >> associated with *zero* or more sessions, rather than one or more. >> >> In addition to the use case Ram mentions above, this would help with >> the >> mapping to xml. If we go with participantSessAssoc (as mentioned >below) >> it becomes *possible* to define a participant with no associations to >> sessions. Allowing the same in the model at least makes them >> consistent. >> >> Thanks, >> Paul >> >> > The current model (ver 04) also impacts the way association >> attributes >> > are represented. Since the current draft (ver-04)the metadata model >> > scopes participant and stream elements to session the schema also >was >> > designed the same way. The and attributes are >> > scoped/associated to a session (see section 7.1 example). IOW the >> > association attributes of to are already >> > represented. >> > >> > Now if we have to go with approach 2 for representing association >> > attributes, we will have to do one of the two ways: >> > >> > >> > If we stick the current model/schema: >> > ----------------------------------- >> > We will have represent in the following way. Note this is a mix of >> > approach 1 (existing representation which acheives participant >> session >> > association) and approach 2 ( for part-stream association). The >> issue >> > with this approach is if the same participant is simultaneously in >> > multiple sessions( cases like participant goes on hold on one line >> and >> > talks to another participant) and SRC sends a snapshot then we will >> have >> > multiple elements each having different session IDs. >> > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >> > sip:ram@blr.cisco.com >> > 2010-12-16T23:41:07Z> time> >> > XXX >> > >> > >> > And for participant-stream you will have a new element >> > >> > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> > 2010-12-16T23:41:07Z >> > contributing SSRC-1 >> > >> > >> > If we change the model to remove the scoping of participant/stream >to >> > session: >> > >--------------------------------------------------------------------- >> --- >> > ----- >> > >> > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >> > sip:ram@blr.cisco.com >> > >> > >> > > > >participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > = session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425" >> > >2010-12-16T23:41:07Z >> > XXX >> > >> > >> > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> > 2010-12-16T23:41:07Z >> > contributing SSRC-1 >> > >> > >> > Let me know your comments. >> > >> > Regards, >> > Ram >> > _______________________________________________ >> > 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 Fri Oct 28 03:45: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 729B221F8AF0 for ; Fri, 28 Oct 2011 03:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.846 X-Spam-Level: X-Spam-Status: No, score=-6.846 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvwc6v953hZ4 for ; Fri, 28 Oct 2011 03:45:30 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id F0B3D21F8A70 for ; Fri, 28 Oct 2011 03:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=7012; q=dns/txt; s=iport; t=1319798730; x=1321008330; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=NnrNhYQI/BZCCbx9zUWzJ9rtbgmeL/M5LgWmBR4Frz4=; b=LzHclUD00bQVASXCLX479P4uDRQtYYszNMWAmXJhFTk6e4mRMeOwVFXo lPMOZwBnQ+NNRr54Qlm4bOLHt16j9gTTGIc/4KU8dxRVGS+wh+Svk6RYh MYgX/37pb2nfDE6vz7BtLa6MbhtyYzrJGzKe9sUr9AmNsiPuAHCFmDJYW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssAAOmGqk5Io8UQ/2dsb2JhbABCmhKPTIEFgXIBAQEBAwEBAQ8BHQo0FwQCAQgRBAEBCwYTBAEGASAGHwkIAQEEAQoICAEQCYdolg0BniiIImEEiASRP4UAhzE X-IronPort-AV: E=Sophos;i="4.69,417,1315180800"; d="scan'208";a="1959468" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-4.cisco.com with ESMTP; 28 Oct 2011 10:45: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 p9SAjRpU011764; Fri, 28 Oct 2011 10:45:27 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); Fri, 28 Oct 2011 16:15:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: BGkl BwrH CTAc GBwp Hdda IGd9 JCZ0 K0/q O4t4 P11U Q5rX RSKC Ra9J SSmh TS3F UQOy; 2; agBvAGgAbgAuAHIALgBlAGwAdwBlAGwAbABAAGcAbQBhAGkAbAAuAGMAbwBtADsAcwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {0D879CC7-2418-4DDC-87F9-86546BD00561}; cgBtAG8AaABhAG4AcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Fri, 28 Oct 2011 10:45:20 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABJAHMAcwB1AGUAIAB3AGkAdABoACAAcABhAHIAdABpAGMAaQBwAGEAbgB0ACAAcwBjAG8AcABpAG4AZwAgAGkAbgAgAHQAaABlACAAYwB1AHIAcgBlAG4AdAAgAG0AbwBkAGUAbAAgAGEAbgBkAGkAdABzACAAaQBtAHAAbABpAGMAYQB0AGkAbwBuACAAbwBuACAAYQBzAHMAbwBjAGkAYQB0AGkAbwBuACAAYQB0AHQAcgAgAHIAZQBwAHIAZQBzAGUAbgB0AGEAdABpAG8AbgA= MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {0D879CC7-2418-4DDC-87F9-86546BD00561} Content-class: urn:content-classes:message Date: Fri, 28 Oct 2011 16:15:20 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B8005@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Issue with participant scoping in the current model andits implication on association attr representation Thread-Index: AcyVSJSPNWq6hPmNTleZ60y5QLfJKwAFfHcA References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "John Elwell" , X-OriginalArrivalTime: 28 Oct 2011 10:45:26.0936 (UTC) FILETIME=[B42F3980:01CC955E] Subject: Re: [siprec] Issue with participant scoping in the current model andits implication on association attr representation 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, 28 Oct 2011 10:45:31 -0000 Hello John, The change we are discussing to the model is only for participant. A stream will still be associated with 1 or more session. Only for participant we want to make it associate Zero or more sessions. The zero is to give the flexibility to represent the XML in the following way: =20 sip:ram@blr.cisco.com=20 2010-12-16T23:41:07Z XXX=20 2010-12-16T23:41:07Z contributing SSRC-1 =20 In practice there will be very few use-cases where a participant will be zero session. I had given one example below. The main intent to change the model is to keep it inconsistent with XML (approach 2 above) In case we wish not to change to model (as it may creep in some corner cases), we will have to go with a mix of approach1+2 as I outlined below ( first example). Is this ok with the WG ? Regards, Ram > -----Original Message----- > From: John Elwell [mailto:john.r.elwell@gmail.com] > Sent: Friday, October 28, 2011 1:37 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] Issue with participant scoping in the current > model andits implication on association attr representation >=20 > A participant has various identification attributes (aor, name) that > can be > derived from different SIP header fields. So how does the SRC determine > that > two participants from different CSs are really the same participant? > For > example, they might have the same SIP URI but different display names, > or in > one case there might only be the From header field but in the other > case > there might also be the PAI header field. If the idea is to dump all > the > information we know about a participant (from the SIP signalling on the > CS > concerned), into the element, it seems to me the > element really should be tied to a single CS. Any > attempt to > do otherwise is likely to lead to inconsistent results. >=20 > John >=20 >=20 > ----- Original Message ----- > From: "Ram Mohan R (rmohanr)" > To: > Sent: Thursday, October 27, 2011 6:46 PM > Subject: [siprec] Issue with participant scoping in the current model > andits > implication on association attr representation >=20 >=20 > > (Sorry for lengthy e-mail) > > > > This is a follow up to the mail thread > > http://www.ietf.org/mail-archive/web/siprec/current/msg02810.html > > > > In the last IETF meeting there was a consensus that a participant can > > have a life outside of CS. > > > > However the current model scopes participant to always a session. > > Should we have to change the model to have participant outside scope > of > > session ? I think it may not make sense to model participants under > RS > > as these are participants of Session. The only use case where we can > > have a participant in a RS with no CS is for Persistent recording > > sessions (e.g. setup from agent phone(SRC) to SRS) This RS will be > setup > > even without any CS. If an SRC for this case sends a snapshot before > a > > CS starts it may have participant information without any session. > > Does the WG sees a value in such a use case or should we retain the > > model as is ? > > > > The current model (ver 04) also impacts the way association > attributes > > are represented. Since the current draft (ver-04)the metadata model > > scopes participant and stream elements to session the schema also was > > designed the same way. The and attributes are > > scoped/associated to a session (see section 7.1 example). IOW the > > association attributes of to are already > > represented. > > > > Now if we have to go with approach 2 for representing association > > attributes, we will have to do one of the two ways: > > > > > > If we stick the current model/schema: > > ----------------------------------- > > We will have represent in the following way. Note this is a mix of > > approach 1 (existing representation which acheives participant > session > > association) and approach 2 ( for part-stream association). The > issue > > with this approach is if the same participant is simultaneously in > > multiple sessions( cases like participant goes on hold on one line > and > > talks to another participant) and SRC sends a snapshot then we will > have > > multiple elements each having different session IDs. > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > sip:ram@blr.cisco.com > > 2010-12-16T23:41:07Z > > XXX > > > > > > And for participant-stream you will have a new element > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > 2010-12-16T23:41:07Z > > contributing SSRC-1 > > > > > > If we change the model to remove the scoping of participant/stream to > > session: > > --------------------------------------------------------------------- > --- > > ----- > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > sip:ram@blr.cisco.com > > > > > > > = participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425" > > 2010-12-16T23:41:07Z > > XXX > > > > > > > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > 2010-12-16T23:41:07Z > > contributing SSRC-1 > > > > > > Let me know your comments. > > > > Regards, > > Ram > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From john.2.stafford@bt.com Fri Oct 28 06:24: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 989CE21F8B8C for ; Fri, 28 Oct 2011 06:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TVqh2fEehTs for ; Fri, 28 Oct 2011 06:24:00 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id A11AE21F8B88 for ; Fri, 28 Oct 2011 06:23:59 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 28 Oct 2011 14:23:57 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.227]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 28 Oct 2011 14:23:57 +0100 From: To: Date: Fri, 28 Oct 2011 14:23:57 +0100 Thread-Topic: Persistent RS case, when should a recorder consider a CS has ended ? Thread-Index: AQHMlXTYzGCsXdidEkG/D2jI+uiX9A== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_BBA98B7742309546A60F3AE3B4E975A72820ED8FBEEMV64UKRDdoma_" MIME-Version: 1.0 Subject: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? 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, 28 Oct 2011 13:24:00 -0000 --_000_BBA98B7742309546A60F3AE3B4E975A72820ED8FBEEMV64UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Consider the following scenario several phones connected to PBX, all voice record their calls from the phon= e by each having a persistent RS. All calls get initially answered by receptionist, who then conferences in s= omeone to handle the call, then drops out. So there are two phones are conferenced onto same external call, so both ph= ones send metadata for thier RS's to include the call's CS. Since each phone has knowledge of all the conference participants, the CS i= t sends has 3 partiicipants, the two phones and the far party. Also the CS= Id and participant Id's sent by each phone are identical. Now one phone (receptionist) leaves the call, and both phones will sends a = metadata update to say one participant has dissassociated. Now for as long as the call persists, should the receptionists phone, that = has left the call, still include the CS in any full metadata updates it sen= ds, or could it omit the CS ? If it must included it, then over time the receptionists phone may end up h= aving to track multiple calls so as to send metadata updates, it is prefera= ble if it could just forget about the call as it is no longer involved in i= t. So does removing a CS from an RS indicate the CS has ended, or will a recor= der only consider a CS ended when it receives metadata with the CS having a= nd end-time element ? Rgds John Stafford | Solution Architect 1 | BT Global Services --_000_BBA98B7742309546A60F3AE3B4E975A72820ED8FBEEMV64UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Conside= r the following scenario
 
several phones connected to PBX, all= voice record their calls from the phone by each having  a persistent = RS.
 
All calls get initially answered by = receptionist, who then conferences in someone to handle the call, then drop= s out.
 
 
So there are two phones are conferen= ced onto same external call, so both phones send metadata for thier RS's to= include the call's CS.
Since each phone has knowledge of al= l the conference participants, the CS it sends has 3 partiicipants, th= e two phones and the far party.  Also the CS Id and participant Id's s= ent by each phone are identical.
 
Now one phone (receptionist) leaves = the call, and both phones will sends a metadata update to say one participa= nt has dissassociated.
 
Now for as long as the call persists= , should the receptionists phone, that has left the call, still include the= CS in any full metadata updates it sends, or could it omit the CS ?
 
If it must included it, then over ti= me the receptionists phone may end up having to track multiple calls so as = to send metadata updates, it is preferable if it could just forget about th= e call as it is no longer involved in it.
 
So does removing a CS from an RS ind= icate the CS has ended, or will a recorder only consider a CS ended when it= receives metadata with the CS having and end-time element ? 
 
 
 
Rgds
John Stafford | Solution Architect 1 | BT Global = Services
--_000_BBA98B7742309546A60F3AE3B4E975A72820ED8FBEEMV64UKRDdoma_-- From rmohanr@cisco.com Fri Oct 28 06:34: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 B2FC021F84BB for ; Fri, 28 Oct 2011 06:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.832 X-Spam-Level: X-Spam-Status: No, score=-6.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIhb2xqhrtCz for ; Fri, 28 Oct 2011 06:34:30 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 74E1121F84BD for ; Fri, 28 Oct 2011 06:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=15236; q=dns/txt; s=iport; t=1319808869; x=1321018469; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=rCWTHcLnhALYEgYjvbJqaCbBwCEN8CdEUrdBKllNG60=; b=IiLsXAY0CN9KL4QCnsKJ7hS4zGs4I4beG9EnlsVqhfnwR+IH08UzY2pw WE5g6fbQW/I56IP7hFTx/22dsHCPST0b+pg4DMMI2WtM8TC/NBxqOfaLx 8Yry2ua3vVXK2fp7gOcXaDTYtpndzUG9MNDpO1u7J0HE+LxBa9auOXLOZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssAACyuqk5Io8UR/2dsb2JhbABCmhKPTIEFgXIBAQEBAgEBAQEPAR0KLgQCFwQCAQgRBAEBAQoGFwEGASAGHwkIAQEEAQoICAEQAgeHYAiVfAGeJogiYQSIBJE/hQABhzA X-IronPort-AV: E=Sophos;i="4.69,418,1315180800"; d="scan'208";a="1971301" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-3.cisco.com with ESMTP; 28 Oct 2011 13:34:27 +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 p9SDYQ8D011760; Fri, 28 Oct 2011 13:34:26 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, 28 Oct 2011 19:04: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: Fri, 28 Oct 2011 19:04:23 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B806E@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Need Inputs: How to represent attributesofassociation in Metadata Model and in XML ? Thread-Index: AcyUgxjabTGDwIsUSiGpf0vrcAQSAwARqD8gAAB4gS4AKmsw8A== References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com>, <35BCE99A477D6A4986FB2216D8CF2CFD082B7DD5@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: , X-OriginalArrivalTime: 28 Oct 2011 13:34:26.0626 (UTC) FILETIME=[4FE92220:01CC9576] Subject: Re: [siprec] Need Inputs: How to represent attributesofassociation in Metadata Model and 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: Fri, 28 Oct 2011 13:34:31 -0000 Hello John S, Please see inline for answers. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of john.2.stafford@bt.com > Sent: Thursday, October 27, 2011 11:15 PM > To: siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to represent > attributesofassociation in Metadata Model and in XML ? >=20 > I am not clear on the effect on the other XMl elements. >=20 > I presume the participant - CS element will be replaced by > the< participantSessionAssoc>. No. will continue to remain. We are talking about association attributes of participant-session. The other attributes of and which are not association attributes will continue to be the respective elements. >=20 > I also presume and will no longer be needed, and that > the will include an attribute to say send or > recv ? This is a good suggestion. I have not given a thought on this so far. In principle this should be fine as once the association of a participant to a stream ends it stops sending/receiving the same. We need to think through different use-cases to see if its fine to have , inside association element itself. By having send, recv inside the association we can avoid one XML element as they can be attribute. >=20 > Is that correct ? >=20 > I hope the rule will remain that, in the abscence of any recv elements > by default a stream is assumed to be recieved by all participants. No, in the last IETF we agreed it's better to always explicity indicate recv. We will continue to stick to that as I see no reason to change. Regards, Ram >=20 > Rgds > John Stafford | Solution Architect 1 | BT Global Services >=20 > ________________________________________ > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of > Ram Mohan R (rmohanr) [rmohanr@cisco.com] > Sent: 27 October 2011 18:08 > To: John Elwell; Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to represent attributes > ofassociation in Metadata Model and in XML ? >=20 > Hi John, >=20 > Thanks for your comment on this. Yes several of us seem to be inclined > towards approach 2. I like your point that once one of the elements in > the association gets deleted, the association element life ends. SRC > may > choose to send the association element optionally or the SRS can still > learn that as the way you mentioned. >=20 > We ( authors of metadata draft ) discussed internally on this open item > and see some issues with adopting approach 2 as is with the current > model /schema. I will start a separate mail thread for the issue as > this > thread is already too long. >=20 > Thanks, > Ram >=20 >=20 > > -----Original Message----- > > From: John Elwell [mailto:john.r.elwell@gmail.com] > > Sent: Thursday, October 27, 2011 2:03 PM > > To: Ram Mohan R (rmohanr); Paul Kyzivat; siprec@ietf.org > > Subject: Re: [siprec] Need Inputs: How to represent attributes > > ofassociation in Metadata Model and in XML ? > > > > Approach 2 seems reasonable. Could we say that an association is > > implicitly > > deleted (gains a dissociate time) as soon as one of the associated > > elements > > is deleted (gains a dissociate time)? This would reduce the on-the > wire > > document size for both partial and full metadata in some > circumstances > > (e.g., conference termination by the focus). > > > > John > > > > > > ----- Original Message ----- > > From: "Ram Mohan R (rmohanr)" > > To: "Paul Kyzivat" ; > > Sent: Friday, October 14, 2011 4:59 AM > > Subject: Re: [siprec] Need Inputs: How to represent attributes > > ofassociation > > in Metadata Model and in XML ? > > > > > > > Thanks Paul for your comments. I also prefer approach 2 as > mentioned > > > below in this thread. > > > I will wait to hear for comments/opinion from others. > > > > > > Ram > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > >> Behalf Of Paul Kyzivat > > >> Sent: Thursday, October 13, 2011 10:48 PM > > >> To: siprec@ietf.org > > >> Subject: Re: [siprec] Need Inputs: How to represent attributes of > > >> association in Metadata Model and in XML ? > > >> > > >> I like approach 2, as Ram has shown it. It deals with the problems > > > John > > >> raised with the others. > > >> > > >> I didn't follow John's arithmetic on this one, using his 20 party > > >> conference example. As I count that, there are 21 participants > when > > > you > > >> include the focus. Each of the 20 has two stream/participant > > >> associations with the focus, for a total of 40. (The association > is > > >> bidirectional. I can only get to 80 by assuming we had to > represent > > an > > >> association in each direction.) And each has two ids, each of > which > > is > > >> also the id of a stream or participant. So there are really only > 23 > > >> distinct ids that need to be assigned for this. (One for each of > the > > > 21 > > >> participants, and one for each of the two streams.) > > >> > > >> The 40 associations, each carrying two ids, is still kind of a lot > > if > > >> its sent all at once. But when starting up a conference they will > > >> probably be added gradually as each participant joins. Same at the > > end > > >> if they drop off individually. But it could be a bunch together if > > the > > >> conference is forcibly dropped by the focus. But it does minimize > > what > > >> is sent when things happen incrementally. > > >> > > >> There may be some optimizations that can be done - e.g. a sort of > > >> "wildcard" for one of the the two ids in the association class. > E.g. > > >> > > >> > >> participant=3D"*" > > >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > >> 2010-12-16T23:41:07Z > > >> > > >> > > >> (I'm not advocating that particular syntax. Its just something to > > make > > >> the point.) > > >> > > >> Thanks, > > >> Paul > > >> > > >> > > >> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: > > >> > My bad(typo) while sending the example. The correct partial > update > > I > > >> > intended to send is: > > >> > > > >> > > >> > = participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >> > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > >> > 2010-12-16T23:41:07Z time> > > >> > > > >> > > > >> > This is inline with approach 2 where in each association XML > > element > > >> > will have the IDs of the related associated elements. > > >> > > > >> > Ram > > >> > > > >> >> -----Original Message----- > > >> >> From: Leon Portman [mailto:Leon.Portman@nice.com] > > >> >> Sent: Wednesday, October 12, 2011 2:24 PM > > >> >> To: Ram Mohan R (rmohanr); siprec@ietf.org > > >> >> Cc: Ofir Roth > > >> >> Subject: RE: Need Inputs: How to represent attributes of > > > association > > >> > in > > >> >> Metadata Model and in XML ? > > >> >> > > >> >> We do prefer to receive related elements as well, it makes > > >> >> implementation much easier. > > >> >> At least we should get relevant IDs. For example below, SRC > > >> should > > >> >> also send ParticipantId > > >> >> > > >> >> -----Original Message----- > > >> >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >> >> Sent: Wednesday, October 12, 2011 10:52 AM > > >> >> To: Leon Portman; siprec@ietf.org > > >> >> Cc: Ofir Roth > > >> >> Subject: RE: Need Inputs: How to represent attributes of > > > association > > >> > in > > >> >> Metadata Model and in XML ? > > >> >> > > >> >> Leon, > > >> >> Thanks for your response. One of the adv with approach 2 is we > > can > > >> >> indicate only changes in the association without the need to > > >> > indicating > > >> >> the elements ( of association). IOW for the below example, if > > there > > >> is > > >> >> a change in participant-stream association I can simply send > the > > >> >> following in partial update: > > >> >> > > >> >> > > >> >> > >> >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> > > >> >> > 2010-12-16T23:41:07Z > > >> >> > > >> >> > > >> >> Do you see a need to always indicate the related elements too ? > > In > > >> >> which case I see approach 1 as more suitable. > > >> >> > > >> >> Thanks, > > >> >> Ram > > >> >> > > >> >>> -----Original Message----- > > >> >>> From: Leon Portman [mailto:Leon.Portman@nice.com] > > >> >>> Sent: Wednesday, October 12, 2011 12:55 PM > > >> >>> To: Ram Mohan R (rmohanr); siprec@ietf.org > > >> >>> Cc: Ofir Roth > > >> >>> Subject: RE: Need Inputs: How to represent attributes of > > >> association > > >> >>> inmetadata Model and in XML ? > > >> >>> > > >> >>> Ram Hi > > >> >>> > > >> >>> I am ok with approaches 1 and however I do prefer approach > one > > >> >> because > > >> >>> it will be easier for SRS to get decode - association is > inside > > >> >>> relevant element. And it is more readable. > > >> >>> Approach 2 will work as well, however it is important that if > > > there > > >> >>> will be a change in association then to send to SRS not only > > >> updated > > >> >>> association element but also related elements: for example if > > >> stream > > >> >>> was associated to participant and session, send also > participant > > >> and > > >> >>> session latest state. > > >> >>> > > >> >>> Regards > > >> >>> > > >> >>> Leon > > >> >>> > > >> >>> > > >> >>> -----Original Message----- > > >> >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > > On > > >> >>> Behalf Of Ram Mohan R (rmohanr) > > >> >>> Sent: Wednesday, October 12, 2011 7:48 AM > > >> >>> To: siprec@ietf.org > > >> >>> Subject: [siprec] Need Inputs: How to represent attributes of > > >> >>> association in metadata Model and in XML ? > > >> >>> > > >> >>> (Sorry for lengthy e-mail) > > >> >>> > > >> >>> Hi All, > > >> >>> > > >> >>> In the last interim we discussed 4 approaches for representing > > >> >>> attributes of association in XML. > > >> >>> > > >> >>> > > >> >>> Here are some pros/cons for each of them: > > >> >>> Approach 1: > > >> >>> ---------- > > >> >>> Represent the association attribute as a property within one > of > > > the > > >> >>> associated elements. Example given at > http://www.ietf.org/mail- > > >> >>> archive/web/siprec/current/msg02709.html Does not need another > > XML > > >> >>> element and represents the association attributes as > capability > > of > > >> >> one > > >> >>> of the association element. > > >> >>> e.g. > > >> >>> > >> >>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >> >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- > > >> 6da1eeaeb425"> > > >> >>> sip:ram@blr.cisco.com > > >> >>> 2010-12- > > 16T23:41:07Z > >> >> time> > > >> >>> TBD > > >> >>> > >> >>> stream = =3D"urn:uuid:f3373a7b-4958-4e55-8820- > > >> >>> d03a191fb76a > > >> >>> "> > > >> >>> 2010-12- > > >> 16T23:41:07Z > >> >>> time> > > >> >>> contributing SSRC-1 > > >> >>> > In > > >> the > > >> >> above > > >> >>> example the participant contributes a single streams. For each > > >> > stream > > >> >>> the association attribute (participant-stream) is shown with > the > > >> >> stream > > >> >>> ID nested in. > > >> >>> > > >> >>> > > >> >>> Approach 2: > > >> >>> ----------- > > >> >>> In this approach we have a new XML element for every > association > > >> >> class. > > >> >>> This xml element will NOT have a unique ID instead it > references > > >> the > > >> >> ID > > >> >>> of associated elements (shown below). With this approach it is > > > easy > > >> >> to > > >> >>> update as the association class is a separate XML element and > > not > > >> >>> property. > > >> >>> e.g. > > >> >>> > >> >>> = participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >> >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > >> >>> 2010-12-16T23:41:07Z > > >> >>> TBD > > >> >>> > > >> >>> > > >> >>> > >> >>> = participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >> >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > >> >>> 2010-12-16T23:41:07Z > > >> >>> contributing SSRC-1 > > >> >>> > > >> >>> > > >> >>> Approach 3 and 4 are in the below e-mail from John. > > >> >>> Approach 3 defines a new Unique ID for every association XML > > >> elment. > > >> >>> Also it creates alias for the other IDs. In the discussions in > > >> >> interim > > >> >>> there was no strong support for this approach. > > >> >>> > > >> >>> Approach 4 is same as approach 1 where in the association > > element > > >> is > > >> >>> encapsulated in one of the XML elements (to which it is > > >> > associated). > > >> >>> In addition to that it also has reference to the elements > (alias > > > of > > >> >>> IDs) to which the association belongs. > > >> >>> > > >> >>> I prefer approach 2 as it is has a separate XML element to > > >> represent > > >> >>> the association class. The only difference of this XML element > > > from > > >> >>> others is this does not need a unique ID. Instead it > references > > > the > > >> >> IDs > > >> >>> of the elements to which the association belongs. > > >> >>> Since association class is a special class meant to associate > > >> >> multiple > > >> >>> classes, I see it ok to have a representation as in approach 2 > > >> where > > >> >> in > > >> >>> the identifier is the concatenation of the classes to which > the > > >> >>> association belongs to. > > >> >>> > > >> >>> Please provide your comments on this and also suggest any > other > > >> >>> approaches to represent association classes in XML. > > >> >>> > > >> >>> Regards, > > >> >>> Ram > > >> >>> > _______________________________________________ > 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@alum.mit.edu Fri Oct 28 06:35: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 A5AF121F8B42 for ; Fri, 28 Oct 2011 06:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L788B+OfcSMN for ; Fri, 28 Oct 2011 06:35:24 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id A5C6D21F84FC for ; Fri, 28 Oct 2011 06:35:24 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta10.westchester.pa.mail.comcast.net with comcast id qD9J1h0071YDfWL5ADbRMH; Fri, 28 Oct 2011 13:35:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id qDbQ1h0080tdiYw3gDbQKn; Fri, 28 Oct 2011 13:35:25 +0000 Message-ID: <4EAAAF99.1060306@alum.mit.edu> Date: Fri, 28 Oct 2011 09:35:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Issue with participant scoping in the current model andits implication on association attr representation 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, 28 Oct 2011 13:35:25 -0000 On 10/28/11 4:07 AM, John Elwell wrote: > A participant has various identification attributes (aor, name) that can > be derived from different SIP header fields. So how does the SRC > determine that two participants from different CSs are really the same > participant? For example, they might have the same SIP URI but different > display names, or in one case there might only be the From header field > but in the other case there might also be the PAI header field. If the > idea is to dump all the information we know about a participant (from > the SIP signalling on the CS concerned), into the > element, it seems to me the element really should be tied > to a single CS. Any attempt to do otherwise is likely to lead to > inconsistent results. I think we can leave this decision up to the SRC. It can have a variety of ways to determine equivalence of participants in differing CSs. Depending on how it gets into calls it might have special knowledge. It might do so based on Contact address, or by being collocated with the UA. It can clearly know this for a single dialog as it evolves. In the worst case, it *doesn't* recognize that two participants are the same, and so assigns them distinct IDs. This doesn't preclude the SRS from doing analysis on the names/aors of distinct participants and deciding by policy to consider them equivalent. Thanks, Paul > John > > > ----- Original Message ----- From: "Ram Mohan R (rmohanr)" > > To: > Sent: Thursday, October 27, 2011 6:46 PM > Subject: [siprec] Issue with participant scoping in the current model > andits implication on association attr representation > > >> (Sorry for lengthy e-mail) >> >> This is a follow up to the mail thread >> http://www.ietf.org/mail-archive/web/siprec/current/msg02810.html >> >> In the last IETF meeting there was a consensus that a participant can >> have a life outside of CS. >> >> However the current model scopes participant to always a session. >> Should we have to change the model to have participant outside scope of >> session ? I think it may not make sense to model participants under RS >> as these are participants of Session. The only use case where we can >> have a participant in a RS with no CS is for Persistent recording >> sessions (e.g. setup from agent phone(SRC) to SRS) This RS will be setup >> even without any CS. If an SRC for this case sends a snapshot before a >> CS starts it may have participant information without any session. >> Does the WG sees a value in such a use case or should we retain the >> model as is ? >> >> The current model (ver 04) also impacts the way association attributes >> are represented. Since the current draft (ver-04)the metadata model >> scopes participant and stream elements to session the schema also was >> designed the same way. The and attributes are >> scoped/associated to a session (see section 7.1 example). IOW the >> association attributes of to are already >> represented. >> >> Now if we have to go with approach 2 for representing association >> attributes, we will have to do one of the two ways: >> >> >> If we stick the current model/schema: >> ----------------------------------- >> We will have represent in the following way. Note this is a mix of >> approach 1 (existing representation which acheives participant session >> association) and approach 2 ( for part-stream association). The issue >> with this approach is if the same participant is simultaneously in >> multiple sessions( cases like participant goes on hold on one line and >> talks to another participant) and SRC sends a snapshot then we will have >> multiple elements each having different session IDs. >> > id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >> sip:ram@blr.cisco.com >> 2010-12-16T23:41:07Z >> XXX >> >> >> And for participant-stream you will have a new element >> >> > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> 2010-12-16T23:41:07Z >> contributing SSRC-1 >> >> >> If we change the model to remove the scoping of participant/stream to >> session: >> ------------------------------------------------------------------------ >> ----- >> >> > id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >> sip:ram@blr.cisco.com >> >> >> > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425" >> 2010-12-16T23:41:07Z >> XXX >> >> >> > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> 2010-12-16T23:41:07Z >> contributing SSRC-1 >> >> >> Let me know your comments. >> >> Regards, >> Ram >> _______________________________________________ >> 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 pravindran@sonusnet.com Fri Oct 28 06:42: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 6F0F621F8A91 for ; Fri, 28 Oct 2011 06:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jtCoQKpEtJk for ; Fri, 28 Oct 2011 06:42:47 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 06EBC21F8B8C for ; Fri, 28 Oct 2011 06:42:46 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9SDhIQq003343; Fri, 28 Oct 2011 09:43:18 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 09:42:42 -0400 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, 28 Oct 2011 19:12:38 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159D6B@sonusinmail02.sonusnet.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD082B806E@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and in XML ? thread-index: AcyUgxjabTGDwIsUSiGpf0vrcAQSAwARqD8gAAB4gS4AKmsw8AAASw6A References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com>, <35BCE99A477D6A4986FB2216D8CF2CFD082B7DD5@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B806E@XMB-BGL-417.cisco.com> From: "Ravindran Parthasarathi" To: "Ram Mohan R (rmohanr)" , , X-OriginalArrivalTime: 28 Oct 2011 13:42:42.0613 (UTC) FILETIME=[778ABE50:01CC9577] Subject: Re: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and 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: Fri, 28 Oct 2011 13:42:48 -0000 Hi, IMO, send & recv are the element which has to be pushed inside participant stream association element which is inline with the model. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Ram Mohan R (rmohanr) >Sent: Friday, October 28, 2011 7:04 PM >To: john.2.stafford@bt.com; siprec@ietf.org >Subject: Re: [siprec] Need Inputs: How to >representattributesofassociation in Metadata Model and in XML ? > >Hello John S, > >Please see inline for answers. > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of john.2.stafford@bt.com >> Sent: Thursday, October 27, 2011 11:15 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Need Inputs: How to represent >> attributesofassociation in Metadata Model and in XML ? >> >> I am not clear on the effect on the other XMl elements. >> >> I presume the participant - CS element will be replaced by >> the< participantSessionAssoc>. > >No. will continue to remain. We are talking about association >attributes of participant-session. >The other attributes of and which are not >association attributes will continue to be the respective elements. > >> >> I also presume and will no longer be needed, and that >> the will include an attribute to say send >or >> recv ? > >This is a good suggestion. I have not given a thought on this so far. In >principle this should be fine as once the association of a participant >to a stream ends it stops sending/receiving the same. We need to think >through different use-cases to see if its fine to have , >inside association element itself. By having send, recv inside the >association we can avoid one XML element as they can be attribute. > >> >> Is that correct ? >> >> I hope the rule will remain that, in the abscence of any recv >elements >> by default a stream is assumed to be recieved by all participants. > >No, in the last IETF we agreed it's better to always explicity indicate >recv. We will continue to stick to that as I see no reason to change. > >Regards, >Ram > >> >> Rgds >> John Stafford | Solution Architect 1 | BT Global Services >> >> ________________________________________ >> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >> Ram Mohan R (rmohanr) [rmohanr@cisco.com] >> Sent: 27 October 2011 18:08 >> To: John Elwell; Paul Kyzivat; siprec@ietf.org >> Subject: Re: [siprec] Need Inputs: How to represent attributes >> ofassociation in Metadata Model and in XML ? >> >> Hi John, >> >> Thanks for your comment on this. Yes several of us seem to be inclined >> towards approach 2. I like your point that once one of the elements >in >> the association gets deleted, the association element life ends. SRC >> may >> choose to send the association element optionally or the SRS can still >> learn that as the way you mentioned. >> >> We ( authors of metadata draft ) discussed internally on this open >item >> and see some issues with adopting approach 2 as is with the current >> model /schema. I will start a separate mail thread for the issue as >> this >> thread is already too long. >> >> Thanks, >> Ram >> >> >> > -----Original Message----- >> > From: John Elwell [mailto:john.r.elwell@gmail.com] >> > Sent: Thursday, October 27, 2011 2:03 PM >> > To: Ram Mohan R (rmohanr); Paul Kyzivat; siprec@ietf.org >> > Subject: Re: [siprec] Need Inputs: How to represent attributes >> > ofassociation in Metadata Model and in XML ? >> > >> > Approach 2 seems reasonable. Could we say that an association is >> > implicitly >> > deleted (gains a dissociate time) as soon as one of the associated >> > elements >> > is deleted (gains a dissociate time)? This would reduce the on-the >> wire >> > document size for both partial and full metadata in some >> circumstances >> > (e.g., conference termination by the focus). >> > >> > John >> > >> > >> > ----- Original Message ----- >> > From: "Ram Mohan R (rmohanr)" >> > To: "Paul Kyzivat" ; >> > Sent: Friday, October 14, 2011 4:59 AM >> > Subject: Re: [siprec] Need Inputs: How to represent attributes >> > ofassociation >> > in Metadata Model and in XML ? >> > >> > >> > > Thanks Paul for your comments. I also prefer approach 2 as >> mentioned >> > > below in this thread. >> > > I will wait to hear for comments/opinion from others. >> > > >> > > Ram >> > > >> > >> -----Original Message----- >> > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> > >> Behalf Of Paul Kyzivat >> > >> Sent: Thursday, October 13, 2011 10:48 PM >> > >> To: siprec@ietf.org >> > >> Subject: Re: [siprec] Need Inputs: How to represent attributes of >> > >> association in Metadata Model and in XML ? >> > >> >> > >> I like approach 2, as Ram has shown it. It deals with the >problems >> > > John >> > >> raised with the others. >> > >> >> > >> I didn't follow John's arithmetic on this one, using his 20 party >> > >> conference example. As I count that, there are 21 participants >> when >> > > you >> > >> include the focus. Each of the 20 has two stream/participant >> > >> associations with the focus, for a total of 40. (The association >> is >> > >> bidirectional. I can only get to 80 by assuming we had to >> represent >> > an >> > >> association in each direction.) And each has two ids, each of >> which >> > is >> > >> also the id of a stream or participant. So there are really only >> 23 >> > >> distinct ids that need to be assigned for this. (One for each of >> the >> > > 21 >> > >> participants, and one for each of the two streams.) >> > >> >> > >> The 40 associations, each carrying two ids, is still kind of a >lot >> > if >> > >> its sent all at once. But when starting up a conference they will >> > >> probably be added gradually as each participant joins. Same at >the >> > end >> > >> if they drop off individually. But it could be a bunch together >if >> > the >> > >> conference is forcibly dropped by the focus. But it does minimize >> > what >> > >> is sent when things happen incrementally. >> > >> >> > >> There may be some optimizations that can be done - e.g. a sort of >> > >> "wildcard" for one of the the two ids in the association class. >> E.g. >> > >> >> > >> > > >> participant=3D"*" >> > >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> > >> 2010-12-16T23:41:07Z >> > >> >> > >> >> > >> (I'm not advocating that particular syntax. Its just something to >> > make >> > >> the point.) >> > >> >> > >> Thanks, >> > >> Paul >> > >> >> > >> >> > >> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: >> > >> > My bad(typo) while sending the example. The correct partial >> update >> > I >> > >> > intended to send is: >> > >> > >> > >> > > > >> > = participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >> > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> > >> > 2010-12-16T23:41:07Z> time> >> > >> > >> > >> > >> > >> > This is inline with approach 2 where in each association XML >> > element >> > >> > will have the IDs of the related associated elements. >> > >> > >> > >> > Ram >> > >> > >> > >> >> -----Original Message----- >> > >> >> From: Leon Portman [mailto:Leon.Portman@nice.com] >> > >> >> Sent: Wednesday, October 12, 2011 2:24 PM >> > >> >> To: Ram Mohan R (rmohanr); siprec@ietf.org >> > >> >> Cc: Ofir Roth >> > >> >> Subject: RE: Need Inputs: How to represent attributes of >> > > association >> > >> > in >> > >> >> Metadata Model and in XML ? >> > >> >> >> > >> >> We do prefer to receive related elements as well, it makes >> > >> >> implementation much easier. >> > >> >> At least we should get relevant IDs. For example below, SRC >> > >> should >> > >> >> also send ParticipantId >> > >> >> >> > >> >> -----Original Message----- >> > >> >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> > >> >> Sent: Wednesday, October 12, 2011 10:52 AM >> > >> >> To: Leon Portman; siprec@ietf.org >> > >> >> Cc: Ofir Roth >> > >> >> Subject: RE: Need Inputs: How to represent attributes of >> > > association >> > >> > in >> > >> >> Metadata Model and in XML ? >> > >> >> >> > >> >> Leon, >> > >> >> Thanks for your response. One of the adv with approach 2 is we >> > can >> > >> >> indicate only changes in the association without the need to >> > >> > indicating >> > >> >> the elements ( of association). IOW for the below example, if >> > there >> > >> is >> > >> >> a change in participant-stream association I can simply send >> the >> > >> >> following in partial update: >> > >> >> >> > >> >> >> > >> >> > > >> >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> >> > >> >> >> 2010-12-16T23:41:07Z >> > >> >> >> > >> >> >> > >> >> Do you see a need to always indicate the related elements too >? >> > In >> > >> >> which case I see approach 1 as more suitable. >> > >> >> >> > >> >> Thanks, >> > >> >> Ram >> > >> >> >> > >> >>> -----Original Message----- >> > >> >>> From: Leon Portman [mailto:Leon.Portman@nice.com] >> > >> >>> Sent: Wednesday, October 12, 2011 12:55 PM >> > >> >>> To: Ram Mohan R (rmohanr); siprec@ietf.org >> > >> >>> Cc: Ofir Roth >> > >> >>> Subject: RE: Need Inputs: How to represent attributes of >> > >> association >> > >> >>> inmetadata Model and in XML ? >> > >> >>> >> > >> >>> Ram Hi >> > >> >>> >> > >> >>> I am ok with approaches 1 and however I do prefer approach >> one >> > >> >> because >> > >> >>> it will be easier for SRS to get decode - association is >> inside >> > >> >>> relevant element. And it is more readable. >> > >> >>> Approach 2 will work as well, however it is important that if >> > > there >> > >> >>> will be a change in association then to send to SRS not only >> > >> updated >> > >> >>> association element but also related elements: for example if >> > >> stream >> > >> >>> was associated to participant and session, send also >> participant >> > >> and >> > >> >>> session latest state. >> > >> >>> >> > >> >>> Regards >> > >> >>> >> > >> >>> Leon >> > >> >>> >> > >> >>> >> > >> >>> -----Original Message----- >> > >> >>> From: siprec-bounces@ietf.org >[mailto:siprec-bounces@ietf.org] >> > On >> > >> >>> Behalf Of Ram Mohan R (rmohanr) >> > >> >>> Sent: Wednesday, October 12, 2011 7:48 AM >> > >> >>> To: siprec@ietf.org >> > >> >>> Subject: [siprec] Need Inputs: How to represent attributes of >> > >> >>> association in metadata Model and in XML ? >> > >> >>> >> > >> >>> (Sorry for lengthy e-mail) >> > >> >>> >> > >> >>> Hi All, >> > >> >>> >> > >> >>> In the last interim we discussed 4 approaches for >representing >> > >> >>> attributes of association in XML. >> > >> >>> >> > >> >>> >> > >> >>> Here are some pros/cons for each of them: >> > >> >>> Approach 1: >> > >> >>> ---------- >> > >> >>> Represent the association attribute as a property within one >> of >> > > the >> > >> >>> associated elements. Example given at >> http://www.ietf.org/mail- >> > >> >>> archive/web/siprec/current/msg02709.html Does not need >another >> > XML >> > >> >>> element and represents the association attributes as >> capability >> > of >> > >> >> one >> > >> >>> of the association element. >> > >> >>> e.g. >> > >> >>> > > >> >>> >id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >> >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- >> > >> 6da1eeaeb425"> >> > >> >>> sip:ram@blr.cisco.com >> > >> >>> 2010-12- >> > 16T23:41:07Z> > >> >> time> >> > >> >>> TBD >> > >> >>> > > >> >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820- >> > >> >>> d03a191fb76a >> > >> >>> "> >> > >> >>> 2010-12- >> > >> 16T23:41:07Z> > >> >>> time> >> > >> >>> contributing SSRC-1 >> > >> >>> >> In >> > >> the >> > >> >> above >> > >> >>> example the participant contributes a single streams. For >each >> > >> > stream >> > >> >>> the association attribute (participant-stream) is shown with >> the >> > >> >> stream >> > >> >>> ID nested in. >> > >> >>> >> > >> >>> >> > >> >>> Approach 2: >> > >> >>> ----------- >> > >> >>> In this approach we have a new XML element for every >> association >> > >> >> class. >> > >> >>> This xml element will NOT have a unique ID instead it >> references >> > >> the >> > >> >> ID >> > >> >>> of associated elements (shown below). With this approach it >is >> > > easy >> > >> >> to >> > >> >>> update as the association class is a separate XML element and >> > not >> > >> >>> property. >> > >> >>> e.g. >> > >> >>> > > >> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >> >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >> > >> >>> 2010-12-16T23:41:07Z >> > >> >>> TBD >> > >> >>> >> > >> >>> >> > >> >>> > > >> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >> >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a = "> >> > >> >>> 2010-12-16T23:41:07Z >> > >> >>> contributing SSRC-1 >> > >> >>> >> > >> >>> >> > >> >>> Approach 3 and 4 are in the below e-mail from John. >> > >> >>> Approach 3 defines a new Unique ID for every association XML >> > >> elment. >> > >> >>> Also it creates alias for the other IDs. In the discussions >in >> > >> >> interim >> > >> >>> there was no strong support for this approach. >> > >> >>> >> > >> >>> Approach 4 is same as approach 1 where in the association >> > element >> > >> is >> > >> >>> encapsulated in one of the XML elements (to which it is >> > >> > associated). >> > >> >>> In addition to that it also has reference to the elements >> (alias >> > > of >> > >> >>> IDs) to which the association belongs. >> > >> >>> >> > >> >>> I prefer approach 2 as it is has a separate XML element to >> > >> represent >> > >> >>> the association class. The only difference of this XML >element >> > > from >> > >> >>> others is this does not need a unique ID. Instead it >> references >> > > the >> > >> >> IDs >> > >> >>> of the elements to which the association belongs. >> > >> >>> Since association class is a special class meant to associate >> > >> >> multiple >> > >> >>> classes, I see it ok to have a representation as in approach >2 >> > >> where >> > >> >> in >> > >> >>> the identifier is the concatenation of the classes to which >> the >> > >> >>> association belongs to. >> > >> >>> >> > >> >>> Please provide your comments on this and also suggest any >> other >> > >> >>> approaches to represent association classes in XML. >> > >> >>> >> > >> >>> Regards, >> > >> >>> Ram >> > >> >>> >> _______________________________________________ >> 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 pravindran@sonusnet.com Fri Oct 28 06:59: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 4A5B421F8A97 for ; Fri, 28 Oct 2011 06:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R4paAnuMCW7 for ; Fri, 28 Oct 2011 06:59:18 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4982F21F8677 for ; Fri, 28 Oct 2011 06:59:18 -0700 (PDT) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9SDxpbK013885; Fri, 28 Oct 2011 09:59:51 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 09:59:15 -0400 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_01CC9579.B3206C6C" Date: Fri, 28 Oct 2011 19:28:41 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159D6E@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? thread-index: AQHMlXTYzGCsXdidEkG/D2jI+uiX9JWRwZ8A References: From: "Ravindran Parthasarathi" To: , X-OriginalArrivalTime: 28 Oct 2011 13:59:15.0705 (UTC) FILETIME=[C7788E90:01CC9579] Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? 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, 28 Oct 2011 13:59:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9579.B3206C6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, =20 IMO, your requirement is already addressed as part of SIPREC metadata with group (CSG) mechanism. =20 1) Receptionist to customer is CS1 with CSG1 using RS1. RS1 is from Receptionist to SRS. 2) Agent1 to customer is CS2 with CSG1 with RS2. RS2 is from agent to SRS. =20 SRS will be able to group this session (CSG) because of the unique CSG id and able to differentiate CS between receptionist & agent 1 using CS id. How CSG id passed across between receptionist & agent1 is outside the scope of SIPREC. Each update shall be go asynchronously and unique-id helps to group it together in SRS. Please let me know in case I'm missing something in your requirement. =20 Thanks Partha =20 =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of john.2.stafford@bt.com Sent: Friday, October 28, 2011 6:54 PM To: siprec@ietf.org Subject: [siprec] Persistent RS case,when should a recorder consider a CS has ended ? =20 Consider the following scenario =20 several phones connected to PBX, all voice record their calls from the phone by each having a persistent RS. =20 All calls get initially answered by receptionist, who then conferences in someone to handle the call, then drops out. =20 =20 So there are two phones are conferenced onto same external call, so both phones send metadata for thier RS's to include the call's CS.=20 Since each phone has knowledge of all the conference participants, the CS it sends has 3 partiicipants, the two phones and the far party. Also the CS Id and participant Id's sent by each phone are identical. =20 Now one phone (receptionist) leaves the call, and both phones will sends a metadata update to say one participant has dissassociated. =20 Now for as long as the call persists, should the receptionists phone, that has left the call, still include the CS in any full metadata updates it sends, or could it omit the CS ? =20 If it must included it, then over time the receptionists phone may end up having to track multiple calls so as to send metadata updates, it is preferable if it could just forget about the call as it is no longer involved in it. =20 So does removing a CS from an RS indicate the CS has ended, or will a recorder only consider a CS ended when it receives metadata with the CS having and end-time element ? =20 =20 =20 =20 Rgds John Stafford | Solution Architect 1 | BT Global Services=20 ------_=_NextPart_001_01CC9579.B3206C6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John,

 

IMO, your requirement is already addressed as part of = SIPREC metadata with group (CSG) mechanism.

 

1)      Receptionist to customer is CS1 with CSG1 using RS1. RS1 = is from Receptionist to SRS.

2)      Agent1 to customer is CS2 with CSG1 with RS2. RS2 is from = agent to SRS.

 

SRS will be able to group this session (CSG) because of = the unique CSG id and able to differentiate CS between receptionist & = agent 1 using CS id. How CSG id passed across between receptionist & agent1 = is outside the scope of SIPREC. Each update shall be go asynchronously and unique-id helps to group it together in SRS. Please let me know in case = I’m missing something in your requirement.

 

Thanks

Partha

 

 

From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = john.2.stafford@bt.com
Sent: Friday, October 28, 2011 6:54 PM
To: siprec@ietf.org
Subject: [siprec] Persistent RS case,when should a recorder = consider a CS has ended ?

 

Consider the following scenario

 

several phones connected to PBX, all voice record their = calls from the phone by each having  a persistent RS.

 

All calls get initially answered by receptionist, who then conferences in someone to handle the call, then drops = out.

 

 

So there are two phones are conferenced onto same external = call, so both phones send metadata for thier RS's to include the call's CS. =

Since each phone has knowledge of all the conference participants, the CS it sends has 3 partiicipants, the two phones = and the far party.  Also the CS Id and participant Id's sent by each phone are identical.

 

Now one phone (receptionist) leaves the call, and both = phones will sends a metadata update to say one participant has = dissassociated.

 

Now for as long as the call persists, should the = receptionists phone, that has left the call, still include the CS in any full metadata updates it sends, or could it omit the CS ?

 

If it must included it, then over time the receptionists = phone may end up having to track multiple calls so as to send metadata updates, it = is preferable if it could just forget about the call as it is no longer = involved in it.

 

So does removing a CS from an RS indicate the CS has ended, = or will a recorder only consider a CS ended when it receives metadata with = the CS having and end-time element ? 

 

 

 

Rgds

John Stafford | Solution = Architect 1 | BT Global Services

------_=_NextPart_001_01CC9579.B3206C6C-- From pkyzivat@alum.mit.edu Fri Oct 28 07:15: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 4297E21F8A80 for ; Fri, 28 Oct 2011 07:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCXJF3Z2CHuK for ; Fri, 28 Oct 2011 07:15:08 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0B721F8A70 for ; Fri, 28 Oct 2011 07:15:08 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id qDKA1h0011YDfWL54EF831; Fri, 28 Oct 2011 14:15:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id qEF71h0140tdiYw3gEF7G9; Fri, 28 Oct 2011 14:15:08 +0000 Message-ID: <4EAAB8E9.8070708@alum.mit.edu> Date: Fri, 28 Oct 2011 10:15:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com><4EA9C920.8000200@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD082B7ECA@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D3F@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D3F@sonusinmail02.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] participant & stream outside the scope of 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, 28 Oct 2011 14:15:09 -0000 This proposes an additional change, to remove the subordination of stream to session. IMO this should be considered separately from participant, as the arguments are different. AFAICT, the use case Partha gives below is the only one that calls for stream independent of session. And I'm not sure of the need for this. ISTM the only reason to do this is to really record streams from participants when there is no session. This might allow capturing media earlier during call setup, by defining the streams early, and associating them with participants and sessions when that becomes known. *If* an SRS can figure out how to take advantage of that. Thanks, Paul On 10/28/11 5:09 AM, Ravindran Parthasarathi wrote: > change in metadata> > > I'm interested in knowing whether folks are interested in handling > participant, stream completely outside the scope of session. > In fact, we discussed this requirement as part of metadata model > discussion and come to the conclusion not to include. In case > participant, stream are outside the scope of session, the following > recording metadata from SRC is valid: > > > full > id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > sip:agent1@callcenter.com > urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a > > > > > > > > > > Also, in the later partial update, session shall be added and associate > with the above participant& stream element. > > Here, SRS has to maintain participant, stream unique id as a separate > flat > Data (no hierarchy). Only issue is that SRS has to maintain flat > database for > Each of these elements. > > The current -04 draft is based on the assumption that participant and > stream are within a session and it is possible for participant& stream > to move across multiple sessions using unique id. The rationale of the > current draft approach is that commonly used callflow metadata is simple > > whereas specific corner case callflow like same participant in multiple > session will have complex mechanism. > > In case we see the strong usecases for going for independent stream, > Participants which is outside the session, we will go for it. > > Thanks > Partha > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf >> Of Ram Mohan R (rmohanr) >> Sent: Friday, October 28, 2011 10:24 AM >> To: Paul Kyzivat; siprec@ietf.org >> Subject: Re: [siprec] Issue with participant scoping in the current >> modeland its implication on association attr representation >> >> To add to Paul, with the proposed change, the model will look as below >> >> +-------------------------------+ >> | Communication Session (CS) | >> | | >> +-------------------------------+ >> | 0..* |1..* >> | ^^^^^^^^ | >> | 2..* |0..* >> +-------------+ receives +----------------+ >> | Participant |----------| Media Streams | >> | |0..* 0..*| | >> | | | | >> | | | | >> | | sends | | >> | |----------| | >> | |1.* 0..*| | >> +-------------+ +----------------+ >> >> A participant can be associated with zero or more sessions. >> >> And with the above model we can have an approach to define a > participant >> with no associations to sessions and have XML elements separate (like >> ) for association classes as in approach 2 >> mentioned below >> >> Ram >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Friday, October 28, 2011 2:42 AM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Issue with participant scoping in the current >>> model and its implication on association attr representation >>> >>> On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote: >>>> (Sorry for lengthy e-mail) >>>> >>>> This is a follow up to the mail thread >>>> http://www.ietf.org/mail-archive/web/siprec/current/msg02810.html >>>> >>>> In the last IETF meeting there was a consensus that a participant >> can >>>> have a life outside of CS. >>>> >>>> However the current model scopes participant to always a session. >>> >>> I don't think that is quite right. The *model* requires that each >>> participant be associated with one or more sessions. It doesn't scope >>> to >>> a single session. >>> >>>> Should we have to change the model to have participant outside > scope >>> of >>>> session ? I think it may not make sense to model participants under >>> RS >>>> as these are participants of Session. The only use case where we > can >>>> have a participant in a RS with no CS is for Persistent recording >>>> sessions (e.g. setup from agent phone(SRC) to SRS) This RS will be >>> setup >>>> even without any CS. If an SRC for this case sends a snapshot >> before >>> a >>>> CS starts it may have participant information without any session. >>>> Does the WG sees a value in such a use case or should we retain the >>>> model as is ? >>> >>> IMO the change we would be talking about is that a participant can be >>> associated with *zero* or more sessions, rather than one or more. >>> >>> In addition to the use case Ram mentions above, this would help with >>> the >>> mapping to xml. If we go with participantSessAssoc (as mentioned >> below) >>> it becomes *possible* to define a participant with no associations to >>> sessions. Allowing the same in the model at least makes them >>> consistent. >>> >>> Thanks, >>> Paul >>> >>>> The current model (ver 04) also impacts the way association >>> attributes >>>> are represented. Since the current draft (ver-04)the metadata model >>>> scopes participant and stream elements to session the schema also >> was >>>> designed the same way. The and attributes > are >>>> scoped/associated to a session (see section 7.1 example). IOW the >>>> association attributes of to are already >>>> represented. >>>> >>>> Now if we have to go with approach 2 for representing association >>>> attributes, we will have to do one of the two ways: >>>> >>>> >>>> If we stick the current model/schema: >>>> ----------------------------------- >>>> We will have represent in the following way. Note this is a mix of >>>> approach 1 (existing representation which acheives participant >>> session >>>> association) and approach 2 ( for part-stream association). The >>> issue >>>> with this approach is if the same participant is simultaneously in >>>> multiple sessions( cases like participant goes on hold on one line >>> and >>>> talks to another participant) and SRC sends a snapshot then we will >>> have >>>> multiple elements each having different session IDs. >>>> >>> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>> > session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>> sip:ram@blr.cisco.com >>>> 2010-12-16T23:41:07Z>> time> >>>> XXX >>>> >>>> >>>> And for participant-stream you will have a new element >>>> >>>> >>> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>> 2010-12-16T23:41:07Z >>>> contributing SSRC-1 >>>> >>>> >>>> If we change the model to remove the scoping of participant/stream >> to >>>> session: >>>> >> --------------------------------------------------------------------- >>> --- >>>> ----- >>>> >>>> >>> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >>>> sip:ram@blr.cisco.com >>>> >>>> >>>> >>> >> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425" >>>> >> 2010-12-16T23:41:07Z >>>> XXX >>>> >>>> >>>> >>> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>> 2010-12-16T23:41:07Z >>>> contributing SSRC-1 >>>> >>>> >>>> Let me know your comments. >>>> >>>> Regards, >>>> Ram >>>> _______________________________________________ >>>> 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@alum.mit.edu Fri Oct 28 07:19: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 C32AD21F85F7 for ; Fri, 28 Oct 2011 07:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlQvsHACVbOV for ; Fri, 28 Oct 2011 07:19:43 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 3634F21F84C1 for ; Fri, 28 Oct 2011 07:19:43 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta14.westchester.pa.mail.comcast.net with comcast id qDUW1h00317dt5G5EEKj0u; Fri, 28 Oct 2011 14:19:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta13.westchester.pa.mail.comcast.net with comcast id qEKi1h00y0tdiYw3ZEKjpD; Fri, 28 Oct 2011 14:19:43 +0000 Message-ID: <4EAAB9FC.4000902@alum.mit.edu> Date: Fri, 28 Oct 2011 10:19:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com>, <35BCE99A477D6A4986FB2216D8CF2CFD082B7DD5@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B806E@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D6B@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D6B@sonusinmail02.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and 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: Fri, 28 Oct 2011 14:19:44 -0000 Yes, this seems the right thing to do. Thanks, Paul On 10/28/11 9:42 AM, Ravindran Parthasarathi wrote: > Hi, > > IMO, send& recv are the element which has to be pushed inside > participant stream association element which is inline with the model. > > Thanks > Partha > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf >> Of Ram Mohan R (rmohanr) >> Sent: Friday, October 28, 2011 7:04 PM >> To: john.2.stafford@bt.com; siprec@ietf.org >> Subject: Re: [siprec] Need Inputs: How to >> representattributesofassociation in Metadata Model and in XML ? >> >> Hello John S, >> >> Please see inline for answers. >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of john.2.stafford@bt.com >>> Sent: Thursday, October 27, 2011 11:15 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Need Inputs: How to represent >>> attributesofassociation in Metadata Model and in XML ? >>> >>> I am not clear on the effect on the other XMl elements. >>> >>> I presume the participant - CS element will be replaced by >>> the< participantSessionAssoc>. >> >> No. will continue to remain. We are talking about association >> attributes of participant-session. >> The other attributes of and which are not >> association attributes will continue to be the respective elements. >> >>> >>> I also presume and will no longer be needed, and that >>> the will include an attribute to say send >> or >>> recv ? >> >> This is a good suggestion. I have not given a thought on this so far. > In >> principle this should be fine as once the association of a participant >> to a stream ends it stops sending/receiving the same. We need to think >> through different use-cases to see if its fine to have, >> inside association element itself. By having send, recv inside the >> association we can avoid one XML element as they can be attribute. >> >>> >>> Is that correct ? >>> >>> I hope the rule will remain that, in the abscence of any recv >> elements >>> by default a stream is assumed to be recieved by all participants. >> >> No, in the last IETF we agreed it's better to always explicity indicate >> recv. We will continue to stick to that as I see no reason to change. >> >> Regards, >> Ram >> >>> >>> Rgds >>> John Stafford | Solution Architect 1 | BT Global Services >>> >>> ________________________________________ >>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >>> Ram Mohan R (rmohanr) [rmohanr@cisco.com] >>> Sent: 27 October 2011 18:08 >>> To: John Elwell; Paul Kyzivat; siprec@ietf.org >>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>> ofassociation in Metadata Model and in XML ? >>> >>> Hi John, >>> >>> Thanks for your comment on this. Yes several of us seem to be > inclined >>> towards approach 2. I like your point that once one of the elements >> in >>> the association gets deleted, the association element life ends. SRC >>> may >>> choose to send the association element optionally or the SRS can > still >>> learn that as the way you mentioned. >>> >>> We ( authors of metadata draft ) discussed internally on this open >> item >>> and see some issues with adopting approach 2 as is with the current >>> model /schema. I will start a separate mail thread for the issue as >>> this >>> thread is already too long. >>> >>> Thanks, >>> Ram >>> >>> >>>> -----Original Message----- >>>> From: John Elwell [mailto:john.r.elwell@gmail.com] >>>> Sent: Thursday, October 27, 2011 2:03 PM >>>> To: Ram Mohan R (rmohanr); Paul Kyzivat; siprec@ietf.org >>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>> ofassociation in Metadata Model and in XML ? >>>> >>>> Approach 2 seems reasonable. Could we say that an association is >>>> implicitly >>>> deleted (gains a dissociate time) as soon as one of the associated >>>> elements >>>> is deleted (gains a dissociate time)? This would reduce the on-the >>> wire >>>> document size for both partial and full metadata in some >>> circumstances >>>> (e.g., conference termination by the focus). >>>> >>>> John >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Ram Mohan R (rmohanr)" >>>> To: "Paul Kyzivat"; >>>> Sent: Friday, October 14, 2011 4:59 AM >>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>> ofassociation >>>> in Metadata Model and in XML ? >>>> >>>> >>>>> Thanks Paul for your comments. I also prefer approach 2 as >>> mentioned >>>>> below in this thread. >>>>> I will wait to hear for comments/opinion from others. >>>>> >>>>> Ram >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On >>>>>> Behalf Of Paul Kyzivat >>>>>> Sent: Thursday, October 13, 2011 10:48 PM >>>>>> To: siprec@ietf.org >>>>>> Subject: Re: [siprec] Need Inputs: How to represent attributes > of >>>>>> association in Metadata Model and in XML ? >>>>>> >>>>>> I like approach 2, as Ram has shown it. It deals with the >> problems >>>>> John >>>>>> raised with the others. >>>>>> >>>>>> I didn't follow John's arithmetic on this one, using his 20 > party >>>>>> conference example. As I count that, there are 21 participants >>> when >>>>> you >>>>>> include the focus. Each of the 20 has two stream/participant >>>>>> associations with the focus, for a total of 40. (The association >>> is >>>>>> bidirectional. I can only get to 80 by assuming we had to >>> represent >>>> an >>>>>> association in each direction.) And each has two ids, each of >>> which >>>> is >>>>>> also the id of a stream or participant. So there are really only >>> 23 >>>>>> distinct ids that need to be assigned for this. (One for each of >>> the >>>>> 21 >>>>>> participants, and one for each of the two streams.) >>>>>> >>>>>> The 40 associations, each carrying two ids, is still kind of a >> lot >>>> if >>>>>> its sent all at once. But when starting up a conference they > will >>>>>> probably be added gradually as each participant joins. Same at >> the >>>> end >>>>>> if they drop off individually. But it could be a bunch together >> if >>>> the >>>>>> conference is forcibly dropped by the focus. But it does > minimize >>>> what >>>>>> is sent when things happen incrementally. >>>>>> >>>>>> There may be some optimizations that can be done - e.g. a sort > of >>>>>> "wildcard" for one of the the two ids in the association class. >>> E.g. >>>>>> >>>>>> >>>>> participant="*" >>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>> > 2010-12-16T23:41:07Z >>>>>> >>>>>> >>>>>> (I'm not advocating that particular syntax. Its just something > to >>>> make >>>>>> the point.) >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> >>>>>> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: >>>>>>> My bad(typo) while sending the example. The correct partial >>> update >>>> I >>>>>>> intended to send is: >>>>>>> >>>>>>> >>>>>> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>> 2010-12-16T23:41:07Z>> time> >>>>>>> >>>>>>> >>>>>>> This is inline with approach 2 where in each association XML >>>> element >>>>>>> will have the IDs of the related associated elements. >>>>>>> >>>>>>> Ram >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>> Sent: Wednesday, October 12, 2011 2:24 PM >>>>>>>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>>>> Cc: Ofir Roth >>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>> association >>>>>>> in >>>>>>>> Metadata Model and in XML ? >>>>>>>> >>>>>>>> We do prefer to receive related elements as well, it makes >>>>>>>> implementation much easier. >>>>>>>> At least we should get relevant IDs. For example below, > SRC >>>>>> should >>>>>>>> also send ParticipantId >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>>> Sent: Wednesday, October 12, 2011 10:52 AM >>>>>>>> To: Leon Portman; siprec@ietf.org >>>>>>>> Cc: Ofir Roth >>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>> association >>>>>>> in >>>>>>>> Metadata Model and in XML ? >>>>>>>> >>>>>>>> Leon, >>>>>>>> Thanks for your response. One of the adv with approach 2 is > we >>>> can >>>>>>>> indicate only changes in the association without the need to >>>>>>> indicating >>>>>>>> the elements ( of association). IOW for the below example, if >>>> there >>>>>> is >>>>>>>> a change in participant-stream association I can simply send >>> the >>>>>>>> following in partial update: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> >>>>>>>> >>> 2010-12-16T23:41:07Z >>>>>>>> >>>>>>>> >>>>>>>> Do you see a need to always indicate the related elements too >> ? >>>> In >>>>>>>> which case I see approach 1 as more suitable. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ram >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>>> Sent: Wednesday, October 12, 2011 12:55 PM >>>>>>>>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>>>>> Cc: Ofir Roth >>>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>>> association >>>>>>>>> inmetadata Model and in XML ? >>>>>>>>> >>>>>>>>> Ram Hi >>>>>>>>> >>>>>>>>> I am ok with approaches 1 and however I do prefer approach >>> one >>>>>>>> because >>>>>>>>> it will be easier for SRS to get decode - association is >>> inside >>>>>>>>> relevant element. And it is more readable. >>>>>>>>> Approach 2 will work as well, however it is important that > if >>>>> there >>>>>>>>> will be a change in association then to send to SRS not only >>>>>> updated >>>>>>>>> association element but also related elements: for example > if >>>>>> stream >>>>>>>>> was associated to participant and session, send also >>> participant >>>>>> and >>>>>>>>> session latest state. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Leon >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] >>>> On >>>>>>>>> Behalf Of Ram Mohan R (rmohanr) >>>>>>>>> Sent: Wednesday, October 12, 2011 7:48 AM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: [siprec] Need Inputs: How to represent attributes > of >>>>>>>>> association in metadata Model and in XML ? >>>>>>>>> >>>>>>>>> (Sorry for lengthy e-mail) >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> In the last interim we discussed 4 approaches for >> representing >>>>>>>>> attributes of association in XML. >>>>>>>>> >>>>>>>>> >>>>>>>>> Here are some pros/cons for each of them: >>>>>>>>> Approach 1: >>>>>>>>> ---------- >>>>>>>>> Represent the association attribute as a property within one >>> of >>>>> the >>>>>>>>> associated elements. Example given at >>> http://www.ietf.org/mail- >>>>>>>>> archive/web/siprec/current/msg02709.html Does not need >> another >>>> XML >>>>>>>>> element and represents the association attributes as >>> capability >>>> of >>>>>>>> one >>>>>>>>> of the association element. >>>>>>>>> e.g. >>>>>>>>> >>>>>>>> >> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>> session="urn:uuid:855a5ded-8420-456d-a70f- >>>>>> 6da1eeaeb425"> >>>>>>>>> sip:ram@blr.cisco.com >>>>>>>>> 2010-12- >>>> 16T23:41:07Z>>>>>>> time> >>>>>>>>> TBD >>>>>>>>> >>>>>>>> stream > ="urn:uuid:f3373a7b-4958-4e55-8820- >>>>>>>>> d03a191fb76a >>>>>>>>> "> >>>>>>>>> 2010-12- >>>>>> 16T23:41:07Z>>>>>>>> time> >>>>>>>>> contributing SSRC-1 >>>>>>>>> >>> In >>>>>> the >>>>>>>> above >>>>>>>>> example the participant contributes a single streams. For >> each >>>>>>> stream >>>>>>>>> the association attribute (participant-stream) is shown with >>> the >>>>>>>> stream >>>>>>>>> ID nested in. >>>>>>>>> >>>>>>>>> >>>>>>>>> Approach 2: >>>>>>>>> ----------- >>>>>>>>> In this approach we have a new XML element for every >>> association >>>>>>>> class. >>>>>>>>> This xml element will NOT have a unique ID instead it >>> references >>>>>> the >>>>>>>> ID >>>>>>>>> of associated elements (shown below). With this approach it >> is >>>>> easy >>>>>>>> to >>>>>>>>> update as the association class is a separate XML element > and >>>> not >>>>>>>>> property. >>>>>>>>> e.g. >>>>>>>>> >>>>>>>> > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>> TBD >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>> contributing SSRC-1 >>>>>>>>> >>>>>>>>> >>>>>>>>> Approach 3 and 4 are in the below e-mail from John. >>>>>>>>> Approach 3 defines a new Unique ID for every association XML >>>>>> elment. >>>>>>>>> Also it creates alias for the other IDs. In the discussions >> in >>>>>>>> interim >>>>>>>>> there was no strong support for this approach. >>>>>>>>> >>>>>>>>> Approach 4 is same as approach 1 where in the association >>>> element >>>>>> is >>>>>>>>> encapsulated in one of the XML elements (to which it is >>>>>>> associated). >>>>>>>>> In addition to that it also has reference to the elements >>> (alias >>>>> of >>>>>>>>> IDs) to which the association belongs. >>>>>>>>> >>>>>>>>> I prefer approach 2 as it is has a separate XML element to >>>>>> represent >>>>>>>>> the association class. The only difference of this XML >> element >>>>> from >>>>>>>>> others is this does not need a unique ID. Instead it >>> references >>>>> the >>>>>>>> IDs >>>>>>>>> of the elements to which the association belongs. >>>>>>>>> Since association class is a special class meant to > associate >>>>>>>> multiple >>>>>>>>> classes, I see it ok to have a representation as in approach >> 2 >>>>>> where >>>>>>>> in >>>>>>>>> the identifier is the concatenation of the classes to which >>> the >>>>>>>>> association belongs to. >>>>>>>>> >>>>>>>>> Please provide your comments on this and also suggest any >>> other >>>>>>>>> approaches to represent association classes in XML. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ram >>>>>>>>> >>> _______________________________________________ >>> 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.2.stafford@bt.com Fri Oct 28 08:06: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 F343C21F86C1 for ; Fri, 28 Oct 2011 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnewag3+pKKC for ; Fri, 28 Oct 2011 08:06:22 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 524D721F8AFA for ; Fri, 28 Oct 2011 08:06:21 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 28 Oct 2011 16:06:19 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.227]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Fri, 28 Oct 2011 16:06:19 +0100 From: To: Date: Fri, 28 Oct 2011 16:06:19 +0100 Thread-Topic: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and in XML ? Thread-Index: AcyUgxjabTGDwIsUSiGpf0vrcAQSAwARqD8gAAB4gS4AKmsw8AAASw6AAALz4iA= Message-ID: References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCB06@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCC65@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com>, <35BCE99A477D6A4986FB2216D8CF2CFD082B7DD5@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B806E@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D6B@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D6B@sonusinmail02.sonusnet.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and 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: Fri, 28 Oct 2011 15:06:25 -0000 Ram, >> I presume the participant - CS element will be replaced by >> the< participantSessionAssoc>. > >No. will continue to remain. We are talking about association >attributes of participant-session. >The other attributes of and which are not >association attributes will continue to be the respective elements. What I meant to say was: I presume the participant's session attribute will be replaced by the . Is that correct ? RE use of , this means for a large conference each participant update= will be very large as it needs to include recv's for every other participa= nts send ? Rgds John -----Original Message----- From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] Sent: 28 October 2011 14:43 To: Ram Mohan R (rmohanr); Stafford,J,John,JRJ3X C; siprec@ietf.org Subject: RE: [siprec] Need Inputs: How to representattributesofassociation = in Metadata Model and in XML ? Hi, IMO, send & recv are the element which has to be pushed inside participant = stream association element which is inline with the model. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Ram Mohan R (rmohanr) >Sent: Friday, October 28, 2011 7:04 PM >To: john.2.stafford@bt.com; siprec@ietf.org >Subject: Re: [siprec] Need Inputs: How to >representattributesofassociation in Metadata Model and in XML ? > >Hello John S, > >Please see inline for answers. > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of john.2.stafford@bt.com >> Sent: Thursday, October 27, 2011 11:15 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Need Inputs: How to represent >> attributesofassociation in Metadata Model and in XML ? >> >> I am not clear on the effect on the other XMl elements. >> >> I presume the participant - CS element will be replaced by >> the< participantSessionAssoc>. > >No. will continue to remain. We are talking about association >attributes of participant-session. >The other attributes of and which are not >association attributes will continue to be the respective elements. > >> >> I also presume and will no longer be needed, and that >> the will include an attribute to say send >or >> recv ? > >This is a good suggestion. I have not given a thought on this so far. In >principle this should be fine as once the association of a participant >to a stream ends it stops sending/receiving the same. We need to think >through different use-cases to see if its fine to have , >inside association element itself. By having send, recv inside the >association we can avoid one XML element as they can be attribute. > >> >> Is that correct ? >> >> I hope the rule will remain that, in the abscence of any recv >elements >> by default a stream is assumed to be recieved by all participants. > >No, in the last IETF we agreed it's better to always explicity indicate >recv. We will continue to stick to that as I see no reason to change. > >Regards, >Ram > >> >> Rgds >> John Stafford | Solution Architect 1 | BT Global Services >> >> ________________________________________ >> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >> Ram Mohan R (rmohanr) [rmohanr@cisco.com] >> Sent: 27 October 2011 18:08 >> To: John Elwell; Paul Kyzivat; siprec@ietf.org >> Subject: Re: [siprec] Need Inputs: How to represent attributes >> ofassociation in Metadata Model and in XML ? >> >> Hi John, >> >> Thanks for your comment on this. Yes several of us seem to be inclined >> towards approach 2. I like your point that once one of the elements >in >> the association gets deleted, the association element life ends. SRC >> may choose to send the association element optionally or the SRS can still >> learn that as the way you mentioned. >> >> We ( authors of metadata draft ) discussed internally on this open >item >> and see some issues with adopting approach 2 as is with the current >> model /schema. I will start a separate mail thread for the issue as >> this thread is already too long. >> >> Thanks, >> Ram >> >> >> > -----Original Message----- >> > From: John Elwell [mailto:john.r.elwell@gmail.com] >> > Sent: Thursday, October 27, 2011 2:03 PM >> > To: Ram Mohan R (rmohanr); Paul Kyzivat; siprec@ietf.org >> > Subject: Re: [siprec] Need Inputs: How to represent attributes >> > ofassociation in Metadata Model and in XML ? >> > >> > Approach 2 seems reasonable. Could we say that an association is >> > implicitly deleted (gains a dissociate time) as soon as one of the >> > associated elements is deleted (gains a dissociate time)? This >> > would reduce the on-the >> wire >> > document size for both partial and full metadata in some >> circumstances >> > (e.g., conference termination by the focus). >> > >> > John >> > >> > >> > ----- Original Message ----- >> > From: "Ram Mohan R (rmohanr)" >> > To: "Paul Kyzivat" ; >> > Sent: Friday, October 14, 2011 4:59 AM >> > Subject: Re: [siprec] Need Inputs: How to represent attributes >> > ofassociation in Metadata Model and in XML ? >> > >> > >> > > Thanks Paul for your comments. I also prefer approach 2 as >> mentioned >> > > below in this thread. >> > > I will wait to hear for comments/opinion from others. >> > > >> > > Ram >> > > >> > >> -----Original Message----- >> > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> > >> Behalf Of Paul Kyzivat >> > >> Sent: Thursday, October 13, 2011 10:48 PM >> > >> To: siprec@ietf.org >> > >> Subject: Re: [siprec] Need Inputs: How to represent attributes of >> > >> association in Metadata Model and in XML ? >> > >> >> > >> I like approach 2, as Ram has shown it. It deals with the >problems >> > > John >> > >> raised with the others. >> > >> >> > >> I didn't follow John's arithmetic on this one, using his 20 party >> > >> conference example. As I count that, there are 21 participants >> when >> > > you >> > >> include the focus. Each of the 20 has two stream/participant >> > >> associations with the focus, for a total of 40. (The association >> is >> > >> bidirectional. I can only get to 80 by assuming we had to >> represent >> > an >> > >> association in each direction.) And each has two ids, each of >> which >> > is >> > >> also the id of a stream or participant. So there are really only >> 23 >> > >> distinct ids that need to be assigned for this. (One for each of >> the >> > > 21 >> > >> participants, and one for each of the two streams.) >> > >> >> > >> The 40 associations, each carrying two ids, is still kind of a >lot >> > if >> > >> its sent all at once. But when starting up a conference they will >> > >> probably be added gradually as each participant joins. Same at >the >> > end >> > >> if they drop off individually. But it could be a bunch together >if >> > the >> > >> conference is forcibly dropped by the focus. But it does minimize >> > what >> > >> is sent when things happen incrementally. >> > >> >> > >> There may be some optimizations that can be done - e.g. a sort of >> > >> "wildcard" for one of the the two ids in the association class. >> E.g. >> > >> >> > >> > > >> participant=3D"*" >> > >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> > >> 2010-12-16T23:41:07Z >> > >> >> > >> >> > >> (I'm not advocating that particular syntax. Its just something to >> > make >> > >> the point.) >> > >> >> > >> Thanks, >> > >> Paul >> > >> >> > >> >> > >> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: >> > >> > My bad(typo) while sending the example. The correct partial >> update >> > I >> > >> > intended to send is: >> > >> > >> > >> > > > >> > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >> > stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> > >> > 2010-12-16T23:41:07Z> time> >> > >> > >> > >> > >> > >> > This is inline with approach 2 where in each association XML >> > element >> > >> > will have the IDs of the related associated elements. >> > >> > >> > >> > Ram >> > >> > >> > >> >> -----Original Message----- >> > >> >> From: Leon Portman [mailto:Leon.Portman@nice.com] >> > >> >> Sent: Wednesday, October 12, 2011 2:24 PM >> > >> >> To: Ram Mohan R (rmohanr); siprec@ietf.org >> > >> >> Cc: Ofir Roth >> > >> >> Subject: RE: Need Inputs: How to represent attributes of >> > > association >> > >> > in >> > >> >> Metadata Model and in XML ? >> > >> >> >> > >> >> We do prefer to receive related elements as well, it makes >> > >> >> implementation much easier. >> > >> >> At least we should get relevant IDs. For example below, SRC >> > >> should >> > >> >> also send ParticipantId >> > >> >> >> > >> >> -----Original Message----- >> > >> >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> > >> >> Sent: Wednesday, October 12, 2011 10:52 AM >> > >> >> To: Leon Portman; siprec@ietf.org >> > >> >> Cc: Ofir Roth >> > >> >> Subject: RE: Need Inputs: How to represent attributes of >> > > association >> > >> > in >> > >> >> Metadata Model and in XML ? >> > >> >> >> > >> >> Leon, >> > >> >> Thanks for your response. One of the adv with approach 2 is we >> > can >> > >> >> indicate only changes in the association without the need to >> > >> > indicating >> > >> >> the elements ( of association). IOW for the below example, if >> > there >> > >> is >> > >> >> a change in participant-stream association I can simply send >> the >> > >> >> following in partial update: >> > >> >> >> > >> >> >> > >> >> > > >> >> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> >> > >> >> >> 2010-12-16T23:41:07Z >> > >> >> >> > >> >> >> > >> >> Do you see a need to always indicate the related elements too >? >> > In >> > >> >> which case I see approach 1 as more suitable. >> > >> >> >> > >> >> Thanks, >> > >> >> Ram >> > >> >> >> > >> >>> -----Original Message----- >> > >> >>> From: Leon Portman [mailto:Leon.Portman@nice.com] >> > >> >>> Sent: Wednesday, October 12, 2011 12:55 PM >> > >> >>> To: Ram Mohan R (rmohanr); siprec@ietf.org >> > >> >>> Cc: Ofir Roth >> > >> >>> Subject: RE: Need Inputs: How to represent attributes of >> > >> association >> > >> >>> inmetadata Model and in XML ? >> > >> >>> >> > >> >>> Ram Hi >> > >> >>> >> > >> >>> I am ok with approaches 1 and however I do prefer approach >> one >> > >> >> because >> > >> >>> it will be easier for SRS to get decode - association is >> inside >> > >> >>> relevant element. And it is more readable. >> > >> >>> Approach 2 will work as well, however it is important that if >> > > there >> > >> >>> will be a change in association then to send to SRS not only >> > >> updated >> > >> >>> association element but also related elements: for example if >> > >> stream >> > >> >>> was associated to participant and session, send also >> participant >> > >> and >> > >> >>> session latest state. >> > >> >>> >> > >> >>> Regards >> > >> >>> >> > >> >>> Leon >> > >> >>> >> > >> >>> >> > >> >>> -----Original Message----- >> > >> >>> From: siprec-bounces@ietf.org >[mailto:siprec-bounces@ietf.org] >> > On >> > >> >>> Behalf Of Ram Mohan R (rmohanr) >> > >> >>> Sent: Wednesday, October 12, 2011 7:48 AM >> > >> >>> To: siprec@ietf.org >> > >> >>> Subject: [siprec] Need Inputs: How to represent attributes of >> > >> >>> association in metadata Model and in XML ? >> > >> >>> >> > >> >>> (Sorry for lengthy e-mail) >> > >> >>> >> > >> >>> Hi All, >> > >> >>> >> > >> >>> In the last interim we discussed 4 approaches for >representing >> > >> >>> attributes of association in XML. >> > >> >>> >> > >> >>> >> > >> >>> Here are some pros/cons for each of them: >> > >> >>> Approach 1: >> > >> >>> ---------- >> > >> >>> Represent the association attribute as a property within one >> of >> > > the >> > >> >>> associated elements. Example given at >> http://www.ietf.org/mail- >> > >> >>> archive/web/siprec/current/msg02709.html Does not need >another >> > XML >> > >> >>> element and represents the association attributes as >> capability >> > of >> > >> >> one >> > >> >>> of the association element. >> > >> >>> e.g. >> > >> >>> > > >> >>> >id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >> >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- >> > >> 6da1eeaeb425"> >> > >> >>> sip:ram@blr.cisco.com >> > >> >>> 2010-12- >> > 16T23:41:07Z> > >> >> time> >> > >> >>> TBD >> > >> >>> > > >> >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820- >> > >> >>> d03a191fb76a >> > >> >>> "> >> > >> >>> 2010-12- >> > >> 16T23:41:07Z> > >> >>> time> >> > >> >>> contributing SSRC-1 >> > >> >>> >> In >> > >> the >> > >> >> above >> > >> >>> example the participant contributes a single streams. For >each >> > >> > stream >> > >> >>> the association attribute (participant-stream) is shown with >> the >> > >> >> stream >> > >> >>> ID nested in. >> > >> >>> >> > >> >>> >> > >> >>> Approach 2: >> > >> >>> ----------- >> > >> >>> In this approach we have a new XML element for every >> association >> > >> >> class. >> > >> >>> This xml element will NOT have a unique ID instead it >> references >> > >> the >> > >> >> ID >> > >> >>> of associated elements (shown below). With this approach it >is >> > > easy >> > >> >> to >> > >> >>> update as the association class is a separate XML element and >> > not >> > >> >>> property. >> > >> >>> e.g. >> > >> >>> > > >> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >> >>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >> > >> >>> 2010-12-16T23:41:07Z >> > >> >>> TBD >> > >> >>> >> > >> >>> >> > >> >>> > > >> >>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >> >>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> > >> >>> 2010-12-16T23:41:07Z >> > >> >>> contributing SSRC-1 >> > >> >>> >> > >> >>> >> > >> >>> Approach 3 and 4 are in the below e-mail from John. >> > >> >>> Approach 3 defines a new Unique ID for every association XML >> > >> elment. >> > >> >>> Also it creates alias for the other IDs. In the discussions >in >> > >> >> interim >> > >> >>> there was no strong support for this approach. >> > >> >>> >> > >> >>> Approach 4 is same as approach 1 where in the association >> > element >> > >> is >> > >> >>> encapsulated in one of the XML elements (to which it is >> > >> > associated). >> > >> >>> In addition to that it also has reference to the elements >> (alias >> > > of >> > >> >>> IDs) to which the association belongs. >> > >> >>> >> > >> >>> I prefer approach 2 as it is has a separate XML element to >> > >> represent >> > >> >>> the association class. The only difference of this XML >element >> > > from >> > >> >>> others is this does not need a unique ID. Instead it >> references >> > > the >> > >> >> IDs >> > >> >>> of the elements to which the association belongs. >> > >> >>> Since association class is a special class meant to associate >> > >> >> multiple >> > >> >>> classes, I see it ok to have a representation as in approach >2 >> > >> where >> > >> >> in >> > >> >>> the identifier is the concatenation of the classes to which >> the >> > >> >>> association belongs to. >> > >> >>> >> > >> >>> Please provide your comments on this and also suggest any >> other >> > >> >>> approaches to represent association classes in XML. >> > >> >>> >> > >> >>> Regards, >> > >> >>> Ram >> > >> >>> >> _______________________________________________ >> 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.2.stafford@bt.com Fri Oct 28 08:16:16 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 DE04121F84ED for ; Fri, 28 Oct 2011 08:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVqo1klacakN for ; Fri, 28 Oct 2011 08:16:14 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD1821F84DF for ; Fri, 28 Oct 2011 08:16:14 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 28 Oct 2011 16:16:12 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.227]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 28 Oct 2011 16:16:13 +0100 From: To: Date: Fri, 28 Oct 2011 16:16:11 +0100 Thread-Topic: [siprec] Persistent RS case,when should a recorder consider a CS has ended ? Thread-Index: AQHMlXTYzGCsXdidEkG/D2jI+uiX9JWRwZ8AgAAZ5BA= Message-ID: References: <2E239D6FCD033C4BAF15F386A979BF51159D6E@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D6E@sonusinmail02.sonusnet.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_BBA98B7742309546A60F3AE3B4E975A72820CC5B63EMV64UKRDdoma_" MIME-Version: 1.0 Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? 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, 28 Oct 2011 15:16:17 -0000 --_000_BBA98B7742309546A60F3AE3B4E975A72820CC5B63EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Partha, I think that when all three parties are conferenced there is only one CS, n= ot two CS's and a CSG. There may have been a CSG while the conference was being setup with a consu= lt call. In any case the question would be similar, should the phone that is no long= er on the call still include the call's CS/ CSG in its persistent RS ?, and if it doesn't will the recorder assume CS has ended,even though the sa= ne CS is included in the RS from the other phone. ie the key question is Does removing a CS from a persistent RS indicate the CS has ended, or will = a recorder only consider a CS ended when it receives metadata with the CS h= aving an end-time element ? rgds John ________________________________ From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] Sent: 28 October 2011 14:59 To: Stafford,J,John,JRJ3X C; siprec@ietf.org Subject: RE: [siprec] Persistent RS case,when should a recorder consider a = CS has ended ? Hi John, IMO, your requirement is already addressed as part of SIPREC metadata with = group (CSG) mechanism. 1) Receptionist to customer is CS1 with CSG1 using RS1. RS1 is from Re= ceptionist to SRS. 2) Agent1 to customer is CS2 with CSG1 with RS2. RS2 is from agent to = SRS. SRS will be able to group this session (CSG) because of the unique CSG id a= nd able to differentiate CS between receptionist & agent 1 using CS id. How= CSG id passed across between receptionist & agent1 is outside the scope of= SIPREC. Each update shall be go asynchronously and unique-id helps to grou= p it together in SRS. Please let me know in case I'm missing something in y= our requirement. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= john.2.stafford@bt.com Sent: Friday, October 28, 2011 6:54 PM To: siprec@ietf.org Subject: [siprec] Persistent RS case,when should a recorder consider a CS h= as ended ? Consider the following scenario several phones connected to PBX, all voice record their calls from the phon= e by each having a persistent RS. All calls get initially answered by receptionist, who then conferences in s= omeone to handle the call, then drops out. So there are two phones are conferenced onto same external call, so both ph= ones send metadata for thier RS's to include the call's CS. Since each phone has knowledge of all the conference participants, the CS i= t sends has 3 partiicipants, the two phones and the far party. Also the CS= Id and participant Id's sent by each phone are identical. Now one phone (receptionist) leaves the call, and both phones will sends a = metadata update to say one participant has dissassociated. Now for as long as the call persists, should the receptionists phone, that = has left the call, still include the CS in any full metadata updates it sen= ds, or could it omit the CS ? If it must included it, then over time the receptionists phone may end up h= aving to track multiple calls so as to send metadata updates, it is prefera= ble if it could just forget about the call as it is no longer involved in i= t. So does removing a CS from an RS indicate the CS has ended, or will a recor= der only consider a CS ended when it receives metadata with the CS having a= nd end-time element ? Rgds John Stafford | Solution Architect 1 | BT Global Services --_000_BBA98B7742309546A60F3AE3B4E975A72820CC5B63EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Partha,
 
I think that when all three parties are conferen= ced=20 there is only one CS, not two CS's and a CSG.
There may have been a CSG while the conference w= as=20 being setup with a consult call.
 
In any case the question would be similar, shoul= d the=20 phone that is no longer on the call still include the call's CS/ CSG i= n its=20 persistent RS ?,
and if it doesn't will the recorder assume = CS has=20 ended,even though the sane CS is included in the RS from the other=20 phone.
 
ie the key question is

Does=20 removing a CS from a=20 persistent RS indicate the CS has ended, or will a recorder onl= y=20 consider a CS ended when it receives metadata with the CS having an end-tim= e=20 element ? 

 

rgds=20 John
 
 

From: Ravindran Parthasarathi=20 [mailto:pravindran@sonusnet.com]
Sent: 28 October 2011=20 14:59
To: Stafford,J,John,JRJ3X C; siprec@ietf.org
Subject:= =20 RE: [siprec] Persistent RS case,when should a recorder consider a CS has en= ded=20 ?

Hi=20 John,

 

IMO,=20 your requirement is already addressed as part of SIPREC metadata with group= =20 (CSG) mechanism.

 

1)     =20 Receptionist=20 to customer is CS1 with CSG1 using RS1. RS1 is from Receptionist to=20 SRS.

2)     =20 Agent1=20 to customer is CS2 with CSG1 with RS2. RS2 is from agent to=20 SRS.

 

SRS=20 will be able to group this session (CSG) because of the unique CSG id and a= ble=20 to differentiate CS between receptionist & agent 1 using CS id. How CSG= id=20 passed across between receptionist & agent1 is outside the scope of SIP= REC.=20 Each update shall be go asynchronously and unique-id helps to group it toge= ther=20 in SRS. Please let me know in case I’m missing something in your=20 requirement.

 

Thanks

Partha

 

 

From:<= /B>=20 siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of=20 john.2.stafford@bt.com
Sent: Friday, October 28, 2011 6:54=20 PM
To: siprec@ietf.org
Subject: [siprec] Persistent RS= =20 case,when should a recorder consider a CS has ended=20 ?

 

Consider=20 the following scenario

 

several=20 phones connected to PBX, all voice record their calls from the phone by eac= h=20 having  a persistent RS.

 

All=20 calls get initially answered by receptionist, who then conferences in someo= ne to=20 handle the call, then drops out.

 

 

So=20 there are two phones are conferenced onto same external call, so both phone= s=20 send metadata for thier RS's to include the call's CS.=20

Since=20 each phone has knowledge of all the conference participants, the CS it= =20 sends has 3 partiicipants, the two phones and the far party.  Also the= CS=20 Id and participant Id's sent by each phone are=20 identical.

 

Now=20 one phone (receptionist) leaves the call, and both phones will sends a meta= data=20 update to say one participant has dissassociated.

 

Now=20 for as long as the call persists, should the receptionists phone, that has = left=20 the call, still include the CS in any full metadata updates it sends, or co= uld=20 it omit the CS ?

 

If it=20 must included it, then over time the receptionists phone may end up having = to=20 track multiple calls so as to send metadata updates, it is preferable if it= =20 could just forget about the call as it is no longer involved in=20 it.

 

So=20 does removing a CS from an RS indicate the CS has ended, or will a recorder= only=20 consider a CS ended when it receives metadata with the CS having and end-ti= me=20 element ? 

 

 

 

Rgds=

John=20 Stafford | Solution Architect 1 | BT Global Services = =

--_000_BBA98B7742309546A60F3AE3B4E975A72820CC5B63EMV64UKRDdoma_-- From rmohanr@cisco.com Fri Oct 28 08:57: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 D240B21F8548 for ; Fri, 28 Oct 2011 08:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.82 X-Spam-Level: X-Spam-Status: No, score=-6.82 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8r5Cg1-zymEd for ; Fri, 28 Oct 2011 08:57:22 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF821F86A6 for ; Fri, 28 Oct 2011 08:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=11188; q=dns/txt; s=iport; t=1319817442; x=1321027042; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DfHq260sUQZYB3EStQF6nG3/5kXLDhj4ICoZJTED7fA=; b=TyZsSNUYgMUV6ANCNTN1161CEunnzQkUy27iv8+YO09mXb7Wr5lzn+la U/z/J97T7U9O6esGiQET64j2RKtpVv7VHUTQXcJ9Im4ClsdVV5eO0uoDk KuwMMDVL0FYT+bn876rM1g3ZrIjqJycRf3Sf3lXl9gjx2lcc+77KMgptr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssAADrQqk5Io8US/2dsb2JhbABDDpoFj0yBBYFyAQEBAQMBAQEPAR0KNAsMBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQBCggIARAJh2iVUgGeFogiYQSIBJE/i3I/ X-IronPort-AV: E=Sophos;i="4.69,419,1315180800"; d="scan'208";a="1981846" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-3.cisco.com with ESMTP; 28 Oct 2011 15:57:19 +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 p9SFvJAE001199; Fri, 28 Oct 2011 15:57:19 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, 28 Oct 2011 21:27:18 +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: Fri, 28 Oct 2011 21:27:17 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B80A1@XMB-BGL-417.cisco.com> In-Reply-To: <4EAAB8E9.8070708@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: participant & stream outside the scope of session Thread-Index: AcyVfAFb8zwa/WpNTPiMP/ad9aPEQgADgZMQ References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com><4EA9C920.8000200@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD082B7ECA@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D3F@sonusinmail02.sonusnet.com> <4EAAB8E9.8070708@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat" , "Ravindran Parthasarathi" X-OriginalArrivalTime: 28 Oct 2011 15:57:18.0970 (UTC) FILETIME=[456D05A0:01CC958A] Cc: siprec@ietf.org Subject: Re: [siprec] participant & stream outside the scope of 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, 28 Oct 2011 15:57:23 -0000 I don't see a strong use case to have session associate to zero sessions. IMO we can retain the session associations as it is in the current model. Now coming to participant, the main reason why I am inclined to change the association is to have consistency with XML if we adopt approach 2. Regards, Ram > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, October 28, 2011 7:45 PM > To: Ravindran Parthasarathi > Cc: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: participant & stream outside the scope of session >=20 > This proposes an additional change, to remove the subordination of > stream to session. IMO this should be considered separately from > participant, as the arguments are different. >=20 > AFAICT, the use case Partha gives below is the only one that calls for > stream independent of session. And I'm not sure of the need for this. > ISTM the only reason to do this is to really record streams from > participants when there is no session. >=20 > This might allow capturing media earlier during call setup, by defining > the streams early, and associating them with participants and sessions > when that becomes known. *If* an SRS can figure out how to take > advantage of that. >=20 > Thanks, > Paul >=20 > On 10/28/11 5:09 AM, Ravindran Parthasarathi wrote: > > > change in metadata> > > > > I'm interested in knowing whether folks are interested in handling > > participant, stream completely outside the scope of session. > > In fact, we discussed this requirement as part of metadata model > > discussion and come to the conclusion not to include. In case > > participant, stream are outside the scope of session, the following > > recording metadata from SRC is valid: > > > > > > full > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > sip:agent1@callcenter.com > > urn:uuid:f3373a7b-4958-4e55-8820- > d03a191fb76a > > > > d03a191fb76a"> > > > > > > 0090272ff725"> > > > > > > > > > > Also, in the later partial update, session shall be added and > associate > > with the above participant& stream element. > > > > Here, SRS has to maintain participant, stream unique id as a separate > > flat > > Data (no hierarchy). Only issue is that SRS has to maintain flat > > database for > > Each of these elements. > > > > The current -04 draft is based on the assumption that participant and > > stream are within a session and it is possible for participant& > stream > > to move across multiple sessions using unique id. The rationale of > the > > current draft approach is that commonly used callflow metadata is > simple > > > > whereas specific corner case callflow like same participant in > multiple > > session will have complex mechanism. > > > > In case we see the strong usecases for going for independent stream, > > Participants which is outside the session, we will go for it. > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf > >> Of Ram Mohan R (rmohanr) > >> Sent: Friday, October 28, 2011 10:24 AM > >> To: Paul Kyzivat; siprec@ietf.org > >> Subject: Re: [siprec] Issue with participant scoping in the current > >> modeland its implication on association attr representation > >> > >> To add to Paul, with the proposed change, the model will look as > below > >> > >> +-------------------------------+ > >> | Communication Session (CS) | > >> | | > >> +-------------------------------+ > >> | 0..* |1..* > >> | ^^^^^^^^ | > >> | 2..* |0..* > >> +-------------+ receives +----------------+ > >> | Participant |----------| Media Streams | > >> | |0..* 0..*| | > >> | | | | > >> | | | | > >> | | sends | | > >> | |----------| | > >> | |1.* 0..*| | > >> +-------------+ +----------------+ > >> > >> A participant can be associated with zero or more sessions. > >> > >> And with the above model we can have an approach to define a > > participant > >> with no associations to sessions and have XML elements separate > (like > >> ) for association classes as in approach 2 > >> mentioned below > >> > >> Ram > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Paul Kyzivat > >>> Sent: Friday, October 28, 2011 2:42 AM > >>> To: siprec@ietf.org > >>> Subject: Re: [siprec] Issue with participant scoping in the current > >>> model and its implication on association attr representation > >>> > >>> On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote: > >>>> (Sorry for lengthy e-mail) > >>>> > >>>> This is a follow up to the mail thread > >>>> http://www.ietf.org/mail-archive/web/siprec/current/msg02810.html > >>>> > >>>> In the last IETF meeting there was a consensus that a participant > >> can > >>>> have a life outside of CS. > >>>> > >>>> However the current model scopes participant to always a session. > >>> > >>> I don't think that is quite right. The *model* requires that each > >>> participant be associated with one or more sessions. It doesn't > scope > >>> to > >>> a single session. > >>> > >>>> Should we have to change the model to have participant outside > > scope > >>> of > >>>> session ? I think it may not make sense to model participants > under > >>> RS > >>>> as these are participants of Session. The only use case where we > > can > >>>> have a participant in a RS with no CS is for Persistent recording > >>>> sessions (e.g. setup from agent phone(SRC) to SRS) This RS will be > >>> setup > >>>> even without any CS. If an SRC for this case sends a snapshot > >> before > >>> a > >>>> CS starts it may have participant information without any session. > >>>> Does the WG sees a value in such a use case or should we retain > the > >>>> model as is ? > >>> > >>> IMO the change we would be talking about is that a participant can > be > >>> associated with *zero* or more sessions, rather than one or more. > >>> > >>> In addition to the use case Ram mentions above, this would help > with > >>> the > >>> mapping to xml. If we go with participantSessAssoc (as mentioned > >> below) > >>> it becomes *possible* to define a participant with no associations > to > >>> sessions. Allowing the same in the model at least makes them > >>> consistent. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> The current model (ver 04) also impacts the way association > >>> attributes > >>>> are represented. Since the current draft (ver-04)the metadata > model > >>>> scopes participant and stream elements to session the schema also > >> was > >>>> designed the same way. The and attributes > > are > >>>> scoped/associated to a session (see section 7.1 example). IOW the > >>>> association attributes of to are already > >>>> represented. > >>>> > >>>> Now if we have to go with approach 2 for representing association > >>>> attributes, we will have to do one of the two ways: > >>>> > >>>> > >>>> If we stick the current model/schema: > >>>> ----------------------------------- > >>>> We will have represent in the following way. Note this is a mix of > >>>> approach 1 (existing representation which acheives participant > >>> session > >>>> association) and approach 2 ( for part-stream association). The > >>> issue > >>>> with this approach is if the same participant is simultaneously in > >>>> multiple sessions( cases like participant goes on hold on one line > >>> and > >>>> talks to another participant) and SRC sends a snapshot then we > will > >>> have > >>>> multiple elements each having different session > IDs. > >>>> >>>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >>>> > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > >>>> sip:ram@blr.cisco.com > >>>> 2010-12- > 16T23:41:07Z >>> time> > >>>> XXX > >>>> > >>>> > >>>> And for participant-stream you will have a new element > >>>> > >>>> >>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > >>>> 2010-12-16T23:41:07Z > >>>> contributing SSRC-1 > >>>> > >>>> > >>>> If we change the model to remove the scoping of participant/stream > >> to > >>>> session: > >>>> > >> -------------------------------------------------------------------- > - > >>> --- > >>>> ----- > >>>> > >>>> >>>> = id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > >>>> sip:ram@blr.cisco.com > >>>> > >>>> > >>>> >>>> > >> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- > 6da1eeaeb425" > >>>> > >> 2010-12-16T23:41:07Z > >>>> XXX > >>>> > >>>> > >>>> >>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > >>>> 2010-12-16T23:41:07Z > >>>> contributing SSRC-1 > >>>> > >>>> > >>>> Let me know your comments. > >>>> > >>>> Regards, > >>>> Ram > >>>> _______________________________________________ > >>>> 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@alum.mit.edu Fri Oct 28 09:05: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 1345621F86EC for ; Fri, 28 Oct 2011 09:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCDIQHjeG0bx for ; Fri, 28 Oct 2011 09:05:31 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 958B321F86A5 for ; Fri, 28 Oct 2011 09:05:31 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id qFVd1h00E1c6gX85EG5YnL; Fri, 28 Oct 2011 16:05:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id qG5X1h01F0tdiYw3jG5Xd1; Fri, 28 Oct 2011 16:05:32 +0000 Message-ID: <4EAAD2C9.5030008@alum.mit.edu> Date: Fri, 28 Oct 2011 12:05:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com>, <35BCE99A477D6A4986FB2216D8CF2CFD082B7DD5@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B806E@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D6B@sonusinmail02.sonusnet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and 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: Fri, 28 Oct 2011 16:05:33 -0000 On 10/28/11 11:06 AM, john.2.stafford@bt.com wrote: > > Ram, >>> I presume the participant - CS element will be replaced by >>> the< participantSessionAssoc>. >> >> No. will continue to remain. We are talking about association >> attributes of participant-session. >> The other attributes of and which are not >> association attributes will continue to be the respective elements. > > What I meant to say was: > I presume the participant's session attribute will be replaced by the. > Is that correct ? Yup, that's the idea. > RE use of, this means for a large conference each participant update will be very large as it needs to include recv's for every other participants send ? The association is between each participant and a stream, not between two participants. There are two ways to represent this, and neither has the problem you describe: - one stream for the conference. Each participant both sends and receives it. - one stream for each participant in the conference. The focus is represented as a participant. Each real participant sends and receives its own stream. The focus sends and receives all the streams. I guess the situation you describe would occur if there was a full-mesh of streams between participants. But afaik nobody does that. And if they did it would be hard to get an SRC in the middle. Thanks, Paul > Rgds John > > > -----Original Message----- > From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 28 October 2011 14:43 > To: Ram Mohan R (rmohanr); Stafford,J,John,JRJ3X C; siprec@ietf.org > Subject: RE: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and in XML ? > > Hi, > > IMO, send& recv are the element which has to be pushed inside participant stream association element which is inline with the model. > > Thanks > Partha > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf >> Of Ram Mohan R (rmohanr) >> Sent: Friday, October 28, 2011 7:04 PM >> To: john.2.stafford@bt.com; siprec@ietf.org >> Subject: Re: [siprec] Need Inputs: How to >> representattributesofassociation in Metadata Model and in XML ? >> >> Hello John S, >> >> Please see inline for answers. >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of john.2.stafford@bt.com >>> Sent: Thursday, October 27, 2011 11:15 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Need Inputs: How to represent >>> attributesofassociation in Metadata Model and in XML ? >>> >>> I am not clear on the effect on the other XMl elements. >>> >>> I presume the participant - CS element will be replaced by >>> the< participantSessionAssoc>. >> >> No. will continue to remain. We are talking about association >> attributes of participant-session. >> The other attributes of and which are not >> association attributes will continue to be the respective elements. >> >>> >>> I also presume and will no longer be needed, and that >>> the will include an attribute to say send >> or >>> recv ? >> >> This is a good suggestion. I have not given a thought on this so far. > In >> principle this should be fine as once the association of a participant >> to a stream ends it stops sending/receiving the same. We need to think >> through different use-cases to see if its fine to have, >> inside association element itself. By having send, recv inside the >> association we can avoid one XML element as they can be attribute. >> >>> >>> Is that correct ? >>> >>> I hope the rule will remain that, in the abscence of any recv >> elements >>> by default a stream is assumed to be recieved by all participants. >> >> No, in the last IETF we agreed it's better to always explicity indicate >> recv. We will continue to stick to that as I see no reason to change. >> >> Regards, >> Ram >> >>> >>> Rgds >>> John Stafford | Solution Architect 1 | BT Global Services >>> >>> ________________________________________ >>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >>> Ram Mohan R (rmohanr) [rmohanr@cisco.com] >>> Sent: 27 October 2011 18:08 >>> To: John Elwell; Paul Kyzivat; siprec@ietf.org >>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>> ofassociation in Metadata Model and in XML ? >>> >>> Hi John, >>> >>> Thanks for your comment on this. Yes several of us seem to be > inclined >>> towards approach 2. I like your point that once one of the elements >> in >>> the association gets deleted, the association element life ends. SRC >>> may choose to send the association element optionally or the SRS can > still >>> learn that as the way you mentioned. >>> >>> We ( authors of metadata draft ) discussed internally on this open >> item >>> and see some issues with adopting approach 2 as is with the current >>> model /schema. I will start a separate mail thread for the issue as >>> this thread is already too long. >>> >>> Thanks, >>> Ram >>> >>> >>>> -----Original Message----- >>>> From: John Elwell [mailto:john.r.elwell@gmail.com] >>>> Sent: Thursday, October 27, 2011 2:03 PM >>>> To: Ram Mohan R (rmohanr); Paul Kyzivat; siprec@ietf.org >>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>> ofassociation in Metadata Model and in XML ? >>>> >>>> Approach 2 seems reasonable. Could we say that an association is >>>> implicitly deleted (gains a dissociate time) as soon as one of the >>>> associated elements is deleted (gains a dissociate time)? This >>>> would reduce the on-the >>> wire >>>> document size for both partial and full metadata in some >>> circumstances >>>> (e.g., conference termination by the focus). >>>> >>>> John >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Ram Mohan R (rmohanr)" >>>> To: "Paul Kyzivat"; >>>> Sent: Friday, October 14, 2011 4:59 AM >>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>> ofassociation in Metadata Model and in XML ? >>>> >>>> >>>>> Thanks Paul for your comments. I also prefer approach 2 as >>> mentioned >>>>> below in this thread. >>>>> I will wait to hear for comments/opinion from others. >>>>> >>>>> Ram >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On >>>>>> Behalf Of Paul Kyzivat >>>>>> Sent: Thursday, October 13, 2011 10:48 PM >>>>>> To: siprec@ietf.org >>>>>> Subject: Re: [siprec] Need Inputs: How to represent attributes > of >>>>>> association in Metadata Model and in XML ? >>>>>> >>>>>> I like approach 2, as Ram has shown it. It deals with the >> problems >>>>> John >>>>>> raised with the others. >>>>>> >>>>>> I didn't follow John's arithmetic on this one, using his 20 > party >>>>>> conference example. As I count that, there are 21 participants >>> when >>>>> you >>>>>> include the focus. Each of the 20 has two stream/participant >>>>>> associations with the focus, for a total of 40. (The association >>> is >>>>>> bidirectional. I can only get to 80 by assuming we had to >>> represent >>>> an >>>>>> association in each direction.) And each has two ids, each of >>> which >>>> is >>>>>> also the id of a stream or participant. So there are really only >>> 23 >>>>>> distinct ids that need to be assigned for this. (One for each of >>> the >>>>> 21 >>>>>> participants, and one for each of the two streams.) >>>>>> >>>>>> The 40 associations, each carrying two ids, is still kind of a >> lot >>>> if >>>>>> its sent all at once. But when starting up a conference they > will >>>>>> probably be added gradually as each participant joins. Same at >> the >>>> end >>>>>> if they drop off individually. But it could be a bunch together >> if >>>> the >>>>>> conference is forcibly dropped by the focus. But it does > minimize >>>> what >>>>>> is sent when things happen incrementally. >>>>>> >>>>>> There may be some optimizations that can be done - e.g. a sort > of >>>>>> "wildcard" for one of the the two ids in the association class. >>> E.g. >>>>>> >>>>>> >>>>> participant="*" >>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>> > 2010-12-16T23:41:07Z >>>>>> >>>>>> >>>>>> (I'm not advocating that particular syntax. Its just something > to >>>> make >>>>>> the point.) >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> >>>>>> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: >>>>>>> My bad(typo) while sending the example. The correct partial >>> update >>>> I >>>>>>> intended to send is: >>>>>>> >>>>>>> >>>>>> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>> 2010-12-16T23:41:07Z>> time> >>>>>>> >>>>>>> >>>>>>> This is inline with approach 2 where in each association XML >>>> element >>>>>>> will have the IDs of the related associated elements. >>>>>>> >>>>>>> Ram >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>> Sent: Wednesday, October 12, 2011 2:24 PM >>>>>>>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>>>> Cc: Ofir Roth >>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>> association >>>>>>> in >>>>>>>> Metadata Model and in XML ? >>>>>>>> >>>>>>>> We do prefer to receive related elements as well, it makes >>>>>>>> implementation much easier. >>>>>>>> At least we should get relevant IDs. For example below, > SRC >>>>>> should >>>>>>>> also send ParticipantId >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>>> Sent: Wednesday, October 12, 2011 10:52 AM >>>>>>>> To: Leon Portman; siprec@ietf.org >>>>>>>> Cc: Ofir Roth >>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>> association >>>>>>> in >>>>>>>> Metadata Model and in XML ? >>>>>>>> >>>>>>>> Leon, >>>>>>>> Thanks for your response. One of the adv with approach 2 is > we >>>> can >>>>>>>> indicate only changes in the association without the need to >>>>>>> indicating >>>>>>>> the elements ( of association). IOW for the below example, if >>>> there >>>>>> is >>>>>>>> a change in participant-stream association I can simply send >>> the >>>>>>>> following in partial update: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> >>>>>>>> >>> 2010-12-16T23:41:07Z >>>>>>>> >>>>>>>> >>>>>>>> Do you see a need to always indicate the related elements too >> ? >>>> In >>>>>>>> which case I see approach 1 as more suitable. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ram >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>>> Sent: Wednesday, October 12, 2011 12:55 PM >>>>>>>>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>>>>> Cc: Ofir Roth >>>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>>> association >>>>>>>>> inmetadata Model and in XML ? >>>>>>>>> >>>>>>>>> Ram Hi >>>>>>>>> >>>>>>>>> I am ok with approaches 1 and however I do prefer approach >>> one >>>>>>>> because >>>>>>>>> it will be easier for SRS to get decode - association is >>> inside >>>>>>>>> relevant element. And it is more readable. >>>>>>>>> Approach 2 will work as well, however it is important that > if >>>>> there >>>>>>>>> will be a change in association then to send to SRS not only >>>>>> updated >>>>>>>>> association element but also related elements: for example > if >>>>>> stream >>>>>>>>> was associated to participant and session, send also >>> participant >>>>>> and >>>>>>>>> session latest state. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Leon >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] >>>> On >>>>>>>>> Behalf Of Ram Mohan R (rmohanr) >>>>>>>>> Sent: Wednesday, October 12, 2011 7:48 AM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: [siprec] Need Inputs: How to represent attributes > of >>>>>>>>> association in metadata Model and in XML ? >>>>>>>>> >>>>>>>>> (Sorry for lengthy e-mail) >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> In the last interim we discussed 4 approaches for >> representing >>>>>>>>> attributes of association in XML. >>>>>>>>> >>>>>>>>> >>>>>>>>> Here are some pros/cons for each of them: >>>>>>>>> Approach 1: >>>>>>>>> ---------- >>>>>>>>> Represent the association attribute as a property within one >>> of >>>>> the >>>>>>>>> associated elements. Example given at >>> http://www.ietf.org/mail- >>>>>>>>> archive/web/siprec/current/msg02709.html Does not need >> another >>>> XML >>>>>>>>> element and represents the association attributes as >>> capability >>>> of >>>>>>>> one >>>>>>>>> of the association element. >>>>>>>>> e.g. >>>>>>>>> >>>>>>>> >> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>> session="urn:uuid:855a5ded-8420-456d-a70f- >>>>>> 6da1eeaeb425"> >>>>>>>>> sip:ram@blr.cisco.com >>>>>>>>> 2010-12- >>>> 16T23:41:07Z>>>>>>> time> >>>>>>>>> TBD >>>>>>>>> >>>>>>>> stream > ="urn:uuid:f3373a7b-4958-4e55-8820- >>>>>>>>> d03a191fb76a >>>>>>>>> "> >>>>>>>>> 2010-12- >>>>>> 16T23:41:07Z>>>>>>>> time> >>>>>>>>> contributing SSRC-1 >>>>>>>>> >>> In >>>>>> the >>>>>>>> above >>>>>>>>> example the participant contributes a single streams. For >> each >>>>>>> stream >>>>>>>>> the association attribute (participant-stream) is shown with >>> the >>>>>>>> stream >>>>>>>>> ID nested in. >>>>>>>>> >>>>>>>>> >>>>>>>>> Approach 2: >>>>>>>>> ----------- >>>>>>>>> In this approach we have a new XML element for every >>> association >>>>>>>> class. >>>>>>>>> This xml element will NOT have a unique ID instead it >>> references >>>>>> the >>>>>>>> ID >>>>>>>>> of associated elements (shown below). With this approach it >> is >>>>> easy >>>>>>>> to >>>>>>>>> update as the association class is a separate XML element > and >>>> not >>>>>>>>> property. >>>>>>>>> e.g. >>>>>>>>> >>>>>>>> > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>> TBD >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> > participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>> contributing SSRC-1 >>>>>>>>> >>>>>>>>> >>>>>>>>> Approach 3 and 4 are in the below e-mail from John. >>>>>>>>> Approach 3 defines a new Unique ID for every association XML >>>>>> elment. >>>>>>>>> Also it creates alias for the other IDs. In the discussions >> in >>>>>>>> interim >>>>>>>>> there was no strong support for this approach. >>>>>>>>> >>>>>>>>> Approach 4 is same as approach 1 where in the association >>>> element >>>>>> is >>>>>>>>> encapsulated in one of the XML elements (to which it is >>>>>>> associated). >>>>>>>>> In addition to that it also has reference to the elements >>> (alias >>>>> of >>>>>>>>> IDs) to which the association belongs. >>>>>>>>> >>>>>>>>> I prefer approach 2 as it is has a separate XML element to >>>>>> represent >>>>>>>>> the association class. The only difference of this XML >> element >>>>> from >>>>>>>>> others is this does not need a unique ID. Instead it >>> references >>>>> the >>>>>>>> IDs >>>>>>>>> of the elements to which the association belongs. >>>>>>>>> Since association class is a special class meant to > associate >>>>>>>> multiple >>>>>>>>> classes, I see it ok to have a representation as in approach >> 2 >>>>>> where >>>>>>>> in >>>>>>>>> the identifier is the concatenation of the classes to which >>> the >>>>>>>>> association belongs to. >>>>>>>>> >>>>>>>>> Please provide your comments on this and also suggest any >>> other >>>>>>>>> approaches to represent association classes in XML. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ram >>>>>>>>> >>> _______________________________________________ >>> 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 Fri Oct 28 09:09: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 5F3DF21F8A6C for ; Fri, 28 Oct 2011 09:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.809 X-Spam-Level: X-Spam-Status: No, score=-6.809 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+6bNR8ZT3PQ for ; Fri, 28 Oct 2011 09:09:17 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8D67021F8AF8 for ; Fri, 28 Oct 2011 09:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=12627; q=dns/txt; s=iport; t=1319818156; x=1321027756; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qmyHjUHDTI9g/qc9fC3eUry7oXi4OlJ3H9ntpAPzjUA=; b=Zjz4wwA0X6JTFB0tV3YKE74gXoUU8P270M1Mp0JQN/BA4AH9z9cuy0O0 Vg+Yy3yXxOZLkBLMiuAP8K9FAc0aUH2nHUyQtm0ROqwvw5oGIJjLY4pq1 pzuCmvWdJHfgsFE46qQMQN9NzvBjMsDcrKA+kQIJA4QtHascllL2TU8ZA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssAAALTqk5Io8UT/2dsb2JhbABDDpoFj0yBBYFyAQEBAQMBAQEPAR0KNAsMBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAEKCAgBEAmHaJVTAZ4WiCJhBIgEkT+FAYZxPw X-IronPort-AV: E=Sophos;i="4.69,419,1315180800"; d="scan'208";a="1983370" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-4.cisco.com with ESMTP; 28 Oct 2011 16:09:14 +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 p9SG9Da6021252; Fri, 28 Oct 2011 16:09:13 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, 28 Oct 2011 21:39:13 +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: Fri, 28 Oct 2011 21:39:12 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B80A3@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD082B80A1@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] participant & stream outside the scope of session Thread-Index: AcyVfAFb8zwa/WpNTPiMP/ad9aPEQgADgZMQAABntBA= References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com><4EA9C920.8000200@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD082B7ECA@XMB-BGL-417.cisco.com><2E239D6FCD033C4BAF15F386A979BF51159D3F@sonusinmail02.sonusnet.com><4EAAB8E9.8070708@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD082B80A1@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Ram Mohan R (rmohanr)" , "Paul Kyzivat" , "Ravindran Parthasarathi" X-OriginalArrivalTime: 28 Oct 2011 16:09:13.0745 (UTC) FILETIME=[EF770810:01CC958B] Cc: siprec@ietf.org Subject: Re: [siprec] participant & stream outside the scope of 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, 28 Oct 2011 16:09:18 -0000 A typo in the below email. Sorry for that. I meant " I don't see a strong use case to have stream associate to zero sessions. IMO we can retain the stream associations ^^^^^^ ^^^^ as it is in the current model." Thanks, Ram =20 =20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: Friday, October 28, 2011 9:27 PM > To: Paul Kyzivat; Ravindran Parthasarathi > Cc: siprec@ietf.org > Subject: Re: [siprec] participant & stream outside the scope of session >=20 > I don't see a strong use case to have session associate to zero > sessions. IMO we can retain the session associations as it is in the > current model. >=20 > Now coming to participant, the main reason why I am inclined to change > the association is to have consistency with XML if we adopt approach > 2. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: Friday, October 28, 2011 7:45 PM > > To: Ravindran Parthasarathi > > Cc: Ram Mohan R (rmohanr); siprec@ietf.org > > Subject: Re: participant & stream outside the scope of session > > > > This proposes an additional change, to remove the subordination of > > stream to session. IMO this should be considered separately from > > participant, as the arguments are different. > > > > AFAICT, the use case Partha gives below is the only one that calls > for > > stream independent of session. And I'm not sure of the need for this. > > ISTM the only reason to do this is to really record streams from > > participants when there is no session. > > > > This might allow capturing media earlier during call setup, by > defining > > the streams early, and associating them with participants and > sessions > > when that becomes known. *If* an SRS can figure out how to take > > advantage of that. > > > > Thanks, > > Paul > > > > On 10/28/11 5:09 AM, Ravindran Parthasarathi wrote: > > > major > > > change in metadata> > > > > > > I'm interested in knowing whether folks are interested in handling > > > participant, stream completely outside the scope of session. > > > In fact, we discussed this requirement as part of metadata model > > > discussion and come to the conclusion not to include. In case > > > participant, stream are outside the scope of session, the following > > > recording metadata from SRC is valid: > > > > > > > > > full > > > > > = id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > > sip:agent1@callcenter.com > > > urn:uuid:f3373a7b-4958-4e55-8820- > > d03a191fb76a > > > > > > > d03a191fb76a"> > > > > > > > > > > 0090272ff725"> > > > > > > > > > > > > > > > Also, in the later partial update, session shall be added and > > associate > > > with the above participant& stream element. > > > > > > Here, SRS has to maintain participant, stream unique id as a > separate > > > flat > > > Data (no hierarchy). Only issue is that SRS has to maintain flat > > > database for > > > Each of these elements. > > > > > > The current -04 draft is based on the assumption that participant > and > > > stream are within a session and it is possible for participant& > > stream > > > to move across multiple sessions using unique id. The rationale of > > the > > > current draft approach is that commonly used callflow metadata is > > simple > > > > > > whereas specific corner case callflow like same participant in > > multiple > > > session will have complex mechanism. > > > > > > In case we see the strong usecases for going for independent > stream, > > > Participants which is outside the session, we will go for it. > > > > > > Thanks > > > Partha > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf > > >> Of Ram Mohan R (rmohanr) > > >> Sent: Friday, October 28, 2011 10:24 AM > > >> To: Paul Kyzivat; siprec@ietf.org > > >> Subject: Re: [siprec] Issue with participant scoping in the > current > > >> modeland its implication on association attr representation > > >> > > >> To add to Paul, with the proposed change, the model will look as > > below > > >> > > >> +-------------------------------+ > > >> | Communication Session (CS) | > > >> | | > > >> +-------------------------------+ > > >> | 0..* |1..* > > >> | ^^^^^^^^ | > > >> | 2..* |0..* > > >> +-------------+ receives +----------------+ > > >> | Participant |----------| Media Streams | > > >> | |0..* 0..*| | > > >> | | | | > > >> | | | | > > >> | | sends | | > > >> | |----------| | > > >> | |1.* 0..*| | > > >> +-------------+ +----------------+ > > >> > > >> A participant can be associated with zero or more sessions. > > >> > > >> And with the above model we can have an approach to define a > > > participant > > >> with no associations to sessions and have XML elements separate > > (like > > >> ) for association classes as in approach 2 > > >> mentioned below > > >> > > >> Ram > > >> > > >>> -----Original Message----- > > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > >>> Behalf Of Paul Kyzivat > > >>> Sent: Friday, October 28, 2011 2:42 AM > > >>> To: siprec@ietf.org > > >>> Subject: Re: [siprec] Issue with participant scoping in the > current > > >>> model and its implication on association attr representation > > >>> > > >>> On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote: > > >>>> (Sorry for lengthy e-mail) > > >>>> > > >>>> This is a follow up to the mail thread > > >>>> http://www.ietf.org/mail- > archive/web/siprec/current/msg02810.html > > >>>> > > >>>> In the last IETF meeting there was a consensus that a > participant > > >> can > > >>>> have a life outside of CS. > > >>>> > > >>>> However the current model scopes participant to always a > session. > > >>> > > >>> I don't think that is quite right. The *model* requires that each > > >>> participant be associated with one or more sessions. It doesn't > > scope > > >>> to > > >>> a single session. > > >>> > > >>>> Should we have to change the model to have participant outside > > > scope > > >>> of > > >>>> session ? I think it may not make sense to model participants > > under > > >>> RS > > >>>> as these are participants of Session. The only use case where we > > > can > > >>>> have a participant in a RS with no CS is for Persistent > recording > > >>>> sessions (e.g. setup from agent phone(SRC) to SRS) This RS will > be > > >>> setup > > >>>> even without any CS. If an SRC for this case sends a snapshot > > >> before > > >>> a > > >>>> CS starts it may have participant information without any > session. > > >>>> Does the WG sees a value in such a use case or should we retain > > the > > >>>> model as is ? > > >>> > > >>> IMO the change we would be talking about is that a participant > can > > be > > >>> associated with *zero* or more sessions, rather than one or more. > > >>> > > >>> In addition to the use case Ram mentions above, this would help > > with > > >>> the > > >>> mapping to xml. If we go with participantSessAssoc (as mentioned > > >> below) > > >>> it becomes *possible* to define a participant with no > associations > > to > > >>> sessions. Allowing the same in the model at least makes them > > >>> consistent. > > >>> > > >>> Thanks, > > >>> Paul > > >>> > > >>>> The current model (ver 04) also impacts the way association > > >>> attributes > > >>>> are represented. Since the current draft (ver-04)the metadata > > model > > >>>> scopes participant and stream elements to session the schema > also > > >> was > > >>>> designed the same way. The and > attributes > > > are > > >>>> scoped/associated to a session (see section 7.1 example). IOW > the > > >>>> association attributes of to are > already > > >>>> represented. > > >>>> > > >>>> Now if we have to go with approach 2 for representing > association > > >>>> attributes, we will have to do one of the two ways: > > >>>> > > >>>> > > >>>> If we stick the current model/schema: > > >>>> ----------------------------------- > > >>>> We will have represent in the following way. Note this is a mix > of > > >>>> approach 1 (existing representation which acheives participant > > >>> session > > >>>> association) and approach 2 ( for part-stream association). The > > >>> issue > > >>>> with this approach is if the same participant is simultaneously > in > > >>>> multiple sessions( cases like participant goes on hold on one > line > > >>> and > > >>>> talks to another participant) and SRC sends a snapshot then we > > will > > >>> have > > >>>> multiple elements each having different session > > IDs. > > >>>> > >>>> = id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >>>> > > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > >>>> sip:ram@blr.cisco.com > > >>>> 2010-12- > > 16T23:41:07Z > >>> time> > > >>>> XXX > > >>>> > > >>>> > > >>>> And for participant-stream you will have a new element > > >>>> > > >>>> > >>>> = participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > >>>> 2010-12-16T23:41:07Z > > >>>> contributing SSRC-1 > > >>>> > > >>>> > > >>>> If we change the model to remove the scoping of > participant/stream > > >> to > > >>>> session: > > >>>> > > >> > -------------------------------------------------------------------- > > - > > >>> --- > > >>>> ----- > > >>>> > > >>>> > >>>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > > >>>> sip:ram@blr.cisco.com > > >>>> > > >>>> > > >>>> > >>>> > > >> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- > > 6da1eeaeb425" > > >>>> > > >> 2010-12-16T23:41:07Z > > >>>> XXX > > >>>> > > >>>> > > >>>> > >>>> = participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > >>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> > > >>>> 2010-12-16T23:41:07Z > > >>>> contributing SSRC-1 > > >>>> > > >>>> > > >>>> Let me know your comments. > > >>>> > > >>>> Regards, > > >>>> Ram > > >>>> _______________________________________________ > > >>>> 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 > > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.2.stafford@bt.com Fri Oct 28 09:13: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 6EA5121F8B1A for ; Fri, 28 Oct 2011 09:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oijQeK5nfw0D for ; Fri, 28 Oct 2011 09:13:10 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDF021F8B15 for ; Fri, 28 Oct 2011 09:13:09 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 28 Oct 2011 17:13:09 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.227]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Fri, 28 Oct 2011 17:13:08 +0100 From: To: Date: Fri, 28 Oct 2011 17:10:13 +0100 Thread-Topic: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and in XML ? Thread-Index: AcyVi25rJRO0RSqDTK6cIYcQtaWYzwAAKStO Message-ID: References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><35BCE99A477D6A4986FB2216D8CF2CFD07BFCE72@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F8DF@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com>, <35BCE99A477D6A4986FB2216D8CF2CFD082B7DD5@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B806E@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D6B@sonusinmail02.sonusnet.com> , <4EAAD2C9.5030008@alum.mit.edu> In-Reply-To: <4EAAD2C9.5030008@alum.mit.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and 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: Fri, 28 Oct 2011 16:13:11 -0000 Paul, OK, I understand, but how does the recorder know that the stream sent by th= e focus is a mixed conference stream , ie contains all of the streams recei= ved by the focus. ? Rgds John Stafford | Solution Architect 1 | BT Global Services ________________________________________ From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul K= yzivat [pkyzivat@alum.mit.edu] Sent: 28 October 2011 17:05 To: siprec@ietf.org Subject: Re: [siprec] Need Inputs: How to representattributesofassociation = in Metadata Model and in XML ? On 10/28/11 11:06 AM, john.2.stafford@bt.com wrote: > > Ram, >>> I presume the participant - CS element will be replaced by >>> the< participantSessionAssoc>. >> >> No. will continue to remain. We are talking about association >> attributes of participant-session. >> The other attributes of and which are not >> association attributes will continue to be the respective elements. > > What I meant to say was: > I presume the participant's session attribute will be replaced by the. > Is that correct ? Yup, that's the idea. > RE use of, this means for a large conference each participant updat= e will be very large as it needs to include recv's for every other particip= ants send ? The association is between each participant and a stream, not between two participants. There are two ways to represent this, and neither has the problem you describe: - one stream for the conference. Each participant both sends and receives it. - one stream for each participant in the conference. The focus is represented as a participant. Each real participant sends and receives its own stream. The focus sends and receives all the streams. I guess the situation you describe would occur if there was a full-mesh of streams between participants. But afaik nobody does that. And if they did it would be hard to get an SRC in the middle. Thanks, Paul > Rgds John > > > -----Original Message----- > From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 28 October 2011 14:43 > To: Ram Mohan R (rmohanr); Stafford,J,John,JRJ3X C; siprec@ietf.org > Subject: RE: [siprec] Need Inputs: How to representattributesofassociatio= n in Metadata Model and in XML ? > > Hi, > > IMO, send& recv are the element which has to be pushed inside participan= t stream association element which is inline with the model. > > Thanks > Partha > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf >> Of Ram Mohan R (rmohanr) >> Sent: Friday, October 28, 2011 7:04 PM >> To: john.2.stafford@bt.com; siprec@ietf.org >> Subject: Re: [siprec] Need Inputs: How to >> representattributesofassociation in Metadata Model and in XML ? >> >> Hello John S, >> >> Please see inline for answers. >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of john.2.stafford@bt.com >>> Sent: Thursday, October 27, 2011 11:15 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Need Inputs: How to represent >>> attributesofassociation in Metadata Model and in XML ? >>> >>> I am not clear on the effect on the other XMl elements. >>> >>> I presume the participant - CS element will be replaced by >>> the< participantSessionAssoc>. >> >> No. will continue to remain. We are talking about association >> attributes of participant-session. >> The other attributes of and which are not >> association attributes will continue to be the respective elements. >> >>> >>> I also presume and will no longer be needed, and that >>> the will include an attribute to say send >> or >>> recv ? >> >> This is a good suggestion. I have not given a thought on this so far. > In >> principle this should be fine as once the association of a participant >> to a stream ends it stops sending/receiving the same. We need to think >> through different use-cases to see if its fine to have, >> inside association element itself. By having send, recv inside the >> association we can avoid one XML element as they can be attribute. >> >>> >>> Is that correct ? >>> >>> I hope the rule will remain that, in the abscence of any recv >> elements >>> by default a stream is assumed to be recieved by all participants. >> >> No, in the last IETF we agreed it's better to always explicity indicate >> recv. We will continue to stick to that as I see no reason to change. >> >> Regards, >> Ram >> >>> >>> Rgds >>> John Stafford | Solution Architect 1 | BT Global Services >>> >>> ________________________________________ >>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >>> Ram Mohan R (rmohanr) [rmohanr@cisco.com] >>> Sent: 27 October 2011 18:08 >>> To: John Elwell; Paul Kyzivat; siprec@ietf.org >>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>> ofassociation in Metadata Model and in XML ? >>> >>> Hi John, >>> >>> Thanks for your comment on this. Yes several of us seem to be > inclined >>> towards approach 2. I like your point that once one of the elements >> in >>> the association gets deleted, the association element life ends. SRC >>> may choose to send the association element optionally or the SRS can > still >>> learn that as the way you mentioned. >>> >>> We ( authors of metadata draft ) discussed internally on this open >> item >>> and see some issues with adopting approach 2 as is with the current >>> model /schema. I will start a separate mail thread for the issue as >>> this thread is already too long. >>> >>> Thanks, >>> Ram >>> >>> >>>> -----Original Message----- >>>> From: John Elwell [mailto:john.r.elwell@gmail.com] >>>> Sent: Thursday, October 27, 2011 2:03 PM >>>> To: Ram Mohan R (rmohanr); Paul Kyzivat; siprec@ietf.org >>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>> ofassociation in Metadata Model and in XML ? >>>> >>>> Approach 2 seems reasonable. Could we say that an association is >>>> implicitly deleted (gains a dissociate time) as soon as one of the >>>> associated elements is deleted (gains a dissociate time)? This >>>> would reduce the on-the >>> wire >>>> document size for both partial and full metadata in some >>> circumstances >>>> (e.g., conference termination by the focus). >>>> >>>> John >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Ram Mohan R (rmohanr)" >>>> To: "Paul Kyzivat"; >>>> Sent: Friday, October 14, 2011 4:59 AM >>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>> ofassociation in Metadata Model and in XML ? >>>> >>>> >>>>> Thanks Paul for your comments. I also prefer approach 2 as >>> mentioned >>>>> below in this thread. >>>>> I will wait to hear for comments/opinion from others. >>>>> >>>>> Ram >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On >>>>>> Behalf Of Paul Kyzivat >>>>>> Sent: Thursday, October 13, 2011 10:48 PM >>>>>> To: siprec@ietf.org >>>>>> Subject: Re: [siprec] Need Inputs: How to represent attributes > of >>>>>> association in Metadata Model and in XML ? >>>>>> >>>>>> I like approach 2, as Ram has shown it. It deals with the >> problems >>>>> John >>>>>> raised with the others. >>>>>> >>>>>> I didn't follow John's arithmetic on this one, using his 20 > party >>>>>> conference example. As I count that, there are 21 participants >>> when >>>>> you >>>>>> include the focus. Each of the 20 has two stream/participant >>>>>> associations with the focus, for a total of 40. (The association >>> is >>>>>> bidirectional. I can only get to 80 by assuming we had to >>> represent >>>> an >>>>>> association in each direction.) And each has two ids, each of >>> which >>>> is >>>>>> also the id of a stream or participant. So there are really only >>> 23 >>>>>> distinct ids that need to be assigned for this. (One for each of >>> the >>>>> 21 >>>>>> participants, and one for each of the two streams.) >>>>>> >>>>>> The 40 associations, each carrying two ids, is still kind of a >> lot >>>> if >>>>>> its sent all at once. But when starting up a conference they > will >>>>>> probably be added gradually as each participant joins. Same at >> the >>>> end >>>>>> if they drop off individually. But it could be a bunch together >> if >>>> the >>>>>> conference is forcibly dropped by the focus. But it does > minimize >>>> what >>>>>> is sent when things happen incrementally. >>>>>> >>>>>> There may be some optimizations that can be done - e.g. a sort > of >>>>>> "wildcard" for one of the the two ids in the association class. >>> E.g. >>>>>> >>>>>> >>>>> participant=3D"*" >>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>> > 2010-12-16T23:41:07Z >>>>>> >>>>>> >>>>>> (I'm not advocating that particular syntax. Its just something > to >>>> make >>>>>> the point.) >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> >>>>>> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: >>>>>>> My bad(typo) while sending the example. The correct partial >>> update >>>> I >>>>>>> intended to send is: >>>>>>> >>>>>>> >>>>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>> 2010-12-16T23:41:07Z>> time> >>>>>>> >>>>>>> >>>>>>> This is inline with approach 2 where in each association XML >>>> element >>>>>>> will have the IDs of the related associated elements. >>>>>>> >>>>>>> Ram >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>> Sent: Wednesday, October 12, 2011 2:24 PM >>>>>>>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>>>> Cc: Ofir Roth >>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>> association >>>>>>> in >>>>>>>> Metadata Model and in XML ? >>>>>>>> >>>>>>>> We do prefer to receive related elements as well, it makes >>>>>>>> implementation much easier. >>>>>>>> At least we should get relevant IDs. For example below, > SRC >>>>>> should >>>>>>>> also send ParticipantId >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>>> Sent: Wednesday, October 12, 2011 10:52 AM >>>>>>>> To: Leon Portman; siprec@ietf.org >>>>>>>> Cc: Ofir Roth >>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>> association >>>>>>> in >>>>>>>> Metadata Model and in XML ? >>>>>>>> >>>>>>>> Leon, >>>>>>>> Thanks for your response. One of the adv with approach 2 is > we >>>> can >>>>>>>> indicate only changes in the association without the need to >>>>>>> indicating >>>>>>>> the elements ( of association). IOW for the below example, if >>>> there >>>>>> is >>>>>>>> a change in participant-stream association I can simply send >>> the >>>>>>>> following in partial update: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> >>>>>>>> >>> 2010-12-16T23:41:07Z >>>>>>>> >>>>>>>> >>>>>>>> Do you see a need to always indicate the related elements too >> ? >>>> In >>>>>>>> which case I see approach 1 as more suitable. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ram >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>>> Sent: Wednesday, October 12, 2011 12:55 PM >>>>>>>>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>>>>> Cc: Ofir Roth >>>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>>> association >>>>>>>>> inmetadata Model and in XML ? >>>>>>>>> >>>>>>>>> Ram Hi >>>>>>>>> >>>>>>>>> I am ok with approaches 1 and however I do prefer approach >>> one >>>>>>>> because >>>>>>>>> it will be easier for SRS to get decode - association is >>> inside >>>>>>>>> relevant element. And it is more readable. >>>>>>>>> Approach 2 will work as well, however it is important that > if >>>>> there >>>>>>>>> will be a change in association then to send to SRS not only >>>>>> updated >>>>>>>>> association element but also related elements: for example > if >>>>>> stream >>>>>>>>> was associated to participant and session, send also >>> participant >>>>>> and >>>>>>>>> session latest state. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Leon >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] >>>> On >>>>>>>>> Behalf Of Ram Mohan R (rmohanr) >>>>>>>>> Sent: Wednesday, October 12, 2011 7:48 AM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: [siprec] Need Inputs: How to represent attributes > of >>>>>>>>> association in metadata Model and in XML ? >>>>>>>>> >>>>>>>>> (Sorry for lengthy e-mail) >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> In the last interim we discussed 4 approaches for >> representing >>>>>>>>> attributes of association in XML. >>>>>>>>> >>>>>>>>> >>>>>>>>> Here are some pros/cons for each of them: >>>>>>>>> Approach 1: >>>>>>>>> ---------- >>>>>>>>> Represent the association attribute as a property within one >>> of >>>>> the >>>>>>>>> associated elements. Example given at >>> http://www.ietf.org/mail- >>>>>>>>> archive/web/siprec/current/msg02709.html Does not need >> another >>>> XML >>>>>>>>> element and represents the association attributes as >>> capability >>>> of >>>>>>>> one >>>>>>>>> of the association element. >>>>>>>>> e.g. >>>>>>>>> >>>>>>>> >> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- >>>>>> 6da1eeaeb425"> >>>>>>>>> sip:ram@blr.cisco.com >>>>>>>>> 2010-12- >>>> 16T23:41:07Z>>>>>>> time> >>>>>>>>> TBD >>>>>>>>> >>>>>>>> stream > =3D"urn:uuid:f3373a7b-4958-4e55-8820- >>>>>>>>> d03a191fb76a >>>>>>>>> "> >>>>>>>>> 2010-12- >>>>>> 16T23:41:07Z>>>>>>>> time> >>>>>>>>> contributing SSRC-1 >>>>>>>>> >>> In >>>>>> the >>>>>>>> above >>>>>>>>> example the participant contributes a single streams. For >> each >>>>>>> stream >>>>>>>>> the association attribute (participant-stream) is shown with >>> the >>>>>>>> stream >>>>>>>>> ID nested in. >>>>>>>>> >>>>>>>>> >>>>>>>>> Approach 2: >>>>>>>>> ----------- >>>>>>>>> In this approach we have a new XML element for every >>> association >>>>>>>> class. >>>>>>>>> This xml element will NOT have a unique ID instead it >>> references >>>>>> the >>>>>>>> ID >>>>>>>>> of associated elements (shown below). With this approach it >> is >>>>> easy >>>>>>>> to >>>>>>>>> update as the association class is a separate XML element > and >>>> not >>>>>>>>> property. >>>>>>>>> e.g. >>>>>>>>> >>>>>>>> > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>> TBD >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> > participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>> contributing SSRC-1 >>>>>>>>> >>>>>>>>> >>>>>>>>> Approach 3 and 4 are in the below e-mail from John. >>>>>>>>> Approach 3 defines a new Unique ID for every association XML >>>>>> elment. >>>>>>>>> Also it creates alias for the other IDs. In the discussions >> in >>>>>>>> interim >>>>>>>>> there was no strong support for this approach. >>>>>>>>> >>>>>>>>> Approach 4 is same as approach 1 where in the association >>>> element >>>>>> is >>>>>>>>> encapsulated in one of the XML elements (to which it is >>>>>>> associated). >>>>>>>>> In addition to that it also has reference to the elements >>> (alias >>>>> of >>>>>>>>> IDs) to which the association belongs. >>>>>>>>> >>>>>>>>> I prefer approach 2 as it is has a separate XML element to >>>>>> represent >>>>>>>>> the association class. The only difference of this XML >> element >>>>> from >>>>>>>>> others is this does not need a unique ID. Instead it >>> references >>>>> the >>>>>>>> IDs >>>>>>>>> of the elements to which the association belongs. >>>>>>>>> Since association class is a special class meant to > associate >>>>>>>> multiple >>>>>>>>> classes, I see it ok to have a representation as in approach >> 2 >>>>>> where >>>>>>>> in >>>>>>>>> the identifier is the concatenation of the classes to which >>> the >>>>>>>>> association belongs to. >>>>>>>>> >>>>>>>>> Please provide your comments on this and also suggest any >>> other >>>>>>>>> approaches to represent association classes in XML. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ram >>>>>>>>> >>> _______________________________________________ >>> 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@alum.mit.edu Fri Oct 28 10:08:50 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 EDE6921F8A70 for ; Fri, 28 Oct 2011 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAT3munusGJ7 for ; Fri, 28 Oct 2011 10:08:50 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 115AC21F8A66 for ; Fri, 28 Oct 2011 10:08:49 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta15.westchester.pa.mail.comcast.net with comcast id qH3D1h00B0vyq2s5FH8qge; Fri, 28 Oct 2011 17:08:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta05.westchester.pa.mail.comcast.net with comcast id qH8q1h0080tdiYw3RH8qfd; Fri, 28 Oct 2011 17:08:50 +0000 Message-ID: <4EAAE1A0.3010202@alum.mit.edu> Date: Fri, 28 Oct 2011 13:08:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 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] Persistent RS case, when should a recorder consider a CS has ended ? 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, 28 Oct 2011 17:08:51 -0000 Partha commented on this, but rather than inject in that conversation I'll make a separate response: On 10/28/11 9:23 AM, john.2.stafford@bt.com wrote: > Consider the following scenario > several phones connected to PBX, all voice record their calls from the > phone by each having a persistent RS. > All calls get initially answered by receptionist, who then conferences > in someone to handle the call, then drops out. > So there are two phones are conferenced onto same external call, so both > phones send metadata for thier RS's to include the call's CS. Are you assuming that the PBX is a B2BUA, that implements a sip dialog for each half-call? Or are you assuming a more classic sip model, where the PBX is a proxy/registrar? I'm too lazy to draw the call flows, but in summary, for the half-call model: - first there is dialog 1b between caller and pbx - then there is dialog 2b between pbx and receptionist - (1b/2b spliced by the pbx) - then there is dialog 3b between receptionist and pbx (for consult with callee) - then there is dialog 4b between pbx and callee - (dialogs 3b/4b spliced by pbx) - the conference is formed between 1b,2b,4b mixed by the pbx, dialog 3b ends - dialog 2b ends. The pbx switches from mixing to splicing 1b/4b for the "classic" model: - first there is dialog 1a between caller and receptionist - then there is a separate consult dialog between receptionist and internal callee (dialog 2a) - then there is a conference of receptionist, caller, and callee. (dialogs 1a & 2a, joined at receptionist, or dialogs 3a,4a,5a between each of the three and a mixer, with 1a and 1b ending.) - a direct dialog 6a is formed between the caller and callee - then conference ends (dialogs 1a,1b or 3a,4a,5a end) > Since each phone has knowledge of all the conference participants, the That is an assumption that isn't necessarily true, but this is your example, so I'll assume its true > CS it sends has 3 partiicipants, the two phones and the far party. Also > the CS Id and participant Id's sent by each phone are identical. This is another assumption - its a choice to do it this way. (Partha proposed a different way.) But again I'll accept your assumption. Its going to take some work for all the phones to arrive at the same ID for this CS. > Now one phone (receptionist) leaves the call, and both phones will sends > a metadata update to say one participant has dissassociated. Well, I suppose all three phones send an update. > Now for as long as the call persists, should the receptionists phone, > that has left the call, still include the CS in any full metadata > updates it sends, or could it omit the CS ? Given your assumptions, when the receptionist leaves the call it ought to send an update indicating that it is dissociated from the CS and the related streams it was associated with. Then it presumably forgets about the CS and never mentions it again. This is also an assumption. If it somehow continues to track the state of the call I guess it could continue to report the state changes. > If it must included it, then over time the receptionists phone may end > up having to track multiple calls so as to send metadata updates, it is > preferable if it could just forget about the call as it is no longer > involved in it. > So does removing a CS from an RS indicate the CS has ended, That would clearly be the wrong thing to do in this case, since the CS is shared by multiple RSs and the others aren't done with it. > or will a > recorder only consider a CS ended when it receives metadata with the CS > having and end-time element ? IMO the SRS can generally assume the CS ended when all participants and streams have dissociated from it. Even after that, in principle, it could have another participant or stream associate to it. If so, I guess it will have to figure out how to deal with that. (It is probably an error, but in the interest of reliable recording it will want to do *something* - either graft the new stuff onto the the existing CS, or start a new CS with the same ID.) Thanks, Paul > Rgds > John Stafford | Solution Architect 1 | BT Global Services > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Fri Oct 28 10:10: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 779AD21F85C7 for ; Fri, 28 Oct 2011 10:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1n-FOq1T1Dy for ; Fri, 28 Oct 2011 10:10:48 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD4021F8564 for ; Fri, 28 Oct 2011 10:10:48 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id qF6r1h0011ZXKqc53HApJ1; Fri, 28 Oct 2011 17:10:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id qHAo1h0200tdiYw3hHAo0Y; Fri, 28 Oct 2011 17:10:48 +0000 Message-ID: <4EAAE217.6080406@alum.mit.edu> Date: Fri, 28 Oct 2011 13:10:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 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] Persistent RS case, when should a recorder consider a CS has ended ? 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, 28 Oct 2011 17:10:49 -0000 (Revised. I realized I had extra stuff in here that I then decided I didn't need.) Partha commented on this, but rather than inject in that conversation I'll make a separate response: On 10/28/11 9:23 AM, john.2.stafford@bt.com wrote: > Consider the following scenario > several phones connected to PBX, all voice record their calls from the > phone by each having a persistent RS. > All calls get initially answered by receptionist, who then conferences > in someone to handle the call, then drops out. > So there are two phones are conferenced onto same external call, so both > phones send metadata for thier RS's to include the call's CS. > Since each phone has knowledge of all the conference participants, the That is an assumption that isn't necessarily true, but this is your example, so I'll assume its true > CS it sends has 3 partiicipants, the two phones and the far party. Also > the CS Id and participant Id's sent by each phone are identical. This is another assumption - its a choice to do it this way. (Partha proposed a different way.) But again I'll accept your assumption. Its going to take some work for all the phones to arrive at the same ID for this CS. > Now one phone (receptionist) leaves the call, and both phones will sends > a metadata update to say one participant has dissassociated. Well, I suppose all three phones send an update. > Now for as long as the call persists, should the receptionists phone, > that has left the call, still include the CS in any full metadata > updates it sends, or could it omit the CS ? Given your assumptions, when the receptionist leaves the call it ought to send an update indicating that it is dissociated from the CS and the related streams it was associated with. Then it presumably forgets about the CS and never mentions it again. This is also an assumption. If it somehow continues to track the state of the call I guess it could continue to report the state changes. > If it must included it, then over time the receptionists phone may end > up having to track multiple calls so as to send metadata updates, it is > preferable if it could just forget about the call as it is no longer > involved in it. > So does removing a CS from an RS indicate the CS has ended, That would clearly be the wrong thing to do in this case, since the CS is shared by multiple RSs and the others aren't done with it. > or will a > recorder only consider a CS ended when it receives metadata with the CS > having and end-time element ? IMO the SRS can generally assume the CS ended when all participants and streams have dissociated from it. Even after that, in principle, it could have another participant or stream associate to it. If so, I guess it will have to figure out how to deal with that. (It is probably an error, but in the interest of reliable recording it will want to do *something* - either graft the new stuff onto the the existing CS, or start a new CS with the same ID.) Thanks, Paul > Rgds > John Stafford | Solution Architect 1 | BT Global Services > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Fri Oct 28 10:19:36 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 A462721F84B3 for ; Fri, 28 Oct 2011 10:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA+Q3CFEILlA for ; Fri, 28 Oct 2011 10:19:35 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4001721F8486 for ; Fri, 28 Oct 2011 10:19:35 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9SHK70a015722; Fri, 28 Oct 2011 13:20:07 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 13:19:30 -0400 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, 28 Oct 2011 22:48:40 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159D78@sonusinmail02.sonusnet.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD082B80A3@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] participant & stream outside the scope of session thread-index: AcyVfAFb8zwa/WpNTPiMP/ad9aPEQgADgZMQAABntBAAAUjjcA== References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com><4EA9C920.8000200@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD082B7ECA@XMB-BGL-417.cisco.com><2E239D6FCD033C4BAF15F386A979BF51159D3F@sonusinmail02.sonusnet.com><4EAAB8E9.8070708@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD082B80A1@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B80A3@XMB-BGL-417.cisco.com> From: "Ravindran Parthasarathi" To: "Ram Mohan R (rmohanr)" , "Paul Kyzivat" X-OriginalArrivalTime: 28 Oct 2011 17:19:30.0399 (UTC) FILETIME=[C0C95EF0:01CC9595] Cc: siprec@ietf.org Subject: Re: [siprec] participant & stream outside the scope of 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, 28 Oct 2011 17:19:36 -0000 Hi Ram, As Paul mentioned, stream associated with zero session was brought up as part of the persistent connection from the endpoint discussion and it was pushed back because stream & participant has to be within session (CS). I'm worried that participant to zero session change may re-open the earlier closure and call for one more discussion.=20 Also, the current syntax of stream is associated with session closely which has to be changed consistently in case participant is changed its association representation with session. It will be good in case we get the feedback on these aspect. Thanks Partha >-----Original Message----- >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >Sent: Friday, October 28, 2011 9:39 PM >To: Ram Mohan R (rmohanr); Paul Kyzivat; Ravindran Parthasarathi >Cc: siprec@ietf.org >Subject: RE: [siprec] participant & stream outside the scope of session > >A typo in the below email. Sorry for that. I meant > >" > I don't see a strong use case to have stream associate to zero >sessions. IMO we can retain the stream associations > ^^^^^^ >^^^^ > as it is in the current model." > >Thanks, >Ram > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ram Mohan R (rmohanr) >> Sent: Friday, October 28, 2011 9:27 PM >> To: Paul Kyzivat; Ravindran Parthasarathi >> Cc: siprec@ietf.org >> Subject: Re: [siprec] participant & stream outside the scope of >session >> >> I don't see a strong use case to have session associate to zero >> sessions. IMO we can retain the session associations as it is in the >> current model. >> >> Now coming to participant, the main reason why I am inclined to change >> the association is to have consistency with XML if we adopt approach >> 2. >> >> Regards, >> Ram >> >> > -----Original Message----- >> > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> > Sent: Friday, October 28, 2011 7:45 PM >> > To: Ravindran Parthasarathi >> > Cc: Ram Mohan R (rmohanr); siprec@ietf.org >> > Subject: Re: participant & stream outside the scope of session >> > >> > This proposes an additional change, to remove the subordination of >> > stream to session. IMO this should be considered separately from >> > participant, as the arguments are different. >> > >> > AFAICT, the use case Partha gives below is the only one that calls >> for >> > stream independent of session. And I'm not sure of the need for >this. >> > ISTM the only reason to do this is to really record streams from >> > participants when there is no session. >> > >> > This might allow capturing media earlier during call setup, by >> defining >> > the streams early, and associating them with participants and >> sessions >> > when that becomes known. *If* an SRS can figure out how to take >> > advantage of that. >> > >> > Thanks, >> > Paul >> > >> > On 10/28/11 5:09 AM, Ravindran Parthasarathi wrote: >> > > > major >> > > change in metadata> >> > > >> > > I'm interested in knowing whether folks are interested in handling >> > > participant, stream completely outside the scope of session. >> > > In fact, we discussed this requirement as part of metadata model >> > > discussion and come to the conclusion not to include. In case >> > > participant, stream are outside the scope of session, the >following >> > > recording metadata from SRC is valid: >> > > >> > > >> > > full >> > > > > > = id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >> > > sip:agent1@callcenter.com >> > > urn:uuid:f3373a7b-4958-4e55-8820- >> > d03a191fb76a >> > > >> > > > > d03a191fb76a"> >> > > >> > > >> > > > > 0090272ff725"> >> > > >> > > >> > > >> > > >> > > Also, in the later partial update, session shall be added and >> > associate >> > > with the above participant& stream element. >> > > >> > > Here, SRS has to maintain participant, stream unique id as a >> separate >> > > flat >> > > Data (no hierarchy). Only issue is that SRS has to maintain flat >> > > database for >> > > Each of these elements. >> > > >> > > The current -04 draft is based on the assumption that participant >> and >> > > stream are within a session and it is possible for participant& >> > stream >> > > to move across multiple sessions using unique id. The rationale of >> > the >> > > current draft approach is that commonly used callflow metadata is >> > simple >> > > >> > > whereas specific corner case callflow like same participant in >> > multiple >> > > session will have complex mechanism. >> > > >> > > In case we see the strong usecases for going for independent >> stream, >> > > Participants which is outside the session, we will go for it. >> > > >> > > Thanks >> > > Partha >> > > >> > >> -----Original Message----- >> > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> > > Behalf >> > >> Of Ram Mohan R (rmohanr) >> > >> Sent: Friday, October 28, 2011 10:24 AM >> > >> To: Paul Kyzivat; siprec@ietf.org >> > >> Subject: Re: [siprec] Issue with participant scoping in the >> current >> > >> modeland its implication on association attr representation >> > >> >> > >> To add to Paul, with the proposed change, the model will look as >> > below >> > >> >> > >> +-------------------------------+ >> > >> | Communication Session (CS) | >> > >> | | >> > >> +-------------------------------+ >> > >> | 0..* |1..* >> > >> | ^^^^^^^^ | >> > >> | 2..* |0..* >> > >> +-------------+ receives +----------------+ >> > >> | Participant |----------| Media Streams | >> > >> | |0..* 0..*| | >> > >> | | | | >> > >> | | | | >> > >> | | sends | | >> > >> | |----------| | >> > >> | |1.* 0..*| | >> > >> +-------------+ +----------------+ >> > >> >> > >> A participant can be associated with zero or more sessions. >> > >> >> > >> And with the above model we can have an approach to define a >> > > participant >> > >> with no associations to sessions and have XML elements separate >> > (like >> > >> ) for association classes as in approach 2 >> > >> mentioned below >> > >> >> > >> Ram >> > >> >> > >>> -----Original Message----- >> > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >On >> > >>> Behalf Of Paul Kyzivat >> > >>> Sent: Friday, October 28, 2011 2:42 AM >> > >>> To: siprec@ietf.org >> > >>> Subject: Re: [siprec] Issue with participant scoping in the >> current >> > >>> model and its implication on association attr representation >> > >>> >> > >>> On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote: >> > >>>> (Sorry for lengthy e-mail) >> > >>>> >> > >>>> This is a follow up to the mail thread >> > >>>> http://www.ietf.org/mail- >> archive/web/siprec/current/msg02810.html >> > >>>> >> > >>>> In the last IETF meeting there was a consensus that a >> participant >> > >> can >> > >>>> have a life outside of CS. >> > >>>> >> > >>>> However the current model scopes participant to always a >> session. >> > >>> >> > >>> I don't think that is quite right. The *model* requires that >each >> > >>> participant be associated with one or more sessions. It doesn't >> > scope >> > >>> to >> > >>> a single session. >> > >>> >> > >>>> Should we have to change the model to have participant outside >> > > scope >> > >>> of >> > >>>> session ? I think it may not make sense to model participants >> > under >> > >>> RS >> > >>>> as these are participants of Session. The only use case where >we >> > > can >> > >>>> have a participant in a RS with no CS is for Persistent >> recording >> > >>>> sessions (e.g. setup from agent phone(SRC) to SRS) This RS will >> be >> > >>> setup >> > >>>> even without any CS. If an SRC for this case sends a snapshot >> > >> before >> > >>> a >> > >>>> CS starts it may have participant information without any >> session. >> > >>>> Does the WG sees a value in such a use case or should we retain >> > the >> > >>>> model as is ? >> > >>> >> > >>> IMO the change we would be talking about is that a participant >> can >> > be >> > >>> associated with *zero* or more sessions, rather than one or >more. >> > >>> >> > >>> In addition to the use case Ram mentions above, this would help >> > with >> > >>> the >> > >>> mapping to xml. If we go with participantSessAssoc (as mentioned >> > >> below) >> > >>> it becomes *possible* to define a participant with no >> associations >> > to >> > >>> sessions. Allowing the same in the model at least makes them >> > >>> consistent. >> > >>> >> > >>> Thanks, >> > >>> Paul >> > >>> >> > >>>> The current model (ver 04) also impacts the way association >> > >>> attributes >> > >>>> are represented. Since the current draft (ver-04)the metadata >> > model >> > >>>> scopes participant and stream elements to session the schema >> also >> > >> was >> > >>>> designed the same way. The and >> attributes >> > > are >> > >>>> scoped/associated to a session (see section 7.1 example). IOW >> the >> > >>>> association attributes of to are >> already >> > >>>> represented. >> > >>>> >> > >>>> Now if we have to go with approach 2 for representing >> association >> > >>>> attributes, we will have to do one of the two ways: >> > >>>> >> > >>>> >> > >>>> If we stick the current model/schema: >> > >>>> ----------------------------------- >> > >>>> We will have represent in the following way. Note this is a mix >> of >> > >>>> approach 1 (existing representation which acheives participant >> > >>> session >> > >>>> association) and approach 2 ( for part-stream association). >The >> > >>> issue >> > >>>> with this approach is if the same participant is simultaneously >> in >> > >>>> multiple sessions( cases like participant goes on hold on one >> line >> > >>> and >> > >>>> talks to another participant) and SRC sends a snapshot then we >> > will >> > >>> have >> > >>>> multiple elements each having different session >> > IDs. >> > >>>> > > >>>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >>>> >> > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >> > >>>> sip:ram@blr.cisco.com >> > >>>> 2010-12- >> > 16T23:41:07Z> > >>> time> >> > >>>> XXX >> > >>>> >> > >>>> >> > >>>> And for participant-stream you will have a new element >> > >>>> >> > >>>> > > >>>> = participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> > >>>> 2010-12-16T23:41:07Z >> > >>>> contributing SSRC-1 >> > >>>> >> > >>>> >> > >>>> If we change the model to remove the scoping of >> participant/stream >> > >> to >> > >>>> session: >> > >>>> >> > >> >> -------------------------------------------------------------------- >> > - >> > >>> --- >> > >>>> ----- >> > >>>> >> > >>>> > > >>>> >id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >> > >>>> sip:ram@blr.cisco.com >> > >>>> >> > >>>> >> > >>>> > > >>>> >> > >> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- >> > 6da1eeaeb425" >> > >>>> >> > >> 2010-12-16T23:41:07Z >> > >>>> XXX >> > >>>> >> > >>>> >> > >>>> > > >>>> = participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >> > >>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >> > >>>> 2010-12-16T23:41:07Z >> > >>>> contributing SSRC-1 >> > >>>> >> > >>>> >> > >>>> Let me know your comments. >> > >>>> >> > >>>> Regards, >> > >>>> Ram >> > >>>> _______________________________________________ >> > >>>> 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 Fri Oct 28 10:27: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 1BE5621F854F for ; Fri, 28 Oct 2011 10:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q7uasT7ipDp for ; Fri, 28 Oct 2011 10:27:25 -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 DF31821F8500 for ; Fri, 28 Oct 2011 10:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=15537; q=dns/txt; s=iport; t=1319822845; x=1321032445; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=5XSZLmzv1T4fC8KuVtbT7Qf5Iua5GOlkMJ4BeykwLXU=; b=cjGliTly7iEHCx3AL6bWvkGv1hCrzTKU1XRft9gVpJM0hloLCMrT2Chr 4Cvhpsqhc6+cgY7Jb31BtXBXtR/dn6bpEalAppt7YpnAlPCFcvTmqcxo2 i6M6CGzzXkoCZwKdcAjMIvcDmGj8l5HV2BoFW1N8tXviSJMKU71hj1des U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AAC7lqk5Io8UR/2dsb2JhbABDDpoFj1KBBYFyAQEBAQMBAQEPAQoTCjQLDAQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEAQoICAEQCYdolU8BnhOIImEEiASRQIUBhnE/ X-IronPort-AV: E=Sophos;i="4.69,419,1315180800"; d="scan'208";a="120288312" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2011 17:27:22 +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 p9SHRLYq015224; Fri, 28 Oct 2011 17:27:21 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); Fri, 28 Oct 2011 22:57:20 +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: Fri, 28 Oct 2011 22:57:15 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B80C3@XMB-BGL-417.cisco.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D78@sonusinmail02.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] participant & stream outside the scope of session Thread-Index: AcyVfAFb8zwa/WpNTPiMP/ad9aPEQgADgZMQAABntBAAAUjjcAABaYyw References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com><4EA9C920.8000200@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD082B7ECA@XMB-BGL-417.cisco.com><2E239D6FCD033C4BAF15F386A979BF51159D3F@sonusinmail02.sonusnet.com><4EAAB8E9.8070708@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD082B80A1@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B80A3@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D78@sonusinmail02.sonusnet.com> From: "Ram Mohan R (rmohanr)" To: "Ravindran Parthasarathi" , "Paul Kyzivat" X-OriginalArrivalTime: 28 Oct 2011 17:27:20.0964 (UTC) FILETIME=[D943E440:01CC9596] Cc: siprec@ietf.org Subject: Re: [siprec] participant & stream outside the scope of 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, 28 Oct 2011 17:27:27 -0000 Hi Partha, Please see inline > -----Original Message----- > From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: Friday, October 28, 2011 10:49 PM > To: Ram Mohan R (rmohanr); Paul Kyzivat > Cc: siprec@ietf.org > Subject: RE: [siprec] participant & stream outside the scope of session >=20 > Hi Ram, >=20 > As Paul mentioned, stream associated with zero session was brought up > as > part of the persistent connection from the endpoint discussion and it > was pushed back because stream & participant has to be within session > (CS). I'm worried that participant to zero session change may re-open > the earlier closure and call for one more discussion. >=20 > Also, the current syntax of stream is associated with session closely > which has to be changed consistently in case participant is changed its > association representation with session. I don't see a need for the above. We are changing the participant association to session to allow it to be consistent with XML if we choose approach 2. Even in approach 2, stream has to be associated with a session and so there is no need to change that association. Regards, Ram >=20 > = session=3D"urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103"> > > >=20 > It will be good in case we get the feedback on these aspect. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >Sent: Friday, October 28, 2011 9:39 PM > >To: Ram Mohan R (rmohanr); Paul Kyzivat; Ravindran Parthasarathi > >Cc: siprec@ietf.org > >Subject: RE: [siprec] participant & stream outside the scope of > session > > > >A typo in the below email. Sorry for that. I meant > > > >" > > I don't see a strong use case to have stream associate to zero > >sessions. IMO we can retain the stream associations > > ^^^^^^ > >^^^^ > > as it is in the current model." > > > >Thanks, > >Ram > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Ram Mohan R (rmohanr) > >> Sent: Friday, October 28, 2011 9:27 PM > >> To: Paul Kyzivat; Ravindran Parthasarathi > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] participant & stream outside the scope of > >session > >> > >> I don't see a strong use case to have session associate to zero > >> sessions. IMO we can retain the session associations as it is in the > >> current model. > >> > >> Now coming to participant, the main reason why I am inclined to > change > >> the association is to have consistency with XML if we adopt > approach > >> 2. > >> > >> Regards, > >> Ram > >> > >> > -----Original Message----- > >> > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> > Sent: Friday, October 28, 2011 7:45 PM > >> > To: Ravindran Parthasarathi > >> > Cc: Ram Mohan R (rmohanr); siprec@ietf.org > >> > Subject: Re: participant & stream outside the scope of session > >> > > >> > This proposes an additional change, to remove the subordination of > >> > stream to session. IMO this should be considered separately from > >> > participant, as the arguments are different. > >> > > >> > AFAICT, the use case Partha gives below is the only one that calls > >> for > >> > stream independent of session. And I'm not sure of the need for > >this. > >> > ISTM the only reason to do this is to really record streams from > >> > participants when there is no session. > >> > > >> > This might allow capturing media earlier during call setup, by > >> defining > >> > the streams early, and associating them with participants and > >> sessions > >> > when that becomes known. *If* an SRS can figure out how to take > >> > advantage of that. > >> > > >> > Thanks, > >> > Paul > >> > > >> > On 10/28/11 5:09 AM, Ravindran Parthasarathi wrote: > >> > > >> major > >> > > change in metadata> > >> > > > >> > > I'm interested in knowing whether folks are interested in > handling > >> > > participant, stream completely outside the scope of session. > >> > > In fact, we discussed this requirement as part of metadata model > >> > > discussion and come to the conclusion not to include. In case > >> > > participant, stream are outside the scope of session, the > >following > >> > > recording metadata from SRC is valid: > >> > > > >> > > > >> > > full > >> > > >> > > id=3D"urn:uuid:b2b7c112-5982-469d-9007- > 6ddbecca64d3"> > >> > > sip:agent1@callcenter.com > >> > > urn:uuid:f3373a7b-4958-4e55-8820- > >> > d03a191fb76a > >> > > > >> > > >> > d03a191fb76a"> > >> > > > >> > > > >> > > >> > 0090272ff725"> > >> > > > >> > > > >> > > > >> > > > >> > > Also, in the later partial update, session shall be added and > >> > associate > >> > > with the above participant& stream element. > >> > > > >> > > Here, SRS has to maintain participant, stream unique id as a > >> separate > >> > > flat > >> > > Data (no hierarchy). Only issue is that SRS has to maintain flat > >> > > database for > >> > > Each of these elements. > >> > > > >> > > The current -04 draft is based on the assumption that > participant > >> and > >> > > stream are within a session and it is possible for participant& > >> > stream > >> > > to move across multiple sessions using unique id. The rationale > of > >> > the > >> > > current draft approach is that commonly used callflow metadata > is > >> > simple > >> > > > >> > > whereas specific corner case callflow like same participant in > >> > multiple > >> > > session will have complex mechanism. > >> > > > >> > > In case we see the strong usecases for going for independent > >> stream, > >> > > Participants which is outside the session, we will go for it. > >> > > > >> > > Thanks > >> > > Partha > >> > > > >> > >> -----Original Message----- > >> > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >> > > Behalf > >> > >> Of Ram Mohan R (rmohanr) > >> > >> Sent: Friday, October 28, 2011 10:24 AM > >> > >> To: Paul Kyzivat; siprec@ietf.org > >> > >> Subject: Re: [siprec] Issue with participant scoping in the > >> current > >> > >> modeland its implication on association attr representation > >> > >> > >> > >> To add to Paul, with the proposed change, the model will look > as > >> > below > >> > >> > >> > >> +-------------------------------+ > >> > >> | Communication Session (CS) | > >> > >> | | > >> > >> +-------------------------------+ > >> > >> | 0..* |1..* > >> > >> | ^^^^^^^^ | > >> > >> | 2..* |0..* > >> > >> +-------------+ receives +----------------+ > >> > >> | Participant |----------| Media Streams | > >> > >> | |0..* 0..*| | > >> > >> | | | | > >> > >> | | | | > >> > >> | | sends | | > >> > >> | |----------| | > >> > >> | |1.* 0..*| | > >> > >> +-------------+ +----------------+ > >> > >> > >> > >> A participant can be associated with zero or more sessions. > >> > >> > >> > >> And with the above model we can have an approach to define a > >> > > participant > >> > >> with no associations to sessions and have XML elements separate > >> > (like > >> > >> ) for association classes as in approach > 2 > >> > >> mentioned below > >> > >> > >> > >> Ram > >> > >> > >> > >>> -----Original Message----- > >> > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > >On > >> > >>> Behalf Of Paul Kyzivat > >> > >>> Sent: Friday, October 28, 2011 2:42 AM > >> > >>> To: siprec@ietf.org > >> > >>> Subject: Re: [siprec] Issue with participant scoping in the > >> current > >> > >>> model and its implication on association attr representation > >> > >>> > >> > >>> On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote: > >> > >>>> (Sorry for lengthy e-mail) > >> > >>>> > >> > >>>> This is a follow up to the mail thread > >> > >>>> http://www.ietf.org/mail- > >> archive/web/siprec/current/msg02810.html > >> > >>>> > >> > >>>> In the last IETF meeting there was a consensus that a > >> participant > >> > >> can > >> > >>>> have a life outside of CS. > >> > >>>> > >> > >>>> However the current model scopes participant to always a > >> session. > >> > >>> > >> > >>> I don't think that is quite right. The *model* requires that > >each > >> > >>> participant be associated with one or more sessions. It > doesn't > >> > scope > >> > >>> to > >> > >>> a single session. > >> > >>> > >> > >>>> Should we have to change the model to have participant > outside > >> > > scope > >> > >>> of > >> > >>>> session ? I think it may not make sense to model participants > >> > under > >> > >>> RS > >> > >>>> as these are participants of Session. The only use case where > >we > >> > > can > >> > >>>> have a participant in a RS with no CS is for Persistent > >> recording > >> > >>>> sessions (e.g. setup from agent phone(SRC) to SRS) This RS > will > >> be > >> > >>> setup > >> > >>>> even without any CS. If an SRC for this case sends a > snapshot > >> > >> before > >> > >>> a > >> > >>>> CS starts it may have participant information without any > >> session. > >> > >>>> Does the WG sees a value in such a use case or should we > retain > >> > the > >> > >>>> model as is ? > >> > >>> > >> > >>> IMO the change we would be talking about is that a participant > >> can > >> > be > >> > >>> associated with *zero* or more sessions, rather than one or > >more. > >> > >>> > >> > >>> In addition to the use case Ram mentions above, this would > help > >> > with > >> > >>> the > >> > >>> mapping to xml. If we go with participantSessAssoc (as > mentioned > >> > >> below) > >> > >>> it becomes *possible* to define a participant with no > >> associations > >> > to > >> > >>> sessions. Allowing the same in the model at least makes them > >> > >>> consistent. > >> > >>> > >> > >>> Thanks, > >> > >>> Paul > >> > >>> > >> > >>>> The current model (ver 04) also impacts the way association > >> > >>> attributes > >> > >>>> are represented. Since the current draft (ver-04)the metadata > >> > model > >> > >>>> scopes participant and stream elements to session the schema > >> also > >> > >> was > >> > >>>> designed the same way. The and > >> attributes > >> > > are > >> > >>>> scoped/associated to a session (see section 7.1 example). IOW > >> the > >> > >>>> association attributes of to are > >> already > >> > >>>> represented. > >> > >>>> > >> > >>>> Now if we have to go with approach 2 for representing > >> association > >> > >>>> attributes, we will have to do one of the two ways: > >> > >>>> > >> > >>>> > >> > >>>> If we stick the current model/schema: > >> > >>>> ----------------------------------- > >> > >>>> We will have represent in the following way. Note this is a > mix > >> of > >> > >>>> approach 1 (existing representation which acheives > participant > >> > >>> session > >> > >>>> association) and approach 2 ( for part-stream association). > >The > >> > >>> issue > >> > >>>> with this approach is if the same participant is > simultaneously > >> in > >> > >>>> multiple sessions( cases like participant goes on hold on one > >> line > >> > >>> and > >> > >>>> talks to another participant) and SRC sends a snapshot then > we > >> > will > >> > >>> have > >> > >>>> multiple elements each having different > session > >> > IDs. > >> > >>>> >> > >>>> > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >> > >>>> > >> > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > >> > >>>> sip:ram@blr.cisco.com > >> > >>>> 2010-12- > >> > 16T23:41:07Z >> > >>> time> > >> > >>>> XXX > >> > >>>> > >> > >>>> > >> > >>>> And for participant-stream you will have a new element > >> > >>>> > >> > >>>> >> > >>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007- > 6ddbecca64d3" > >> > >>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a = "> > >> > >>>> 2010-12-16T23:41:07Z > >> > >>>> contributing SSRC-1 > >> > >>>> > >> > >>>> > >> > >>>> If we change the model to remove the scoping of > >> participant/stream > >> > >> to > >> > >>>> session: > >> > >>>> > >> > >> > >> -------------------------------------------------------------------- > >> > - > >> > >>> --- > >> > >>>> ----- > >> > >>>> > >> > >>>> >> > >>>> > >id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> > >> > >>>> sip:ram@blr.cisco.com > >> > >>>> > >> > >>>> > >> > >>>> >> > >>>> > >> > >> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > >> > >>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- > >> > 6da1eeaeb425" > >> > >>>> > >> > >> 2010-12-16T23:41:07Z > >> > >>>> XXX > >> > >>>> > >> > >>>> > >> > >>>> >> > >>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007- > 6ddbecca64d3" > >> > >>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a = "> > >> > >>>> 2010-12-16T23:41:07Z > >> > >>>> contributing SSRC-1 > >> > >>>> > >> > >>>> > >> > >>>> Let me know your comments. > >> > >>>> > >> > >>>> Regards, > >> > >>>> Ram > >> > >>>> _______________________________________________ > >> > >>>> 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@alum.mit.edu Fri Oct 28 10: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 69CF021F84B5 for ; Fri, 28 Oct 2011 10:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20RcDlblpN8t for ; Fri, 28 Oct 2011 10:29:43 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id B487821F84B4 for ; Fri, 28 Oct 2011 10:29:42 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id qH711h0031swQuc51HVjvq; Fri, 28 Oct 2011 17:29:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.westchester.pa.mail.comcast.net with comcast id qHVi1h00W0tdiYw3bHVi2S; Fri, 28 Oct 2011 17:29:43 +0000 Message-ID: <4EAAE681.40107@alum.mit.edu> Date: Fri, 28 Oct 2011 13:29:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com>, <35BCE99A477D6A4986FB2216D8CF2CFD082B7DD5@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B806E@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D6B@sonusinmail02.sonusnet.com> , <4EAAD2C9.5030008@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and 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: Fri, 28 Oct 2011 17:29:44 -0000 On 10/28/11 12:10 PM, john.2.stafford@bt.com wrote: > Paul, > > OK, I understand, but how does the recorder know that the stream sent by the focus is a mixed conference stream , ie contains all of the streams received by the focus. ? I don't think I understand the question. The SRS should just believe what it is told: the stream it receives contains a mix of all the participants reported as sending to it. Thanks, Paul > Rgds > John Stafford | Solution Architect 1 | BT Global Services > > ________________________________________ > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: 28 October 2011 17:05 > To: siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and in XML ? > > On 10/28/11 11:06 AM, john.2.stafford@bt.com wrote: >> >> Ram, >>>> I presume the participant - CS element will be replaced by >>>> the< participantSessionAssoc>. >>> >>> No. will continue to remain. We are talking about association >>> attributes of participant-session. >>> The other attributes of and which are not >>> association attributes will continue to be the respective elements. >> >> What I meant to say was: >> I presume the participant's session attribute will be replaced by the. >> Is that correct ? > > Yup, that's the idea. > >> RE use of, this means for a large conference each participant update will be very large as it needs to include recv's for every other participants send ? > > The association is between each participant and a stream, not between > two participants. There are two ways to represent this, and neither has > the problem you describe: > > - one stream for the conference. > Each participant both sends and receives it. > > - one stream for each participant in the conference. > The focus is represented as a participant. > Each real participant sends and receives its own stream. > The focus sends and receives all the streams. > > I guess the situation you describe would occur if there was a full-mesh > of streams between participants. But afaik nobody does that. And if they > did it would be hard to get an SRC in the middle. > > Thanks, > Paul > >> Rgds John >> >> >> -----Original Message----- >> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 28 October 2011 14:43 >> To: Ram Mohan R (rmohanr); Stafford,J,John,JRJ3X C; siprec@ietf.org >> Subject: RE: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and in XML ? >> >> Hi, >> >> IMO, send& recv are the element which has to be pushed inside participant stream association element which is inline with the model. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >>> Of Ram Mohan R (rmohanr) >>> Sent: Friday, October 28, 2011 7:04 PM >>> To: john.2.stafford@bt.com; siprec@ietf.org >>> Subject: Re: [siprec] Need Inputs: How to >>> representattributesofassociation in Metadata Model and in XML ? >>> >>> Hello John S, >>> >>> Please see inline for answers. >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of john.2.stafford@bt.com >>>> Sent: Thursday, October 27, 2011 11:15 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Need Inputs: How to represent >>>> attributesofassociation in Metadata Model and in XML ? >>>> >>>> I am not clear on the effect on the other XMl elements. >>>> >>>> I presume the participant - CS element will be replaced by >>>> the< participantSessionAssoc>. >>> >>> No. will continue to remain. We are talking about association >>> attributes of participant-session. >>> The other attributes of and which are not >>> association attributes will continue to be the respective elements. >>> >>>> >>>> I also presume and will no longer be needed, and that >>>> the will include an attribute to say send >>> or >>>> recv ? >>> >>> This is a good suggestion. I have not given a thought on this so far. >> In >>> principle this should be fine as once the association of a participant >>> to a stream ends it stops sending/receiving the same. We need to think >>> through different use-cases to see if its fine to have, >>> inside association element itself. By having send, recv inside the >>> association we can avoid one XML element as they can be attribute. >>> >>>> >>>> Is that correct ? >>>> >>>> I hope the rule will remain that, in the abscence of any recv >>> elements >>>> by default a stream is assumed to be recieved by all participants. >>> >>> No, in the last IETF we agreed it's better to always explicity indicate >>> recv. We will continue to stick to that as I see no reason to change. >>> >>> Regards, >>> Ram >>> >>>> >>>> Rgds >>>> John Stafford | Solution Architect 1 | BT Global Services >>>> >>>> ________________________________________ >>>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >>>> Ram Mohan R (rmohanr) [rmohanr@cisco.com] >>>> Sent: 27 October 2011 18:08 >>>> To: John Elwell; Paul Kyzivat; siprec@ietf.org >>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>> ofassociation in Metadata Model and in XML ? >>>> >>>> Hi John, >>>> >>>> Thanks for your comment on this. Yes several of us seem to be >> inclined >>>> towards approach 2. I like your point that once one of the elements >>> in >>>> the association gets deleted, the association element life ends. SRC >>>> may choose to send the association element optionally or the SRS can >> still >>>> learn that as the way you mentioned. >>>> >>>> We ( authors of metadata draft ) discussed internally on this open >>> item >>>> and see some issues with adopting approach 2 as is with the current >>>> model /schema. I will start a separate mail thread for the issue as >>>> this thread is already too long. >>>> >>>> Thanks, >>>> Ram >>>> >>>> >>>>> -----Original Message----- >>>>> From: John Elwell [mailto:john.r.elwell@gmail.com] >>>>> Sent: Thursday, October 27, 2011 2:03 PM >>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat; siprec@ietf.org >>>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>>> ofassociation in Metadata Model and in XML ? >>>>> >>>>> Approach 2 seems reasonable. Could we say that an association is >>>>> implicitly deleted (gains a dissociate time) as soon as one of the >>>>> associated elements is deleted (gains a dissociate time)? This >>>>> would reduce the on-the >>>> wire >>>>> document size for both partial and full metadata in some >>>> circumstances >>>>> (e.g., conference termination by the focus). >>>>> >>>>> John >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "Ram Mohan R (rmohanr)" >>>>> To: "Paul Kyzivat"; >>>>> Sent: Friday, October 14, 2011 4:59 AM >>>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>>> ofassociation in Metadata Model and in XML ? >>>>> >>>>> >>>>>> Thanks Paul for your comments. I also prefer approach 2 as >>>> mentioned >>>>>> below in this thread. >>>>>> I will wait to hear for comments/opinion from others. >>>>>> >>>>>> Ram >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >>>>>>> Behalf Of Paul Kyzivat >>>>>>> Sent: Thursday, October 13, 2011 10:48 PM >>>>>>> To: siprec@ietf.org >>>>>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >> of >>>>>>> association in Metadata Model and in XML ? >>>>>>> >>>>>>> I like approach 2, as Ram has shown it. It deals with the >>> problems >>>>>> John >>>>>>> raised with the others. >>>>>>> >>>>>>> I didn't follow John's arithmetic on this one, using his 20 >> party >>>>>>> conference example. As I count that, there are 21 participants >>>> when >>>>>> you >>>>>>> include the focus. Each of the 20 has two stream/participant >>>>>>> associations with the focus, for a total of 40. (The association >>>> is >>>>>>> bidirectional. I can only get to 80 by assuming we had to >>>> represent >>>>> an >>>>>>> association in each direction.) And each has two ids, each of >>>> which >>>>> is >>>>>>> also the id of a stream or participant. So there are really only >>>> 23 >>>>>>> distinct ids that need to be assigned for this. (One for each of >>>> the >>>>>> 21 >>>>>>> participants, and one for each of the two streams.) >>>>>>> >>>>>>> The 40 associations, each carrying two ids, is still kind of a >>> lot >>>>> if >>>>>>> its sent all at once. But when starting up a conference they >> will >>>>>>> probably be added gradually as each participant joins. Same at >>> the >>>>> end >>>>>>> if they drop off individually. But it could be a bunch together >>> if >>>>> the >>>>>>> conference is forcibly dropped by the focus. But it does >> minimize >>>>> what >>>>>>> is sent when things happen incrementally. >>>>>>> >>>>>>> There may be some optimizations that can be done - e.g. a sort >> of >>>>>>> "wildcard" for one of the the two ids in the association class. >>>> E.g. >>>>>>> >>>>>>> >>>>>> participant="*" >>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>> >> 2010-12-16T23:41:07Z >>>>>>> >>>>>>> >>>>>>> (I'm not advocating that particular syntax. Its just something >> to >>>>> make >>>>>>> the point.) >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: >>>>>>>> My bad(typo) while sending the example. The correct partial >>>> update >>>>> I >>>>>>>> intended to send is: >>>>>>>> >>>>>>>> >>>>>>> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>>> 2010-12-16T23:41:07Z>>> time> >>>>>>>> >>>>>>>> >>>>>>>> This is inline with approach 2 where in each association XML >>>>> element >>>>>>>> will have the IDs of the related associated elements. >>>>>>>> >>>>>>>> Ram >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>>> Sent: Wednesday, October 12, 2011 2:24 PM >>>>>>>>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>>>>> Cc: Ofir Roth >>>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>>> association >>>>>>>> in >>>>>>>>> Metadata Model and in XML ? >>>>>>>>> >>>>>>>>> We do prefer to receive related elements as well, it makes >>>>>>>>> implementation much easier. >>>>>>>>> At least we should get relevant IDs. For example below, >> SRC >>>>>>> should >>>>>>>>> also send ParticipantId >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>>>> Sent: Wednesday, October 12, 2011 10:52 AM >>>>>>>>> To: Leon Portman; siprec@ietf.org >>>>>>>>> Cc: Ofir Roth >>>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>>> association >>>>>>>> in >>>>>>>>> Metadata Model and in XML ? >>>>>>>>> >>>>>>>>> Leon, >>>>>>>>> Thanks for your response. One of the adv with approach 2 is >> we >>>>> can >>>>>>>>> indicate only changes in the association without the need to >>>>>>>> indicating >>>>>>>>> the elements ( of association). IOW for the below example, if >>>>> there >>>>>>> is >>>>>>>>> a change in participant-stream association I can simply send >>>> the >>>>>>>>> following in partial update: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> >>>>>>>>> >>>> 2010-12-16T23:41:07Z >>>>>>>>> >>>>>>>>> >>>>>>>>> Do you see a need to always indicate the related elements too >>> ? >>>>> In >>>>>>>>> which case I see approach 1 as more suitable. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Ram >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>>>> Sent: Wednesday, October 12, 2011 12:55 PM >>>>>>>>>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>>>>>> Cc: Ofir Roth >>>>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>>>> association >>>>>>>>>> inmetadata Model and in XML ? >>>>>>>>>> >>>>>>>>>> Ram Hi >>>>>>>>>> >>>>>>>>>> I am ok with approaches 1 and however I do prefer approach >>>> one >>>>>>>>> because >>>>>>>>>> it will be easier for SRS to get decode - association is >>>> inside >>>>>>>>>> relevant element. And it is more readable. >>>>>>>>>> Approach 2 will work as well, however it is important that >> if >>>>>> there >>>>>>>>>> will be a change in association then to send to SRS not only >>>>>>> updated >>>>>>>>>> association element but also related elements: for example >> if >>>>>>> stream >>>>>>>>>> was associated to participant and session, send also >>>> participant >>>>>>> and >>>>>>>>>> session latest state. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Leon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] >>>>> On >>>>>>>>>> Behalf Of Ram Mohan R (rmohanr) >>>>>>>>>> Sent: Wednesday, October 12, 2011 7:48 AM >>>>>>>>>> To: siprec@ietf.org >>>>>>>>>> Subject: [siprec] Need Inputs: How to represent attributes >> of >>>>>>>>>> association in metadata Model and in XML ? >>>>>>>>>> >>>>>>>>>> (Sorry for lengthy e-mail) >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> In the last interim we discussed 4 approaches for >>> representing >>>>>>>>>> attributes of association in XML. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here are some pros/cons for each of them: >>>>>>>>>> Approach 1: >>>>>>>>>> ---------- >>>>>>>>>> Represent the association attribute as a property within one >>>> of >>>>>> the >>>>>>>>>> associated elements. Example given at >>>> http://www.ietf.org/mail- >>>>>>>>>> archive/web/siprec/current/msg02709.html Does not need >>> another >>>>> XML >>>>>>>>>> element and represents the association attributes as >>>> capability >>>>> of >>>>>>>>> one >>>>>>>>>> of the association element. >>>>>>>>>> e.g. >>>>>>>>>> >>>>>>>>> >>> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>>> session="urn:uuid:855a5ded-8420-456d-a70f- >>>>>>> 6da1eeaeb425"> >>>>>>>>>> sip:ram@blr.cisco.com >>>>>>>>>> 2010-12- >>>>> 16T23:41:07Z>>>>>>>> time> >>>>>>>>>> TBD >>>>>>>>>> >>>>>>>>> stream >> ="urn:uuid:f3373a7b-4958-4e55-8820- >>>>>>>>>> d03a191fb76a >>>>>>>>>> "> >>>>>>>>>> 2010-12- >>>>>>> 16T23:41:07Z>>>>>>>>> time> >>>>>>>>>> contributing SSRC-1 >>>>>>>>>> >>>> In >>>>>>> the >>>>>>>>> above >>>>>>>>>> example the participant contributes a single streams. For >>> each >>>>>>>> stream >>>>>>>>>> the association attribute (participant-stream) is shown with >>>> the >>>>>>>>> stream >>>>>>>>>> ID nested in. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Approach 2: >>>>>>>>>> ----------- >>>>>>>>>> In this approach we have a new XML element for every >>>> association >>>>>>>>> class. >>>>>>>>>> This xml element will NOT have a unique ID instead it >>>> references >>>>>>> the >>>>>>>>> ID >>>>>>>>>> of associated elements (shown below). With this approach it >>> is >>>>>> easy >>>>>>>>> to >>>>>>>>>> update as the association class is a separate XML element >> and >>>>> not >>>>>>>>>> property. >>>>>>>>>> e.g. >>>>>>>>>> >>>>>>>>> >> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>>> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>>> TBD >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>>> contributing SSRC-1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Approach 3 and 4 are in the below e-mail from John. >>>>>>>>>> Approach 3 defines a new Unique ID for every association XML >>>>>>> elment. >>>>>>>>>> Also it creates alias for the other IDs. In the discussions >>> in >>>>>>>>> interim >>>>>>>>>> there was no strong support for this approach. >>>>>>>>>> >>>>>>>>>> Approach 4 is same as approach 1 where in the association >>>>> element >>>>>>> is >>>>>>>>>> encapsulated in one of the XML elements (to which it is >>>>>>>> associated). >>>>>>>>>> In addition to that it also has reference to the elements >>>> (alias >>>>>> of >>>>>>>>>> IDs) to which the association belongs. >>>>>>>>>> >>>>>>>>>> I prefer approach 2 as it is has a separate XML element to >>>>>>> represent >>>>>>>>>> the association class. The only difference of this XML >>> element >>>>>> from >>>>>>>>>> others is this does not need a unique ID. Instead it >>>> references >>>>>> the >>>>>>>>> IDs >>>>>>>>>> of the elements to which the association belongs. >>>>>>>>>> Since association class is a special class meant to >> associate >>>>>>>>> multiple >>>>>>>>>> classes, I see it ok to have a representation as in approach >>> 2 >>>>>>> where >>>>>>>>> in >>>>>>>>>> the identifier is the concatenation of the classes to which >>>> the >>>>>>>>>> association belongs to. >>>>>>>>>> >>>>>>>>>> Please provide your comments on this and also suggest any >>>> other >>>>>>>>>> approaches to represent association classes in XML. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Ram >>>>>>>>>> >>>> _______________________________________________ >>>> 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@alum.mit.edu Fri Oct 28 11:01: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 B400421F8997 for ; Fri, 28 Oct 2011 11:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM-fP27zbeYt for ; Fri, 28 Oct 2011 11:01:27 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4D33121F84A1 for ; Fri, 28 Oct 2011 11:01:26 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta08.westchester.pa.mail.comcast.net with comcast id qEgN1h00427AodY58J1Tx4; Fri, 28 Oct 2011 18:01:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta19.westchester.pa.mail.comcast.net with comcast id qJ1S1h00g0tdiYw3fJ1SXF; Fri, 28 Oct 2011 18:01:27 +0000 Message-ID: <4EAAEDF5.7080004@alum.mit.edu> Date: Fri, 28 Oct 2011 14:01:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Ram Mohan R (rmohanr)" References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com><4EA9C920.8000200@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD082B7ECA@XMB-BGL-417.cisco.com><2E239D6FCD033C4BAF15F386A979BF51159D3F@sonusinmail02.sonusnet.com><4EAAB8E9.8070708@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD082B80A1@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B80A3@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D78@sonusinmail02.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B80C3@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD082B80C3@XMB-BGL-417.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] participant & stream outside the scope of 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, 28 Oct 2011 18:01:28 -0000 +1 to Ram's response. As I noted before, if you want to reopen question of allowing stream without session, I think that should be discussed separately. Thanks, Paul On 10/28/11 1:27 PM, Ram Mohan R (rmohanr) wrote: > Hi Partha, > > Please see inline > >> -----Original Message----- >> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: Friday, October 28, 2011 10:49 PM >> To: Ram Mohan R (rmohanr); Paul Kyzivat >> Cc: siprec@ietf.org >> Subject: RE: [siprec] participant& stream outside the scope of > session >> >> Hi Ram, >> >> As Paul mentioned, stream associated with zero session was brought up >> as >> part of the persistent connection from the endpoint discussion and it >> was pushed back because stream& participant has to be within session >> (CS). I'm worried that participant to zero session change may re-open >> the earlier closure and call for one more discussion. >> >> Also, the current syntax of stream is associated with session closely >> which has to be changed consistently in case participant is changed > its >> association representation with session. > > I don't see a need for the above. We are changing the participant > association to session to allow it to be consistent with XML if we > choose approach 2. > Even in approach 2, stream has to be associated with a session and so > there is no need to change that association. > > Regards, > Ram > >> >> > session="urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103"> >> >> >> >> It will be good in case we get the feedback on these aspect. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>> Sent: Friday, October 28, 2011 9:39 PM >>> To: Ram Mohan R (rmohanr); Paul Kyzivat; Ravindran Parthasarathi >>> Cc: siprec@ietf.org >>> Subject: RE: [siprec] participant& stream outside the scope of >> session >>> >>> A typo in the below email. Sorry for that. I meant >>> >>> " >>> I don't see a strong use case to have stream associate to zero >>> sessions. IMO we can retain the stream associations >>> ^^^^^^ >>> ^^^^ >>> as it is in the current model." >>> >>> Thanks, >>> Ram >>> >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Ram Mohan R (rmohanr) >>>> Sent: Friday, October 28, 2011 9:27 PM >>>> To: Paul Kyzivat; Ravindran Parthasarathi >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] participant& stream outside the scope of >>> session >>>> >>>> I don't see a strong use case to have session associate to zero >>>> sessions. IMO we can retain the session associations as it is in > the >>>> current model. >>>> >>>> Now coming to participant, the main reason why I am inclined to >> change >>>> the association is to have consistency with XML if we adopt >> approach >>>> 2. >>>> >>>> Regards, >>>> Ram >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: Friday, October 28, 2011 7:45 PM >>>>> To: Ravindran Parthasarathi >>>>> Cc: Ram Mohan R (rmohanr); siprec@ietf.org >>>>> Subject: Re: participant& stream outside the scope of session >>>>> >>>>> This proposes an additional change, to remove the subordination > of >>>>> stream to session. IMO this should be considered separately from >>>>> participant, as the arguments are different. >>>>> >>>>> AFAICT, the use case Partha gives below is the only one that > calls >>>> for >>>>> stream independent of session. And I'm not sure of the need for >>> this. >>>>> ISTM the only reason to do this is to really record streams from >>>>> participants when there is no session. >>>>> >>>>> This might allow capturing media earlier during call setup, by >>>> defining >>>>> the streams early, and associating them with participants and >>>> sessions >>>>> when that becomes known. *If* an SRS can figure out how to take >>>>> advantage of that. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 10/28/11 5:09 AM, Ravindran Parthasarathi wrote: >>>>>> >>> major >>>>>> change in metadata> >>>>>> >>>>>> I'm interested in knowing whether folks are interested in >> handling >>>>>> participant, stream completely outside the scope of session. >>>>>> In fact, we discussed this requirement as part of metadata > model >>>>>> discussion and come to the conclusion not to include. In case >>>>>> participant, stream are outside the scope of session, the >>> following >>>>>> recording metadata from SRC is valid: >>>>>> >>>>>> >>>>>> full >>>>>> >>>>> id="urn:uuid:b2b7c112-5982-469d-9007- >> 6ddbecca64d3"> >>>>>> sip:agent1@callcenter.com >>>>>> urn:uuid:f3373a7b-4958-4e55-8820- >>>>> d03a191fb76a >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Also, in the later partial update, session shall be added and >>>>> associate >>>>>> with the above participant& stream element. >>>>>> >>>>>> Here, SRS has to maintain participant, stream unique id as a >>>> separate >>>>>> flat >>>>>> Data (no hierarchy). Only issue is that SRS has to maintain > flat >>>>>> database for >>>>>> Each of these elements. >>>>>> >>>>>> The current -04 draft is based on the assumption that >> participant >>>> and >>>>>> stream are within a session and it is possible for participant& >>>>> stream >>>>>> to move across multiple sessions using unique id. The rationale >> of >>>>> the >>>>>> current draft approach is that commonly used callflow metadata >> is >>>>> simple >>>>>> >>>>>> whereas specific corner case callflow like same participant in >>>>> multiple >>>>>> session will have complex mechanism. >>>>>> >>>>>> In case we see the strong usecases for going for independent >>>> stream, >>>>>> Participants which is outside the session, we will go for it. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >>>>>> Behalf >>>>>>> Of Ram Mohan R (rmohanr) >>>>>>> Sent: Friday, October 28, 2011 10:24 AM >>>>>>> To: Paul Kyzivat; siprec@ietf.org >>>>>>> Subject: Re: [siprec] Issue with participant scoping in the >>>> current >>>>>>> modeland its implication on association attr representation >>>>>>> >>>>>>> To add to Paul, with the proposed change, the model will look >> as >>>>> below >>>>>>> >>>>>>> +-------------------------------+ >>>>>>> | Communication Session (CS) | >>>>>>> | | >>>>>>> +-------------------------------+ >>>>>>> | 0..* |1..* >>>>>>> | ^^^^^^^^ | >>>>>>> | 2..* |0..* >>>>>>> +-------------+ receives +----------------+ >>>>>>> | Participant |----------| Media Streams | >>>>>>> | |0..* 0..*| | >>>>>>> | | | | >>>>>>> | | | | >>>>>>> | | sends | | >>>>>>> | |----------| | >>>>>>> | |1.* 0..*| | >>>>>>> +-------------+ +----------------+ >>>>>>> >>>>>>> A participant can be associated with zero or more sessions. >>>>>>> >>>>>>> And with the above model we can have an approach to define a >>>>>> participant >>>>>>> with no associations to sessions and have XML elements > separate >>>>> (like >>>>>>> ) for association classes as in approach >> 2 >>>>>>> mentioned below >>>>>>> >>>>>>> Ram >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] >>> On >>>>>>>> Behalf Of Paul Kyzivat >>>>>>>> Sent: Friday, October 28, 2011 2:42 AM >>>>>>>> To: siprec@ietf.org >>>>>>>> Subject: Re: [siprec] Issue with participant scoping in the >>>> current >>>>>>>> model and its implication on association attr representation >>>>>>>> >>>>>>>> On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote: >>>>>>>>> (Sorry for lengthy e-mail) >>>>>>>>> >>>>>>>>> This is a follow up to the mail thread >>>>>>>>> http://www.ietf.org/mail- >>>> archive/web/siprec/current/msg02810.html >>>>>>>>> >>>>>>>>> In the last IETF meeting there was a consensus that a >>>> participant >>>>>>> can >>>>>>>>> have a life outside of CS. >>>>>>>>> >>>>>>>>> However the current model scopes participant to always a >>>> session. >>>>>>>> >>>>>>>> I don't think that is quite right. The *model* requires that >>> each >>>>>>>> participant be associated with one or more sessions. It >> doesn't >>>>> scope >>>>>>>> to >>>>>>>> a single session. >>>>>>>> >>>>>>>>> Should we have to change the model to have participant >> outside >>>>>> scope >>>>>>>> of >>>>>>>>> session ? I think it may not make sense to model > participants >>>>> under >>>>>>>> RS >>>>>>>>> as these are participants of Session. The only use case > where >>> we >>>>>> can >>>>>>>>> have a participant in a RS with no CS is for Persistent >>>> recording >>>>>>>>> sessions (e.g. setup from agent phone(SRC) to SRS) This RS >> will >>>> be >>>>>>>> setup >>>>>>>>> even without any CS. If an SRC for this case sends a >> snapshot >>>>>>> before >>>>>>>> a >>>>>>>>> CS starts it may have participant information without any >>>> session. >>>>>>>>> Does the WG sees a value in such a use case or should we >> retain >>>>> the >>>>>>>>> model as is ? >>>>>>>> >>>>>>>> IMO the change we would be talking about is that a > participant >>>> can >>>>> be >>>>>>>> associated with *zero* or more sessions, rather than one or >>> more. >>>>>>>> >>>>>>>> In addition to the use case Ram mentions above, this would >> help >>>>> with >>>>>>>> the >>>>>>>> mapping to xml. If we go with participantSessAssoc (as >> mentioned >>>>>>> below) >>>>>>>> it becomes *possible* to define a participant with no >>>> associations >>>>> to >>>>>>>> sessions. Allowing the same in the model at least makes them >>>>>>>> consistent. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> The current model (ver 04) also impacts the way association >>>>>>>> attributes >>>>>>>>> are represented. Since the current draft (ver-04)the > metadata >>>>> model >>>>>>>>> scopes participant and stream elements to session the schema >>>> also >>>>>>> was >>>>>>>>> designed the same way. The and >>>> attributes >>>>>> are >>>>>>>>> scoped/associated to a session (see section 7.1 example). > IOW >>>> the >>>>>>>>> association attributes of to are >>>> already >>>>>>>>> represented. >>>>>>>>> >>>>>>>>> Now if we have to go with approach 2 for representing >>>> association >>>>>>>>> attributes, we will have to do one of the two ways: >>>>>>>>> >>>>>>>>> >>>>>>>>> If we stick the current model/schema: >>>>>>>>> ----------------------------------- >>>>>>>>> We will have represent in the following way. Note this is a >> mix >>>> of >>>>>>>>> approach 1 (existing representation which acheives >> participant >>>>>>>> session >>>>>>>>> association) and approach 2 ( for part-stream association). >>> The >>>>>>>> issue >>>>>>>>> with this approach is if the same participant is >> simultaneously >>>> in >>>>>>>>> multiple sessions( cases like participant goes on hold on > one >>>> line >>>>>>>> and >>>>>>>>> talks to another participant) and SRC sends a snapshot then >> we >>>>> will >>>>>>>> have >>>>>>>>> multiple elements each having different >> session >>>>> IDs. >>>>>>>>> >>>>>>>> >> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>> >>>>>> session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>>>>>> sip:ram@blr.cisco.com >>>>>>>>> 2010-12- >>>>> 16T23:41:07Z>>>>>>> time> >>>>>>>>> XXX >>>>>>>>> >>>>>>>>> >>>>>>>>> And for participant-stream you will have a new element >>>>>>>>> >>>>>>>>> >>>>>>>> participant="urn:uuid:b2b7c112-5982-469d-9007- >> 6ddbecca64d3" >>>>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>> contributing SSRC-1 >>>>>>>>> >>>>>>>>> >>>>>>>>> If we change the model to remove the scoping of >>>> participant/stream >>>>>>> to >>>>>>>>> session: >>>>>>>>> >>>>>>> >>>> > -------------------------------------------------------------------- >>>>> - >>>>>>>> --- >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>> >>> id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >>>>>>>>> sip:ram@blr.cisco.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>> session="urn:uuid:855a5ded-8420-456d-a70f- >>>>> 6da1eeaeb425" >>>>>>>>> >>>>>>> 2010-12-16T23:41:07Z >>>>>>>>> XXX >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> participant="urn:uuid:b2b7c112-5982-469d-9007- >> 6ddbecca64d3" >>>>>>>>> stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>> contributing SSRC-1 >>>>>>>>> >>>>>>>>> >>>>>>>>> Let me know your comments. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ram >>>>>>>>> _______________________________________________ >>>>>>>>> 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 pravindran@sonusnet.com Fri Oct 28 12:57:03 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 98D4821F8610 for ; Fri, 28 Oct 2011 12:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDAOMtKkfBhP for ; Fri, 28 Oct 2011 12:57:02 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC1B21F85F7 for ; Fri, 28 Oct 2011 12:57:02 -0700 (PDT) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9SJvYvX021873; Fri, 28 Oct 2011 15:57:34 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 15:56:59 -0400 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, 29 Oct 2011 01:19:00 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51159D7E@sonusinmail02.sonusnet.com> In-Reply-To: <4EAAEDF5.7080004@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] participant & stream outside the scope of session thread-index: AcyVm6FSEXoItteWRSWY5B83xRNGowAAE87w References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com><4EA9C920.8000200@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD082B7ECA@XMB-BGL-417.cisco.com><2E239D6FCD033C4BAF15F386A979BF51159D3F@sonusinmail02.sonusnet.com><4EAAB8E9.8070708@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD082B80A1@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B80A3@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D78@sonusinmail02.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B80C3@XMB-BGL-417.cisco.com> <4EAAEDF5.7080004@alum.mit.edu> From: "Ravindran Parthasarathi" To: "Paul Kyzivat" , "Ram Mohan R (rmohanr)" , "Leon Portman" X-OriginalArrivalTime: 28 Oct 2011 19:56:59.0102 (UTC) FILETIME=[C0A707E0:01CC95AB] Cc: siprec@ietf.org Subject: Re: [siprec] participant & stream outside the scope of 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, 28 Oct 2011 19:57:03 -0000 Paul/Ram, Now, participant and stream are associated with session as an aggregation. In case participant is possible to be represented outside session, it is very much possible for stream to be outside the session as shown in persistent usecase. In case of persistent usecase, RS stream is created in advance to avoid the earlier clipping, the session will be associated in metadata whenever the session is established, session will be terminated without removing RS stream In case new participant session associated XML element is added, it is possible to have stream session associated XML element as well separately. Including Leon in this mail thread as he asked for persistent usecase. I'm reopening this usecase because let us close the related issue at the same time. Thanks Partha >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >Sent: Friday, October 28, 2011 11:31 PM >To: Ram Mohan R (rmohanr) >Cc: Ravindran Parthasarathi; siprec@ietf.org >Subject: Re: [siprec] participant & stream outside the scope of session > >+1 to Ram's response. > >As I noted before, if you want to reopen question of allowing stream >without session, I think that should be discussed separately. > > Thanks, > Paul > >On 10/28/11 1:27 PM, Ram Mohan R (rmohanr) wrote: >> Hi Partha, >> >> Please see inline >> >>> -----Original Message----- >>> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] >>> Sent: Friday, October 28, 2011 10:49 PM >>> To: Ram Mohan R (rmohanr); Paul Kyzivat >>> Cc: siprec@ietf.org >>> Subject: RE: [siprec] participant& stream outside the scope of >> session >>> >>> Hi Ram, >>> >>> As Paul mentioned, stream associated with zero session was brought up >>> as >>> part of the persistent connection from the endpoint discussion and it >>> was pushed back because stream& participant has to be within session >>> (CS). I'm worried that participant to zero session change may re-open >>> the earlier closure and call for one more discussion. >>> >>> Also, the current syntax of stream is associated with session closely >>> which has to be changed consistently in case participant is changed >> its >>> association representation with session. >> >> I don't see a need for the above. We are changing the participant >> association to session to allow it to be consistent with XML if we >> choose approach 2. >> Even in approach 2, stream has to be associated with a session and so >> there is no need to change that association. >> >> Regards, >> Ram >> >>> >>> >> session=3D"urn:uuid:cd27cfa1-2bdd-4830-a653- >70374d10f103"> >>> >>> >>> >>> It will be good in case we get the feedback on these aspect. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>> Sent: Friday, October 28, 2011 9:39 PM >>>> To: Ram Mohan R (rmohanr); Paul Kyzivat; Ravindran Parthasarathi >>>> Cc: siprec@ietf.org >>>> Subject: RE: [siprec] participant& stream outside the scope of >>> session >>>> >>>> A typo in the below email. Sorry for that. I meant >>>> >>>> " >>>> I don't see a strong use case to have stream associate to zero >>>> sessions. IMO we can retain the stream associations >>>> ^^^^^^ >>>> ^^^^ >>>> as it is in the current model." >>>> >>>> Thanks, >>>> Ram >>>> >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Ram Mohan R (rmohanr) >>>>> Sent: Friday, October 28, 2011 9:27 PM >>>>> To: Paul Kyzivat; Ravindran Parthasarathi >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] participant& stream outside the scope of >>>> session >>>>> >>>>> I don't see a strong use case to have session associate to zero >>>>> sessions. IMO we can retain the session associations as it is in >> the >>>>> current model. >>>>> >>>>> Now coming to participant, the main reason why I am inclined to >>> change >>>>> the association is to have consistency with XML if we adopt >>> approach >>>>> 2. >>>>> >>>>> Regards, >>>>> Ram >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>> Sent: Friday, October 28, 2011 7:45 PM >>>>>> To: Ravindran Parthasarathi >>>>>> Cc: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>> Subject: Re: participant& stream outside the scope of session >>>>>> >>>>>> This proposes an additional change, to remove the subordination >> of >>>>>> stream to session. IMO this should be considered separately from >>>>>> participant, as the arguments are different. >>>>>> >>>>>> AFAICT, the use case Partha gives below is the only one that >> calls >>>>> for >>>>>> stream independent of session. And I'm not sure of the need for >>>> this. >>>>>> ISTM the only reason to do this is to really record streams from >>>>>> participants when there is no session. >>>>>> >>>>>> This might allow capturing media earlier during call setup, by >>>>> defining >>>>>> the streams early, and associating them with participants and >>>>> sessions >>>>>> when that becomes known. *If* an SRS can figure out how to take >>>>>> advantage of that. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 10/28/11 5:09 AM, Ravindran Parthasarathi wrote: >>>>>>> >>>> major >>>>>>> change in metadata> >>>>>>> >>>>>>> I'm interested in knowing whether folks are interested in >>> handling >>>>>>> participant, stream completely outside the scope of session. >>>>>>> In fact, we discussed this requirement as part of metadata >> model >>>>>>> discussion and come to the conclusion not to include. In case >>>>>>> participant, stream are outside the scope of session, the >>>> following >>>>>>> recording metadata from SRC is valid: >>>>>>> >>>>>>> >>>>>>> full >>>>>>> >>>>>> id=3D"urn:uuid:b2b7c112-5982-469d-9007- >>> 6ddbecca64d3"> >>>>>>> sip:agent1@callcenter.com >>>>>>> urn:uuid:f3373a7b-4958-4e55-8820- >>>>>> d03a191fb76a >>>>>>> >>>>>>> >>>>> d03a191fb76a"> >>>>>>> >>>>>>> >>>>>>> >>>>> 0090272ff725"> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Also, in the later partial update, session shall be added and >>>>>> associate >>>>>>> with the above participant& stream element. >>>>>>> >>>>>>> Here, SRS has to maintain participant, stream unique id as a >>>>> separate >>>>>>> flat >>>>>>> Data (no hierarchy). Only issue is that SRS has to maintain >> flat >>>>>>> database for >>>>>>> Each of these elements. >>>>>>> >>>>>>> The current -04 draft is based on the assumption that >>> participant >>>>> and >>>>>>> stream are within a session and it is possible for participant& >>>>>> stream >>>>>>> to move across multiple sessions using unique id. The rationale >>> of >>>>>> the >>>>>>> current draft approach is that commonly used callflow metadata >>> is >>>>>> simple >>>>>>> >>>>>>> whereas specific corner case callflow like same participant in >>>>>> multiple >>>>>>> session will have complex mechanism. >>>>>>> >>>>>>> In case we see the strong usecases for going for independent >>>>> stream, >>>>>>> Participants which is outside the session, we will go for it. >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >>> On >>>>>>> Behalf >>>>>>>> Of Ram Mohan R (rmohanr) >>>>>>>> Sent: Friday, October 28, 2011 10:24 AM >>>>>>>> To: Paul Kyzivat; siprec@ietf.org >>>>>>>> Subject: Re: [siprec] Issue with participant scoping in the >>>>> current >>>>>>>> modeland its implication on association attr representation >>>>>>>> >>>>>>>> To add to Paul, with the proposed change, the model will look >>> as >>>>>> below >>>>>>>> >>>>>>>> +-------------------------------+ >>>>>>>> | Communication Session (CS) | >>>>>>>> | | >>>>>>>> +-------------------------------+ >>>>>>>> | 0..* |1..* >>>>>>>> | ^^^^^^^^ | >>>>>>>> | 2..* |0..* >>>>>>>> +-------------+ receives +----------------+ >>>>>>>> | Participant |----------| Media Streams | >>>>>>>> | |0..* 0..*| | >>>>>>>> | | | | >>>>>>>> | | | | >>>>>>>> | | sends | | >>>>>>>> | |----------| | >>>>>>>> | |1.* 0..*| | >>>>>>>> +-------------+ +----------------+ >>>>>>>> >>>>>>>> A participant can be associated with zero or more sessions. >>>>>>>> >>>>>>>> And with the above model we can have an approach to define a >>>>>>> participant >>>>>>>> with no associations to sessions and have XML elements >> separate >>>>>> (like >>>>>>>> ) for association classes as in approach >>> 2 >>>>>>>> mentioned below >>>>>>>> >>>>>>>> Ram >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] >>>> On >>>>>>>>> Behalf Of Paul Kyzivat >>>>>>>>> Sent: Friday, October 28, 2011 2:42 AM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: Re: [siprec] Issue with participant scoping in the >>>>> current >>>>>>>>> model and its implication on association attr representation >>>>>>>>> >>>>>>>>> On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote: >>>>>>>>>> (Sorry for lengthy e-mail) >>>>>>>>>> >>>>>>>>>> This is a follow up to the mail thread >>>>>>>>>> http://www.ietf.org/mail- >>>>> archive/web/siprec/current/msg02810.html >>>>>>>>>> >>>>>>>>>> In the last IETF meeting there was a consensus that a >>>>> participant >>>>>>>> can >>>>>>>>>> have a life outside of CS. >>>>>>>>>> >>>>>>>>>> However the current model scopes participant to always a >>>>> session. >>>>>>>>> >>>>>>>>> I don't think that is quite right. The *model* requires that >>>> each >>>>>>>>> participant be associated with one or more sessions. It >>> doesn't >>>>>> scope >>>>>>>>> to >>>>>>>>> a single session. >>>>>>>>> >>>>>>>>>> Should we have to change the model to have participant >>> outside >>>>>>> scope >>>>>>>>> of >>>>>>>>>> session ? I think it may not make sense to model >> participants >>>>>> under >>>>>>>>> RS >>>>>>>>>> as these are participants of Session. The only use case >> where >>>> we >>>>>>> can >>>>>>>>>> have a participant in a RS with no CS is for Persistent >>>>> recording >>>>>>>>>> sessions (e.g. setup from agent phone(SRC) to SRS) This RS >>> will >>>>> be >>>>>>>>> setup >>>>>>>>>> even without any CS. If an SRC for this case sends a >>> snapshot >>>>>>>> before >>>>>>>>> a >>>>>>>>>> CS starts it may have participant information without any >>>>> session. >>>>>>>>>> Does the WG sees a value in such a use case or should we >>> retain >>>>>> the >>>>>>>>>> model as is ? >>>>>>>>> >>>>>>>>> IMO the change we would be talking about is that a >> participant >>>>> can >>>>>> be >>>>>>>>> associated with *zero* or more sessions, rather than one or >>>> more. >>>>>>>>> >>>>>>>>> In addition to the use case Ram mentions above, this would >>> help >>>>>> with >>>>>>>>> the >>>>>>>>> mapping to xml. If we go with participantSessAssoc (as >>> mentioned >>>>>>>> below) >>>>>>>>> it becomes *possible* to define a participant with no >>>>> associations >>>>>> to >>>>>>>>> sessions. Allowing the same in the model at least makes them >>>>>>>>> consistent. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>> The current model (ver 04) also impacts the way association >>>>>>>>> attributes >>>>>>>>>> are represented. Since the current draft (ver-04)the >> metadata >>>>>> model >>>>>>>>>> scopes participant and stream elements to session the schema >>>>> also >>>>>>>> was >>>>>>>>>> designed the same way. The and >>>>> attributes >>>>>>> are >>>>>>>>>> scoped/associated to a session (see section 7.1 example). >> IOW >>>>> the >>>>>>>>>> association attributes of to are >>>>> already >>>>>>>>>> represented. >>>>>>>>>> >>>>>>>>>> Now if we have to go with approach 2 for representing >>>>> association >>>>>>>>>> attributes, we will have to do one of the two ways: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If we stick the current model/schema: >>>>>>>>>> ----------------------------------- >>>>>>>>>> We will have represent in the following way. Note this is a >>> mix >>>>> of >>>>>>>>>> approach 1 (existing representation which acheives >>> participant >>>>>>>>> session >>>>>>>>>> association) and approach 2 ( for part-stream association). >>>> The >>>>>>>>> issue >>>>>>>>>> with this approach is if the same participant is >>> simultaneously >>>>> in >>>>>>>>>> multiple sessions( cases like participant goes on hold on >> one >>>>> line >>>>>>>>> and >>>>>>>>>> talks to another participant) and SRC sends a snapshot then >>> we >>>>>> will >>>>>>>>> have >>>>>>>>>> multiple elements each having different >>> session >>>>>> IDs. >>>>>>>>>> >>>>>>>>> >>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>>> >>>>>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>>>>>>> sip:ram@blr.cisco.com >>>>>>>>>> 2010-12- >>>>>> 16T23:41:07Z>>>>>>>> time> >>>>>>>>>> XXX >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> And for participant-stream you will have a new element >>>>>>>>>> >>>>>>>>>> >>>>>>>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007- >>> 6ddbecca64d3" >>>>>>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a = "> >>>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>>> contributing SSRC-1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If we change the model to remove the scoping of >>>>> participant/stream >>>>>>>> to >>>>>>>>>> session: >>>>>>>>>> >>>>>>>> >>>>> >> -------------------------------------------------------------------- >>>>>> - >>>>>>>>> --- >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >>>>>>>>>> sip:ram@blr.cisco.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- >>>>>> 6da1eeaeb425" >>>>>>>>>> >>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>>> XXX >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007- >>> 6ddbecca64d3" >>>>>>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a = "> >>>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>>> contributing SSRC-1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Let me know your comments. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Ram >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 HKaplan@acmepacket.com Fri Oct 28 14:22: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 719D31F0C40 for ; Fri, 28 Oct 2011 14:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mq4y-c6irlnu for ; Fri, 28 Oct 2011 14:22:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id C717D1F0C34 for ; Fri, 28 Oct 2011 14:22:04 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 28 Oct 2011 17:22:03 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 17:22:03 -0400 From: Hadriel Kaplan To: "Charles Eckel (eckelcu)" Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AQHMlbeiyyj2zm2fFUyYADHXk3O11g== Date: Fri, 28 Oct 2011 21:22:02 +0000 Message-ID: <45505479-1B66-4E98-9446-F81C3A5DF250@acmepacket.com> References: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <1C23D23605C66744AACB0845E9A9F2DF@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [siprec] proposed text for dealing with packet loss 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, 28 Oct 2011 21:22:05 -0000 Hi Charles, comments inline... On Oct 27, 2011, at 2:45 PM, Charles Eckel (eckelcu) wrote: >>> If the SRC does not forward the RTCP reports from the SRS, the UA >>> either: >>> 1) receives no RTCP reports, in the case where is the SRS is the > only >>> recipient of the packets >>=20 >> The _other_ UA in the CS is the receiver of RTP packets, and generates > RTCP. In other words, both >> real UAs in the CS generate RTCP which gets to each other. >>=20 >> Though of course there are UAs in the real-world which generate no > RTCP to begin with, so in that case >> you wont get any - but that just provides examples that doing so > doesn't necessarily break RTP, >> because calls work without the RTCP today. >> (I should note I'm talking about audio, not video) >=20 > Okay, so we could call out that special case. However, since having the > SRC forward the RTCP packets is required in the case of video, and > should only help in the case of audio, the MUST seems appropriate and > more straightforward to me. The UA receiving the multiple sets of RTCP > receiver reports should at worst ignore the ones from the SRS, right? Call what out as a special case? The case of audio being used? I'm not even convinced the SRC has to forward RTCP from the SRS for video, = but that probably depends on the SRS' design and use-case. (i.e., I know of= one which doesn't apparently send RTCP from itself to the two real UA's ev= en for video, but I don't know if that's because of something special they = do or what) >> It is true that if C/D is congested, then for certain codecs the RTCP > receiver reports can help >> improve the call quality to the SRS, but reduce the call quality for > UA-A and UA-B.=20 >=20 > I may be missing something here because I do not see how the RTCP > receiver reports from the SRS would reduce the call quality of UA-A and > UA-B. Is it because the recovery attempts by UA-A targeted for the SRS > would waste bandwidth on the path to UA-B? If a dynamic audio codec is used - i.e., an audio codec which can adapt its= elf to compress-more/use-less-bandwidth, which is basically the only thing = any audio codec does to improve things based on RTCP Receive Reports, afaic= t - then if the SRS tells UA-A it's getting packet loss, UA-A's dynamic cod= ec will adapt to trade off quality vs. bandwidth. This means the audio-qua= lity of the UA-A to UA-B call degrades. For some customer use-cases that's appropriate - what they want. For some customer use-cases that's inappropriate - not what they want. -hadriel From HKaplan@acmepacket.com Fri Oct 28 14:51: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 B85631F0C45 for ; Fri, 28 Oct 2011 14:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFS-kfrAr1Ps for ; Fri, 28 Oct 2011 14:51:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0E1F0C34 for ; Fri, 28 Oct 2011 14:51:38 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 28 Oct 2011 17:51:36 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 17:51:36 -0400 From: Hadriel Kaplan To: "Charles Eckel (eckelcu)" Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AQHMlbvDyyj2zm2fFUyYADHXk3O11g== Date: Fri, 28 Oct 2011 21:51:36 +0000 Message-ID: <761013E5-E881-4C85-BF7C-04119BE13E03@acmepacket.com> References: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <81FF262DFA09F249A4877977718C8CD7@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [siprec] proposed text for dealing with packet loss 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, 28 Oct 2011 21:51:38 -0000 On Oct 27, 2011, at 2:45 PM, Charles Eckel (eckelcu) wrote: > I do not think changing this one word is an option. If we want to > downgrade this MUST to a SHOULD, we need to provide some justification. > The only justification I see so far is that forwarding the RTCP packets > may cause problems for "badly" broken UAs, where a "somewhat" broken UA > ignores RTCP receiver reports, and a "badly" broken UA chokes on rather > than ignores unexpected RTCP receiver reports.=20 Yes, I would expect that to be the case as well. I'm not sure I consider i= t a valid reason for an RFC, though. But I think I've given a valid use-case for not doing it - namely not to im= pact the two real UA's call-quality no matter what the SRS is experiencing. With regard to your proposed text, can we really make mandates for the real= UA's, from a practical perspective? And if we can, why would we make it a= SHOULD not a MUST, since they won't know what type of SRC/SRS' they're tal= king through? How about this instead: ---------------------- 4.1.1. Forwarding Translator When acting as a forwarding translator, RTP received as separate streams from different sources (e.g., from different UAs with different SSRCs) cannot be mixed by the SRC and MUST be sent separately to the SRS. All RTCP reports MUST be passed by the SRC between the UAs and the SRS, such that the UAs and SRS are able to detect any SSRC collisions. RTCP Sender Reports generated by a UA sending a stream MUST be forwarded to the SRS. =20 Per [RFC3550] RTCP Receiver Reports generated by the SRS MUST be forwarded to the relevant UA by default. The SRC MAY choose=20 to not forward RTCP Reports from the SRS to the UAs based on local=20 policy, however, since doing so may impact the audio-quality between the UAs for dynamic audio codecs. UAs may receive multiple sets of RTCP Receiver Reports, one or more=20 from other UAs participating in the CS, and one from the SRS=20 participating in the RS. A SIPREC aware UA MUST be prepared to=20 process the RTCP Receiver Reports from the SRS. If SRTP is used on both the CS and the RS, decryption and/or re- encryption may occur. For example, if different keys are used, it will occur. If the same keys are used, it need not occur. If packet loss occurs, either from the UA to the SRC or from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss. The SRC does not play a role in this other than forwarding the associated RTP and RTCP packets. -------------------------- From eckelcu@cisco.com Fri Oct 28 15:00: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 AFC7F1F0C38 for ; Fri, 28 Oct 2011 15:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlAfFFJ9SlVH for ; Fri, 28 Oct 2011 15:00:56 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1835621F84BD for ; Fri, 28 Oct 2011 15:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3216; q=dns/txt; s=iport; t=1319839256; x=1321048856; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RnKMKHR4xykMkK1zB2z4/T2GdgLG9Qupe5WkskoVB0A=; b=J/ee6oskJ24wvrvxG6ObvkEKUMkKelzLenUdyL+4WWCTRDCd/a6S/2VQ l0gRiOEsEVgEl9+SZ7XQBV6KdxIvPZV4aT5JB6/3d8v9p140glxZXiNKK G8arlYaPZ24YlO8Z9zosOxzrVgu8h59s/WWKxrTKoq4Jmb5LRYAXewryH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0AAI4lq06rRDoI/2dsb2JhbABCmhSPUoEFgXIBAQEBAxIBHQo/DAQCAQgOAwQBAQEKBhcBBgFFCQgCBBMIGp1cAZ4SiCJhBIgGkT6MSQ X-IronPort-AV: E=Sophos;i="4.69,420,1315180800"; d="scan'208";a="11024889" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 28 Oct 2011 22:00:55 +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 p9SM0rTx013397; Fri, 28 Oct 2011 22:00:53 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, 28 Oct 2011 15:00:53 -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, 28 Oct 2011 15:00:52 -0700 Message-ID: In-Reply-To: <761013E5-E881-4C85-BF7C-04119BE13E03@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AQHMlbvDyyj2zm2fFUyYADHXk3O11pWSTcCw References: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com> <761013E5-E881-4C85-BF7C-04119BE13E03@acmepacket.com> From: "Charles Eckel (eckelcu)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 28 Oct 2011 22:00:53.0757 (UTC) FILETIME=[100D5AD0:01CC95BD] Cc: siprec@ietf.org Subject: Re: [siprec] proposed text for dealing with packet loss 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, 28 Oct 2011 22:00:56 -0000 Hi Hadriel, I can live with that. Thanks for the suggested wording. If anyone has anything else to add, please let me know asap, otherwise I will submit the updated draft based on this wording. Cheers, Charles=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, October 28, 2011 2:52 PM > To: Charles Eckel (eckelcu) > Cc: > Subject: Re: [siprec] proposed text for dealing with packet loss >=20 >=20 > On Oct 27, 2011, at 2:45 PM, Charles Eckel (eckelcu) wrote: >=20 > > I do not think changing this one word is an option. If we want to > > downgrade this MUST to a SHOULD, we need to provide some justification. > > The only justification I see so far is that forwarding the RTCP packets > > may cause problems for "badly" broken UAs, where a "somewhat" broken UA > > ignores RTCP receiver reports, and a "badly" broken UA chokes on rather > > than ignores unexpected RTCP receiver reports. >=20 > Yes, I would expect that to be the case as well. I'm not sure I consider it a valid reason for an > RFC, though. > But I think I've given a valid use-case for not doing it - namely not to impact the two real UA's > call-quality no matter what the SRS is experiencing. >=20 > With regard to your proposed text, can we really make mandates for the real UA's, from a practical > perspective? And if we can, why would we make it a SHOULD not a MUST, since they won't know what type > of SRC/SRS' they're talking through? >=20 > How about this instead: >=20 > ---------------------- > 4.1.1. Forwarding Translator >=20 > When acting as a forwarding translator, RTP received as separate > streams from different sources (e.g., from different UAs with > different SSRCs) cannot be mixed by the SRC and MUST be sent > separately to the SRS. All RTCP reports MUST be passed by the SRC > between the UAs and the SRS, such that the UAs and SRS are able to > detect any SSRC collisions. >=20 > RTCP Sender Reports generated by a UA sending a stream MUST be > forwarded to the SRS. >=20 > Per [RFC3550] RTCP Receiver Reports generated by the SRS > MUST be forwarded to the relevant UA by default. The SRC MAY choose > to not forward RTCP Reports from the SRS to the UAs based on local > policy, however, since doing so may impact the audio-quality > between the UAs for dynamic audio codecs. >=20 > UAs may receive multiple sets of RTCP Receiver Reports, one or more > from other UAs participating in the CS, and one from the SRS > participating in the RS. A SIPREC aware UA MUST be prepared to > process the RTCP Receiver Reports from the SRS. >=20 > If SRTP is used on both the CS and the RS, decryption and/or re- > encryption may occur. For example, if different keys are used, it > will occur. If the same keys are used, it need not occur. >=20 > If packet loss occurs, either from the UA to the SRC or from the SRC > to the SRS, the SRS SHOULD detect and attempt to recover from the > loss. The SRC does not play a role in this other than forwarding the > associated RTP and RTCP packets. > -------------------------- From pkyzivat@alum.mit.edu Fri Oct 28 15:53:36 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 6B0F521F84C5 for ; Fri, 28 Oct 2011 15:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJFEo3+n3-ih for ; Fri, 28 Oct 2011 15:53:35 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id AC85721F84C2 for ; Fri, 28 Oct 2011 15:53:35 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id qNly1h0021ap0As51NtcUu; Fri, 28 Oct 2011 22:53:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta22.westchester.pa.mail.comcast.net with comcast id qNtb1h0100tdiYw3iNtbu5; Fri, 28 Oct 2011 22:53:36 +0000 Message-ID: <4EAB326D.4070109@alum.mit.edu> Date: Fri, 28 Oct 2011 18:53:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com> <45505479-1B66-4E98-9446-F81C3A5DF250@acmepacket.com> In-Reply-To: <45505479-1B66-4E98-9446-F81C3A5DF250@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] proposed text for dealing with packet loss 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, 28 Oct 2011 22:53:36 -0000 On 10/28/11 5:22 PM, Hadriel Kaplan wrote: > Hi Charles, > comments inline... > > On Oct 27, 2011, at 2:45 PM, Charles Eckel (eckelcu) wrote: > >>>> If the SRC does not forward the RTCP reports from the SRS, the UA >>>> either: >>>> 1) receives no RTCP reports, in the case where is the SRS is the >> only >>>> recipient of the packets >>> >>> The _other_ UA in the CS is the receiver of RTP packets, and generates >> RTCP. In other words, both >>> real UAs in the CS generate RTCP which gets to each other. >>> >>> Though of course there are UAs in the real-world which generate no >> RTCP to begin with, so in that case >>> you wont get any - but that just provides examples that doing so >> doesn't necessarily break RTP, >>> because calls work without the RTCP today. >>> (I should note I'm talking about audio, not video) >> >> Okay, so we could call out that special case. However, since having the >> SRC forward the RTCP packets is required in the case of video, and >> should only help in the case of audio, the MUST seems appropriate and >> more straightforward to me. The UA receiving the multiple sets of RTCP >> receiver reports should at worst ignore the ones from the SRS, right? > > Call what out as a special case? The case of audio being used? I assumed that the special case was when RTCP wasn't being used on the CS. > I'm not even convinced the SRC has to forward RTCP from the SRS for video, but that probably depends on the SRS' design and use-case. (i.e., I know of one which doesn't apparently send RTCP from itself to the two real UA's even for video, but I don't know if that's because of something special they do or what) By "has to" do you mean what it must do so that things seem to work? Or do you mean what it is required to do to conform to the requirements of a translator? ISTM that we should expect that the SRC conforms to whatever RTP role it is following. If none of the defined ones is suitable, then maybe there should be another one. (But that will be hard.) >>> It is true that if C/D is congested, then for certain codecs the RTCP >> receiver reports can help >>> improve the call quality to the SRS, but reduce the call quality for >> UA-A and UA-B. >> >> I may be missing something here because I do not see how the RTCP >> receiver reports from the SRS would reduce the call quality of UA-A and >> UA-B. Is it because the recovery attempts by UA-A targeted for the SRS >> would waste bandwidth on the path to UA-B? > > If a dynamic audio codec is used - i.e., an audio codec which can adapt itself to compress-more/use-less-bandwidth, which is basically the only thing any audio codec does to improve things based on RTCP Receive Reports, afaict - then if the SRS tells UA-A it's getting packet loss, UA-A's dynamic codec will adapt to trade off quality vs. bandwidth. This means the audio-quality of the UA-A to UA-B call degrades. > > For some customer use-cases that's appropriate - what they want. > For some customer use-cases that's inappropriate - not what they want. Then perhaps in the first case the SRC can be a translator, but in the other case it will have to function as a (back-to-back) endpoint. Thanks, Paul From pkyzivat@alum.mit.edu Fri Oct 28 16:02: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 16A191F0C34 for ; Fri, 28 Oct 2011 16:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28+T1yjO8DfW for ; Fri, 28 Oct 2011 16:02:39 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 15F7911E8089 for ; Fri, 28 Oct 2011 16:02:37 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta05.westchester.pa.mail.comcast.net with comcast id qNtH1h0030ldTLk55P2dhu; Fri, 28 Oct 2011 23:02:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta04.westchester.pa.mail.comcast.net with comcast id qP2d1h00H0tdiYw3QP2dRT; Fri, 28 Oct 2011 23:02:37 +0000 Message-ID: <4EAB348C.1010806@alum.mit.edu> Date: Fri, 28 Oct 2011 19:02:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com> <761013E5-E881-4C85-BF7C-04119BE13E03@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] proposed text for dealing with packet loss 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, 28 Oct 2011 23:02:40 -0000 On 10/28/11 6:00 PM, Charles Eckel (eckelcu) wrote: > Hi Hadriel, > > I can live with that. Thanks for the suggested wording. > If anyone has anything else to add, please let me know asap, otherwise I > will submit the updated draft based on this wording. I just replied to an earlier message on this. I am quite sure we cannot give dispensation to violate a MUST condition in another RFC. That in effect is a revision of that RFC. When AVT reviews this (as they will) they will burst into flames. Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: Friday, October 28, 2011 2:52 PM >> To: Charles Eckel (eckelcu) >> Cc: >> Subject: Re: [siprec] proposed text for dealing with packet loss >> >> >> On Oct 27, 2011, at 2:45 PM, Charles Eckel (eckelcu) wrote: >> >>> I do not think changing this one word is an option. If we want to >>> downgrade this MUST to a SHOULD, we need to provide some > justification. >>> The only justification I see so far is that forwarding the RTCP > packets >>> may cause problems for "badly" broken UAs, where a "somewhat" broken > UA >>> ignores RTCP receiver reports, and a "badly" broken UA chokes on > rather >>> than ignores unexpected RTCP receiver reports. >> >> Yes, I would expect that to be the case as well. I'm not sure I > consider it a valid reason for an >> RFC, though. >> But I think I've given a valid use-case for not doing it - namely not > to impact the two real UA's >> call-quality no matter what the SRS is experiencing. >> >> With regard to your proposed text, can we really make mandates for the > real UA's, from a practical >> perspective? And if we can, why would we make it a SHOULD not a MUST, > since they won't know what type >> of SRC/SRS' they're talking through? >> >> How about this instead: >> >> ---------------------- >> 4.1.1. Forwarding Translator >> >> When acting as a forwarding translator, RTP received as separate >> streams from different sources (e.g., from different UAs with >> different SSRCs) cannot be mixed by the SRC and MUST be sent >> separately to the SRS. All RTCP reports MUST be passed by the SRC >> between the UAs and the SRS, such that the UAs and SRS are able to >> detect any SSRC collisions. >> >> RTCP Sender Reports generated by a UA sending a stream MUST be >> forwarded to the SRS. >> >> Per [RFC3550] RTCP Receiver Reports generated by the SRS >> MUST be forwarded to the relevant UA by default. The SRC MAY choose >> to not forward RTCP Reports from the SRS to the UAs based on local >> policy, however, since doing so may impact the audio-quality >> between the UAs for dynamic audio codecs. >> >> UAs may receive multiple sets of RTCP Receiver Reports, one or more >> from other UAs participating in the CS, and one from the SRS >> participating in the RS. A SIPREC aware UA MUST be prepared to >> process the RTCP Receiver Reports from the SRS. >> >> If SRTP is used on both the CS and the RS, decryption and/or re- >> encryption may occur. For example, if different keys are used, it >> will occur. If the same keys are used, it need not occur. >> >> If packet loss occurs, either from the UA to the SRC or from the SRC >> to the SRS, the SRS SHOULD detect and attempt to recover from the >> loss. The SRC does not play a role in this other than forwarding > the >> associated RTP and RTCP packets. >> -------------------------- > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From HKaplan@acmepacket.com Fri Oct 28 16:44: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 B263521F8486 for ; Fri, 28 Oct 2011 16:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp2WxZThF5He for ; Fri, 28 Oct 2011 16:44:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6CD21F8485 for ; Fri, 28 Oct 2011 16:44:52 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 28 Oct 2011 19:44:51 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 19:44:51 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AQHMlcuVyyj2zm2fFUyYADHXk3O11g== Date: Fri, 28 Oct 2011 23:44:50 +0000 Message-ID: <1E043D61-888C-497D-861F-7788225FC889@acmepacket.com> References: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com> <761013E5-E881-4C85-BF7C-04119BE13E03@acmepacket.com> <4EAB348C.1010806@alum.mit.edu> In-Reply-To: <4EAB348C.1010806@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <527FAF626CFF8044A3A72159EB18A52D@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [siprec] proposed text for dealing with packet loss 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, 28 Oct 2011 23:44:53 -0000 On Oct 28, 2011, at 7:02 PM, Paul Kyzivat wrote: > I just replied to an earlier message on this. > I am quite sure we cannot give dispensation to violate a MUST condition i= n another RFC. That in effect is a revision of that RFC. Yeah, you're probably right. =20 Of course RFC 3550 Translator model never had an SRS model in mind ether, b= ut I suppose we shouldn't open that can of worms. On the other hand, if we're going to play the RFC-says-so card, why are we = putting this MUST statement in at all? Why aren't we just saying "the Translator MUST follow [RFC 3550]", period. = ? That way if, at some future time, there's an update or extension to RFC 355= 0 that affects the RTCP-forwarding behavior, then the update doesn't need t= o also update this SIPREC doc? > When AVT reviews this (as they will) they will burst into flames. Hmmm... maybe we *should* do it then - I'll bring the marshmallows. ;) -hadriel From HKaplan@acmepacket.com Fri Oct 28 17:11:26 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 498FA11E8087 for ; Fri, 28 Oct 2011 17:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+d4GeKA4PN5 for ; Fri, 28 Oct 2011 17:11:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B226F11E8081 for ; Fri, 28 Oct 2011 17:11:25 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 28 Oct 2011 20:11:23 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 20:11:23 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AQHMlc9Kyyj2zm2fFUyYADHXk3O11g== Date: Sat, 29 Oct 2011 00:11:22 +0000 Message-ID: <67D1B629-7624-4807-9445-907C7E750299@acmepacket.com> References: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com> <45505479-1B66-4E98-9446-F81C3A5DF250@acmepacket.com> <4EAB326D.4070109@alum.mit.edu> In-Reply-To: <4EAB326D.4070109@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [siprec] proposed text for dealing with packet loss 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, 29 Oct 2011 00:11:26 -0000 On Oct 28, 2011, at 6:53 PM, Paul Kyzivat wrote: > On 10/28/11 5:22 PM, Hadriel Kaplan wrote: >> I'm not even convinced the SRC has to forward RTCP from the SRS for vide= o, but that probably depends on the SRS' design and use-case. (i.e., I know= of one which doesn't apparently send RTCP from itself to the two real UA's= even for video, but I don't know if that's because of something special th= ey do or what) >=20 > By "has to" do you mean what it must do so that things seem to work? > Or do you mean what it is required to do to conform to the requirements o= f a translator? I mean has to to make things work. Of course it is has to to claim complia= nce with the RFC, but that RFC was written under the assumption that all RT= P agents are active RTP endpoints in the RTP session. That isn't always th= e case in call-recording, in practice. Heck, some people just mirror the R= TP packets and use the logical equivalent of wireshark to "record" it... an= d it works for them. >> For some customer use-cases that's appropriate - what they want. >> For some customer use-cases that's inappropriate - not what they want. >=20 > Then perhaps in the first case the SRC can be a translator, but in the ot= her case it will have to function as a (back-to-back) endpoint. Sigh. Yes, from an RFC perspective that's probably what will have to be cla= imed. For example my company makes an SRC, and though we offer transcoding it's n= ot free, so instead as a Translator we may decide to forward the RTCP from = the SRS by default just so we can claim compliance with this SIPREC doc... = but in practice we'll probably tell people to disable that forwarding in or= der to make things truly work. I was trying to get the MUST statement remo= ved from this SIPREC spec because (1) I don't think it will actually break = anything, (2) will likely make things better not to forward them, and (3) d= on't like to see misleading MUST statements. I'm ok with keeping it though because you're right it will never pass AVT r= eview. And it actually occurs to me as an _SBC_ we can claim the SRC is a logicall= y separate internal function that does indeed forward RTCP packets from the= SRS, but the SBC simply discards them as a B2BUA, to make things work. So= we can be RFC compliant but still ignore the MUST. It's good to be a B2BU= A. :) -hadriel From pkyzivat@alum.mit.edu Fri Oct 28 21: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 D99751F0C3D for ; Fri, 28 Oct 2011 21:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVt0VCT6Zwsu for ; Fri, 28 Oct 2011 21:15:14 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD881F0C36 for ; Fri, 28 Oct 2011 21:15:14 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id qUEz1h0021swQuc53UFEPq; Sat, 29 Oct 2011 04:15:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.westchester.pa.mail.comcast.net with comcast id qUFE1h00J0tdiYw3bUFEk4; Sat, 29 Oct 2011 04:15:14 +0000 Message-ID: <4EAB7DD0.8060002@alum.mit.edu> Date: Sat, 29 Oct 2011 00:15:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com> <761013E5-E881-4C85-BF7C-04119BE13E03@acmepacket.com> <4EAB348C.1010806@alum.mit.edu> <1E043D61-888C-497D-861F-7788225FC889@acmepacket.com> In-Reply-To: <1E043D61-888C-497D-861F-7788225FC889@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [siprec] proposed text for dealing with packet loss 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, 29 Oct 2011 04:15:15 -0000 On 10/28/11 7:44 PM, Hadriel Kaplan wrote: > > On Oct 28, 2011, at 7:02 PM, Paul Kyzivat wrote: > >> I just replied to an earlier message on this. >> I am quite sure we cannot give dispensation to violate a MUST condition in another RFC. That in effect is a revision of that RFC. > > Yeah, you're probably right. > Of course RFC 3550 Translator model never had an SRS model in mind ether, but I suppose we shouldn't open that can of worms. > > On the other hand, if we're going to play the RFC-says-so card, why are we putting this MUST statement in at all? > Why aren't we just saying "the Translator MUST follow [RFC 3550]", period. ? > That way if, at some future time, there's an update or extension to RFC 3550 that affects the RTCP-forwarding behavior, then the update doesn't need to also update this SIPREC doc? I agree, at least regarding normative statements. But it is helpful to spell out the implications of those requirements in the specific context of our usage. Thanks, Paul >> When AVT reviews this (as they will) they will burst into flames. > > Hmmm... maybe we *should* do it then - I'll bring the marshmallows. > ;) > > -hadriel > > From rmohanr@cisco.com Sat Oct 29 02:43:04 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 5242021F899F for ; Sat, 29 Oct 2011 02:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.881 X-Spam-Level: X-Spam-Status: No, score=-6.881 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cgh+zdYEk85a for ; Sat, 29 Oct 2011 02:43:03 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 066DB21F88A0 for ; Sat, 29 Oct 2011 02:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=409; q=dns/txt; s=iport; t=1319881380; x=1321090980; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=UJ+lF8/2rnHeULqjVwa3yXs6InyCqT4gr2sfhKYagmw=; b=fULRE/i2Sq7tGqbtvm4mV0nlo8YBZ2PErIr4hrOqQee/dA7Bc/EeiLt/ 7mhhv94xcgofDFq06nVhJBL5CTs4JfvjxsdVqT5YtC+Fc5Oh3rIjdBqW4 3naDNh8D160PsCpB4nLDUCSjp9C6Q0LxyUg/4jaYk8mKLN2VjbRImqukt M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcGAHvKq05Io8US/2dsb2JhbABDmlePEYEFgXQBAQMSAR0KUQEqBhgHVwEECxAanDKBJgGddoghYQSIBJFAjDE X-IronPort-AV: E=Sophos;i="4.69,423,1315180800"; d="scan'208";a="2012520" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-4.cisco.com with ESMTP; 29 Oct 2011 09:42:53 +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 p9T9gqkJ030154 for ; Sat, 29 Oct 2011 09:42:52 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); Sat, 29 Oct 2011 15:12:52 +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, 29 Oct 2011 15:12:50 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B814A@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ticket #75: How to represent recording callee capabilities in metadata XML ? Thread-Index: AcyWHx+k91itbd68Rb6imnohebupbA== From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 29 Oct 2011 09:42:52.0316 (UTC) FILETIME=[20AB6DC0:01CC961F] Subject: [siprec] Ticket #75: How to represent recording callee capabilities in metadata 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, 29 Oct 2011 09:43:04 -0000 In the second session of last virtual interim there was a discussion on how to represent callee capabilities attribute of participant in metadata XML document.=20 There was an agreement to go with the encoding RFC 4235 as is. My question is - Should we just give reference to the XML namespace of RFC 4235 ? if so how ? In general how do we reference one XML schema inside another ? Regards, Ram From john.2.stafford@bt.com Mon Oct 31 04:58: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 1B5D421F8B83 for ; Mon, 31 Oct 2011 04:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ37LFaHRCna for ; Mon, 31 Oct 2011 04:58:21 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1968021F8DBF for ; Mon, 31 Oct 2011 04:58:21 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 31 Oct 2011 11:58:20 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.102]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Mon, 31 Oct 2011 11:58:19 +0000 From: To: Date: Mon, 31 Oct 2011 11:58:19 +0000 Thread-Topic: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and in XML ? Thread-Index: AcyVlzEk23tDFSgTTFStwDtHBKDAbwCH8Kjl Message-ID: References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org><07465C1D981ABC41A344374066AE1A2C38BA872881@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D2@XMB-BGL-417.cisco.com><07465C1D981ABC41A344374066AE1A2C38BA8728E6@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD07F6F9D8@XMB-BGL-417.cisco.com><4E971D30.5090101@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD080912F6@XMB-BGL-417.cisco.com>, <35BCE99A477D6A4986FB2216D8CF2CFD082B7DD5@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B806E@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D6B@sonusinmail02.sonusnet.com> , <4EAAD2C9.5030008@alum.mit.edu> , <4EAAE681.40107@alum.mit.edu> In-Reply-To: <4EAAE681.40107@alum.mit.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and 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, 31 Oct 2011 11:58:23 -0000 Paul, RE use of recv with conferences, thanks for your response, I think I am ok with this now, I got myself all c= onfused last week, your response made me stop and think. Here is my understanding, please point if I am still wrong: The elements in metadata describe the RTP streams that flow as par= t of the call, so for a 3 party conference (A,B,C) with a separate media server conference= focus, there are 6 streams. The recorder stream is sent from the conference focus, assume this this ha= s a=3Dlabel:1234 in its SDP. So in the metadata, the streams would be labelled to indicate that the the = transmit streams from the 3 participants are mixed into the recorder stream= , as follows: A->focus stream focus->A stream B->focus stream focus->B stream C->focus stream focus->C stream I think the metadata draft would benefit from having a conference example. Rgds John Stafford | Solution Architect 1 | BT Global Services ________________________________________ From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul K= yzivat [pkyzivat@alum.mit.edu] Sent: 28 October 2011 18:29 To: siprec@ietf.org Subject: Re: [siprec] Need Inputs: How to representattributesofassociation = in Metadata Model and in XML ? On 10/28/11 12:10 PM, john.2.stafford@bt.com wrote: > Paul, > > OK, I understand, but how does the recorder know that the stream sent by = the focus is a mixed conference stream , ie contains all of the streams rec= eived by the focus. ? I don't think I understand the question. The SRS should just believe what it is told: the stream it receives contains a mix of all the participants reported as sending to it. Thanks, Paul > Rgds > John Stafford | Solution Architect 1 | BT Global Services > > ________________________________________ > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@alum.mit.edu] > Sent: 28 October 2011 17:05 > To: siprec@ietf.org > Subject: Re: [siprec] Need Inputs: How to representattributesofassociatio= n in Metadata Model and in XML ? > > On 10/28/11 11:06 AM, john.2.stafford@bt.com wrote: >> >> Ram, >>>> I presume the participant - CS element will be replaced by >>>> the< participantSessionAssoc>. >>> >>> No. will continue to remain. We are talking about associatio= n >>> attributes of participant-session. >>> The other attributes of and which are not >>> association attributes will continue to be the respective elements. >> >> What I meant to say was: >> I presume the participant's session attribute will be replaced by the. >> Is that correct ? > > Yup, that's the idea. > >> RE use of, this means for a large conference each participant upda= te will be very large as it needs to include recv's for every other partici= pants send ? > > The association is between each participant and a stream, not between > two participants. There are two ways to represent this, and neither has > the problem you describe: > > - one stream for the conference. > Each participant both sends and receives it. > > - one stream for each participant in the conference. > The focus is represented as a participant. > Each real participant sends and receives its own stream. > The focus sends and receives all the streams. > > I guess the situation you describe would occur if there was a full-mesh > of streams between participants. But afaik nobody does that. And if they > did it would be hard to get an SRC in the middle. > > Thanks, > Paul > >> Rgds John >> >> >> -----Original Message----- >> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 28 October 2011 14:43 >> To: Ram Mohan R (rmohanr); Stafford,J,John,JRJ3X C; siprec@ietf.org >> Subject: RE: [siprec] Need Inputs: How to representattributesofassociati= on in Metadata Model and in XML ? >> >> Hi, >> >> IMO, send& recv are the element which has to be pushed inside particip= ant stream association element which is inline with the model. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >>> Of Ram Mohan R (rmohanr) >>> Sent: Friday, October 28, 2011 7:04 PM >>> To: john.2.stafford@bt.com; siprec@ietf.org >>> Subject: Re: [siprec] Need Inputs: How to >>> representattributesofassociation in Metadata Model and in XML ? >>> >>> Hello John S, >>> >>> Please see inline for answers. >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of john.2.stafford@bt.com >>>> Sent: Thursday, October 27, 2011 11:15 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Need Inputs: How to represent >>>> attributesofassociation in Metadata Model and in XML ? >>>> >>>> I am not clear on the effect on the other XMl elements. >>>> >>>> I presume the participant - CS element will be replaced by >>>> the< participantSessionAssoc>. >>> >>> No. will continue to remain. We are talking about associatio= n >>> attributes of participant-session. >>> The other attributes of and which are not >>> association attributes will continue to be the respective elements. >>> >>>> >>>> I also presume and will no longer be needed, and that >>>> the will include an attribute to say send >>> or >>>> recv ? >>> >>> This is a good suggestion. I have not given a thought on this so far. >> In >>> principle this should be fine as once the association of a participant >>> to a stream ends it stops sending/receiving the same. We need to think >>> through different use-cases to see if its fine to have, >>> inside association element itself. By having send, recv inside the >>> association we can avoid one XML element as they can be attribute. >>> >>>> >>>> Is that correct ? >>>> >>>> I hope the rule will remain that, in the abscence of any recv >>> elements >>>> by default a stream is assumed to be recieved by all participants. >>> >>> No, in the last IETF we agreed it's better to always explicity indicate >>> recv. We will continue to stick to that as I see no reason to change. >>> >>> Regards, >>> Ram >>> >>>> >>>> Rgds >>>> John Stafford | Solution Architect 1 | BT Global Services >>>> >>>> ________________________________________ >>>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of >>>> Ram Mohan R (rmohanr) [rmohanr@cisco.com] >>>> Sent: 27 October 2011 18:08 >>>> To: John Elwell; Paul Kyzivat; siprec@ietf.org >>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>> ofassociation in Metadata Model and in XML ? >>>> >>>> Hi John, >>>> >>>> Thanks for your comment on this. Yes several of us seem to be >> inclined >>>> towards approach 2. I like your point that once one of the elements >>> in >>>> the association gets deleted, the association element life ends. SRC >>>> may choose to send the association element optionally or the SRS can >> still >>>> learn that as the way you mentioned. >>>> >>>> We ( authors of metadata draft ) discussed internally on this open >>> item >>>> and see some issues with adopting approach 2 as is with the current >>>> model /schema. I will start a separate mail thread for the issue as >>>> this thread is already too long. >>>> >>>> Thanks, >>>> Ram >>>> >>>> >>>>> -----Original Message----- >>>>> From: John Elwell [mailto:john.r.elwell@gmail.com] >>>>> Sent: Thursday, October 27, 2011 2:03 PM >>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat; siprec@ietf.org >>>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>>> ofassociation in Metadata Model and in XML ? >>>>> >>>>> Approach 2 seems reasonable. Could we say that an association is >>>>> implicitly deleted (gains a dissociate time) as soon as one of the >>>>> associated elements is deleted (gains a dissociate time)? This >>>>> would reduce the on-the >>>> wire >>>>> document size for both partial and full metadata in some >>>> circumstances >>>>> (e.g., conference termination by the focus). >>>>> >>>>> John >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "Ram Mohan R (rmohanr)" >>>>> To: "Paul Kyzivat"; >>>>> Sent: Friday, October 14, 2011 4:59 AM >>>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >>>>> ofassociation in Metadata Model and in XML ? >>>>> >>>>> >>>>>> Thanks Paul for your comments. I also prefer approach 2 as >>>> mentioned >>>>>> below in this thread. >>>>>> I will wait to hear for comments/opinion from others. >>>>>> >>>>>> Ram >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >>>>>>> Behalf Of Paul Kyzivat >>>>>>> Sent: Thursday, October 13, 2011 10:48 PM >>>>>>> To: siprec@ietf.org >>>>>>> Subject: Re: [siprec] Need Inputs: How to represent attributes >> of >>>>>>> association in Metadata Model and in XML ? >>>>>>> >>>>>>> I like approach 2, as Ram has shown it. It deals with the >>> problems >>>>>> John >>>>>>> raised with the others. >>>>>>> >>>>>>> I didn't follow John's arithmetic on this one, using his 20 >> party >>>>>>> conference example. As I count that, there are 21 participants >>>> when >>>>>> you >>>>>>> include the focus. Each of the 20 has two stream/participant >>>>>>> associations with the focus, for a total of 40. (The association >>>> is >>>>>>> bidirectional. I can only get to 80 by assuming we had to >>>> represent >>>>> an >>>>>>> association in each direction.) And each has two ids, each of >>>> which >>>>> is >>>>>>> also the id of a stream or participant. So there are really only >>>> 23 >>>>>>> distinct ids that need to be assigned for this. (One for each of >>>> the >>>>>> 21 >>>>>>> participants, and one for each of the two streams.) >>>>>>> >>>>>>> The 40 associations, each carrying two ids, is still kind of a >>> lot >>>>> if >>>>>>> its sent all at once. But when starting up a conference they >> will >>>>>>> probably be added gradually as each participant joins. Same at >>> the >>>>> end >>>>>>> if they drop off individually. But it could be a bunch together >>> if >>>>> the >>>>>>> conference is forcibly dropped by the focus. But it does >> minimize >>>>> what >>>>>>> is sent when things happen incrementally. >>>>>>> >>>>>>> There may be some optimizations that can be done - e.g. a sort >> of >>>>>>> "wildcard" for one of the the two ids in the association class. >>>> E.g. >>>>>>> >>>>>>> >>>>>> participant=3D"*" >>>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>> >> 2010-12-16T23:41:07Z >>>>>>> >>>>>>> >>>>>>> (I'm not advocating that particular syntax. Its just something >> to >>>>> make >>>>>>> the point.) >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote: >>>>>>>> My bad(typo) while sending the example. The correct partial >>>> update >>>>> I >>>>>>>> intended to send is: >>>>>>>> >>>>>>>> >>>>>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>>> 2010-12-16T23:41:07Z>>> time> >>>>>>>> >>>>>>>> >>>>>>>> This is inline with approach 2 where in each association XML >>>>> element >>>>>>>> will have the IDs of the related associated elements. >>>>>>>> >>>>>>>> Ram >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>>> Sent: Wednesday, October 12, 2011 2:24 PM >>>>>>>>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>>>>> Cc: Ofir Roth >>>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>>> association >>>>>>>> in >>>>>>>>> Metadata Model and in XML ? >>>>>>>>> >>>>>>>>> We do prefer to receive related elements as well, it makes >>>>>>>>> implementation much easier. >>>>>>>>> At least we should get relevant IDs. For example below, >> SRC >>>>>>> should >>>>>>>>> also send ParticipantId >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>>>> Sent: Wednesday, October 12, 2011 10:52 AM >>>>>>>>> To: Leon Portman; siprec@ietf.org >>>>>>>>> Cc: Ofir Roth >>>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>>> association >>>>>>>> in >>>>>>>>> Metadata Model and in XML ? >>>>>>>>> >>>>>>>>> Leon, >>>>>>>>> Thanks for your response. One of the adv with approach 2 is >> we >>>>> can >>>>>>>>> indicate only changes in the association without the need to >>>>>>>> indicating >>>>>>>>> the elements ( of association). IOW for the below example, if >>>>> there >>>>>>> is >>>>>>>>> a change in participant-stream association I can simply send >>>> the >>>>>>>>> following in partial update: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"> >>>>>>>>> >>>> 2010-12-16T23:41:07Z >>>>>>>>> >>>>>>>>> >>>>>>>>> Do you see a need to always indicate the related elements too >>> ? >>>>> In >>>>>>>>> which case I see approach 1 as more suitable. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Ram >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>>>> Sent: Wednesday, October 12, 2011 12:55 PM >>>>>>>>>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>>>>>> Cc: Ofir Roth >>>>>>>>>> Subject: RE: Need Inputs: How to represent attributes of >>>>>>> association >>>>>>>>>> inmetadata Model and in XML ? >>>>>>>>>> >>>>>>>>>> Ram Hi >>>>>>>>>> >>>>>>>>>> I am ok with approaches 1 and however I do prefer approach >>>> one >>>>>>>>> because >>>>>>>>>> it will be easier for SRS to get decode - association is >>>> inside >>>>>>>>>> relevant element. And it is more readable. >>>>>>>>>> Approach 2 will work as well, however it is important that >> if >>>>>> there >>>>>>>>>> will be a change in association then to send to SRS not only >>>>>>> updated >>>>>>>>>> association element but also related elements: for example >> if >>>>>>> stream >>>>>>>>>> was associated to participant and session, send also >>>> participant >>>>>>> and >>>>>>>>>> session latest state. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Leon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] >>>>> On >>>>>>>>>> Behalf Of Ram Mohan R (rmohanr) >>>>>>>>>> Sent: Wednesday, October 12, 2011 7:48 AM >>>>>>>>>> To: siprec@ietf.org >>>>>>>>>> Subject: [siprec] Need Inputs: How to represent attributes >> of >>>>>>>>>> association in metadata Model and in XML ? >>>>>>>>>> >>>>>>>>>> (Sorry for lengthy e-mail) >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> In the last interim we discussed 4 approaches for >>> representing >>>>>>>>>> attributes of association in XML. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here are some pros/cons for each of them: >>>>>>>>>> Approach 1: >>>>>>>>>> ---------- >>>>>>>>>> Represent the association attribute as a property within one >>>> of >>>>>> the >>>>>>>>>> associated elements. Example given at >>>> http://www.ietf.org/mail- >>>>>>>>>> archive/web/siprec/current/msg02709.html Does not need >>> another >>>>> XML >>>>>>>>>> element and represents the association attributes as >>>> capability >>>>> of >>>>>>>>> one >>>>>>>>>> of the association element. >>>>>>>>>> e.g. >>>>>>>>>> >>>>>>>>> >>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- >>>>>>> 6da1eeaeb425"> >>>>>>>>>> sip:ram@blr.cisco.com >>>>>>>>>> 2010-12- >>>>> 16T23:41:07Z>>>>>>>> time> >>>>>>>>>> TBD >>>>>>>>>> >>>>>>>>> stream >> =3D"urn:uuid:f3373a7b-4958-4e55-8820- >>>>>>>>>> d03a191fb76a >>>>>>>>>> "> >>>>>>>>>> 2010-12- >>>>>>> 16T23:41:07Z>>>>>>>>> time> >>>>>>>>>> contributing SSRC-1 >>>>>>>>>> >>>> In >>>>>>> the >>>>>>>>> above >>>>>>>>>> example the participant contributes a single streams. For >>> each >>>>>>>> stream >>>>>>>>>> the association attribute (participant-stream) is shown with >>>> the >>>>>>>>> stream >>>>>>>>>> ID nested in. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Approach 2: >>>>>>>>>> ----------- >>>>>>>>>> In this approach we have a new XML element for every >>>> association >>>>>>>>> class. >>>>>>>>>> This xml element will NOT have a unique ID instead it >>>> references >>>>>>> the >>>>>>>>> ID >>>>>>>>>> of associated elements (shown below). With this approach it >>> is >>>>>> easy >>>>>>>>> to >>>>>>>>>> update as the association class is a separate XML element >> and >>>>> not >>>>>>>>>> property. >>>>>>>>>> e.g. >>>>>>>>>> >>>>>>>>> >> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>>> TBD >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>>> contributing SSRC-1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Approach 3 and 4 are in the below e-mail from John. >>>>>>>>>> Approach 3 defines a new Unique ID for every association XML >>>>>>> elment. >>>>>>>>>> Also it creates alias for the other IDs. In the discussions >>> in >>>>>>>>> interim >>>>>>>>>> there was no strong support for this approach. >>>>>>>>>> >>>>>>>>>> Approach 4 is same as approach 1 where in the association >>>>> element >>>>>>> is >>>>>>>>>> encapsulated in one of the XML elements (to which it is >>>>>>>> associated). >>>>>>>>>> In addition to that it also has reference to the elements >>>> (alias >>>>>> of >>>>>>>>>> IDs) to which the association belongs. >>>>>>>>>> >>>>>>>>>> I prefer approach 2 as it is has a separate XML element to >>>>>>> represent >>>>>>>>>> the association class. The only difference of this XML >>> element >>>>>> from >>>>>>>>>> others is this does not need a unique ID. Instead it >>>> references >>>>>> the >>>>>>>>> IDs >>>>>>>>>> of the elements to which the association belongs. >>>>>>>>>> Since association class is a special class meant to >> associate >>>>>>>>> multiple >>>>>>>>>> classes, I see it ok to have a representation as in approach >>> 2 >>>>>>> where >>>>>>>>> in >>>>>>>>>> the identifier is the concatenation of the classes to which >>>> the >>>>>>>>>> association belongs to. >>>>>>>>>> >>>>>>>>>> Please provide your comments on this and also suggest any >>>> other >>>>>>>>>> approaches to represent association classes in XML. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Ram >>>>>>>>>> >>>> _______________________________________________ >>>> 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.2.stafford@bt.com Mon Oct 31 05:30: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 69CFE21F84A7 for ; Mon, 31 Oct 2011 05:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUhQ26KgaW4i for ; Mon, 31 Oct 2011 05:30:01 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 62ACB21F84A3 for ; Mon, 31 Oct 2011 05:30:00 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 31 Oct 2011 12:29:59 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.102]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Mon, 31 Oct 2011 12:29:59 +0000 From: To: , Date: Mon, 31 Oct 2011 12:29:58 +0000 Thread-Topic: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? Thread-Index: AcyVlIx9IPs7Up/0RJWeJBsLHBtXsACMvn7H Message-ID: References: , <4EAAE217.6080406@alum.mit.edu> In-Reply-To: <4EAAE217.6080406@alum.mit.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? 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, 31 Oct 2011 12:30:02 -0000 Paul, I agree that a SRS should treat a call as ended when all participants have = dissassociated,=20 or I guess if it gets a CS with and end-time. But I saw discussion about allowing a CS to have zero participants, so then= , for persistent RS, we are back to needing to use CS end-time. Rgds John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932= 773504 | E: john.2.stafford@bt.com | www.bt.com/globalservices ________________________________________ From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul K= yzivat [pkyzivat@alum.mit.edu] Sent: 28 October 2011 18:10 To: siprec@ietf.org Subject: Re: [siprec] Persistent RS case, when should a recorder consider a= CS has ended ? (Revised. I realized I had extra stuff in here that I then decided I didn't need.) Partha commented on this, but rather than inject in that conversation I'll make a separate response: On 10/28/11 9:23 AM, john.2.stafford@bt.com wrote: > Consider the following scenario > several phones connected to PBX, all voice record their calls from the > phone by each having a persistent RS. > All calls get initially answered by receptionist, who then conferences > in someone to handle the call, then drops out. > So there are two phones are conferenced onto same external call, so both > phones send metadata for thier RS's to include the call's CS. > Since each phone has knowledge of all the conference participants, the That is an assumption that isn't necessarily true, but this is your example, so I'll assume its true > CS it sends has 3 partiicipants, the two phones and the far party. Also > the CS Id and participant Id's sent by each phone are identical. This is another assumption - its a choice to do it this way. (Partha proposed a different way.) But again I'll accept your assumption. Its going to take some work for all the phones to arrive at the same ID for this CS. > Now one phone (receptionist) leaves the call, and both phones will sends > a metadata update to say one participant has dissassociated. Well, I suppose all three phones send an update. > Now for as long as the call persists, should the receptionists phone, > that has left the call, still include the CS in any full metadata > updates it sends, or could it omit the CS ? Given your assumptions, when the receptionist leaves the call it ought to send an update indicating that it is dissociated from the CS and the related streams it was associated with. Then it presumably forgets about the CS and never mentions it again. This is also an assumption. If it somehow continues to track the state of the call I guess it could continue to report the state changes. > If it must included it, then over time the receptionists phone may end > up having to track multiple calls so as to send metadata updates, it is > preferable if it could just forget about the call as it is no longer > involved in it. > So does removing a CS from an RS indicate the CS has ended, That would clearly be the wrong thing to do in this case, since the CS is shared by multiple RSs and the others aren't done with it. > or will a > recorder only consider a CS ended when it receives metadata with the CS > having and end-time element ? IMO the SRS can generally assume the CS ended when all participants and streams have dissociated from it. Even after that, in principle, it could have another participant or stream associate to it. If so, I guess it will have to figure out how to deal with that. (It is probably an error, but in the interest of reliable recording it will want to do *something* - either graft the new stuff onto the the existing CS, or start a new CS with the same ID.) Thanks, Paul > Rgds > John Stafford | Solution Architect 1 | BT Global Services > > > _______________________________________________ > 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 internet-drafts@ietf.org Mon Oct 31 06:36: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 D47CB21F8B56; Mon, 31 Oct 2011 06:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W37r-w3zt06i; Mon, 31 Oct 2011 06:36:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736FD21F8B1A; Mon, 31 Oct 2011 06:36:17 -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.62 Message-ID: <20111031133617.24449.96357.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 06:36:17 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-05.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, 31 Oct 2011 13:36:18 -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-05.txt Pages : 45 Date : 2011-10-31 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) and the Recording metadata format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-05.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-05.txt From pravindran@sonusnet.com Mon Oct 31 07:24: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 1078F21F8BE8 for ; Mon, 31 Oct 2011 07:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JY12bpSW-Cg for ; Mon, 31 Oct 2011 07:24:30 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5A83721F8BE7 for ; Mon, 31 Oct 2011 07:24:30 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9VEP3fa028068; Mon, 31 Oct 2011 10:25:03 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 10:24:28 -0400 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 19:54:31 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Mon, 31 Oct 2011 19:54:30 +0530 From: Ravindran Parthasarathi To: "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt Thread-Index: AQHMl9IYaRYn3PgZpEiEBZ/ddZrMQZWWd8mA Date: Mon, 31 Oct 2011 14:24:30 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CBA08@inba-mail01.sonusnet.com> References: <20111031133617.24449.96357.idtracker@ietfa.amsl.com> In-Reply-To: <20111031133617.24449.96357.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 14:24:31.0259 (UTC) FILETIME=[CE0CFEB0:01CC97D8] Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-05.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, 31 Oct 2011 14:24:31 -0000 Hi all, Based on the last interim meeting and mailing closure, SIPREC metadata -05 = is published with the following update: 1) Removal of Extensiondata element from the model & XML 2) "csrc" XML element addition=20 3) "NameID" pair addition in XML schema 4) Usage of base64Binary encoded URN UUID values. 5) call disconnect XML example addition 6) Association representation in metadata model Open items: 1) Association class representation in XML.=20 Please review the updated draft and provide your valuable comments. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of internet-drafts@ietf.org >Sent: Monday, October 31, 2011 7:06 PM >To: i-d-announce@ietf.org >Cc: siprec@ietf.org >Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-05.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 : Session Initiation Protocol (SIP) Recording >Metadata > Author(s) : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ietf-siprec-metadata-05.txt > Pages : 45 > Date : 2011-10-31 > > 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) and the Recording metadata > format. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-05.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-05.txt >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Mon Oct 31 07:34:03 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 BA75F21F8CBC for ; Mon, 31 Oct 2011 07:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKyXVx8f2bdX for ; Mon, 31 Oct 2011 07:34:03 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id B066D21F8CAA for ; Mon, 31 Oct 2011 07:34:02 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id rSXi1h00416LCl053Sa3X1; Mon, 31 Oct 2011 14:34:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta06.westchester.pa.mail.comcast.net with comcast id rSa21h00e0tdiYw3SSa2kb; Mon, 31 Oct 2011 14:34:03 +0000 Message-ID: <4EAEB1DB.7010505@alum.mit.edu> Date: Mon, 31 Oct 2011 10:34:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: john.2.stafford@bt.com References: , <4EAAE217.6080406@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? 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, 31 Oct 2011 14:34:03 -0000 On 10/31/11 8:29 AM, john.2.stafford@bt.com wrote: > Paul, > > I agree that a SRS should treat a call as ended when all participants have dissassociated, > or I guess if it gets a CS with and end-time. > > But I saw discussion about allowing a CS to have zero participants, You did? Where? We have been talking about a participant with no CSs, but AFAIK not about a CS with no participants. Thanks, Paul > so then, for persistent RS, we are back to needing to use CS end-time. > > > Rgds > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932 773504 | E: john.2.stafford@bt.com | www.bt.com/globalservices > ________________________________________ > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: 28 October 2011 18:10 > To: siprec@ietf.org > Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? > > (Revised. I realized I had extra stuff in here that I then decided I > didn't need.) > > Partha commented on this, but rather than inject in that conversation > I'll make a separate response: > > On 10/28/11 9:23 AM, john.2.stafford@bt.com wrote: >> Consider the following scenario >> several phones connected to PBX, all voice record their calls from the >> phone by each having a persistent RS. >> All calls get initially answered by receptionist, who then conferences >> in someone to handle the call, then drops out. >> So there are two phones are conferenced onto same external call, so both >> phones send metadata for thier RS's to include the call's CS. >> Since each phone has knowledge of all the conference participants, the > > That is an assumption that isn't necessarily true, but this is your > example, so I'll assume its true > >> CS it sends has 3 partiicipants, the two phones and the far party. Also >> the CS Id and participant Id's sent by each phone are identical. > > This is another assumption - its a choice to do it this way. (Partha > proposed a different way.) But again I'll accept your assumption. Its > going to take some work for all the phones to arrive at the same ID for > this CS. > >> Now one phone (receptionist) leaves the call, and both phones will sends >> a metadata update to say one participant has dissassociated. > > Well, I suppose all three phones send an update. > >> Now for as long as the call persists, should the receptionists phone, >> that has left the call, still include the CS in any full metadata >> updates it sends, or could it omit the CS ? > > Given your assumptions, when the receptionist leaves the call it ought > to send an update indicating that it is dissociated from the CS and the > related streams it was associated with. Then it presumably forgets about > the CS and never mentions it again. > > This is also an assumption. If it somehow continues to track the state > of the call I guess it could continue to report the state changes. > >> If it must included it, then over time the receptionists phone may end >> up having to track multiple calls so as to send metadata updates, it is >> preferable if it could just forget about the call as it is no longer >> involved in it. >> So does removing a CS from an RS indicate the CS has ended, > > That would clearly be the wrong thing to do in this case, since the CS > is shared by multiple RSs and the others aren't done with it. > >> or will a >> recorder only consider a CS ended when it receives metadata with the CS >> having and end-time element ? > > IMO the SRS can generally assume the CS ended when all participants and > streams have dissociated from it. Even after that, in principle, it > could have another participant or stream associate to it. If so, I guess > it will have to figure out how to deal with that. (It is probably an > error, but in the interest of reliable recording it will want to do > *something* - either graft the new stuff onto the the existing CS, or > start a new CS with the same ID.) > > Thanks, > Paul > >> Rgds >> John Stafford | Solution Architect 1 | BT Global Services >> >> >> _______________________________________________ >> 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.2.stafford@bt.com Mon Oct 31 07:39: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 6852B21F8CCA for ; Mon, 31 Oct 2011 07:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.342 X-Spam-Level: X-Spam-Status: No, score=-3.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvPngvZbatsB for ; Mon, 31 Oct 2011 07:39:07 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 9A34821F8B89 for ; Mon, 31 Oct 2011 07:39:07 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 31 Oct 2011 14:39:06 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.102]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 31 Oct 2011 14:39:06 +0000 From: To: Date: Mon, 31 Oct 2011 14:39:05 +0000 Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt Thread-Index: AcyX0hMfUaa0S1rzTNidKyxIGmNhvQABfbNw Message-ID: References: <20111031133617.24449.96357.idtracker@ietfa.amsl.com> In-Reply-To: <20111031133617.24449.96357.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-05.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, 31 Oct 2011 14:39:08 -0000 Partha sections 6.3, 7.1,and 8 show CS as having Associate Time and Dissassociate= Time, but examples in section 13 show CS having start-time and end-time. Rgds John Stafford | Solution Architect 1 | BT Global Services=20 ________________________________________ From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of intern= et-drafts@ietf.org [internet-drafts@ietf.org] Sent: 31 October 2011 13:36 To: i-d-announce@ietf.org Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt 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 Metad= ata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-05.txt Pages : 45 Date : 2011-10-31 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) and the Recording metadata format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-05.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-05.txt _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec= From john.2.stafford@bt.com Mon Oct 31 08:13: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 DF39121F8DF9 for ; Mon, 31 Oct 2011 08:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.074 X-Spam-Level: X-Spam-Status: No, score=-3.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFz9MBfmxmUx for ; Mon, 31 Oct 2011 08:13:12 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id C593421F8D9E for ; Mon, 31 Oct 2011 08:13:11 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 31 Oct 2011 15:13:10 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.102]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 31 Oct 2011 15:13:10 +0000 From: To: Date: Mon, 31 Oct 2011 15:09:46 +0000 Thread-Topic: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? Thread-Index: AcyX2iWVCDg58Xj1SjqQN5Hbd3XtKwABPrd6 Message-ID: References: , <4EAAE217.6080406@alum.mit.edu> , <4EAEB1DB.7010505@alum.mit.edu> In-Reply-To: <4EAEB1DB.7010505@alum.mit.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: siprec@ietf.org Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? 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, 31 Oct 2011 15:13:13 -0000 Paul, Ok, my mistake, as I see in latest matadata draft, CS must have 2 particip= ants. thanks Rgds John Stafford | Solution Architect 1 | BT Global Services=20 ________________________________________ From: Paul Kyzivat [pkyzivat@alum.mit.edu] Sent: 31 October 2011 14:34 To: Stafford,J,John,JRJ3X C Cc: siprec@ietf.org Subject: Re: [siprec] Persistent RS case, when should a recorder consider a= CS has ended ? On 10/31/11 8:29 AM, john.2.stafford@bt.com wrote: > Paul, > > I agree that a SRS should treat a call as ended when all participants hav= e dissassociated, > or I guess if it gets a CS with and end-time. > > But I saw discussion about allowing a CS to have zero participants, You did? Where? We have been talking about a participant with no CSs, but AFAIK not about a CS with no participants. Thanks, Paul > so then, for persistent RS, we are back to needing to use CS end-time. > > > Rgds > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)19= 32 773504 | E: john.2.stafford@bt.com | www.bt.com/globalservices > ________________________________________ > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@alum.mit.edu] > Sent: 28 October 2011 18:10 > To: siprec@ietf.org > Subject: Re: [siprec] Persistent RS case, when should a recorder consider= a CS has ended ? > > (Revised. I realized I had extra stuff in here that I then decided I > didn't need.) > > Partha commented on this, but rather than inject in that conversation > I'll make a separate response: > > On 10/28/11 9:23 AM, john.2.stafford@bt.com wrote: >> Consider the following scenario >> several phones connected to PBX, all voice record their calls from the >> phone by each having a persistent RS. >> All calls get initially answered by receptionist, who then conferences >> in someone to handle the call, then drops out. >> So there are two phones are conferenced onto same external call, so both >> phones send metadata for thier RS's to include the call's CS. >> Since each phone has knowledge of all the conference participants, the > > That is an assumption that isn't necessarily true, but this is your > example, so I'll assume its true > >> CS it sends has 3 partiicipants, the two phones and the far party. Also >> the CS Id and participant Id's sent by each phone are identical. > > This is another assumption - its a choice to do it this way. (Partha > proposed a different way.) But again I'll accept your assumption. Its > going to take some work for all the phones to arrive at the same ID for > this CS. > >> Now one phone (receptionist) leaves the call, and both phones will sends >> a metadata update to say one participant has dissassociated. > > Well, I suppose all three phones send an update. > >> Now for as long as the call persists, should the receptionists phone, >> that has left the call, still include the CS in any full metadata >> updates it sends, or could it omit the CS ? > > Given your assumptions, when the receptionist leaves the call it ought > to send an update indicating that it is dissociated from the CS and the > related streams it was associated with. Then it presumably forgets about > the CS and never mentions it again. > > This is also an assumption. If it somehow continues to track the state > of the call I guess it could continue to report the state changes. > >> If it must included it, then over time the receptionists phone may end >> up having to track multiple calls so as to send metadata updates, it is >> preferable if it could just forget about the call as it is no longer >> involved in it. >> So does removing a CS from an RS indicate the CS has ended, > > That would clearly be the wrong thing to do in this case, since the CS > is shared by multiple RSs and the others aren't done with it. > >> or will a >> recorder only consider a CS ended when it receives metadata with the CS >> having and end-time element ? > > IMO the SRS can generally assume the CS ended when all participants and > streams have dissociated from it. Even after that, in principle, it > could have another participant or stream associate to it. If so, I guess > it will have to figure out how to deal with that. (It is probably an > error, but in the interest of reliable recording it will want to do > *something* - either graft the new stuff onto the the existing CS, or > start a new CS with the same ID.) > > Thanks, > Paul > >> Rgds >> John Stafford | Solution Architect 1 | BT Global Services >> >> >> _______________________________________________ >> 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 Mon Oct 31 08:16: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 EC3A421F8DB7 for ; Mon, 31 Oct 2011 08:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.091 X-Spam-Level: X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PALEl9n+HHnT for ; Mon, 31 Oct 2011 08:16:01 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA5A1F0C3B for ; Mon, 31 Oct 2011 08:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1865; q=dns/txt; s=iport; t=1320074156; x=1321283756; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=UyfTEb5dXm26ow7rUump8WnsTOuP5xpCpUpcqfHKHqE=; b=Swsvcy0Unre+LYCmIxcLBRmhzh1plbmSB+vJnHG0HgHl04oRdvhvqfuG NQ0rAchsfV4Zc8Z98HGZoE0niKQXtHHBAUtWKTpua4AIaMfyM1Qk0NP5O 53XyT8dPt6vtrGNmFTnS5x9r4xndUO6ny+CCGZ8glcFut6jTBjtIFnebo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAAJO7rk6rRDoG/2dsb2JhbABDDplQj1OBBYFyAQEBAQMBAQEPAR0KNAsMBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQBEggah2iVUAGeEQSIIWEEiAaRPotyVw X-IronPort-AV: E=Sophos;i="4.69,432,1315180800"; d="scan'208";a="11404131" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 31 Oct 2011 15:15:47 +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 p9VFFlrd023314; Mon, 31 Oct 2011 15:15:47 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, 31 Oct 2011 08:15:47 -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, 31 Oct 2011 08:15:45 -0700 Message-ID: In-Reply-To: <4EAB7DD0.8060002@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] proposed text for dealing with packet loss Thread-Index: AcyV8V6u/wXTI1ZzSA6geu9fKqtfwAB7mN1g References: <8106422D-D2DE-4E5F-89A2-85E204CC7B10@acmepacket.com><761013E5-E881-4C85-BF7C-04119BE13E03@acmepacket.com><4EAB348C.1010806@alum.mit.edu><1E043D61-888C-497D-861F-7788225FC889@acmepacket.com> <4EAB7DD0.8060002@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" , "Hadriel Kaplan" X-OriginalArrivalTime: 31 Oct 2011 15:15:47.0104 (UTC) FILETIME=[F765B200:01CC97DF] Cc: siprec@ietf.org Subject: Re: [siprec] proposed text for dealing with packet loss 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, 31 Oct 2011 15:16:02 -0000 To summarize, I will keep the MUST in regard to forwarding the RTCP packets, as well as the text describing the implications on the UA. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, October 28, 2011 9:15 PM > To: Hadriel Kaplan > Cc: > Subject: Re: [siprec] proposed text for dealing with packet loss >=20 > On 10/28/11 7:44 PM, Hadriel Kaplan wrote: > > > > On Oct 28, 2011, at 7:02 PM, Paul Kyzivat wrote: > > > >> I just replied to an earlier message on this. > >> I am quite sure we cannot give dispensation to violate a MUST condition in another RFC. That in > effect is a revision of that RFC. > > > > Yeah, you're probably right. > > Of course RFC 3550 Translator model never had an SRS model in mind ether, but I suppose we shouldn't > open that can of worms. > > > > On the other hand, if we're going to play the RFC-says-so card, why are we putting this MUST > statement in at all? > > Why aren't we just saying "the Translator MUST follow [RFC 3550]", period. ? > > That way if, at some future time, there's an update or extension to RFC 3550 that affects the RTCP- > forwarding behavior, then the update doesn't need to also update this SIPREC doc? >=20 > I agree, at least regarding normative statements. > But it is helpful to spell out the implications of those requirements in > the specific context of our usage. >=20 > Thanks, > Paul >=20 > >> When AVT reviews this (as they will) they will burst into flames. > > > > Hmmm... maybe we *should* do it then - I'll bring the marshmallows. > > ;) > > > > -hadriel > > > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Mon Oct 31 08:22: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 B49631F0C6D for ; Mon, 31 Oct 2011 08:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.828 X-Spam-Level: X-Spam-Status: No, score=-5.828 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrN6ax4kP3UA for ; Mon, 31 Oct 2011 08:22:11 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B99E91F0C69 for ; Mon, 31 Oct 2011 08:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5871; q=dns/txt; s=iport; t=1320074531; x=1321284131; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=goaRfM87GW6joreIqRdZHZ0BNDx5bkNmh7l1/4Lngn4=; b=Q0e0B+W6OziSfb7Nd6HcMLrXNl3IoLYFszhDszL+/iAkMy1hHWgEIcJK OEIFcnncvfDsEj0yCbrnG0jwyc/pOikW1LrT/eW22IiU7azi+sgQXiBy1 4NPEaC0U1hmMdLwAuTmMsmA7V5yEh757hPveHySzIMXrePtEzWR7xPIDk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAAKS8rk6rRDoG/2dsb2JhbABDDplQj1KBBYFyAQEBAQMBAQEPAR0KDx8GCwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIARIHh2iVTAGeGoghYQSIBpE+hQGGcVc X-IronPort-AV: E=Sophos;i="4.69,432,1315180800"; d="scan'208";a="11406137" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 31 Oct 2011 15:22: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 p9VFM40Y026975; Mon, 31 Oct 2011 15:22:04 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, 31 Oct 2011 08:22: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: Mon, 31 Oct 2011 08:22:02 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? Thread-Index: AcyX2iWVCDg58Xj1SjqQN5Hbd3XtKwABPrd6AABmmYA= References: , <4EAAE217.6080406@alum.mit.edu>, <4EAEB1DB.7010505@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: , X-OriginalArrivalTime: 31 Oct 2011 15:22:04.0008 (UTC) FILETIME=[D80CAE80:01CC97E0] Cc: siprec@ietf.org Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? 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, 31 Oct 2011 15:22:12 -0000 Actually, I thought we did agree to relax this to be 0 or more. Here is the conclusion of the thread: http://www.ietf.org/mail-archive/web/siprec/current/msg02616.html Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of john.2.stafford@bt.com > Sent: Monday, October 31, 2011 8:10 AM > To: pkyzivat@alum.mit.edu > Cc: siprec@ietf.org > Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? >=20 > Paul, > Ok, my mistake, as I see in latest matadata draft, CS must have 2 participants. > thanks > Rgds > John Stafford | Solution Architect 1 | BT Global Services > ________________________________________ > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: 31 October 2011 14:34 > To: Stafford,J,John,JRJ3X C > Cc: siprec@ietf.org > Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? >=20 > On 10/31/11 8:29 AM, john.2.stafford@bt.com wrote: > > Paul, > > > > I agree that a SRS should treat a call as ended when all participants have dissassociated, > > or I guess if it gets a CS with and end-time. > > > > But I saw discussion about allowing a CS to have zero participants, >=20 > You did? Where? >=20 > We have been talking about a participant with no CSs, but AFAIK not > about a CS with no participants. >=20 > Thanks, > Paul >=20 > > so then, for persistent RS, we are back to needing to use CS end-time. > > > > > > Rgds > > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932 773504 | E: > john.2.stafford@bt.com | www.bt.com/globalservices > > ________________________________________ > > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > [pkyzivat@alum.mit.edu] > > Sent: 28 October 2011 18:10 > > To: siprec@ietf.org > > Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? > > > > (Revised. I realized I had extra stuff in here that I then decided I > > didn't need.) > > > > Partha commented on this, but rather than inject in that conversation > > I'll make a separate response: > > > > On 10/28/11 9:23 AM, john.2.stafford@bt.com wrote: > >> Consider the following scenario > >> several phones connected to PBX, all voice record their calls from the > >> phone by each having a persistent RS. > >> All calls get initially answered by receptionist, who then conferences > >> in someone to handle the call, then drops out. > >> So there are two phones are conferenced onto same external call, so both > >> phones send metadata for thier RS's to include the call's CS. > >> Since each phone has knowledge of all the conference participants, the > > > > That is an assumption that isn't necessarily true, but this is your > > example, so I'll assume its true > > > >> CS it sends has 3 partiicipants, the two phones and the far party. Also > >> the CS Id and participant Id's sent by each phone are identical. > > > > This is another assumption - its a choice to do it this way. (Partha > > proposed a different way.) But again I'll accept your assumption. Its > > going to take some work for all the phones to arrive at the same ID for > > this CS. > > > >> Now one phone (receptionist) leaves the call, and both phones will sends > >> a metadata update to say one participant has dissassociated. > > > > Well, I suppose all three phones send an update. > > > >> Now for as long as the call persists, should the receptionists phone, > >> that has left the call, still include the CS in any full metadata > >> updates it sends, or could it omit the CS ? > > > > Given your assumptions, when the receptionist leaves the call it ought > > to send an update indicating that it is dissociated from the CS and the > > related streams it was associated with. Then it presumably forgets about > > the CS and never mentions it again. > > > > This is also an assumption. If it somehow continues to track the state > > of the call I guess it could continue to report the state changes. > > > >> If it must included it, then over time the receptionists phone may end > >> up having to track multiple calls so as to send metadata updates, it is > >> preferable if it could just forget about the call as it is no longer > >> involved in it. > >> So does removing a CS from an RS indicate the CS has ended, > > > > That would clearly be the wrong thing to do in this case, since the CS > > is shared by multiple RSs and the others aren't done with it. > > > >> or will a > >> recorder only consider a CS ended when it receives metadata with the CS > >> having and end-time element ? > > > > IMO the SRS can generally assume the CS ended when all participants and > > streams have dissociated from it. Even after that, in principle, it > > could have another participant or stream associate to it. If so, I guess > > it will have to figure out how to deal with that. (It is probably an > > error, but in the interest of reliable recording it will want to do > > *something* - either graft the new stuff onto the the existing CS, or > > start a new CS with the same ID.) > > > > Thanks, > > Paul > > > >> Rgds > >> John Stafford | Solution Architect 1 | BT Global Services > >> > >> > >> _______________________________________________ > >> 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 Oct 31 08:46: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 D5FE71F0C74 for ; Mon, 31 Oct 2011 08:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.869 X-Spam-Level: X-Spam-Status: No, score=-6.869 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx6X6K+4EMKa for ; Mon, 31 Oct 2011 08:46:20 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8A01F0C72 for ; Mon, 31 Oct 2011 08:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2708; q=dns/txt; s=iport; t=1320075979; x=1321285579; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=S3pCDGkzQliSTtjfh5EwcEDuPUi4VN2lJaTZiaAgmS0=; b=DLNP2seheBS0LWVgN+rJMUzvS62Rx3sN7Jfp2qiMauTa9tDAJLyrBvB0 wixtsphL1LaZH/ZxWWDTFgOiSnIUL2RFvKGxX0gdQA4+d/ZU/DCBxGFrO tYR7dxwZuQRmBq3qlHtFwN+ndKUd5j8YI8pFOlgv6GeeMfhpWf72wkVfA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAAPPBrk5Io8US/2dsb2JhbABCmWOPUoEFgXIBAQEBAwEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAEKCAgBEgeHaJVQAZ4aiCFhBIgEkUCMMQ X-IronPort-AV: E=Sophos;i="4.69,432,1315180800"; d="scan'208";a="2116146" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-4.cisco.com with ESMTP; 31 Oct 2011 15:46:17 +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 p9VFkGRB012095; Mon, 31 Oct 2011 15:46:16 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, 31 Oct 2011 21:16:16 +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, 31 Oct 2011 21:16:13 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B8463@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-metadata-05.txt Thread-Index: AcyX0hMfUaa0S1rzTNidKyxIGmNhvQABfbNwAAMGh8A= References: <20111031133617.24449.96357.idtracker@ietfa.amsl.com> From: "Ram Mohan R (rmohanr)" To: , X-OriginalArrivalTime: 31 Oct 2011 15:46:16.0661 (UTC) FILETIME=[39E5F050:01CC97E4] Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-05.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, 31 Oct 2011 15:46:21 -0000 John, This needs to be changed to associate/disassociate time to be in consistent with model. We will take care in the next revision. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of john.2.stafford@bt.com > Sent: Monday, October 31, 2011 8:09 PM > To: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt >=20 > Partha >=20 > sections 6.3, 7.1,and 8 show CS as having Associate Time and > Dissassociate Time, > but examples in section 13 show CS having start-time and end-time. >=20 >=20 > Rgds > John Stafford | Solution Architect 1 | BT Global Services >=20 > ________________________________________ > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: 31 October 2011 13:36 > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-05.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-05.txt > Pages : 45 > Date : 2011-10-31 >=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) and the Recording metadata > format. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-05.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-05.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 john.2.stafford@bt.com Mon Oct 31 09:33: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 65CC61F0C78 for ; Mon, 31 Oct 2011 09:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYDFLggBJVKI for ; Mon, 31 Oct 2011 09:32:59 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 602601F0C77 for ; Mon, 31 Oct 2011 09:32:59 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 31 Oct 2011 16:32:57 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.102]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 31 Oct 2011 16:32:58 +0000 From: To: , Date: Mon, 31 Oct 2011 16:28:53 +0000 Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt Thread-Index: AcyX0hMfUaa0S1rzTNidKyxIGmNhvQABfbNwAAMGh8AAAYJv3Q== Message-ID: References: <20111031133617.24449.96357.idtracker@ietfa.amsl.com> , <35BCE99A477D6A4986FB2216D8CF2CFD082B8463@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD082B8463@XMB-BGL-417.cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-05.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, 31 Oct 2011 16:33:00 -0000 Ram, If CS has associate/dissaociated instead of begin/end times, then there won= 't be any way of signalling that a CS has ended, only that it is no longer = being recorded. Especially as Charles says it was going to be allowed to have a CS with zer= o participants. Maybe CS needs BOTH associate/dissassociate and begin/end times ? Rgds John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932= 773504 | E: john.2.stafford@bt.com | www.bt.com/globalservices ________________________________________ From: Ram Mohan R (rmohanr) [rmohanr@cisco.com] Sent: 31 October 2011 15:46 To: Stafford,J,John,JRJ3X C; siprec@ietf.org Subject: RE: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt John, This needs to be changed to associate/disassociate time to be in consistent with model. We will take care in the next revision. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of john.2.stafford@bt.com > Sent: Monday, October 31, 2011 8:09 PM > To: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt > > Partha > > sections 6.3, 7.1,and 8 show CS as having Associate Time and > Dissassociate Time, > but examples in section 13 show CS having start-time and end-time. > > > Rgds > John Stafford | Solution Architect 1 | BT Global Services > > ________________________________________ > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: 31 October 2011 13:36 > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-05.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 : Session Initiation Protocol (SIP) Recording > Metadata > Author(s) : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ietf-siprec-metadata-05.txt > Pages : 45 > Date : 2011-10-31 > > 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) and the Recording metadata > format. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-05.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-05.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 internet-drafts@ietf.org Mon Oct 31 09:43:16 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 2AF1611E80EC; Mon, 31 Oct 2011 09:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohSug-Mawmbx; Mon, 31 Oct 2011 09:43:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14E911E80DC; Mon, 31 Oct 2011 09:43:15 -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.62 Message-ID: <20111031164315.9335.53190.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 09:43:15 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-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: Mon, 31 Oct 2011 16:43:16 -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 Recording Protocol Author(s) : Leon Portman Henry Lum Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-02.txt Pages : 26 Date : 2011-10-31 This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) from the Session Recording Client (SRC), which is on the path of the CS, to a Session Recording Server (SRS) at the recording device. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-protocol-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-protocol-02.txt From pkyzivat@alum.mit.edu Mon Oct 31 10:22:04 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 0D96921F8AF4 for ; Mon, 31 Oct 2011 10:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArM+iCa6L-9K for ; Mon, 31 Oct 2011 10:22:03 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id D9F4421F87C9 for ; Mon, 31 Oct 2011 10:22:02 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id rUJN1h0031c6gX85CVN3GV; Mon, 31 Oct 2011 17:22:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id rVN21h0110tdiYw3jVN24m; Mon, 31 Oct 2011 17:22:03 +0000 Message-ID: <4EAED938.10203@alum.mit.edu> Date: Mon, 31 Oct 2011 13:22:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: , <4EAAE217.6080406@alum.mit.edu>, <4EAEB1DB.7010505@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ? 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, 31 Oct 2011 17:22:04 -0000 On 10/31/11 11:22 AM, Charles Eckel (eckelcu) wrote: > Actually, I thought we did agree to relax this to be 0 or more. Here is > the conclusion of the thread: > http://www.ietf.org/mail-archive/web/siprec/current/msg02616.html Unless I am missing something, that mail mentions one-or-more, but I don't see a mention of zero-or-more. OTOH, it talks about being lenient in what you accept, perhaps suggesting accepting zero. The tradeoff here is in whether you can assume that a CS that has all of its participants removed is "done". But I'm not sure that is a question that requires an answer. It is a normal state of affairs that a CS with a non-zero number of participants is *not* done. And conversely when a CS *is* done it is reduced to zero participants. But perhaps we should admit the possibility that a CS that has been reduced to zero participants may subsequently have participants added to it. It may seem odd, but if an SRC does that, the SRS is probably well advised to accept that for what it is and keep going. And if that is supported, then why not allow a CS to be created with no participants, and then have participants added to it later. Given our XML schema, that is what will happen in any case - its just a matter of whether the creation of the CS and the addition of a participant to it occur in the same message or separate messages. Is there a need to declare a CS *done* in a final sort of way that guarantees that nothing more will ever be added to it??? Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of john.2.stafford@bt.com >> Sent: Monday, October 31, 2011 8:10 AM >> To: pkyzivat@alum.mit.edu >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Persistent RS case, when should a recorder > consider a CS has ended ? >> >> Paul, >> Ok, my mistake, as I see in latest matadata draft, CS must have 2 > participants. >> thanks >> Rgds >> John Stafford | Solution Architect 1 | BT Global Services >> ________________________________________ >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >> Sent: 31 October 2011 14:34 >> To: Stafford,J,John,JRJ3X C >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Persistent RS case, when should a recorder > consider a CS has ended ? >> >> On 10/31/11 8:29 AM, john.2.stafford@bt.com wrote: >>> Paul, >>> >>> I agree that a SRS should treat a call as ended when all > participants have dissassociated, >>> or I guess if it gets a CS with and end-time. >>> >>> But I saw discussion about allowing a CS to have zero participants, >> >> You did? Where? >> >> We have been talking about a participant with no CSs, but AFAIK not >> about a CS with no participants. >> >> Thanks, >> Paul >> >>> so then, for persistent RS, we are back to needing to use CS > end-time. >>> >>> >>> Rgds >>> John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 > (0)1932 773504 | E: >> john.2.stafford@bt.com | www.bt.com/globalservices >>> ________________________________________ >>> From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of > Paul Kyzivat >> [pkyzivat@alum.mit.edu] >>> Sent: 28 October 2011 18:10 >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Persistent RS case, when should a recorder > consider a CS has ended ? >>> >>> (Revised. I realized I had extra stuff in here that I then decided I >>> didn't need.) >>> >>> Partha commented on this, but rather than inject in that > conversation >>> I'll make a separate response: >>> >>> On 10/28/11 9:23 AM, john.2.stafford@bt.com wrote: >>>> Consider the following scenario >>>> several phones connected to PBX, all voice record their calls from > the >>>> phone by each having a persistent RS. >>>> All calls get initially answered by receptionist, who then > conferences >>>> in someone to handle the call, then drops out. >>>> So there are two phones are conferenced onto same external call, so > both >>>> phones send metadata for thier RS's to include the call's CS. >>>> Since each phone has knowledge of all the conference participants, > the >>> >>> That is an assumption that isn't necessarily true, but this is your >>> example, so I'll assume its true >>> >>>> CS it sends has 3 partiicipants, the two phones and the far party. > Also >>>> the CS Id and participant Id's sent by each phone are identical. >>> >>> This is another assumption - its a choice to do it this way. (Partha >>> proposed a different way.) But again I'll accept your assumption. > Its >>> going to take some work for all the phones to arrive at the same ID > for >>> this CS. >>> >>>> Now one phone (receptionist) leaves the call, and both phones will > sends >>>> a metadata update to say one participant has dissassociated. >>> >>> Well, I suppose all three phones send an update. >>> >>>> Now for as long as the call persists, should the receptionists > phone, >>>> that has left the call, still include the CS in any full metadata >>>> updates it sends, or could it omit the CS ? >>> >>> Given your assumptions, when the receptionist leaves the call it > ought >>> to send an update indicating that it is dissociated from the CS and > the >>> related streams it was associated with. Then it presumably forgets > about >>> the CS and never mentions it again. >>> >>> This is also an assumption. If it somehow continues to track the > state >>> of the call I guess it could continue to report the state changes. >>> >>>> If it must included it, then over time the receptionists phone may > end >>>> up having to track multiple calls so as to send metadata updates, > it is >>>> preferable if it could just forget about the call as it is no > longer >>>> involved in it. >>>> So does removing a CS from an RS indicate the CS has ended, >>> >>> That would clearly be the wrong thing to do in this case, since the > CS >>> is shared by multiple RSs and the others aren't done with it. >>> >>>> or will a >>>> recorder only consider a CS ended when it receives metadata with > the CS >>>> having and end-time element ? >>> >>> IMO the SRS can generally assume the CS ended when all participants > and >>> streams have dissociated from it. Even after that, in principle, it >>> could have another participant or stream associate to it. If so, I > guess >>> it will have to figure out how to deal with that. (It is probably an >>> error, but in the interest of reliable recording it will want to do >>> *something* - either graft the new stuff onto the the existing CS, > or >>> start a new CS with the same ID.) >>> >>> Thanks, >>> Paul >>> >>>> Rgds >>>> John Stafford | Solution Architect 1 | BT Global Services >>>> >>>> >>>> _______________________________________________ >>>> 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 andrew.hutton@siemens-enterprise.com Mon Oct 31 10:43: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 DB57221F8DD6 for ; Mon, 31 Oct 2011 10:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOa5U5H9ZL+2 for ; Mon, 31 Oct 2011 10:43:37 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEFC21F8DD4 for ; Mon, 31 Oct 2011 10:43:37 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id BFF9423F0432 for ; Mon, 31 Oct 2011 18:43:35 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 31 Oct 2011 18:43:35 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Mon, 31 Oct 2011 18:43:34 +0100 Thread-Topic: IETF82 SIPREC - Draft Agenda. Thread-Index: AcyX9JyhsSO7cwmgR4iWc18FFRzBKQ== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E311F7FC07E4@MCHP058A.global-ad.net> 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] IETF82 SIPREC - Draft Agenda. 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, 31 Oct 2011 17:43:38 -0000 Hi All, I have uploaded a draft agenda for IETF82 which can be found at: http://www= .ietf.org/proceedings/82/agenda/siprec.html Any comments, changes or additions ? Regards Andy From eckelcu@cisco.com Mon Oct 31 11:01: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 9B8A111E8142 for ; Mon, 31 Oct 2011 11:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2XEw3Be7z9b for ; Mon, 31 Oct 2011 11:01:14 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E73F611E8138 for ; Mon, 31 Oct 2011 11:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2066; q=dns/txt; s=iport; t=1320084074; x=1321293674; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=YrlWgI9gb3VgHjQAF0hHufvC4s+jmY5d4fpE+gyEDrI=; b=QmQO+KkwEvQyQPpThL8krGt/5rI8dBYru9ES1JWI51HWo+gk+gbuX3o4 +VskpB5pYM3NxhxLpVLb9oRjwz4kD8/ToL7BZpcRZljQXb+1U19oxqqzj W9lTQ/fnCxjC3zChaXnzS1opSGVgAIgZoxFu8QfDKNrYen3h9hXhXBLKD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMBAETirk6rRDoH/2dsb2JhbAApGoR3lGxDjgqBBYEFgXIBAQEBAxIBEA0EQw4GAQgRBAEBAwIGBhcBAgIDAUQHAQEFBAEEEwgah2gjlAiBJgGMSpFpgTCGPjNhBIgGkT6MSQ X-IronPort-AV: E=Sophos;i="4.69,433,1315180800"; d="scan'208";a="10237141" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 31 Oct 2011 18:01:00 +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 p9VI10pa002727 for ; Mon, 31 Oct 2011 18:01:00 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, 31 Oct 2011 11:00:54 -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, 31 Oct 2011 11:00:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-eckel-siprec-rtp-rec-03.txt Thread-Index: AcyX9eYa4Vrri3KXTWCmYJUXtWMQHgAAD39Q From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 31 Oct 2011 18:00:54.0916 (UTC) FILETIME=[08E9D440:01CC97F7] Subject: [siprec] FW: New Version Notification for draft-eckel-siprec-rtp-rec-03.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, 31 Oct 2011 18:01:15 -0000 RllJLCBJIGhhdmUgc3VibWl0dGVkIHRoZSB1cGRhdGVkIGRyYWZ0IGFuZCBpdCBpcyBhdmFpbGFi bGUgdGhyb3VnaCB0aGUgU0lQUkVDIGRvY3VtZW50cyBwYWdlOg0KaHR0cDovL3Byb3h5Mjk3NC5t eS1hZGRyLm5ldC9teWFkZHJwcm94eS5waHAvaHR0cHMvZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cv c2lwcmVjLw0KDQpJdCBjb250YWlucyBlZGl0b3JpYWwgY2hhbmdlcyBhcyB3ZWxsIGFzIGFkZGl0 aW9uYWwgdGV4dCBkZXNjcmliaW5nIHRoZSBoYW5kbGluZyBvZiBSVENQIHBhY2tldHMgYnkgdGhl IFNSQyBhbmQgVUFzIHBlciB0aGUgcmVjZW50IFNJUFJFQyBsaXN0IGRpc2N1c3Npb24uDQoNCkNo ZWVycywNCkNoYXJsZXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBNb25kYXksIE9jdG9iZXIgMzEsIDIwMTEgMTA6NTMgQU0NClRvOiBDaGFybGVzIEVja2Vs IChlY2tlbGN1KQ0KQ2M6IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWVja2VsLXNpcHJlYy1ydHAtcmVjLTAzLnR4dA0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZWNrZWwtc2lwcmVjLXJ0cC1yZWMtMDMudHh0 IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ2hhcmxlcyBFY2tlbCBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtZWNrZWwtc2lw cmVjLXJ0cC1yZWMNClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIFJlYWwtdGltZSBUcmFuc3BvcnQg UHJvdG9jb2wgKFJUUCkgUmVjb21tZW5kYXRpb25zIGZvciBTSVBSRUMNCkNyZWF0aW9uIGRhdGU6 CSAyMDExLTEwLTMxDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBw YWdlczogMTMNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIHJlY29tbWVu ZGF0aW9ucyBhbmQgZ3VpZGVsaW5lcyBmb3IgUlRQIGFuZA0KICAgUlRDUCBpbiB0aGUgY29udGV4 dCBvZiBTSVBSRUMuICBUaGlzIGRvY3VtZW50IGV4aXN0cyBhcyBhIHN0YW5kYWxvbmUNCiAgIGRv Y3VtZW50IHRvIGZhY2lsaXRhdGUgZGlzY3Vzc2lvbiBvZiB0aGUgUlRQIHJlY29tbWVuZGF0aW9u cywgYW5kIGl0DQogICBpcyBhbnRpY2lwYXRlZCB0aGF0IHBvcnRpb25zIG9mIHRoaXMgZG9jdW1l bnQgd2lsbCBiZSBpbmNvcnBvcmF0ZWQNCiAgIGludG8gW0ktRC5pZXRmLXNpcHJlYy1wcm90b2Nv bF0gcmF0aGVyIHRoYW4gdGhpcyBkb2N1bWVudCBpdHNlbGYNCiAgIGJlaW5nIGFkb3B0ZWQgYXMg YSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoN Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From bwinslow@acmepacket.com Mon Oct 31 13:26: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 1C05D11E8221 for ; Mon, 31 Oct 2011 13:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGtYngPAzAwh for ; Mon, 31 Oct 2011 13:26:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8F711E8220 for ; Mon, 31 Oct 2011 13:26:38 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 31 Oct 2011 16:26:36 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 16:26:36 -0400 From: Brad Winslow To: "siprec@ietf.org" Thread-Topic: [siprec] participant & stream outside the scope of session Thread-Index: AQHMlYpJUBvlLhtytkSCvIPaymIqHZWSL9YAgAATaQCAAAJlgIAACYyAgAAeDwCABHpTAA== Date: Mon, 31 Oct 2011 20:26:35 +0000 Message-ID: <622B0E14298DDE47ACA9E16B292F22A40F2F6D2E@Mail1.acmepacket.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD082B7DEA@XMB-BGL-417.cisco.com><4EA9C920.8000200@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD082B7ECA@XMB-BGL-417.cisco.com><2E239D6FCD033C4BAF15F386A979BF51159D3F@sonusinmail02.sonusnet.com><4EAAB8E9.8070708@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD082B80A1@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B80A3@XMB-BGL-417.cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159D78@sonusinmail02.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD082B80C3@XMB-BGL-417.cisco.com> <4EAAEDF5.7080004@alum.mit.edu> <2E239D6FCD033C4BAF15F386A979BF51159D7E@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159D7E@sonusinmail02.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: Re: [siprec] participant & stream outside the scope of 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, 31 Oct 2011 20:26:40 -0000 Hi Folks, Perhaps I'm missing something about the Participant/Session association, an= d perhaps some of this applies to the stream/session association as well. The current metadata draft has two attributes for the participant, the "id"= and the "session" both expressed as UUIDs. The "id" field seems to be a u= nique identifier the SRC could use to indicate the uniqueness of this parti= cipant in multiple CSs assuming the SRC has the ability to determine if the= participant is the same between CSs. The SRS cold use this field to ident= ify participants across sessions. The same holds true of the 'id' field in= the stream element, if we assume a particular 'id' is a MOH stream, it's i= d could be consistent across CSs. IMO we are under-utilizing the 'id' attr= ibute for participant and stream identity. In the case where the SRC canno= t determine if the unique identity of the participant, it would simply crea= te a new UUID for the participant when it enters into a new CS. Much of the information in the new ParticipantSessionAssoc element could be= contained in the participant element. perhaps I don't understand the use-c= ases where the association element reduces the complexity of the metadata w= ell enough. Additional xs:any elements could be passed between SRC and SRS = to help identify the participants however this would quickly lead to intero= perability problems between vendors. Thanks, Brad -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ravindran Parthasarathi Sent: Friday, October 28, 2011 3:49 PM To: Paul Kyzivat; Ram Mohan R (rmohanr); Leon Portman Cc: siprec@ietf.org Subject: Re: [siprec] participant & stream outside the scope of session Paul/Ram, Now, participant and stream are associated with session as an aggregation. = In case participant is possible to be represented outside session, it is ve= ry much possible for stream to be outside the session as shown in persisten= t usecase. In case of persistent usecase, RS stream is created in advance t= o avoid the earlier clipping, the session will be associated in metadata wh= enever the session is established, session will be terminated without remov= ing RS stream In case new participant session associated XML element is added, it is poss= ible to have stream session associated XML element as well separately. Including Leon in this mail thread as he asked for persistent usecase. I'm reopening this usecase because let us close the related issue at the sa= me time. Thanks Partha >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >Sent: Friday, October 28, 2011 11:31 PM >To: Ram Mohan R (rmohanr) >Cc: Ravindran Parthasarathi; siprec@ietf.org >Subject: Re: [siprec] participant & stream outside the scope of session > >+1 to Ram's response. > >As I noted before, if you want to reopen question of allowing stream=20 >without session, I think that should be discussed separately. > > Thanks, > Paul > >On 10/28/11 1:27 PM, Ram Mohan R (rmohanr) wrote: >> Hi Partha, >> >> Please see inline >> >>> -----Original Message----- >>> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] >>> Sent: Friday, October 28, 2011 10:49 PM >>> To: Ram Mohan R (rmohanr); Paul Kyzivat >>> Cc: siprec@ietf.org >>> Subject: RE: [siprec] participant& stream outside the scope of >> session >>> >>> Hi Ram, >>> >>> As Paul mentioned, stream associated with zero session was brought up >>> as >>> part of the persistent connection from the endpoint discussion and it >>> was pushed back because stream& participant has to be within session >>> (CS). I'm worried that participant to zero session change may re-open >>> the earlier closure and call for one more discussion. >>> >>> Also, the current syntax of stream is associated with session closely >>> which has to be changed consistently in case participant is changed >> its >>> association representation with session. >> >> I don't see a need for the above. We are changing the participant=20 >> association to session to allow it to be consistent with XML if we=20 >> choose approach 2. >> Even in approach 2, stream has to be associated with a session and so=20 >> there is no need to change that association. >> >> Regards, >> Ram >> >>> >>> >> session=3D"urn:uuid:cd27cfa1-2bdd-4830-a653- >70374d10f103"> >>> >>> >>> >>> It will be good in case we get the feedback on these aspect. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>> Sent: Friday, October 28, 2011 9:39 PM >>>> To: Ram Mohan R (rmohanr); Paul Kyzivat; Ravindran Parthasarathi >>>> Cc: siprec@ietf.org >>>> Subject: RE: [siprec] participant& stream outside the scope of >>> session >>>> >>>> A typo in the below email. Sorry for that. I meant >>>> >>>> " >>>> I don't see a strong use case to have stream associate to zero=20 >>>> sessions. IMO we can retain the stream associations >>>> ^^^^^^ ^^^^ as it is in the=20 >>>> current model." >>>> >>>> Thanks, >>>> Ram >>>> >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>>>> Behalf Of Ram Mohan R (rmohanr) >>>>> Sent: Friday, October 28, 2011 9:27 PM >>>>> To: Paul Kyzivat; Ravindran Parthasarathi >>>>> Cc: siprec@ietf.org >>>>> Subject: Re: [siprec] participant& stream outside the scope of >>>> session >>>>> >>>>> I don't see a strong use case to have session associate to zero=20 >>>>> sessions. IMO we can retain the session associations as it is in >> the >>>>> current model. >>>>> >>>>> Now coming to participant, the main reason why I am inclined to >>> change >>>>> the association is to have consistency with XML if we adopt >>> approach >>>>> 2. >>>>> >>>>> Regards, >>>>> Ram >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>> Sent: Friday, October 28, 2011 7:45 PM >>>>>> To: Ravindran Parthasarathi >>>>>> Cc: Ram Mohan R (rmohanr); siprec@ietf.org >>>>>> Subject: Re: participant& stream outside the scope of session >>>>>> >>>>>> This proposes an additional change, to remove the subordination >> of >>>>>> stream to session. IMO this should be considered separately from=20 >>>>>> participant, as the arguments are different. >>>>>> >>>>>> AFAICT, the use case Partha gives below is the only one that >> calls >>>>> for >>>>>> stream independent of session. And I'm not sure of the need for >>>> this. >>>>>> ISTM the only reason to do this is to really record streams from=20 >>>>>> participants when there is no session. >>>>>> >>>>>> This might allow capturing media earlier during call setup, by >>>>> defining >>>>>> the streams early, and associating them with participants and >>>>> sessions >>>>>> when that becomes known. *If* an SRS can figure out how to take=20 >>>>>> advantage of that. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 10/28/11 5:09 AM, Ravindran Parthasarathi wrote: >>>>>>> >>>> major >>>>>>> change in metadata> >>>>>>> >>>>>>> I'm interested in knowing whether folks are interested in >>> handling >>>>>>> participant, stream completely outside the scope of session. >>>>>>> In fact, we discussed this requirement as part of metadata >> model >>>>>>> discussion and come to the conclusion not to include. In case=20 >>>>>>> participant, stream are outside the scope of session, the >>>> following >>>>>>> recording metadata from SRC is valid: >>>>>>> >>>>>>> >>>>>>> full >>>>>>> >>>>>> id=3D"urn:uuid:b2b7c112-5982-469d-9007- >>> 6ddbecca64d3"> >>>>>>> sip:agent1@callcenter.com >>>>>>> urn:uuid:f3373a7b-4958-4e55-8820- >>>>>> d03a191fb76a >>>>>>> >>>>>>> >>>>> d03a191fb76a"> >>>>>>> >>>>>>> >>>>>>> >>>>> 0090272ff725"> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Also, in the later partial update, session shall be added and >>>>>> associate >>>>>>> with the above participant& stream element. >>>>>>> >>>>>>> Here, SRS has to maintain participant, stream unique id as a >>>>> separate >>>>>>> flat >>>>>>> Data (no hierarchy). Only issue is that SRS has to maintain >> flat >>>>>>> database for >>>>>>> Each of these elements. >>>>>>> >>>>>>> The current -04 draft is based on the assumption that >>> participant >>>>> and >>>>>>> stream are within a session and it is possible for participant& >>>>>> stream >>>>>>> to move across multiple sessions using unique id. The rationale >>> of >>>>>> the >>>>>>> current draft approach is that commonly used callflow metadata >>> is >>>>>> simple >>>>>>> >>>>>>> whereas specific corner case callflow like same participant in >>>>>> multiple >>>>>>> session will have complex mechanism. >>>>>>> >>>>>>> In case we see the strong usecases for going for independent >>>>> stream, >>>>>>> Participants which is outside the session, we will go for it. >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >>> On >>>>>>> Behalf >>>>>>>> Of Ram Mohan R (rmohanr) >>>>>>>> Sent: Friday, October 28, 2011 10:24 AM >>>>>>>> To: Paul Kyzivat; siprec@ietf.org >>>>>>>> Subject: Re: [siprec] Issue with participant scoping in the >>>>> current >>>>>>>> modeland its implication on association attr representation >>>>>>>> >>>>>>>> To add to Paul, with the proposed change, the model will look >>> as >>>>>> below >>>>>>>> >>>>>>>> +-------------------------------+ >>>>>>>> | Communication Session (CS) | >>>>>>>> | | >>>>>>>> +-------------------------------+ >>>>>>>> | 0..* |1..* >>>>>>>> | ^^^^^^^^ | >>>>>>>> | 2..* |0..* >>>>>>>> +-------------+ receives +----------------+ >>>>>>>> | Participant |----------| Media Streams | >>>>>>>> | |0..* 0..*| | >>>>>>>> | | | | >>>>>>>> | | | | >>>>>>>> | | sends | | >>>>>>>> | |----------| | >>>>>>>> | |1.* 0..*| | >>>>>>>> +-------------+ +----------------+ >>>>>>>> >>>>>>>> A participant can be associated with zero or more sessions. >>>>>>>> >>>>>>>> And with the above model we can have an approach to define a >>>>>>> participant >>>>>>>> with no associations to sessions and have XML elements >> separate >>>>>> (like >>>>>>>> ) for association classes as in approach >>> 2 >>>>>>>> mentioned below >>>>>>>> >>>>>>>> Ram >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] >>>> On >>>>>>>>> Behalf Of Paul Kyzivat >>>>>>>>> Sent: Friday, October 28, 2011 2:42 AM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: Re: [siprec] Issue with participant scoping in the >>>>> current >>>>>>>>> model and its implication on association attr representation >>>>>>>>> >>>>>>>>> On 10/27/11 1:46 PM, Ram Mohan R (rmohanr) wrote: >>>>>>>>>> (Sorry for lengthy e-mail) >>>>>>>>>> >>>>>>>>>> This is a follow up to the mail thread >>>>>>>>>> http://www.ietf.org/mail- >>>>> archive/web/siprec/current/msg02810.html >>>>>>>>>> >>>>>>>>>> In the last IETF meeting there was a consensus that a >>>>> participant >>>>>>>> can >>>>>>>>>> have a life outside of CS. >>>>>>>>>> >>>>>>>>>> However the current model scopes participant to always a >>>>> session. >>>>>>>>> >>>>>>>>> I don't think that is quite right. The *model* requires that >>>> each >>>>>>>>> participant be associated with one or more sessions. It >>> doesn't >>>>>> scope >>>>>>>>> to >>>>>>>>> a single session. >>>>>>>>> >>>>>>>>>> Should we have to change the model to have participant >>> outside >>>>>>> scope >>>>>>>>> of >>>>>>>>>> session ? I think it may not make sense to model >> participants >>>>>> under >>>>>>>>> RS >>>>>>>>>> as these are participants of Session. The only use case >> where >>>> we >>>>>>> can >>>>>>>>>> have a participant in a RS with no CS is for Persistent >>>>> recording >>>>>>>>>> sessions (e.g. setup from agent phone(SRC) to SRS) This RS >>> will >>>>> be >>>>>>>>> setup >>>>>>>>>> even without any CS. If an SRC for this case sends a >>> snapshot >>>>>>>> before >>>>>>>>> a >>>>>>>>>> CS starts it may have participant information without any >>>>> session. >>>>>>>>>> Does the WG sees a value in such a use case or should we >>> retain >>>>>> the >>>>>>>>>> model as is ? >>>>>>>>> >>>>>>>>> IMO the change we would be talking about is that a >> participant >>>>> can >>>>>> be >>>>>>>>> associated with *zero* or more sessions, rather than one or >>>> more. >>>>>>>>> >>>>>>>>> In addition to the use case Ram mentions above, this would >>> help >>>>>> with >>>>>>>>> the >>>>>>>>> mapping to xml. If we go with participantSessAssoc (as >>> mentioned >>>>>>>> below) >>>>>>>>> it becomes *possible* to define a participant with no >>>>> associations >>>>>> to >>>>>>>>> sessions. Allowing the same in the model at least makes them=20 >>>>>>>>> consistent. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>> The current model (ver 04) also impacts the way association >>>>>>>>> attributes >>>>>>>>>> are represented. Since the current draft (ver-04)the >> metadata >>>>>> model >>>>>>>>>> scopes participant and stream elements to session the schema >>>>> also >>>>>>>> was >>>>>>>>>> designed the same way. The and >>>>> attributes >>>>>>> are >>>>>>>>>> scoped/associated to a session (see section 7.1 example). >> IOW >>>>> the >>>>>>>>>> association attributes of to are >>>>> already >>>>>>>>>> represented. >>>>>>>>>> >>>>>>>>>> Now if we have to go with approach 2 for representing >>>>> association >>>>>>>>>> attributes, we will have to do one of the two ways: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If we stick the current model/schema: >>>>>>>>>> ----------------------------------- >>>>>>>>>> We will have represent in the following way. Note this is a >>> mix >>>>> of >>>>>>>>>> approach 1 (existing representation which acheives >>> participant >>>>>>>>> session >>>>>>>>>> association) and approach 2 ( for part-stream association). >>>> The >>>>>>>>> issue >>>>>>>>>> with this approach is if the same participant is >>> simultaneously >>>>> in >>>>>>>>>> multiple sessions( cases like participant goes on hold on >> one >>>>> line >>>>>>>>> and >>>>>>>>>> talks to another participant) and SRC sends a snapshot then >>> we >>>>>> will >>>>>>>>> have >>>>>>>>>> multiple elements each having different >>> session >>>>>> IDs. >>>>>>>>>> >>>>>>>>> >>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>>> >>>>>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> >>>>>>>>>> sip:ram@blr.cisco.com >>>>>>>>>> 2010-12- >>>>>> 16T23:41:07Z>>>>>>>> time> >>>>>>>>>> XXX >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> And for participant-stream you will have a new element >>>>>>>>>> >>>>>>>>>> >>>>>>>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007- >>> 6ddbecca64d3" >>>>>>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>>> contributing SSRC-1=20 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If we change the model to remove the scoping of >>>>> participant/stream >>>>>>>> to >>>>>>>>>> session: >>>>>>>>>> >>>>>>>> >>>>> >> -------------------------------------------------------------------- >>>>>> - >>>>>>>>> --- >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>> id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"> >>>>>>>>>> sip:ram@blr.cisco.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" >>>>>>>>>> session=3D"urn:uuid:855a5ded-8420-456d-a70f- >>>>>> 6da1eeaeb425" >>>>>>>>>> >>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>>> XXX >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> participant=3D"urn:uuid:b2b7c112-5982-469d-9007- >>> 6ddbecca64d3" >>>>>>>>>> stream =3D"urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a "> >>>>>>>>>> 2010-12-16T23:41:07Z >>>>>>>>>> contributing SSRC-1=20 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Let me know your comments. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Ram >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 Oct 31 23:50: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 8C54111E80B2 for ; Mon, 31 Oct 2011 23:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.557 X-Spam-Level: X-Spam-Status: No, score=-8.557 tagged_above=-999 required=5 tests=[AWL=1.442, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zC7afA-yjNF for ; Mon, 31 Oct 2011 23:50:11 -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 D33B111E808E for ; Mon, 31 Oct 2011 23:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=5226; q=dns/txt; s=iport; t=1320130211; x=1321339811; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=7UvT3cXsnhcl44HZd3mVk/uehjF5nqZWl0pDuwfFylM=; b=KHa8WU8U8aDFyhrFnXixGTwwnLiNiXRGJ7eoy1S37Tz1URdhym3fb+w4 qjryxemH4fv0ZRU2LEW4PdDmjyKuf0H52I8uUSgLpnlRjPeyi7A/yBwWj E/hutvU5tHw37HqW824rAWP5e+gJYtfv039OY0FFZbOKZiH+Ns56fwFsX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0AAIWWr05Io8US/2dsb2JhbABDmWSPU4EFgXIBAQEBAgEBAQEPAR0KDyUXBAIBCBEEAQELBhcBBgEmHwkIAQEEAQoICAESB4dgCJV1AZ5SiCFhBIgEkUGFAYcw X-IronPort-AV: E=Sophos;i="4.69,436,1315180800"; d="scan'208";a="120483866" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 01 Nov 2011 06:49:57 +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 pA16ns02009091; Tue, 1 Nov 2011 06:49:56 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); Tue, 1 Nov 2011 12:19:56 +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, 1 Nov 2011 12:19:51 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD082B8592@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-metadata-05.txt Thread-Index: AcyX0hMfUaa0S1rzTNidKyxIGmNhvQABfbNwAAMGh8AAAYJv3QAdYrGg References: <20111031133617.24449.96357.idtracker@ietfa.amsl.com> , <35BCE99A477D6A4986FB2216D8CF2CFD082B8463@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: , X-OriginalArrivalTime: 01 Nov 2011 06:49:56.0129 (UTC) FILETIME=[77383110:01CC9862] Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-05.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, 01 Nov 2011 06:50:12 -0000 Hi John S Please see inline > -----Original Message----- > From: john.2.stafford@bt.com [mailto:john.2.stafford@bt.com] > Sent: Monday, October 31, 2011 9:59 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: RE: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt >=20 > Ram, >=20 > If CS has associate/dissaociated instead of begin/end times, then there > won't be any way of signalling that a CS has ended, only that it is no > longer being recorded. >=20 > Especially as Charles says it was going to be allowed to have a CS with > zero participants. >=20 > Maybe CS needs BOTH associate/dissassociate and begin/end times ? The associate-time here indicates the time a CS was associated with a RS. IOW it is the time the recording of CS is started in that RS. Disassociate time indicate the time the recording of CS was stopped from that RS. The reason why this attribute was added is to address cases where only parts of CS is recorded(e.g. you record the first few mins of a CS, then stop the recording, then re-start recording of the same CS after some time). In such cases indicating begin/end of CS is not correct as CS has not ended, but RS has ended. So the WG decided it's better to have associate/disassociate time and have its scope to a RS so that a CS may have multiple associate/disassociate times if need be. For simple cases where the entire CS is recorded, the associate/disassociate times may be mapped to the CS begin/end times assuming recording is started the same moment CS is setup. I agree that with this approach, we are not indicating explicitly indicating when the CS has actually started/ended.=20 >From the past discussions, there was no much interest in keeping both of this information. If you think there are enough use-cases where indicating both these will be helpful please bring them, we can discuss further and add begin/end times after getting consensus from WG. Regards, Ram >=20 > Rgds > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 > (0)1932 773504 | E: john.2.stafford@bt.com | > www.bt.com/globalservices > ________________________________________ > From: Ram Mohan R (rmohanr) [rmohanr@cisco.com] > Sent: 31 October 2011 15:46 > To: Stafford,J,John,JRJ3X C; siprec@ietf.org > Subject: RE: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt >=20 > John, >=20 > This needs to be changed to associate/disassociate time to be in > consistent with model. We will take care in the next revision. >=20 > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of john.2.stafford@bt.com > > Sent: Monday, October 31, 2011 8:09 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt > > > > Partha > > > > sections 6.3, 7.1,and 8 show CS as having Associate Time and > > Dissassociate Time, > > but examples in section 13 show CS having start-time and end-time. > > > > > > Rgds > > John Stafford | Solution Architect 1 | BT Global Services > > > > ________________________________________ > > From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org [internet-drafts@ietf.org] > > Sent: 31 October 2011 13:36 > > To: i-d-announce@ietf.org > > Cc: siprec@ietf.org > > Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-05.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 : Session Initiation Protocol (SIP) Recording > > Metadata > > Author(s) : Ram Mohan Ravindranath > > Parthasarathi Ravindran > > Paul Kyzivat > > Filename : draft-ietf-siprec-metadata-05.txt > > Pages : 45 > > Date : 2011-10-31 > > > > 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) and the Recording metadata > > format. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-05.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-05.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