From nobody Wed Oct 1 08:38:57 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD1D1ACE5D for ; Wed, 1 Oct 2014 08:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLyZjuZ1_wGn for ; Wed, 1 Oct 2014 08:38:53 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id F3C211ACE5B for ; Wed, 1 Oct 2014 08:38:52 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id C7BC51EB85CF; Wed, 1 Oct 2014 17:38:51 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 1 Oct 2014 17:38:51 +0200 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] IETF91 SIPREC Meeting Thread-Index: AQHP2BH626Sy94gZRGe/WNqN1yRzT5wZgcwA///5zQCAAe+HwA== Date: Wed, 1 Oct 2014 15:38:51 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5B37CC@MCHP04MSX.global-ad.net> References: <54223161.8030106@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF1E5B1BE6@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/OB4kV2T13HxQ3D1Huxz-r26LuFY Subject: Re: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 15:38:55 -0000 We need to identify some individuals willing to put some time in to reviewi= ng these drafts. The chairs will look for people to do this but if anybody is willing to do = this please let us know. Regards Andy > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 30 September 2014 13:04 > To: Hutton, Andrew; Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] IETF91 SIPREC Meeting >=20 > Hi Andy, >=20 > Overall it Sounds a good plan. If possible we can start the WGLC for > metadata in parallel while we get feedback for protocol draft from IESG > unless we expect some changes in metadata as a result of IESG review of > protocol draft. We can keep the WGLC for metadata draft open till we > finish the protocol draft. In that way we would give the WG sufficient > time to review and give any LC feedback they have on the metadata > draft. >=20 > Regards, > Ram >=20 > -----Original Message----- > From: , Andrew > Date: Tuesday, 30 September 2014 4:10 pm > To: Cisco Employee , Paul Kyzivat > , "siprec@ietf.org" > Subject: RE: [siprec] IETF91 SIPREC Meeting >=20 > >The meeting time should be used to discuss open issues with the > documents > >that have not been resolved on the list. > > > >The protocol document should be going to the IESG shortly hopefully > Brian > >is working on the write-up. > > > >Regarding the metadata and call flows then there has been no > discussion > >on these for some time and my thinking is that these will move forward > >once we have made some progress with the protocol draft which is the > main > >SIPREC spec. > > > >Alissa informs me that we are likely to get lots of IESG feedback on > the > >protocol draft so my thinking is that we should get this feedback > before > >progressing the other drafts. > > > >Does that sound like a plan? > > > >I have a meeting with Brian and Alissa coming up so will discuss it > again > >with them. > > > >Regards > >Andy (SIPREC Co-Chair). > > > > > > > >> -----Original Message----- > >> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan > R > >> (rmohanr) > >> Sent: 24 September 2014 17:10 > >> To: Paul Kyzivat; siprec@ietf.org > >> Subject: Re: [siprec] IETF91 SIPREC Meeting > >> > >> +1 > >> > >> I also second Paul. Can we please get some attention on the base > drafts > >> (protocol, metadata, call flows) and try to finish them at this > meeting > >> ? > >> > >> Ram > >> > >> -----Original Message----- > >> From: Paul Kyzivat > >> Date: Wednesday, 24 September 2014 8:20 am > >> To: "siprec@ietf.org" > >> Subject: Re: [siprec] IETF91 SIPREC Meeting > >> > >> >Can we please try to *finish* the base siprec drafts before or at > this > >> >meeting??? > >> > > >> >On 9/22/14 5:08 PM, Charles Eckel (eckelcu) wrote: > >> >> Hi Andy, > >> >> > >> >> I posted an update to the protocol draft 4 weeks ago. > >> >> http://www.ietf.org/mail-archive/web/siprec/current/msg03997.html > >> >> > >> >> I believe this version addresses all comments and issues; > however, > >> there > >> >> has not been confirmation by reviewers yet. If the chairs think > it > >> would > >> >> be helpful, I can present the latest changes at IETF 91 > >> >> > >> >> Cheers, > >> >> Charles > >> >> > >> >> From: , Andrew >> >> > > >> >> Date: Friday, September 19, 2014 at 1:13 AM > >> >> To: "siprec@ietf.org " >> >> > > >> >> Subject: [siprec] IETF91 SIPREC Meeting > >> >> > >> >> Hi All, > >> >> The deadline for requesting an IETF91 meeting slot is next > week > >> >> (26^th of Sept). > >> >> Please let the chairs know if you believe a SIPREC meeting at > >> IETF91 > >> >> is needed and why and whether you have anything to present. > >> >> Given that there has no list discussion I am thinking that > maybe > >> >> there is no need for a SIPREC meeting this time. > >> >> Regards > >> >> Andy (SIPREC Co-Chair). > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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 nobody Wed Oct 1 09:05:24 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9F21ACE7C for ; Wed, 1 Oct 2014 09:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpIq4eaaMsKW for ; Wed, 1 Oct 2014 09:05:20 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C32D1ACE71 for ; Wed, 1 Oct 2014 09:05:20 -0700 (PDT) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-09v.sys.comcast.net with comcast id xs3g1o0085Geu2801s5LUB; Wed, 01 Oct 2014 16:05:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-20v.sys.comcast.net with comcast id xs5K1o0023Ge9ey01s5KjN; Wed, 01 Oct 2014 16:05:19 +0000 Message-ID: <542C263E.6020507@alum.mit.edu> Date: Wed, 01 Oct 2014 12:05:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hutton, Andrew" , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" References: <54223161.8030106@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF1E5B1BE6@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E5B37CC@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E5B37CC@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412179520; bh=M43aGtkPqNegGFqw4iai9guK0Q0s/RGsY9tfz9O0GE8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=h+2kNOLBHtfzLVwm2AFSTy7Ci02U8MOCYPYP/BuKZ0N7WTaL0DF/YQN2kvHeKNLGH Ux/6erBfLVJjx8t7Q7dKzJr+wUj5mHvvQ7PMviamatp7S0abPNw7wPbUiBcfImvaBk EpKPIY2itfc/fU+ZvTZthypjFzhR4G9220Wbx43htYzBA01U6mZFd/fkoTP0Yp9gEr HAzR9KyqO0fMub60FWjT/VjAK4WTdb92bm6O/veQf40ltJiSVWFdUaIaxJeEl9/EvX zIJDYJNW+PSwnc6d05l70SMKd4cATKulTCTDNc5Fr6+hJOSst5FaA2PnBWJH0YlSpQ YN3mgDI4Go0ng== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/37YOWSIDtSV04wf3GX0EFTos-Ak Subject: Re: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 16:05:23 -0000 On 10/1/14 11:38 AM, Hutton, Andrew wrote: > We need to identify some individuals willing to put some time in to reviewing these drafts. > > The chairs will look for people to do this but if anybody is willing to do this please let us know. Are you issuing WGLC and trying to identify people for it? I guess it doesn't make sense for me to review the metadata draft. :-) I've been reviewing the protocol all along. But I will volunteer to do it from a WGLC perspective, once WGLC is called. Thanks, Paul > Regards > Andy > >> -----Original Message----- >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> Sent: 30 September 2014 13:04 >> To: Hutton, Andrew; Paul Kyzivat; siprec@ietf.org >> Subject: Re: [siprec] IETF91 SIPREC Meeting >> >> Hi Andy, >> >> Overall it Sounds a good plan. If possible we can start the WGLC for >> metadata in parallel while we get feedback for protocol draft from IESG >> unless we expect some changes in metadata as a result of IESG review of >> protocol draft. We can keep the WGLC for metadata draft open till we >> finish the protocol draft. In that way we would give the WG sufficient >> time to review and give any LC feedback they have on the metadata >> draft. >> >> Regards, >> Ram >> >> -----Original Message----- >> From: , Andrew >> Date: Tuesday, 30 September 2014 4:10 pm >> To: Cisco Employee , Paul Kyzivat >> , "siprec@ietf.org" >> Subject: RE: [siprec] IETF91 SIPREC Meeting >> >>> The meeting time should be used to discuss open issues with the >> documents >>> that have not been resolved on the list. >>> >>> The protocol document should be going to the IESG shortly hopefully >> Brian >>> is working on the write-up. >>> >>> Regarding the metadata and call flows then there has been no >> discussion >>> on these for some time and my thinking is that these will move forward >>> once we have made some progress with the protocol draft which is the >> main >>> SIPREC spec. >>> >>> Alissa informs me that we are likely to get lots of IESG feedback on >> the >>> protocol draft so my thinking is that we should get this feedback >> before >>> progressing the other drafts. >>> >>> Does that sound like a plan? >>> >>> I have a meeting with Brian and Alissa coming up so will discuss it >> again >>> with them. >>> >>> Regards >>> Andy (SIPREC Co-Chair). >>> >>> >>> >>>> -----Original Message----- >>>> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan >> R >>>> (rmohanr) >>>> Sent: 24 September 2014 17:10 >>>> To: Paul Kyzivat; siprec@ietf.org >>>> Subject: Re: [siprec] IETF91 SIPREC Meeting >>>> >>>> +1 >>>> >>>> I also second Paul. Can we please get some attention on the base >> drafts >>>> (protocol, metadata, call flows) and try to finish them at this >> meeting >>>> ? >>>> >>>> Ram >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat >>>> Date: Wednesday, 24 September 2014 8:20 am >>>> To: "siprec@ietf.org" >>>> Subject: Re: [siprec] IETF91 SIPREC Meeting >>>> >>>>> Can we please try to *finish* the base siprec drafts before or at >> this >>>>> meeting??? >>>>> >>>>> On 9/22/14 5:08 PM, Charles Eckel (eckelcu) wrote: >>>>>> Hi Andy, >>>>>> >>>>>> I posted an update to the protocol draft 4 weeks ago. >>>>>> http://www.ietf.org/mail-archive/web/siprec/current/msg03997.html >>>>>> >>>>>> I believe this version addresses all comments and issues; >> however, >>>> there >>>>>> has not been confirmation by reviewers yet. If the chairs think >> it >>>> would >>>>>> be helpful, I can present the latest changes at IETF 91 >>>>>> >>>>>> Cheers, >>>>>> Charles >>>>>> >>>>>> From: , Andrew >>>>> > >>>>>> Date: Friday, September 19, 2014 at 1:13 AM >>>>>> To: "siprec@ietf.org " >>>>> > >>>>>> Subject: [siprec] IETF91 SIPREC Meeting >>>>>> >>>>>> Hi All, >>>>>> The deadline for requesting an IETF91 meeting slot is next >> week >>>>>> (26^th of Sept). >>>>>> Please let the chairs know if you believe a SIPREC meeting at >>>> IETF91 >>>>>> is needed and why and whether you have anything to present. >>>>>> Given that there has no list discussion I am thinking that >> maybe >>>>>> there is no need for a SIPREC meeting this time. >>>>>> Regards >>>>>> Andy (SIPREC Co-Chair). >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 nobody Wed Oct 1 09:24:37 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109A01ACE4D for ; Wed, 1 Oct 2014 09:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH15F7JAWVuF for ; Wed, 1 Oct 2014 09:24:31 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4C01ACE29 for ; Wed, 1 Oct 2014 09:24:30 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id ABE0923F05D6; Wed, 1 Oct 2014 18:24:29 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Wed, 1 Oct 2014 18:24:29 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] IETF91 SIPREC Meeting Thread-Index: AQHP2BH626Sy94gZRGe/WNqN1yRzT5wZgcwA///5zQCAAe+HwP//5jIAgAAmrdA= Date: Wed, 1 Oct 2014 16:24:29 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5B394E@MCHP04MSX.global-ad.net> References: <54223161.8030106@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF1E5B1BE6@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E5B37CC@MCHP04MSX.global-ad.net> <542C263E.6020507@alum.mit.edu> In-Reply-To: <542C263E.6020507@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/KdRiQWG-A2QfSwO2K1zab5iQOpM Subject: Re: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 16:24:35 -0000 No we are not calling WGLC on anything at this time. The protocol draft is already past WGLC. Andy > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 01 October 2014 17:05 > To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] IETF91 SIPREC Meeting >=20 > On 10/1/14 11:38 AM, Hutton, Andrew wrote: > > We need to identify some individuals willing to put some time in to > reviewing these drafts. > > > > The chairs will look for people to do this but if anybody is willing > to do this please let us know. >=20 > Are you issuing WGLC and trying to identify people for it? >=20 > I guess it doesn't make sense for me to review the metadata draft. :-) >=20 > I've been reviewing the protocol all along. But I will volunteer to do > it from a WGLC perspective, once WGLC is called. >=20 > Thanks, > Paul >=20 > > Regards > > Andy > > > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >> Sent: 30 September 2014 13:04 > >> To: Hutton, Andrew; Paul Kyzivat; siprec@ietf.org > >> Subject: Re: [siprec] IETF91 SIPREC Meeting > >> > >> Hi Andy, > >> > >> Overall it Sounds a good plan. If possible we can start the WGLC for > >> metadata in parallel while we get feedback for protocol draft from > IESG > >> unless we expect some changes in metadata as a result of IESG review > of > >> protocol draft. We can keep the WGLC for metadata draft open till we > >> finish the protocol draft. In that way we would give the WG > sufficient > >> time to review and give any LC feedback they have on the metadata > >> draft. > >> > >> Regards, > >> Ram > >> > >> -----Original Message----- > >> From: , Andrew > >> Date: Tuesday, 30 September 2014 4:10 pm > >> To: Cisco Employee , Paul Kyzivat > >> , "siprec@ietf.org" > >> Subject: RE: [siprec] IETF91 SIPREC Meeting > >> > >>> The meeting time should be used to discuss open issues with the > >> documents > >>> that have not been resolved on the list. > >>> > >>> The protocol document should be going to the IESG shortly hopefully > >> Brian > >>> is working on the write-up. > >>> > >>> Regarding the metadata and call flows then there has been no > >> discussion > >>> on these for some time and my thinking is that these will move > forward > >>> once we have made some progress with the protocol draft which is > the > >> main > >>> SIPREC spec. > >>> > >>> Alissa informs me that we are likely to get lots of IESG feedback > on > >> the > >>> protocol draft so my thinking is that we should get this feedback > >> before > >>> progressing the other drafts. > >>> > >>> Does that sound like a plan? > >>> > >>> I have a meeting with Brian and Alissa coming up so will discuss it > >> again > >>> with them. > >>> > >>> Regards > >>> Andy (SIPREC Co-Chair). > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Ram > Mohan > >> R > >>>> (rmohanr) > >>>> Sent: 24 September 2014 17:10 > >>>> To: Paul Kyzivat; siprec@ietf.org > >>>> Subject: Re: [siprec] IETF91 SIPREC Meeting > >>>> > >>>> +1 > >>>> > >>>> I also second Paul. Can we please get some attention on the base > >> drafts > >>>> (protocol, metadata, call flows) and try to finish them at this > >> meeting > >>>> ? > >>>> > >>>> Ram > >>>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat > >>>> Date: Wednesday, 24 September 2014 8:20 am > >>>> To: "siprec@ietf.org" > >>>> Subject: Re: [siprec] IETF91 SIPREC Meeting > >>>> > >>>>> Can we please try to *finish* the base siprec drafts before or at > >> this > >>>>> meeting??? > >>>>> > >>>>> On 9/22/14 5:08 PM, Charles Eckel (eckelcu) wrote: > >>>>>> Hi Andy, > >>>>>> > >>>>>> I posted an update to the protocol draft 4 weeks ago. > >>>>>> http://www.ietf.org/mail- > archive/web/siprec/current/msg03997.html > >>>>>> > >>>>>> I believe this version addresses all comments and issues; > >> however, > >>>> there > >>>>>> has not been confirmation by reviewers yet. If the chairs think > >> it > >>>> would > >>>>>> be helpful, I can present the latest changes at IETF 91 > >>>>>> > >>>>>> Cheers, > >>>>>> Charles > >>>>>> > >>>>>> From: , Andrew >>>>>> > > >>>>>> Date: Friday, September 19, 2014 at 1:13 AM > >>>>>> To: "siprec@ietf.org " >>>>>> > > >>>>>> Subject: [siprec] IETF91 SIPREC Meeting > >>>>>> > >>>>>> Hi All, > >>>>>> The deadline for requesting an IETF91 meeting slot is next > >> week > >>>>>> (26^th of Sept). > >>>>>> Please let the chairs know if you believe a SIPREC meeting > at > >>>> IETF91 > >>>>>> is needed and why and whether you have anything to present. > >>>>>> Given that there has no list discussion I am thinking that > >> maybe > >>>>>> there is no need for a SIPREC meeting this time. > >>>>>> Regards > >>>>>> Andy (SIPREC Co-Chair). > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 nobody Wed Oct 1 09:42:04 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A401A1A6D for ; Wed, 1 Oct 2014 09:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAwkenBiEaCa for ; Wed, 1 Oct 2014 09:42:01 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BFC1A1A37 for ; Wed, 1 Oct 2014 09:42:01 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-02v.sys.comcast.net with comcast id xsgs1o0044s37d401si1oP; Wed, 01 Oct 2014 16:42:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-01v.sys.comcast.net with comcast id xshy1o00a3Ge9ey01shzgM; Wed, 01 Oct 2014 16:41:59 +0000 Message-ID: <542C2ED6.50308@alum.mit.edu> Date: Wed, 01 Oct 2014 12:41:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hutton, Andrew" , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" References: <54223161.8030106@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF1E5B1BE6@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E5B37CC@MCHP04MSX.global-ad.net> <542C263E.6020507@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF1E5B394E@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E5B394E@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412181721; bh=MXaf8Oowa0j8K9ixiMTIErKbgL0/dqMJOsZMmPpA3Us=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BcJBPuJ+5uqjKwcz3IYPBR9KPRJOBe+43ysgfXYlcAY5oCo3J+a1iIjouT4ndBiIB qb8rWsQfrxv0gW7W+mOvCj3GzSe+BxsaHcD17bd17wOhnv6FYgygwW4yUg0BP3cazD 1pWCalDSKS8qtxteVK9zJ+9tYR+ijSnmjxMJHTL5zNda9CkAbKksKzZWHDgwCc1pBS FfFI8xEvfI775AjuV/DghCL8d5lCJog94ydl4JLtCYVoshF8+Hs8TxColL2tKkpldb 8JY/MvwQlHPKA4YffT9/kyq5kgcEMGCCjir6JIjPTsbTdTVJZ6A0C1/wRPySL3hVTg Mi2ggmEHpHL0A== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/G0MvCL27McPKts2FKGLyFOCf-gs Subject: Re: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 16:42:03 -0000 On 10/1/14 12:24 PM, Hutton, Andrew wrote: > No we are not calling WGLC on anything at this time. Then can you clarify what you are asking for? Thanks, Paul > The protocol draft is already past WGLC. > > Andy > > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 01 October 2014 17:05 >> To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org >> Subject: Re: [siprec] IETF91 SIPREC Meeting >> >> On 10/1/14 11:38 AM, Hutton, Andrew wrote: >>> We need to identify some individuals willing to put some time in to >> reviewing these drafts. >>> >>> The chairs will look for people to do this but if anybody is willing >> to do this please let us know. >> >> Are you issuing WGLC and trying to identify people for it? >> >> I guess it doesn't make sense for me to review the metadata draft. :-) >> >> I've been reviewing the protocol all along. But I will volunteer to do >> it from a WGLC perspective, once WGLC is called. >> >> Thanks, >> Paul >> >>> Regards >>> Andy >>> >>>> -----Original Message----- >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>> Sent: 30 September 2014 13:04 >>>> To: Hutton, Andrew; Paul Kyzivat; siprec@ietf.org >>>> Subject: Re: [siprec] IETF91 SIPREC Meeting >>>> >>>> Hi Andy, >>>> >>>> Overall it Sounds a good plan. If possible we can start the WGLC for >>>> metadata in parallel while we get feedback for protocol draft from >> IESG >>>> unless we expect some changes in metadata as a result of IESG review >> of >>>> protocol draft. We can keep the WGLC for metadata draft open till we >>>> finish the protocol draft. In that way we would give the WG >> sufficient >>>> time to review and give any LC feedback they have on the metadata >>>> draft. >>>> >>>> Regards, >>>> Ram >>>> >>>> -----Original Message----- >>>> From: , Andrew >>>> Date: Tuesday, 30 September 2014 4:10 pm >>>> To: Cisco Employee , Paul Kyzivat >>>> , "siprec@ietf.org" >>>> Subject: RE: [siprec] IETF91 SIPREC Meeting >>>> >>>>> The meeting time should be used to discuss open issues with the >>>> documents >>>>> that have not been resolved on the list. >>>>> >>>>> The protocol document should be going to the IESG shortly hopefully >>>> Brian >>>>> is working on the write-up. >>>>> >>>>> Regarding the metadata and call flows then there has been no >>>> discussion >>>>> on these for some time and my thinking is that these will move >> forward >>>>> once we have made some progress with the protocol draft which is >> the >>>> main >>>>> SIPREC spec. >>>>> >>>>> Alissa informs me that we are likely to get lots of IESG feedback >> on >>>> the >>>>> protocol draft so my thinking is that we should get this feedback >>>> before >>>>> progressing the other drafts. >>>>> >>>>> Does that sound like a plan? >>>>> >>>>> I have a meeting with Brian and Alissa coming up so will discuss it >>>> again >>>>> with them. >>>>> >>>>> Regards >>>>> Andy (SIPREC Co-Chair). >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Ram >> Mohan >>>> R >>>>>> (rmohanr) >>>>>> Sent: 24 September 2014 17:10 >>>>>> To: Paul Kyzivat; siprec@ietf.org >>>>>> Subject: Re: [siprec] IETF91 SIPREC Meeting >>>>>> >>>>>> +1 >>>>>> >>>>>> I also second Paul. Can we please get some attention on the base >>>> drafts >>>>>> (protocol, metadata, call flows) and try to finish them at this >>>> meeting >>>>>> ? >>>>>> >>>>>> Ram >>>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat >>>>>> Date: Wednesday, 24 September 2014 8:20 am >>>>>> To: "siprec@ietf.org" >>>>>> Subject: Re: [siprec] IETF91 SIPREC Meeting >>>>>> >>>>>>> Can we please try to *finish* the base siprec drafts before or at >>>> this >>>>>>> meeting??? >>>>>>> >>>>>>> On 9/22/14 5:08 PM, Charles Eckel (eckelcu) wrote: >>>>>>>> Hi Andy, >>>>>>>> >>>>>>>> I posted an update to the protocol draft 4 weeks ago. >>>>>>>> http://www.ietf.org/mail- >> archive/web/siprec/current/msg03997.html >>>>>>>> >>>>>>>> I believe this version addresses all comments and issues; >>>> however, >>>>>> there >>>>>>>> has not been confirmation by reviewers yet. If the chairs think >>>> it >>>>>> would >>>>>>>> be helpful, I can present the latest changes at IETF 91 >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Charles >>>>>>>> >>>>>>>> From: , Andrew >>>>>>> > >>>>>>>> Date: Friday, September 19, 2014 at 1:13 AM >>>>>>>> To: "siprec@ietf.org " >>>>>>> > >>>>>>>> Subject: [siprec] IETF91 SIPREC Meeting >>>>>>>> >>>>>>>> Hi All, >>>>>>>> The deadline for requesting an IETF91 meeting slot is next >>>> week >>>>>>>> (26^th of Sept). >>>>>>>> Please let the chairs know if you believe a SIPREC meeting >> at >>>>>> IETF91 >>>>>>>> is needed and why and whether you have anything to present. >>>>>>>> Given that there has no list discussion I am thinking that >>>> maybe >>>>>>>> there is no need for a SIPREC meeting this time. >>>>>>>> Regards >>>>>>>> Andy (SIPREC Co-Chair). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 nobody Wed Oct 1 09:49:11 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23561A1A9D for ; Wed, 1 Oct 2014 09:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVYG25gOcNF5 for ; Wed, 1 Oct 2014 09:49:08 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id AB3271A1A6D for ; Wed, 1 Oct 2014 09:49:07 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 1F4DF23F0467; Wed, 1 Oct 2014 18:49:07 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 1 Oct 2014 18:49:06 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Thread-Topic: [siprec] IETF91 SIPREC Meeting Thread-Index: AQHP2BH626Sy94gZRGe/WNqN1yRzT5wZgcwA///5zQCAAe+HwP//5jIAgAAmrdD//+ORAAAEN5NQ Date: Wed, 1 Oct 2014 16:49:06 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5B39F5@MCHP04MSX.global-ad.net> References: <54223161.8030106@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF1E5B1BE6@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E5B37CC@MCHP04MSX.global-ad.net> <542C263E.6020507@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF1E5B394E@MCHP04MSX.global-ad.net> <542C2ED6.50308@alum.mit.edu> In-Reply-To: <542C2ED6.50308@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/oeK5OjK1k8Tc6dpkyQrfy2pcDT0 Subject: Re: [siprec] IETF91 SIPREC Meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 16:49:10 -0000 Sorry if I caused confusion. All I was saying is that we should look for some more reviewers for the met= adata and call flows. I know Brian is looking at the NG911 community as a possible source but if = there are other volunteers then would be good if they could come forward. Regards Andy > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 01 October 2014 17:42 > To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] IETF91 SIPREC Meeting >=20 > On 10/1/14 12:24 PM, Hutton, Andrew wrote: > > No we are not calling WGLC on anything at this time. >=20 > Then can you clarify what you are asking for? >=20 > Thanks, > Paul >=20 > > The protocol draft is already past WGLC. > > > > Andy > > > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: 01 October 2014 17:05 > >> To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org > >> Subject: Re: [siprec] IETF91 SIPREC Meeting > >> > >> On 10/1/14 11:38 AM, Hutton, Andrew wrote: > >>> We need to identify some individuals willing to put some time in to > >> reviewing these drafts. > >>> > >>> The chairs will look for people to do this but if anybody is > willing > >> to do this please let us know. > >> > >> Are you issuing WGLC and trying to identify people for it? > >> > >> I guess it doesn't make sense for me to review the metadata draft. > :-) > >> > >> I've been reviewing the protocol all along. But I will volunteer to > do > >> it from a WGLC perspective, once WGLC is called. > >> > >> Thanks, > >> Paul > >> > >>> Regards > >>> Andy > >>> > >>>> -----Original Message----- > >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>> Sent: 30 September 2014 13:04 > >>>> To: Hutton, Andrew; Paul Kyzivat; siprec@ietf.org > >>>> Subject: Re: [siprec] IETF91 SIPREC Meeting > >>>> > >>>> Hi Andy, > >>>> > >>>> Overall it Sounds a good plan. If possible we can start the WGLC > for > >>>> metadata in parallel while we get feedback for protocol draft from > >> IESG > >>>> unless we expect some changes in metadata as a result of IESG > review > >> of > >>>> protocol draft. We can keep the WGLC for metadata draft open till > we > >>>> finish the protocol draft. In that way we would give the WG > >> sufficient > >>>> time to review and give any LC feedback they have on the metadata > >>>> draft. > >>>> > >>>> Regards, > >>>> Ram > >>>> > >>>> -----Original Message----- > >>>> From: , Andrew > >>>> Date: Tuesday, 30 September 2014 4:10 pm > >>>> To: Cisco Employee , Paul Kyzivat > >>>> , "siprec@ietf.org" > >>>> Subject: RE: [siprec] IETF91 SIPREC Meeting > >>>> > >>>>> The meeting time should be used to discuss open issues with the > >>>> documents > >>>>> that have not been resolved on the list. > >>>>> > >>>>> The protocol document should be going to the IESG shortly > hopefully > >>>> Brian > >>>>> is working on the write-up. > >>>>> > >>>>> Regarding the metadata and call flows then there has been no > >>>> discussion > >>>>> on these for some time and my thinking is that these will move > >> forward > >>>>> once we have made some progress with the protocol draft which is > >> the > >>>> main > >>>>> SIPREC spec. > >>>>> > >>>>> Alissa informs me that we are likely to get lots of IESG feedback > >> on > >>>> the > >>>>> protocol draft so my thinking is that we should get this feedback > >>>> before > >>>>> progressing the other drafts. > >>>>> > >>>>> Does that sound like a plan? > >>>>> > >>>>> I have a meeting with Brian and Alissa coming up so will discuss > it > >>>> again > >>>>> with them. > >>>>> > >>>>> Regards > >>>>> Andy (SIPREC Co-Chair). > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Ram > >> Mohan > >>>> R > >>>>>> (rmohanr) > >>>>>> Sent: 24 September 2014 17:10 > >>>>>> To: Paul Kyzivat; siprec@ietf.org > >>>>>> Subject: Re: [siprec] IETF91 SIPREC Meeting > >>>>>> > >>>>>> +1 > >>>>>> > >>>>>> I also second Paul. Can we please get some attention on the base > >>>> drafts > >>>>>> (protocol, metadata, call flows) and try to finish them at this > >>>> meeting > >>>>>> ? > >>>>>> > >>>>>> Ram > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Paul Kyzivat > >>>>>> Date: Wednesday, 24 September 2014 8:20 am > >>>>>> To: "siprec@ietf.org" > >>>>>> Subject: Re: [siprec] IETF91 SIPREC Meeting > >>>>>> > >>>>>>> Can we please try to *finish* the base siprec drafts before or > at > >>>> this > >>>>>>> meeting??? > >>>>>>> > >>>>>>> On 9/22/14 5:08 PM, Charles Eckel (eckelcu) wrote: > >>>>>>>> Hi Andy, > >>>>>>>> > >>>>>>>> I posted an update to the protocol draft 4 weeks ago. > >>>>>>>> http://www.ietf.org/mail- > >> archive/web/siprec/current/msg03997.html > >>>>>>>> > >>>>>>>> I believe this version addresses all comments and issues; > >>>> however, > >>>>>> there > >>>>>>>> has not been confirmation by reviewers yet. If the chairs > think > >>>> it > >>>>>> would > >>>>>>>> be helpful, I can present the latest changes at IETF 91 > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Charles > >>>>>>>> > >>>>>>>> From: , Andrew >>>>>>>> > > >>>>>>>> Date: Friday, September 19, 2014 at 1:13 AM > >>>>>>>> To: "siprec@ietf.org " > >>>>>>>> > > >>>>>>>> Subject: [siprec] IETF91 SIPREC Meeting > >>>>>>>> > >>>>>>>> Hi All, > >>>>>>>> The deadline for requesting an IETF91 meeting slot is > next > >>>> week > >>>>>>>> (26^th of Sept). > >>>>>>>> Please let the chairs know if you believe a SIPREC > meeting > >> at > >>>>>> IETF91 > >>>>>>>> is needed and why and whether you have anything to > present. > >>>>>>>> Given that there has no list discussion I am thinking > that > >>>> maybe > >>>>>>>> there is no need for a SIPREC meeting this time. > >>>>>>>> Regards > >>>>>>>> Andy (SIPREC Co-Chair). > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 nobody Wed Oct 1 10:32:24 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD7D1A1A7D for ; Wed, 1 Oct 2014 10:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUPJifhxVAWQ for ; Wed, 1 Oct 2014 10:32:21 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B703B1A1A77 for ; Wed, 1 Oct 2014 10:32:20 -0700 (PDT) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-01v.sys.comcast.net with comcast id xtY81o0074yXVJQ01tYLJJ; Wed, 01 Oct 2014 17:32:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-06v.sys.comcast.net with comcast id xtYJ1o00E3Ge9ey01tYKwF; Wed, 01 Oct 2014 17:32:19 +0000 Message-ID: <542C3AA2.5090006@alum.mit.edu> Date: Wed, 01 Oct 2014 13:32:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Georgescu References: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> <541EF4B8.7080603@alum.mit.edu> <541EFAF3.5000904@alum.mit.edu> <4B74C2B7-D38B-43A4-8847-AAA35065208F@ag-projects.com> <54259A33.5010503@alum.mit.edu> <964D4991-FB40-4393-A433-E7230555BD76@ag-projects.com> <5426F322.3060407@alum.mit.edu> <40C7B392-22C2-46CB-BA34-8FC5A519F9BF@ag-projects.com> In-Reply-To: <40C7B392-22C2-46CB-BA34-8FC5A519F9BF@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412184740; bh=D3IpqEbi/+6cGsR4NZYi1VLMk5ST35fhSXl2k7aV6Nw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jeLf8RpsdMB+wZ57jC1orkp+wqgwywj2D+kb5yZLJSnzE9Rzbx9iNSQtshjL7ne1m 4lp7OpQ0dnpqbXnMi7/qinSmmLwIWYvyItm8hUiKh2n+XtZN27rpOjaPJ4R6n2NJ9H jzJ3WckyCib9hw9UkyxRndI2IQq/ciQDWA6ef6wjVZIngKtv7jZ+lnBildKWDqcIJk jAGUvG0puG4hLZcZQl8xkG+X5QxyQDlhYQ3N9jpQLGC1/PBu9VX4aukF3n/lgUtgPr ndN9Il2n5Oxc6nmQMQ0ywjddMgKhTq46mlZ4fHx+jxkMwu+rEtUjcSAFX51DwghdHC KDoCDj+4npLoA== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/G3FzuXbsHawP9aY8hAFTP_5rkCg Cc: siprec@ietf.org Subject: Re: [siprec] Declaring desired MSRP recording status within MSRP X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 17:32:22 -0000 Adrian, I am inclined to view the mechanism you describe below as *another* way to indicate desires regarding recording. The SRC is free to honor such mechanism if it wishes. But I see no reason to forbid the media-neutral mechanism that is already defined by siprec. Even if we didn't mention your mechanism at all, it would still be ok for an SRC to honor it. I guess the main issue here is whether that mechanism should be mentioned in the msrp recording draft. Is that mechanism formally specified anywhere than can be referenced by an ietf draft? Or would we need to take on the job of standardizing it? Thanks, Paul On 9/27/14 1:53 PM, Adrian Georgescu wrote: > > On 27 Sep 2014, at 14:25, Paul Kyzivat > wrote: > >> On 9/27/14 7:39 AM, Adrian Georgescu wrote: >>> >>> On 26 Sep 2014, at 13:54, Paul Kyzivat >> >>> > wrote: >> >>>>>> Are you familiar with the base siprec drafts? (Particularly >>>>>> draft-ietf-siprec-protocol-14.) There is a mechanism (a=recordpref) to >>>>>> indicate a preference for recording, or for *not* recording. It >>>>>> applies to audio and video, and with the msrp-recording draft it will >>>>>> apply also to that. >>>>> >>>>> This requires a re-INVITE, which may fail later in the middle of the >>>>> session, or be out of sync with media plane, while the media continues >>>>> to flow. It is a bad strategy as signalling and data are disconnected. >>>> >>>> Well, this is what was mandated for audio and video. For those, AFAIK >>>> there is no way to carry the signaling for this in the media. >>> >>> MSRP is different as each message can carry by design any type of media >>> described by its content-type inside the CPIM envelope. >>> >>>> >>>>> So mandating to use SIP packet that may get lost to control MSRP chat >>>>> messages in progress, is not gonna work properly. I want to know >>>>> deterministically that my next MSRP message is not going to be stored >>>>> (or fail to send at all), regardless of the SIP signalling or other >>>>> middle box protocols that helped setup the MSRP media in the first >>>>> place. >>>> >>>> With the current siprec mechanism, the do-not-record indication on the >>>> CS is a *request* from a UA to the SRC. The SRC doesn't have to honor >>>> it. However it is required to signal its actual >>>> recording/not-recording state. So the requesting UA can decide not to >>>> transmit sensitive information (or terminate the session) if it >>>> doesn't get an indication that recording has stopped. And similarly if >>>> the re-INVITE fails. >>> >>> For RTP sounds reasonable. For MSRP however is not ideal as it is much >>> safer and reliable to send a MSRP message for which there is end-to-end >>> integrity, sequencing and delivery reporting capability. >> >>>> So how do you do this? Have you defined an MSRP or CPIM extension? Or >>>> have you defined a special MIME type for a body that communicates this? >>> >>> I just send a CPIM message like these: >>> >>> content_type='application/history-on' >>> >>> or >>> >>> content_type='application/history-off' >>> >>> The support for this feature is negotiated in the SDP of the MSRP media >>> block, e.g.: >>> >>> Offer: >>> >>> o=- 3620806345 3620806345 IN IP4 192.168.8.3 >>> s=Blink 4.7.4 (MacOSX) >>> m=message 2855 TCP/TLS/MSRP * >>> c=IN IP4 192.168.8.3 >>> a=path:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp >>> a=accept-types:message/cpim text/* application/im-iscomposing+xml >>> a=accept-wrapped-types:* >>> a=setup:active >>> a=features:history-control icon >>> >>> Answer: >>> >>> o=- 3620806346 3620806347 IN IP4 10.0.0.139 >>> s=SylkServer-2.6.0 >>> c=IN IP4 10.0.0.139 >>> m=message 51634 TCP/TLS/MSRP * >>> a=path:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp >>> a=accept-types:message/cpim >>> a=accept-wrapped-types:* >>> a=setup:passive >>> a=chatroom:nickname private-messages com.ag-projects.screen-sharing >> >> IIUC, a message with content type of application/history-off would not >> be valid within the MSRP session negotiated above. (Unless it was sent >> within a CPIM wrapper.) > > It is within the CPIM. > > >> Ignoring that, what are the semantics? Are you sending an *empty* >> message with this content type, to set a mode? Or is this the type of >> a message containing a body that is to be displayed but not added to >> the history? > > It asks the remote party to toggle its save to history on or off. Is a > switch that can be toggled remotely (if the recipient want to honour it). > > >> >> If the latter, then how do you know the actual type of the content? >> >> How normative is this? Is it advisory to the recipient? Or binding? >> Doe it need to be acknowledged? > > It is advisory as there is no way for force the other recipient to > comply with such directive. You cannot control what a remote party will > really save in its history database, is a gentlemen's agreement. > >> >> Thanks, >> Paul >> > > -- > Adrian > > > From nobody Wed Oct 1 13:19:08 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EF91A700B for ; Wed, 1 Oct 2014 13:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.512 X-Spam-Level: X-Spam-Status: No, score=0.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb0SNIk_PMjC for ; Wed, 1 Oct 2014 13:19:05 -0700 (PDT) Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 92D8D1A700C for ; Wed, 1 Oct 2014 13:19:04 -0700 (PDT) Received: from [10.3.0.172] (unknown [201.140.212.131]) by mail.sipthor.net (Postfix) with ESMTPSA id AC82B14AC001; Wed, 1 Oct 2014 22:18:49 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_4166F65D-87B8-4892-9DCA-0B6F0E511E16"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Adrian Georgescu In-Reply-To: <542C3AA2.5090006@alum.mit.edu> Date: Wed, 1 Oct 2014 17:18:42 -0300 Message-Id: References: <0C8E832C-0B48-43ED-9235-B5D1925E4569@ag-projects.com> <541EF4B8.7080603@alum.mit.edu> <541EFAF3.5000904@alum.mit.edu> <4B74C2B7-D38B-43A4-8847-AAA35065208F@ag-projects.com> <54259A33.5010503@alum.mit.edu> <964D4991-FB40-4393-A433-E7230555BD76@ag-projects.com> <5426F322.3060407@alum.mit.edu> <40C7B392-22C2-46CB-BA34-8FC5A519F9BF@ag-projects.com> <542C3AA2.5090006@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/o6Unr3YB0_MNOVTvXgiSuN3mjYE Cc: siprec@ietf.org Subject: Re: [siprec] Declaring desired MSRP recording status within MSRP X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 20:19:07 -0000 --Apple-Mail=_4166F65D-87B8-4892-9DCA-0B6F0E511E16 Content-Type: multipart/alternative; boundary="Apple-Mail=_142CCBC8-3296-406B-9CE0-3E990FC81C11" --Apple-Mail=_142CCBC8-3296-406B-9CE0-3E990FC81C11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 01 Oct 2014, at 14:32, Paul Kyzivat wrote: > Adrian, >=20 > I am inclined to view the mechanism you describe below as *another* = way to indicate desires regarding recording. The SRC is free to honor = such mechanism if it wishes. >=20 > But I see no reason to forbid the media-neutral mechanism that is = already defined by siprec. > Even if we didn't mention your mechanism at all, it would still be ok = for an SRC to honor it. I guess the main issue here is whether that = mechanism should be mentioned in the msrp recording draft. >=20 > Is that mechanism formally specified anywhere than can be referenced = by an ietf draft? Not that I know of. > Or would we need to take on the job of standardizing it? I believe that this would be a great addition to MSRP specs! Adrian >=20 > Thanks, > Paul >=20 > On 9/27/14 1:53 PM, Adrian Georgescu wrote: >>=20 >> On 27 Sep 2014, at 14:25, Paul Kyzivat > > wrote: >>=20 >>> On 9/27/14 7:39 AM, Adrian Georgescu wrote: >>>>=20 >>>> On 26 Sep 2014, at 13:54, Paul Kyzivat >>> >>>> > wrote: >>>=20 >>>>>>> Are you familiar with the base siprec drafts? (Particularly >>>>>>> draft-ietf-siprec-protocol-14.) There is a mechanism = (a=3Drecordpref) to >>>>>>> indicate a preference for recording, or for *not* recording. It >>>>>>> applies to audio and video, and with the msrp-recording draft it = will >>>>>>> apply also to that. >>>>>>=20 >>>>>> This requires a re-INVITE, which may fail later in the middle of = the >>>>>> session, or be out of sync with media plane, while the media = continues >>>>>> to flow. It is a bad strategy as signalling and data are = disconnected. >>>>>=20 >>>>> Well, this is what was mandated for audio and video. For those, = AFAIK >>>>> there is no way to carry the signaling for this in the media. >>>>=20 >>>> MSRP is different as each message can carry by design any type of = media >>>> described by its content-type inside the CPIM envelope. >>>>=20 >>>>>=20 >>>>>> So mandating to use SIP packet that may get lost to control MSRP = chat >>>>>> messages in progress, is not gonna work properly. I want to know >>>>>> deterministically that my next MSRP message is not going to be = stored >>>>>> (or fail to send at all), regardless of the SIP signalling or = other >>>>>> middle box protocols that helped setup the MSRP media in the = first >>>>>> place. >>>>>=20 >>>>> With the current siprec mechanism, the do-not-record indication on = the >>>>> CS is a *request* from a UA to the SRC. The SRC doesn't have to = honor >>>>> it. However it is required to signal its actual >>>>> recording/not-recording state. So the requesting UA can decide not = to >>>>> transmit sensitive information (or terminate the session) if it >>>>> doesn't get an indication that recording has stopped. And = similarly if >>>>> the re-INVITE fails. >>>>=20 >>>> For RTP sounds reasonable. For MSRP however is not ideal as it is = much >>>> safer and reliable to send a MSRP message for which there is = end-to-end >>>> integrity, sequencing and delivery reporting capability. >>>=20 >>>>> So how do you do this? Have you defined an MSRP or CPIM extension? = Or >>>>> have you defined a special MIME type for a body that communicates = this? >>>>=20 >>>> I just send a CPIM message like these: >>>>=20 >>>> content_type=3D'application/history-on' >>>>=20 >>>> or >>>>=20 >>>> content_type=3D'application/history-off' >>>>=20 >>>> The support for this feature is negotiated in the SDP of the MSRP = media >>>> block, e.g.: >>>>=20 >>>> Offer: >>>>=20 >>>> o=3D- 3620806345 3620806345 IN IP4 192.168.8.3 >>>> s=3DBlink 4.7.4 (MacOSX) >>>> m=3Dmessage 2855 TCP/TLS/MSRP * >>>> c=3DIN IP4 192.168.8.3 >>>> a=3Dpath:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp >>>> a=3Daccept-types:message/cpim text/* application/im-iscomposing+xml >>>> a=3Daccept-wrapped-types:* >>>> a=3Dsetup:active >>>> a=3Dfeatures:history-control icon >>>>=20 >>>> Answer: >>>>=20 >>>> o=3D- 3620806346 3620806347 IN IP4 10.0.0.139 >>>> s=3DSylkServer-2.6.0 >>>> c=3DIN IP4 10.0.0.139 >>>> m=3Dmessage 51634 TCP/TLS/MSRP * >>>> a=3Dpath:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp >>>> a=3Daccept-types:message/cpim >>>> a=3Daccept-wrapped-types:* >>>> a=3Dsetup:passive >>>> a=3Dchatroom:nickname private-messages = com.ag-projects.screen-sharing >>>=20 >>> IIUC, a message with content type of application/history-off would = not >>> be valid within the MSRP session negotiated above. (Unless it was = sent >>> within a CPIM wrapper.) >>=20 >> It is within the CPIM. >>=20 >>=20 >>> Ignoring that, what are the semantics? Are you sending an *empty* >>> message with this content type, to set a mode? Or is this the type = of >>> a message containing a body that is to be displayed but not added to >>> the history? >>=20 >> It asks the remote party to toggle its save to history on or off. Is = a >> switch that can be toggled remotely (if the recipient want to honour = it). >>=20 >>=20 >>>=20 >>> If the latter, then how do you know the actual type of the content? >>>=20 >>> How normative is this? Is it advisory to the recipient? Or binding? >>> Doe it need to be acknowledged? >>=20 >> It is advisory as there is no way for force the other recipient to >> comply with such directive. You cannot control what a remote party = will >> really save in its history database, is a gentlemen's agreement. >>=20 >>>=20 >>> Thanks, >>> Paul >>>=20 >>=20 >> -- >> Adrian >>=20 >>=20 >>=20 >=20 -- Adrian --Apple-Mail=_142CCBC8-3296-406B-9CE0-3E990FC81C11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 01 Oct 2014, at 14:32, Paul Kyzivat = <pkyzivat@alum.mit.edu>= wrote:

Adrian,

I am inclined to view the mechanism you = describe below as *another* way to indicate desires regarding recording. = The SRC is free to honor such mechanism if it wishes.

But I see = no reason to forbid the media-neutral mechanism that is already defined = by siprec.

Even if we didn't mention your mechanism at all, it would = still be ok for an SRC to honor it. I guess the main issue here is = whether that mechanism should be mentioned in the msrp recording = draft.

Is that mechanism formally specified anywhere than can be = referenced by an ietf draft?

Not that I know = of.

Or would we need to take on = the job of standardizing it?

I = believe that this would be a great addition to MSRP = specs!

Adrian



Thanks,
= Paul

On 9/27/14 1:53 PM, Adrian Georgescu = wrote:

On 27 Sep 2014, at 14:25, Paul = Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzivat@alum.mit.edu>= > wrote:

On 9/27/14 7:39 AM, Adrian = Georgescu wrote:

On 26 Sep 2014, at = 13:54, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzivat@alum.mit.edu>=
<mailto:pkyzivat@alum.mit.edu>= > wrote:

Are = you familiar with the base siprec drafts? = (Particularly
draft-ietf-siprec-protocol-14.) There is a mechanism = (a=3Drecordpref) to
indicate a preference for recording, or for *not* = recording. It
applies to audio and video, and with the msrp-recording = draft it will
apply also to that.

This requires a = re-INVITE, which may fail later in the middle of the
session, or be = out of sync with media plane, while the media continues
to flow. It = is a bad strategy as signalling and data are = disconnected.

Well, this is what was mandated for = audio and video. For those, AFAIK
there is no way to carry the = signaling for this in the media.

MSRP is different = as each message can carry by design any type of media
described by = its content-type inside the CPIM envelope.


So mandating to use SIP = packet that may get lost to control MSRP chat
messages in progress, = is not gonna work properly. I want to know
deterministically that my = next MSRP message is not going to be stored
(or fail to send at all), = regardless of the SIP signalling or other
middle box protocols that = helped setup the MSRP media in the = first
place.

With the current siprec mechanism, = the do-not-record indication on the
CS is a *request* from a UA to = the SRC. The SRC doesn't have to honor
it. However it is required to = signal its actual
recording/not-recording state. So the requesting UA = can decide not to
transmit sensitive information (or terminate the = session) if it
doesn't get an indication that recording has stopped. = And similarly if
the re-INVITE fails.

For RTP = sounds reasonable. For MSRP however is not ideal as it is much
safer = and reliable to send a MSRP message for which there is = end-to-end
integrity, sequencing and delivery reporting = capability.

So how do you do this? Have you defined an MSRP or CPIM = extension? Or
have you defined a special MIME type for a body that = communicates this?

I just send a CPIM message like = these:

content_type=3D'application/history-on'

or

con= tent_type=3D'application/history-off'

The support for this = feature is negotiated in the SDP of the MSRP media
block, = e.g.:

Offer:

o=3D- 3620806345 3620806345 IN IP4 = 192.168.8.3
s=3DBlink 4.7.4 (MacOSX)
m=3Dmessage 2855 TCP/TLS/MSRP = *
c=3DIN IP4 = 192.168.8.3
a=3Dpath:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp<= br>a=3Daccept-types:message/cpim text/* = application/im-iscomposing+xml
a=3Daccept-wrapped-types:*
a=3Dsetup:= active
a=3Dfeatures:history-control icon

Answer:

o=3D- = 3620806346 3620806347 IN IP4 10.0.0.139
s=3DSylkServer-2.6.0
c=3DIN = IP4 10.0.0.139
m=3Dmessage 51634 TCP/TLS/MSRP = *
a=3Dpath:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp
a=3D= accept-types:message/cpim
a=3Daccept-wrapped-types:*
a=3Dsetup:passi= ve
a=3Dchatroom:nickname private-messages = com.ag-projects.screen-sharing

IIUC, a message with = content type of application/history-off would not
be valid within the = MSRP session negotiated above. (Unless it was sent
within a CPIM = wrapper.)

It is within the = CPIM.


Ignoring that, what are the = semantics? Are you sending an *empty*
message with this content type, = to set a mode? Or is this the type of
a message containing a body = that is to be displayed but not added to
the = history?

It asks the remote party to toggle its save = to history on or off. Is a
switch that can be toggled remotely (if = the recipient want to honour it).



If the latter, then how do you know the actual type of = the content?

How normative is this? Is it advisory to the = recipient? Or binding?
Doe it need to be = acknowledged?

It is advisory as there is no way for = force the other recipient to
comply with such directive. You cannot = control what a remote party will
really save in its history database, = is a gentlemen's agreement.


Thanks,
Paul


--
Adrian
=




; Wed, 8 Oct 2014 06:45:01 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.227]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 01:45:01 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: Carrying Session-ID in SIPREC metadata Thread-Index: AQHP4sNh+Iv+qTLBVkCUQtBsPS75Cg== Date: Wed, 8 Oct 2014 06:45:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [173.39.65.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <3A6D7EE179A2914A856F88292BD88287@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/R18LKDyTzqXELehzAZLqJHb2TkM Subject: [siprec] Carrying Session-ID in SIPREC metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 06:45:03 -0000 We had discussed this in the past (see this archive email - http://www.ietf.org/mail-archive/web/insipid/current/msg00285.html) however at that time since INSIPID WG and Session-ID document was in early stage we deferred including Session-ID in the metadata. Now that Session-ID is a mature document I believe it is good to include the same in the Metadata XML as part of CS. My initial thought is to include it as a element of CS. Let me know your thoughts ? Regards, Ram From nobody Tue Oct 7 23:48:54 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF75F1A0067 for ; Tue, 7 Oct 2014 23:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZS9-HcvOrRI for ; Tue, 7 Oct 2014 23:48:52 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891F21A004B for ; Tue, 7 Oct 2014 23:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=918; q=dns/txt; s=iport; t=1412750932; x=1413960532; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dSVZgOZcYR7AUlS2CC4O7qBcIHKfl5glBJCaJ8d/Wt0=; b=Rn5HTcWsPt2rxl9yv2bkXkT4CKqXNYK9i5VvtBniYOw8FzjtWPEY1Iah ZhmfLY3zTH8uFVdCA6Rb6rS/11S2UYT1kGEhexqhCUF1im3JAIQXPNaMt +ef8rVrbbkdgLxXaRLo0abxB2bAoAK7w6pW2xksNeO9Z/gZ8JrkVuVw40 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAPHdNFStJV2b/2dsb2JhbABfgw5TTQsEyxAKhnlUAoEGFgF7hAQBAQMBAQEBNzQGBQULAgEINhAnCyUCBA4FCYgtCA3CAwEXj2IQAgEcMwIFgy2BHgWRd4tNgS2NSYMVg3+DY2wBgUeBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,675,1406592000"; d="scan'208";a="361627947" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 08 Oct 2014 06:48:49 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s986mm51028154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Oct 2014 06:48:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.78]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 01:48:48 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Ram Mohan R (rmohanr)" Thread-Topic: [siprec] Carrying Session-ID in SIPREC metadata Thread-Index: AQHP4sNh+Iv+qTLBVkCUQtBsPS75CpwmFhyA Date: Wed, 8 Oct 2014 06:48:47 +0000 Message-ID: <14B37702-7E5A-431E-B4A7-7DAA2DE8A233@cisco.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.82.237.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/phrKEtLkNE-sKpGIm8yDRFO_q5I Cc: "siprec@ietf.org" Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 06:48:54 -0000 Hi Ram -=20 On Oct 8, 2014, at 2:45 AM, Ram Mohan R (rmohanr) wrote= : > We had discussed this in the past (see this archive email - > http://www.ietf.org/mail-archive/web/insipid/current/msg00285.html) > however at that time since INSIPID WG and Session-ID document was in earl= y > stage we deferred including Session-ID in the metadata. Now that > Session-ID is a mature document I believe it is good to include the same > in the Metadata XML as part of CS. I also believe it would be a very good thing. =20 FYI - Chair status update: we are preparing to WGLC that document. Cheers, Gonzalo >=20 > My initial thought is to include it as a element of CS. >=20 > Let me know your thoughts ? >=20 > Regards, > Ram >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From nobody Wed Oct 8 09:27:34 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77F91A88AC for ; Wed, 8 Oct 2014 09:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGJzv7k6fhwK for ; Wed, 8 Oct 2014 09:27:31 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A370C1A6FBF for ; Wed, 8 Oct 2014 09:27:31 -0700 (PDT) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-06v.sys.comcast.net with comcast id 0gSR1p0025Geu2801gTX7u; Wed, 08 Oct 2014 16:27:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-20v.sys.comcast.net with comcast id 0gTW1p0023Ge9ey01gTWlV; Wed, 08 Oct 2014 16:27:30 +0000 Message-ID: <543565F1.30903@alum.mit.edu> Date: Wed, 08 Oct 2014 12:27:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412785651; bh=wrjjfFQtdhN7fiuYRpUC11IUAro1DA7aihvyvDooiIA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hzhFAmCJ2weTUuJr2Q4BrVPWIJaGtJG8KIzcyFWPBs0e54ubDm/uwldrGoI+ITJdg C5jdEBCle569Va0tis51uabJemnJnf+Zd496Z/JHegxyP0Md4dCSkdIu2vyFu2Ang5 fMcdUvf45429nRPKCztdOdElRQJ/v6R32RFjwxwoVh8UqjJi4E8E0jgvYca3n29QTf Rftv/0ACLch9cObrGNca1RlFphct+mKABMZwad+iPPJ2UdvLRp/pWLPLdRmq0YyVFJ yVYL2e2duUhCQ2uULPHc8mtI2bNrkqRvb9jK/kN2gn3iffyECridqaa6AayY4heUnx IC9IiQgWKcQfg== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/ZfGKsqSTCBInIsfBkNG1eHrDbdc Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 16:27:33 -0000 On 10/8/14 2:45 AM, Ram Mohan R (rmohanr) wrote: > We had discussed this in the past (see this archive email - > http://www.ietf.org/mail-archive/web/insipid/current/msg00285.html) > however at that time since INSIPID WG and Session-ID document was in early > stage we deferred including Session-ID in the metadata. Now that > Session-ID is a mature document I believe it is good to include the same > in the Metadata XML as part of CS. > > My initial thought is to include it as a element of CS. > > Let me know your thoughts ? IMO we can't depend on the session id being present, so we can't use it as one of our identifiers. SRCs that want to coordinate, and that know they are in an environment that uses session-id *could* derive their IDs based on the session-id. We wouldn't have to standardize that, but it would only work with SRCs that have an agreement. We could also allow the session-id to be added as an optional element in the metadata. That wouldn't cause two SRCs in the same call to choose the same siprec id for the call, but the SRS could then correlate them. Thanks, Paul From nobody Wed Oct 8 09:43:58 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702A61A9142 for ; Wed, 8 Oct 2014 09:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9JqxeR5joJL for ; Wed, 8 Oct 2014 09:43:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13F31A916A for ; Wed, 8 Oct 2014 09:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2582; q=dns/txt; s=iport; t=1412786635; x=1413996235; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qosZSohDb0+FORThL6ESlk3MknJ4RrixdzOHpuGs76c=; b=XHKz+Lanp31JE9FgbB2/yQ2RNtslkl4iff+1tlEeYjRUqHMyt1YFmSVj CDZ4LqNpxms8jYZxzxVB5+bmoL/ogoBo1Q+QqkEHBEN0H9+aDP+XVmRns Y/WS1W7gMfCiVzpEVjO0gx6Xl928Ijka8BkgIachKKuNYmiLAY3AHCwvy A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAHdoNVStJA2L/2dsb2JhbABfDoMAU1zLAgqGeVQCgQoWAXuEAwEBAQQBAQFkBwYRBAIBCA4DAwECAS4nCx0IAgQBEgmINQ3DUgEXj2IQAgFRBQaERQWLHoZZi06BLoNFgyyJb4N/gyNAbAGBR4ECAQEB X-IronPort-AV: E=Sophos;i="5.04,678,1406592000"; d="scan'208";a="358548257" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP; 08 Oct 2014 16:43:54 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s98Ghrm1030349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Oct 2014 16:43:53 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.227]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 11:43:52 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Carrying Session-ID in SIPREC metadata Thread-Index: AQHP4xcLBFwV1kDEV0GwOgQI9F8TBw== Date: Wed, 8 Oct 2014 16:43:52 +0000 Message-ID: References: <543565F1.30903@alum.mit.edu> In-Reply-To: <543565F1.30903@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.58.171] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/jQXJasrzIkGs6_WGmuE9V6U2Ii4 Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 16:43:56 -0000 Hi Paul, Please see inline -----Original Message----- From: Paul Kyzivat Date: Wednesday, 8 October 2014 9:57 pm To: "siprec@ietf.org" Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata >On 10/8/14 2:45 AM, Ram Mohan R (rmohanr) wrote: >> We had discussed this in the past (see this archive email - >> http://www.ietf.org/mail-archive/web/insipid/current/msg00285.html) >> however at that time since INSIPID WG and Session-ID document was in >>early >> stage we deferred including Session-ID in the metadata. Now that >> Session-ID is a mature document I believe it is good to include the same >> in the Metadata XML as part of CS. >> >> My initial thought is to include it as a element of CS. >> >> Let me know your thoughts ? > >IMO we can't depend on the session id being present, so we can't use it >as one of our identifiers. Yes. Agree. What I am saying if a CS has INSIPID Session_id present and a SRC who is part of that CS happens to read this id, then it can pass it in the metadata to SRS. IMO the SRC need not worry about how the INSIPID session_id is derived. All we need is a carrier(field) to carry the received Session_id to SRS. Note this is independent of the ids we have in the XML. The ids we have will continue to be present. I don=B9t see a need to link. > >SRCs that want to coordinate, and that know they are in an environment >that uses session-id *could* derive their IDs based on the session-id. Well I don=B9t know if we want to say that and create some dependancy. I am open to have that but think it can create confusion as we need to define both the cases (when Session_id present and when it is not). Rather I would think we should leave the current CS Id scope as is. >=20 >We wouldn't have to standardize that, but it would only work with SRCs >that have an agreement. > >We could also allow the session-id to be added as an optional element in >the metadata.=20 Yes that is what I was coming to. We need a field in metadata (possibly a child XML element inside element) that can carry INSIPID session_id of CS ( if present in CS) as is to SRS. An SRS may use it for relating sessions or for whatever it needs. Regards, Ram >That wouldn't cause two SRCs in the same call to choose >the same siprec id for the call, but the SRS could then correlate them. > > Thanks, > Paul > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From nobody Wed Oct 8 09:57:54 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11671ACCF0 for ; Wed, 8 Oct 2014 09:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyCuK92oQHH7 for ; Wed, 8 Oct 2014 09:57:51 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78ABC1ACC8B for ; Wed, 8 Oct 2014 09:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4668; q=dns/txt; s=iport; t=1412787471; x=1413997071; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YmrSBPwNln1inMnKROtCKeZQsIoNnSnrjlPxllchtnM=; b=HKwkQG3jsyfLVuyIrtLygCF0BoKW7SYXlsqumcP3c4sH+0PBTgXc/ugu PxWwCCfGyOqy9gYZrYId9Z0cpP6JNeTSXWyPEs8LUmCT/25t4qEciudZd 4/IKprW6VrOvLyjDQ0c71GSegCOLni2b7K4l22RNXz5G0XtvJ4TJIjGz+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAL1rNVStJV2T/2dsb2JhbABfDoMAU1yDAMgCCoZ5VAIZcRYBe4QDAQEBBAEBATEzBwYRBAIBCA4DAwECAQQoAgIlCx0IAgQBEgmINQ2SIJxFBpRfAReBJo48EAIBVgaCa4FaBZF3hjSFGoEug0WDLIlvg3+DI0BsAYFHgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,678,1406592000"; d="scan'208";a="361620595" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP; 08 Oct 2014 16:57:51 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s98GvoGL010962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Oct 2014 16:57:50 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.227]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 11:57:50 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Carrying Session-ID in SIPREC metadata Thread-Index: AQHP4xj+iTR67vuTJ0WRJyYyOzFzAQ== Date: Wed, 8 Oct 2014 16:57:49 +0000 Message-ID: References: <543565F1.30903@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.58.171] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/3hFZXDIgcwaJTPUTpAxX7oxPpEk Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 16:57:53 -0000 VG8gYWRkIHRvIGJlbG93LCBPbmUgaXNzdWUgSSBzZWUgYnkgbWFwcGluZyBJTlNJUElEIFNlc3Np b25faWQgdG8gQ1MgeG1sDQppZCBpcyAtICB3aGVuIGEgU1JTIHJlY2VpdmVzIG1ldGFkYXRhIGl0 IHdpbGwgbm90IGtub3cgaWYgdGhlIHJlY2VpdmVkIGlkDQppbiBDUyBpcyBJTlNJUElEIHNlc3Np b25faWQgb3IgU1JDIGdlbmVyYXRlZCBVVUlELiBJdCBpcyBpbXBvcnRhbnQgZm9yIFNSUw0KdG8g a25vdyB0aGlzLCBzaW5jZSBJTlNJUElEIHNlc3Npb25faWQgc2NvcGUgaXMgbXVjaCBsYXJnZXIg YW5kIHRoZSBTUlMNCm1heSB3YW50IHRvIHVzZSB0aGF0IFNlc3Npb25faWQgZm9yIHNvbWUgb3Ro ZXIgdGhpbmdzLg0KDQpSYW0NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog Q2lzY28gRW1wbG95ZWUgPHJtb2hhbnJAY2lzY28uY29tPg0KRGF0ZTogV2VkbmVzZGF5LCA4IE9j dG9iZXIgMjAxNCAxMDoxMyBwbQ0KVG86IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQu ZWR1PiwgInNpcHJlY0BpZXRmLm9yZyINCjxzaXByZWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W3NpcHJlY10gQ2FycnlpbmcgU2Vzc2lvbi1JRCBpbiBTSVBSRUMgbWV0YWRhdGENCg0KPkhpIFBh dWwsDQo+DQo+UGxlYXNlIHNlZSBpbmxpbmUNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KPkRhdGU6IFdl ZG5lc2RheSwgOCBPY3RvYmVyIDIwMTQgOTo1NyBwbQ0KPlRvOiAic2lwcmVjQGlldGYub3JnIiA8 c2lwcmVjQGlldGYub3JnPg0KPlN1YmplY3Q6IFJlOiBbc2lwcmVjXSBDYXJyeWluZyBTZXNzaW9u LUlEIGluIFNJUFJFQyBtZXRhZGF0YQ0KPg0KPj5PbiAxMC84LzE0IDI6NDUgQU0sIFJhbSBNb2hh biBSIChybW9oYW5yKSB3cm90ZToNCj4+PiBXZSBoYWQgZGlzY3Vzc2VkIHRoaXMgaW4gdGhlIHBh c3QgKHNlZSB0aGlzIGFyY2hpdmUgZW1haWwgLQ0KPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9pbnNpcGlkL2N1cnJlbnQvbXNnMDAyODUuaHRtbCkNCj4+PiBob3dldmVy IGF0IHRoYXQgdGltZSBzaW5jZSBJTlNJUElEIFdHIGFuZCBTZXNzaW9uLUlEIGRvY3VtZW50IHdh cyBpbg0KPj4+ZWFybHkNCj4+PiBzdGFnZSB3ZSBkZWZlcnJlZCBpbmNsdWRpbmcgU2Vzc2lvbi1J RCBpbiB0aGUgbWV0YWRhdGEuIE5vdyB0aGF0DQo+Pj4gU2Vzc2lvbi1JRCBpcyBhIG1hdHVyZSBk b2N1bWVudCBJIGJlbGlldmUgaXQgaXMgZ29vZCB0byBpbmNsdWRlIHRoZQ0KPj4+c2FtZQ0KPj4+ IGluIHRoZSBNZXRhZGF0YSBYTUwgYXMgcGFydCBvZiBDUy4NCj4+Pg0KPj4+IE15IGluaXRpYWwg dGhvdWdodCBpcyB0byBpbmNsdWRlIGl0IGFzIGEgZWxlbWVudCBvZiBDUy4NCj4+Pg0KPj4+IExl dCBtZSBrbm93IHlvdXIgdGhvdWdodHMgPw0KPj4NCj4+SU1PIHdlIGNhbid0IGRlcGVuZCBvbiB0 aGUgc2Vzc2lvbiBpZCBiZWluZyBwcmVzZW50LCBzbyB3ZSBjYW4ndCB1c2UgaXQNCj4+YXMgb25l IG9mIG91ciBpZGVudGlmaWVycy4NCj4NCj5ZZXMuIEFncmVlLiBXaGF0IEkgYW0gc2F5aW5nIGlm IGEgQ1MgaGFzIElOU0lQSUQgU2Vzc2lvbl9pZCBwcmVzZW50IGFuZCBhDQo+U1JDIHdobyBpcyBw YXJ0IG9mIHRoYXQgQ1MgaGFwcGVucyB0byByZWFkIHRoaXMgaWQsIHRoZW4gaXQgY2FuIHBhc3Mg aXQgaW4NCj50aGUgbWV0YWRhdGEgdG8gU1JTLiBJTU8gdGhlIFNSQyBuZWVkIG5vdCB3b3JyeSBh Ym91dCBob3cgdGhlIElOU0lQSUQNCj5zZXNzaW9uX2lkIGlzIGRlcml2ZWQuIEFsbCB3ZSBuZWVk IGlzIGEgY2FycmllcihmaWVsZCkgdG8gY2FycnkgdGhlDQo+cmVjZWl2ZWQgU2Vzc2lvbl9pZCB0 byBTUlMuIE5vdGUgdGhpcyBpcyBpbmRlcGVuZGVudCBvZiB0aGUgaWRzIHdlIGhhdmUgaW4NCj50 aGUgWE1MLiBUaGUgaWRzIHdlIGhhdmUgd2lsbCBjb250aW51ZSB0byBiZSBwcmVzZW50LiBJIGRv bqn2dCBzZWUgYSBuZWVkDQo+dG8gbGluay4NCj4+DQo+PlNSQ3MgdGhhdCB3YW50IHRvIGNvb3Jk aW5hdGUsIGFuZCB0aGF0IGtub3cgdGhleSBhcmUgaW4gYW4gZW52aXJvbm1lbnQNCj4+dGhhdCB1 c2VzIHNlc3Npb24taWQgKmNvdWxkKiBkZXJpdmUgdGhlaXIgSURzIGJhc2VkIG9uIHRoZSBzZXNz aW9uLWlkLg0KPg0KPldlbGwgSSBkb26p9nQga25vdyBpZiB3ZSB3YW50IHRvIHNheSB0aGF0IGFu ZCBjcmVhdGUgc29tZSBkZXBlbmRhbmN5LiBJIGFtDQo+b3BlbiB0byBoYXZlIHRoYXQgYnV0IHRo aW5rIGl0IGNhbiBjcmVhdGUgY29uZnVzaW9uIGFzIHdlIG5lZWQgdG8gZGVmaW5lDQo+Ym90aCB0 aGUgY2FzZXMgKHdoZW4gU2Vzc2lvbl9pZCBwcmVzZW50IGFuZCB3aGVuIGl0IGlzIG5vdCkuIFJh dGhlciBJDQo+d291bGQgdGhpbmsgd2Ugc2hvdWxkIGxlYXZlIHRoZSBjdXJyZW50IENTIElkIHNj b3BlIGFzIGlzLg0KPg0KPj4gDQo+PldlIHdvdWxkbid0IGhhdmUgdG8gc3RhbmRhcmRpemUgdGhh dCwgYnV0IGl0IHdvdWxkIG9ubHkgd29yayB3aXRoIFNSQ3MNCj4+dGhhdCBoYXZlIGFuIGFncmVl bWVudC4NCj4+DQo+PldlIGNvdWxkIGFsc28gYWxsb3cgdGhlIHNlc3Npb24taWQgdG8gYmUgYWRk ZWQgYXMgYW4gb3B0aW9uYWwgZWxlbWVudCBpbg0KPj50aGUgbWV0YWRhdGEuIA0KPg0KPlllcyB0 aGF0IGlzIHdoYXQgSSB3YXMgY29taW5nIHRvLiBXZSBuZWVkIGEgZmllbGQgaW4gbWV0YWRhdGEg KHBvc3NpYmx5IGENCj5jaGlsZCBYTUwgZWxlbWVudCBpbnNpZGUgPHNlc3Npb24+IGVsZW1lbnQp IHRoYXQgY2FuIGNhcnJ5IElOU0lQSUQNCj5zZXNzaW9uX2lkIG9mIENTICggaWYgcHJlc2VudCBp biBDUykgYXMgaXMgdG8gU1JTLiBBbiBTUlMgbWF5IHVzZSBpdCBmb3INCj5yZWxhdGluZyBzZXNz aW9ucyBvciBmb3Igd2hhdGV2ZXIgaXQgbmVlZHMuDQo+DQo+UmVnYXJkcywNCj5SYW0NCj4NCj4N Cj4+VGhhdCB3b3VsZG4ndCBjYXVzZSB0d28gU1JDcyBpbiB0aGUgc2FtZSBjYWxsIHRvIGNob29z ZQ0KPj50aGUgc2FtZSBzaXByZWMgaWQgZm9yIHRoZSBjYWxsLCBidXQgdGhlIFNSUyBjb3VsZCB0 aGVuIGNvcnJlbGF0ZSB0aGVtLg0KPj4NCj4+CVRoYW5rcywNCj4+CVBhdWwNCj4+DQo+Pl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnNpcHJlYyBtYWls aW5nIGxpc3QNCj4+c2lwcmVjQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lwcmVjDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5zaXByZWMgbWFpbGluZyBsaXN0DQo+c2lwcmVjQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXByZWMNCg0K From nobody Thu Oct 9 17:16:15 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB671A875B for ; Thu, 9 Oct 2014 17:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ7azbJzsTei for ; Thu, 9 Oct 2014 17:15:55 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.15]) by ietfa.amsl.com (Postfix) with ESMTP id EE6881A0030 for ; Thu, 9 Oct 2014 17:15:54 -0700 (PDT) Received: from userPC (unknown [122.172.225.99]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 8CD141918014; Fri, 10 Oct 2014 00:15:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1412900153; bh=BLJIFvJjxQB8GxFWTz7sY8ayUdOVhPE3dG/FZ5g0PuY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ALSbqHSNIys6sgXJAGE1/GzMXY2Ku2Sh764BHVQXnfClJvhNUhxGmYIXxSkPFPELC U5nTeUB9T8vNysRKLekeeL7S8TRjr3nWbvd0k/o427avlikt+xKJHOm8k25KUA3VSx bOtr9gzsvRn2HKHadfUebf1G701lVNeaOLyz+DxE= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , "'Paul Kyzivat'" , References: <543565F1.30903@alum.mit.edu> In-Reply-To: Date: Fri, 10 Oct 2014 05:45:40 +0530 Message-ID: <009601cfe41f$571951f0$054bf5d0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHP4xj+iTR67vuTJ0WRJyYyOzFzAZwodqMg Content-Language: en-us X-CTCH-RefID: str=0001.0A020204.54372539.004E, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 64 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/69RjE1ootUIORR4aVMqQFri0mFE Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 00:16:04 -0000 Hi Ram, I agree with Paul & you for adding optional XML element to carry INSIPID session-id. We need to clearly explain the interaction of CS group id with INSIPID session-id as INSIPID session-id shall act as CS group ID as well. = Updating example draft with the usage of these unique-id for call transfer = scenario will provide better clarity. Thanks Partha > -----Original Message----- > From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: Wednesday, October 08, 2014 10:28 PM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata >=20 > To add to below, One issue I see by mapping INSIPID Session_id to CS > xml > id is - when a SRS receives metadata it will not know if the received > id > in CS is INSIPID session_id or SRC generated UUID. It is important for > SRS > to know this, since INSIPID session_id scope is much larger and the = SRS > may want to use that Session_id for some other things. >=20 > Ram >=20 >=20 > -----Original Message----- > From: Cisco Employee > Date: Wednesday, 8 October 2014 10:13 pm > To: Paul Kyzivat , "siprec@ietf.org" > > Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata >=20 > >Hi Paul, > > > >Please see inline > > > >-----Original Message----- > >From: Paul Kyzivat > >Date: Wednesday, 8 October 2014 9:57 pm > >To: "siprec@ietf.org" > >Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata > > > >>On 10/8/14 2:45 AM, Ram Mohan R (rmohanr) wrote: > >>> We had discussed this in the past (see this archive email - > >>> = http://www.ietf.org/mail-archive/web/insipid/current/msg00285.html) > >>> however at that time since INSIPID WG and Session-ID document was > in > >>>early > >>> stage we deferred including Session-ID in the metadata. Now that > >>> Session-ID is a mature document I believe it is good to include = the > >>>same > >>> in the Metadata XML as part of CS. > >>> > >>> My initial thought is to include it as a element of CS. > >>> > >>> Let me know your thoughts ? > >> > >>IMO we can't depend on the session id being present, so we can't use > it > >>as one of our identifiers. > > > >Yes. Agree. What I am saying if a CS has INSIPID Session_id present > and a > >SRC who is part of that CS happens to read this id, then it can pass > it in > >the metadata to SRS. IMO the SRC need not worry about how the INSIPID > >session_id is derived. All we need is a carrier(field) to carry the > >received Session_id to SRS. Note this is independent of the ids we > have in > >the XML. The ids we have will continue to be present. I don=B9t see a > need > >to link. > >> > >>SRCs that want to coordinate, and that know they are in an > environment > >>that uses session-id *could* derive their IDs based on the session- > id. > > > >Well I don=B9t know if we want to say that and create some = dependancy. I > am > >open to have that but think it can create confusion as we need to > define > >both the cases (when Session_id present and when it is not). Rather I > >would think we should leave the current CS Id scope as is. > > > >> > >>We wouldn't have to standardize that, but it would only work with > SRCs > >>that have an agreement. > >> > >>We could also allow the session-id to be added as an optional = element > in > >>the metadata. > > > >Yes that is what I was coming to. We need a field in metadata > (possibly a > >child XML element inside element) that can carry INSIPID > >session_id of CS ( if present in CS) as is to SRS. An SRS may use it > for > >relating sessions or for whatever it needs. > > > >Regards, > >Ram > > > > > >>That wouldn't cause two SRCs in the same call to choose > >>the same siprec id for the call, but the SRS could then correlate > them. > >> > >> Thanks, > >> Paul > >> > >>_______________________________________________ > >>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 nobody Thu Oct 9 18:32:43 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9166E1AD05A for ; Thu, 9 Oct 2014 18:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22Sqi4YMXlM4 for ; Thu, 9 Oct 2014 18:32:39 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F701A87E4 for ; Thu, 9 Oct 2014 18:32:33 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-08v.sys.comcast.net with comcast id 1DY81p0045E3ZMc01DYZU5; Fri, 10 Oct 2014 01:32:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-18v.sys.comcast.net with comcast id 1DYV1p0063Ge9ey01DYVgV; Fri, 10 Oct 2014 01:32:30 +0000 Message-ID: <5437372D.4070406@alum.mit.edu> Date: Thu, 09 Oct 2014 21:32:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Parthasarathi R , "'Ram Mohan R (rmohanr)'" , siprec@ietf.org References: <543565F1.30903@alum.mit.edu> <009601cfe41f$571951f0$054bf5d0$@co.in> In-Reply-To: <009601cfe41f$571951f0$054bf5d0$@co.in> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412904753; bh=MoGprK3ZQDktE/crtpkXfWfQXtG4cZUjBJdaoVQ9oS0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cV+G3OjhGSgHfbvZWPqSz1Rj3qmrB73EFwI4AErYby0WZGqMZflAEyAqoLNFhsZuq zbOlShwKhMDLuvH4Wv3itOKsw0ozo2B9G2hlPGOmUP4AyuOpegOCLfHYLvm6aQWT+6 /8T2L2gxQChfeUj94yD8s2u/rrYmIYh2G+cy2+C9p7jx6Zx3fooPMQVK4bim7JF71m wJjqjSWpgEMHbSkaLmeYWjCcF4D8sJ6uqtHmHo1eWUzehvqBFHk7ZmFGKjdv2V1yyT SpnLZA9RQJaCo3Wjwl1X/OEQaNUjPoOBCdsi3no1IB/UXUbsvW0nRNvYPfx4Z0Q4Gi Pw9vlpFyOIUqA== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/GhqPcqZ9KvHeslSxyes2HDmJJ8g Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 01:32:41 -0000 One thing to keep in mind is that a single siprec session may correspond to multiple sip dialogs. (E.g. when a conference focus is the SRC.) So we should probably allow multiple insipid session-ids. Alternately CS groups might be used for that. In *some* cases a CS group might correspond to a *half* insipid session-id. But that need not be the case. I doubt we need to talk about that. Thanks, Paul On 10/9/14 8:15 PM, Parthasarathi R wrote: > Hi Ram, > > I agree with Paul & you for adding optional XML element to carry INSIPID > session-id. > > We need to clearly explain the interaction of CS group id with INSIPID > session-id as INSIPID session-id shall act as CS group ID as well. Updating > example draft with the usage of these unique-id for call transfer scenario > will provide better clarity. > > Thanks > Partha > >> -----Original Message----- >> From: siprec [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R >> (rmohanr) >> Sent: Wednesday, October 08, 2014 10:28 PM >> To: Paul Kyzivat; siprec@ietf.org >> Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata >> >> To add to below, One issue I see by mapping INSIPID Session_id to CS >> xml >> id is - when a SRS receives metadata it will not know if the received >> id >> in CS is INSIPID session_id or SRC generated UUID. It is important for >> SRS >> to know this, since INSIPID session_id scope is much larger and the SRS >> may want to use that Session_id for some other things. >> >> Ram >> >> >> -----Original Message----- >> From: Cisco Employee >> Date: Wednesday, 8 October 2014 10:13 pm >> To: Paul Kyzivat , "siprec@ietf.org" >> >> Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata >> >>> Hi Paul, >>> >>> Please see inline >>> >>> -----Original Message----- >>> From: Paul Kyzivat >>> Date: Wednesday, 8 October 2014 9:57 pm >>> To: "siprec@ietf.org" >>> Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata >>> >>>> On 10/8/14 2:45 AM, Ram Mohan R (rmohanr) wrote: >>>>> We had discussed this in the past (see this archive email - >>>>> http://www.ietf.org/mail-archive/web/insipid/current/msg00285.html) >>>>> however at that time since INSIPID WG and Session-ID document was >> in >>>>> early >>>>> stage we deferred including Session-ID in the metadata. Now that >>>>> Session-ID is a mature document I believe it is good to include the >>>>> same >>>>> in the Metadata XML as part of CS. >>>>> >>>>> My initial thought is to include it as a element of CS. >>>>> >>>>> Let me know your thoughts ? >>>> >>>> IMO we can't depend on the session id being present, so we can't use >> it >>>> as one of our identifiers. >>> >>> Yes. Agree. What I am saying if a CS has INSIPID Session_id present >> and a >>> SRC who is part of that CS happens to read this id, then it can pass >> it in >>> the metadata to SRS. IMO the SRC need not worry about how the INSIPID >>> session_id is derived. All we need is a carrier(field) to carry the >>> received Session_id to SRS. Note this is independent of the ids we >> have in >>> the XML. The ids we have will continue to be present. I donšt see a >> need >>> to link. >>>> >>>> SRCs that want to coordinate, and that know they are in an >> environment >>>> that uses session-id *could* derive their IDs based on the session- >> id. >>> >>> Well I donšt know if we want to say that and create some dependancy. I >> am >>> open to have that but think it can create confusion as we need to >> define >>> both the cases (when Session_id present and when it is not). Rather I >>> would think we should leave the current CS Id scope as is. >>> >>>> >>>> We wouldn't have to standardize that, but it would only work with >> SRCs >>>> that have an agreement. >>>> >>>> We could also allow the session-id to be added as an optional element >> in >>>> the metadata. >>> >>> Yes that is what I was coming to. We need a field in metadata >> (possibly a >>> child XML element inside element) that can carry INSIPID >>> session_id of CS ( if present in CS) as is to SRS. An SRS may use it >> for >>> relating sessions or for whatever it needs. >>> >>> Regards, >>> Ram >>> >>> >>>> That wouldn't cause two SRCs in the same call to choose >>>> the same siprec id for the call, but the SRS could then correlate >> them. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> 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 nobody Thu Oct 9 19:18:16 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC611A0059 for ; Thu, 9 Oct 2014 19:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97mdrLDBukxY for ; Thu, 9 Oct 2014 19:18:10 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A141A003A for ; Thu, 9 Oct 2014 19:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7686; q=dns/txt; s=iport; t=1412907490; x=1414117090; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CfrRyZCRhWqH0aZVl7rxjbGCmtaAHQLnnJEQGj17e2M=; b=RYdOqzUz9bt4lEALs9+FbaLQXBP4KK4SgrR8Tj82cOVHboWsi5MalU0Q UX/AmHYVyb4vj9BiRuB1ADxCEBsQ21igYKYgcWsHFGuhCzoig6RUKMDKm fCLNLIMDYIOYUtMeZ+qDZEu2LQ2BO9Mm9brhrrbEwbSLPRunMmQJZdGar c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAC5BN1StJV2c/2dsb2JhbABgDoMAU1gEgwLIDAqGeVQCGXAWAXuEAwEBAQQBAQExMwEGBhEEAgEIDgMDAQEBAQQjBQICJQsUCQgCBAEJCQmINQ2SG5xFBpQkAReBJo48EAIBNCIGgmuBWgWReYY4hRqBLoNGgy2JcoN+gyNAbAGBR4ECAQEB X-IronPort-AV: E=Sophos;i="5.04,689,1406592000"; d="scan'208";a="85586662" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 10 Oct 2014 02:18:08 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9A2I89Z026454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 02:18:08 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.227]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 21:18:08 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , Parthasarathi R , "siprec@ietf.org" Thread-Topic: [siprec] Carrying Session-ID in SIPREC metadata Thread-Index: AQHP5DBu2I4CgJog+Uu12FHB7nDCAA== Date: Fri, 10 Oct 2014 02:18:07 +0000 Message-ID: References: <543565F1.30903@alum.mit.edu> <009601cfe41f$571951f0$054bf5d0$@co.in> <5437372D.4070406@alum.mit.edu> In-Reply-To: <5437372D.4070406@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.58.67] Content-Type: text/plain; charset="euc-kr" Content-ID: <97ADA6BDAA42E54CA7B9AA94129781AB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/J3dlLMOmiWd42D6_pGjgYixqnXQ Subject: Re: [siprec] Carrying Session-ID in SIPREC metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 02:18:13 -0000 SGkgUGF1bCwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGF1bCBLeXpp dmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+DQpEYXRlOiBGcmlkYXksIDEwIE9jdG9iZXIgMjAx NCA3OjAyIGFtDQpUbzogUGFydGhhc2FyYXRoaSBSIDxwYXJ0aGFAcGFydGhhc2FyYXRoaS5jby5p bj4sIENpc2NvIEVtcGxveWVlDQo8cm1vaGFuckBjaXNjby5jb20+LCAic2lwcmVjQGlldGYub3Jn IiA8c2lwcmVjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXByZWNdIENhcnJ5aW5nIFNlc3Np b24tSUQgaW4gU0lQUkVDIG1ldGFkYXRhDQoNCj5PbmUgdGhpbmcgdG8ga2VlcCBpbiBtaW5kIGlz IHRoYXQgYSBzaW5nbGUgc2lwcmVjIHNlc3Npb24gbWF5IGNvcnJlc3BvbmQNCj50byBtdWx0aXBs ZSBzaXAgZGlhbG9ncy4gKEUuZy4gd2hlbiBhIGNvbmZlcmVuY2UgZm9jdXMgaXMgdGhlIFNSQy4p IFNvDQo+d2Ugc2hvdWxkIHByb2JhYmx5IGFsbG93IG11bHRpcGxlIGluc2lwaWQgc2Vzc2lvbi1p ZHMuDQoNCkdvb2QgcG9pbnQuIEFncmVlIHRoYXQgd2UgbWF5IGhhdmUgc3VjaCBhIHNjZW5hcmlv IHdoZXJlIG11bHRpcGxlIGluc2lwaWQNCnNlc3Npb24taWRzIG1heSBuZWVkIHRvIGJlIGNhcnJp ZWQgaW4gdGhlIG1ldGFkYXRhLg0KDQpSYW0NCg0KPg0KPkFsdGVybmF0ZWx5IENTIGdyb3VwcyBt aWdodCBiZSB1c2VkIGZvciB0aGF0LiBJbiAqc29tZSogY2FzZXMgYSBDUyBncm91cA0KPm1pZ2h0 IGNvcnJlc3BvbmQgdG8gYSAqaGFsZiogaW5zaXBpZCBzZXNzaW9uLWlkLiBCdXQgdGhhdCBuZWVk IG5vdCBiZQ0KPnRoZSBjYXNlLiBJIGRvdWJ0IHdlIG5lZWQgdG8gdGFsayBhYm91dCB0aGF0Lg0K Pg0KPglUaGFua3MsDQo+CVBhdWwNCj4NCj5PbiAxMC85LzE0IDg6MTUgUE0sIFBhcnRoYXNhcmF0 aGkgUiB3cm90ZToNCj4+IEhpIFJhbSwNCj4+DQo+PiBJIGFncmVlIHdpdGggUGF1bCAmIHlvdSBm b3IgYWRkaW5nIG9wdGlvbmFsIFhNTCBlbGVtZW50IHRvIGNhcnJ5IElOU0lQSUQNCj4+IHNlc3Np b24taWQuDQo+Pg0KPj4gV2UgbmVlZCB0byBjbGVhcmx5IGV4cGxhaW4gdGhlIGludGVyYWN0aW9u IG9mIENTIGdyb3VwIGlkIHdpdGggSU5TSVBJRA0KPj4gc2Vzc2lvbi1pZCBhcyBJTlNJUElEIHNl c3Npb24taWQgc2hhbGwgYWN0IGFzIENTIGdyb3VwIElEIGFzIHdlbGwuDQo+PlVwZGF0aW5nDQo+ PiBleGFtcGxlIGRyYWZ0IHdpdGggdGhlIHVzYWdlIG9mIHRoZXNlIHVuaXF1ZS1pZCBmb3IgY2Fs bCB0cmFuc2Zlcg0KPj5zY2VuYXJpbw0KPj4gd2lsbCBwcm92aWRlIGJldHRlciBjbGFyaXR5Lg0K Pj4NCj4+IFRoYW5rcw0KPj4gUGFydGhhDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4gRnJvbTogc2lwcmVjIFttYWlsdG86c2lwcmVjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBSYW0gTW9oYW4gUg0KPj4+IChybW9oYW5yKQ0KPj4+IFNlbnQ6IFdlZG5lc2Rh eSwgT2N0b2JlciAwOCwgMjAxNCAxMDoyOCBQTQ0KPj4+IFRvOiBQYXVsIEt5eml2YXQ7IHNpcHJl Y0BpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbc2lwcmVjXSBDYXJyeWluZyBTZXNzaW9uLUlE IGluIFNJUFJFQyBtZXRhZGF0YQ0KPj4+DQo+Pj4gVG8gYWRkIHRvIGJlbG93LCBPbmUgaXNzdWUg SSBzZWUgYnkgbWFwcGluZyBJTlNJUElEIFNlc3Npb25faWQgdG8gQ1MNCj4+PiB4bWwNCj4+PiBp ZCBpcyAtICB3aGVuIGEgU1JTIHJlY2VpdmVzIG1ldGFkYXRhIGl0IHdpbGwgbm90IGtub3cgaWYg dGhlIHJlY2VpdmVkDQo+Pj4gaWQNCj4+PiBpbiBDUyBpcyBJTlNJUElEIHNlc3Npb25faWQgb3Ig U1JDIGdlbmVyYXRlZCBVVUlELiBJdCBpcyBpbXBvcnRhbnQgZm9yDQo+Pj4gU1JTDQo+Pj4gdG8g a25vdyB0aGlzLCBzaW5jZSBJTlNJUElEIHNlc3Npb25faWQgc2NvcGUgaXMgbXVjaCBsYXJnZXIg YW5kIHRoZSBTUlMNCj4+PiBtYXkgd2FudCB0byB1c2UgdGhhdCBTZXNzaW9uX2lkIGZvciBzb21l IG90aGVyIHRoaW5ncy4NCj4+Pg0KPj4+IFJhbQ0KPj4+DQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IENpc2NvIEVtcGxveWVlIDxybW9oYW5yQGNpc2NvLmNv bT4NCj4+PiBEYXRlOiBXZWRuZXNkYXksIDggT2N0b2JlciAyMDE0IDEwOjEzIHBtDQo+Pj4gVG86 IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PiwgInNpcHJlY0BpZXRmLm9yZyIN Cj4+PiA8c2lwcmVjQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJlOiBbc2lwcmVjXSBDYXJyeWlu ZyBTZXNzaW9uLUlEIGluIFNJUFJFQyBtZXRhZGF0YQ0KPj4+DQo+Pj4+IEhpIFBhdWwsDQo+Pj4+ DQo+Pj4+IFBsZWFzZSBzZWUgaW5saW5lDQo+Pj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+IEZyb206IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0K Pj4+PiBEYXRlOiBXZWRuZXNkYXksIDggT2N0b2JlciAyMDE0IDk6NTcgcG0NCj4+Pj4gVG86ICJz aXByZWNAaWV0Zi5vcmciIDxzaXByZWNAaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFJlOiBbc2lw cmVjXSBDYXJyeWluZyBTZXNzaW9uLUlEIGluIFNJUFJFQyBtZXRhZGF0YQ0KPj4+Pg0KPj4+Pj4g T24gMTAvOC8xNCAyOjQ1IEFNLCBSYW0gTW9oYW4gUiAocm1vaGFucikgd3JvdGU6DQo+Pj4+Pj4g V2UgaGFkIGRpc2N1c3NlZCB0aGlzIGluIHRoZSBwYXN0IChzZWUgdGhpcyBhcmNoaXZlIGVtYWls IC0NCj4+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaW5zaXBpZC9j dXJyZW50L21zZzAwMjg1Lmh0bWwpDQo+Pj4+Pj4gaG93ZXZlciBhdCB0aGF0IHRpbWUgc2luY2Ug SU5TSVBJRCBXRyBhbmQgU2Vzc2lvbi1JRCBkb2N1bWVudCB3YXMNCj4+PiBpbg0KPj4+Pj4+IGVh cmx5DQo+Pj4+Pj4gc3RhZ2Ugd2UgZGVmZXJyZWQgaW5jbHVkaW5nIFNlc3Npb24tSUQgaW4gdGhl IG1ldGFkYXRhLiBOb3cgdGhhdA0KPj4+Pj4+IFNlc3Npb24tSUQgaXMgYSBtYXR1cmUgZG9jdW1l bnQgSSBiZWxpZXZlIGl0IGlzIGdvb2QgdG8gaW5jbHVkZSB0aGUNCj4+Pj4+PiBzYW1lDQo+Pj4+ Pj4gaW4gdGhlIE1ldGFkYXRhIFhNTCBhcyBwYXJ0IG9mIENTLg0KPj4+Pj4+DQo+Pj4+Pj4gTXkg aW5pdGlhbCB0aG91Z2h0IGlzIHRvIGluY2x1ZGUgaXQgYXMgYSBlbGVtZW50IG9mIENTLg0KPj4+ Pj4+DQo+Pj4+Pj4gTGV0IG1lIGtub3cgeW91ciB0aG91Z2h0cyA/DQo+Pj4+Pg0KPj4+Pj4gSU1P IHdlIGNhbid0IGRlcGVuZCBvbiB0aGUgc2Vzc2lvbiBpZCBiZWluZyBwcmVzZW50LCBzbyB3ZSBj YW4ndCB1c2UNCj4+PiBpdA0KPj4+Pj4gYXMgb25lIG9mIG91ciBpZGVudGlmaWVycy4NCj4+Pj4N Cj4+Pj4gWWVzLiBBZ3JlZS4gV2hhdCBJIGFtIHNheWluZyBpZiBhIENTIGhhcyBJTlNJUElEIFNl c3Npb25faWQgcHJlc2VudA0KPj4+IGFuZCBhDQo+Pj4+IFNSQyB3aG8gaXMgcGFydCBvZiB0aGF0 IENTIGhhcHBlbnMgdG8gcmVhZCB0aGlzIGlkLCB0aGVuIGl0IGNhbiBwYXNzDQo+Pj4gaXQgaW4N Cj4+Pj4gdGhlIG1ldGFkYXRhIHRvIFNSUy4gSU1PIHRoZSBTUkMgbmVlZCBub3Qgd29ycnkgYWJv dXQgaG93IHRoZSBJTlNJUElEDQo+Pj4+IHNlc3Npb25faWQgaXMgZGVyaXZlZC4gQWxsIHdlIG5l ZWQgaXMgYSBjYXJyaWVyKGZpZWxkKSB0byBjYXJyeSB0aGUNCj4+Pj4gcmVjZWl2ZWQgU2Vzc2lv bl9pZCB0byBTUlMuIE5vdGUgdGhpcyBpcyBpbmRlcGVuZGVudCBvZiB0aGUgaWRzIHdlDQo+Pj4g aGF2ZSBpbg0KPj4+PiB0aGUgWE1MLiBUaGUgaWRzIHdlIGhhdmUgd2lsbCBjb250aW51ZSB0byBi ZSBwcmVzZW50LiBJIGRvbqn2dCBzZWUgYQ0KPj4+IG5lZWQNCj4+Pj4gdG8gbGluay4NCj4+Pj4+ DQo+Pj4+PiBTUkNzIHRoYXQgd2FudCB0byBjb29yZGluYXRlLCBhbmQgdGhhdCBrbm93IHRoZXkg YXJlIGluIGFuDQo+Pj4gZW52aXJvbm1lbnQNCj4+Pj4+IHRoYXQgdXNlcyBzZXNzaW9uLWlkICpj b3VsZCogZGVyaXZlIHRoZWlyIElEcyBiYXNlZCBvbiB0aGUgc2Vzc2lvbi0NCj4+PiBpZC4NCj4+ Pj4NCj4+Pj4gV2VsbCBJIGRvbqn2dCBrbm93IGlmIHdlIHdhbnQgdG8gc2F5IHRoYXQgYW5kIGNy ZWF0ZSBzb21lIGRlcGVuZGFuY3kuIEkNCj4+PiBhbQ0KPj4+PiBvcGVuIHRvIGhhdmUgdGhhdCBi dXQgdGhpbmsgaXQgY2FuIGNyZWF0ZSBjb25mdXNpb24gYXMgd2UgbmVlZCB0bw0KPj4+IGRlZmlu ZQ0KPj4+PiBib3RoIHRoZSBjYXNlcyAod2hlbiBTZXNzaW9uX2lkIHByZXNlbnQgYW5kIHdoZW4g aXQgaXMgbm90KS4gUmF0aGVyIEkNCj4+Pj4gd291bGQgdGhpbmsgd2Ugc2hvdWxkIGxlYXZlIHRo ZSBjdXJyZW50IENTIElkIHNjb3BlIGFzIGlzLg0KPj4+Pg0KPj4+Pj4NCj4+Pj4+IFdlIHdvdWxk bid0IGhhdmUgdG8gc3RhbmRhcmRpemUgdGhhdCwgYnV0IGl0IHdvdWxkIG9ubHkgd29yayB3aXRo DQo+Pj4gU1JDcw0KPj4+Pj4gdGhhdCBoYXZlIGFuIGFncmVlbWVudC4NCj4+Pj4+DQo+Pj4+PiBX ZSBjb3VsZCBhbHNvIGFsbG93IHRoZSBzZXNzaW9uLWlkIHRvIGJlIGFkZGVkIGFzIGFuIG9wdGlv bmFsIGVsZW1lbnQNCj4+PiBpbg0KPj4+Pj4gdGhlIG1ldGFkYXRhLg0KPj4+Pg0KPj4+PiBZZXMg dGhhdCBpcyB3aGF0IEkgd2FzIGNvbWluZyB0by4gV2UgbmVlZCBhIGZpZWxkIGluIG1ldGFkYXRh DQo+Pj4gKHBvc3NpYmx5IGENCj4+Pj4gY2hpbGQgWE1MIGVsZW1lbnQgaW5zaWRlIDxzZXNzaW9u PiBlbGVtZW50KSB0aGF0IGNhbiBjYXJyeSBJTlNJUElEDQo+Pj4+IHNlc3Npb25faWQgb2YgQ1Mg KCBpZiBwcmVzZW50IGluIENTKSBhcyBpcyB0byBTUlMuIEFuIFNSUyBtYXkgdXNlIGl0DQo+Pj4g Zm9yDQo+Pj4+IHJlbGF0aW5nIHNlc3Npb25zIG9yIGZvciB3aGF0ZXZlciBpdCBuZWVkcy4NCj4+ Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4gUmFtDQo+Pj4+DQo+Pj4+DQo+Pj4+PiBUaGF0IHdvdWxk bid0IGNhdXNlIHR3byBTUkNzIGluIHRoZSBzYW1lIGNhbGwgdG8gY2hvb3NlDQo+Pj4+PiB0aGUg c2FtZSBzaXByZWMgaWQgZm9yIHRoZSBjYWxsLCBidXQgdGhlIFNSUyBjb3VsZCB0aGVuIGNvcnJl bGF0ZQ0KPj4+IHRoZW0uDQo+Pj4+Pg0KPj4+Pj4gCVRoYW5rcywNCj4+Pj4+IAlQYXVsDQo+Pj4+ Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+IHNpcHJlYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNpcHJlY0BpZXRmLm9yZw0KPj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXByZWMNCj4+Pj4NCj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2lw cmVjIG1haWxpbmcgbGlzdA0KPj4+PiBzaXByZWNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXByZWMNCj4+Pg0KPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2lwcmVjIG1haWxpbmcgbGlz dA0KPj4+IHNpcHJlY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwcmVjDQo+Pg0KPj4NCj4NCg0K From nobody Tue Oct 21 03:24:30 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EDE1A0275 for ; Tue, 21 Oct 2014 03:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPEdL8mEX_RK for ; Tue, 21 Oct 2014 03:24:27 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id B6C431A01AA for ; Tue, 21 Oct 2014 03:24:27 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id A78BE23F0464; Tue, 21 Oct 2014 12:24:26 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 12:24:26 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: IETF 91 Final Agenda - SIPREC Thread-Index: AQHP6moF7eH4F8fIwEGUzbVBKhO/o5w4n0VQgAG992A= Date: Tue, 21 Oct 2014 10:24:25 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5CE120@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/C28KcSsCHprTxpKg7h5FFMN02bQ Subject: [siprec] FW: IETF 91 Final Agenda - SIPREC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 10:24:29 -0000 DQpTSVBSRUMgaGFzIGEgb25lIGhvdXIgc2xvdCBvbiBUdWVzZGF5IG1vcm5pbmcgKFNlZSBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTEvYWdlbmRhLmh0bWwpDQoNClBsZWFz ZSBsZXQgdGhlIGNoYWlycyBrbm93IGlmIHlvdSB3YW50IHRvIHByZXNlbnQuDQoNClJlZ2FyZHMN CkFuZHkNCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWV0ZiBb bWFpbHRvOmlldGYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElFVEYgQWdlbmRhDQo+ IFNlbnQ6IFNhbXN0YWcsIDE4LiBPa3RvYmVyIDIwMTQgMDI6MjUNCj4gVG86IElFVEYgQW5ub3Vu Y2VtZW50IExpc3QNCj4gQ2M6IGlldGZAaWV0Zi5vcmcNCj4gU3ViamVjdDogSUVURiA5MSBGaW5h bCBBZ2VuZGENCj4gDQo+IDkxc3QgSUVURiBNZWV0aW5nIC0gSG9ub2x1bHUsIEhJLCBVU0ENCj4g Tm92ZW1iZXIgOSAtIDE0LCAyMDE0DQo+IA0KPiBUaGUgZmluYWwgYWdlbmRhIGlzIG5vdyBhdmFp bGFibGUuDQo+IA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTEvYWdl bmRhLmh0bWwNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzkxL2FnZW5k YS50eHQNCj4gDQo+IFdoaWxlIHRoaXMgaXMgY29uc2lkZXJlZCB0aGUgZmluYWwgYWdlbmRhIGZv ciBwcmludGluZywgY2hhbmdlcyBtYXkgYmUgbWFkZQ0KPiB0byB0aGUgYWdlbmRhIHVwIHVudGls IGFuZCBkdXJpbmcgdGhlIG1lZXRpbmcuIFVwZGF0ZXMgd2lsbCBiZSByZWZsZWN0ZWQgb24NCj4g dGhlIHdlYiB2ZXJzaW9uIG9mIHRoZSBhZ2VuZGEuDQo+IA0KPiBJbmZvcm1hdGlvbiBhYm91dCB0 aGUgOTFzdCBJRVRGIG1lZXRpbmcgaW4gSG9ub2x1bHUsIEhJLCBVU0EgY2FuIGJlIGZvdW5kDQo+ IGhlcmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21lZXRpbmcvOTEvaW5kZXguaHRtbA0KPiANCj4g VGhhbmsgeW91IGFuZCBzZWUgeW91IGluIEhvbm9sdWx1IQ0KPiANCj4gU2luY2VyZWx5LA0KPiAN Cj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Oct 21 08:22:01 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55931A875E for ; Tue, 21 Oct 2014 08:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRk4IJjTezlx for ; Tue, 21 Oct 2014 08:21:50 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57AD1A8743 for ; Tue, 21 Oct 2014 08:21:50 -0700 (PDT) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-07v.sys.comcast.net with comcast id 5rM51p00B4ueUHc01rMqTF; Tue, 21 Oct 2014 15:21:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-03v.sys.comcast.net with comcast id 5rMp1p00T3Ge9ey01rMpRW; Tue, 21 Oct 2014 15:21:50 +0000 Message-ID: <54467A0D.1010701@alum.mit.edu> Date: Tue, 21 Oct 2014 11:21:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF1E5CE120@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E5CE120@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413904910; bh=RWGZtFoWBwGYR1sBS7t6GClt96wUp70le759wpkbVbU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kRNIFfVQCPVGDnY8pKx3UgxaLap4sfYeav/i2H4tM6rF5aH7aF2DrBfsARt8Igmuz +GIbhr1nAF7Y/CjNmsm2BDOkq7EUQJCeMDmaY5N8s7UapMFVi6vZnXDb46wRF2F8Bw uTAZvw0wCP2LktoZjRibBp7LRmbuESrYHhuZ8mgKTl78EgjgKRhRfX8ZquO9YAhMq/ nyPp8Jd2CA7C5O3a/Ur5J3D3RAc+PA0LJvz2EefZdh1z2GScrZ/+32920vu2rfi8Me l7G/MHBZeeM2uwm/Jl5IzcV44hUY7V3eenJNJn74l0wGMXT4FsI7u91J3vvAQeRyg5 9SWBT+SRA/Qvw== Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/CKrj4TxofeG9Yom2E9KwtHCbIe0 Subject: Re: [siprec] FW: IETF 91 Final Agenda - SIPREC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:21:56 -0000 On 10/21/14 6:24 AM, Hutton, Andrew wrote: > > SIPREC has a one hour slot on Tuesday morning (See https://datatracker.ietf.org/meeting/91/agenda.html) > > Please let the chairs know if you want to present. I want to present. I got my -01 out very early, but have had little luck getting discussion going on it on the list. I am hoping a f2f will help with that. Thanks, Paul From nobody Tue Oct 21 14:34:39 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FA21A8777 for ; Tue, 21 Oct 2014 14:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scPcxn3gzkwx for ; Tue, 21 Oct 2014 14:34:31 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB511A8783 for ; Tue, 21 Oct 2014 14:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1587; q=dns/txt; s=iport; t=1413927244; x=1415136844; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Qwa/dY28B18WDo/rZecMkbellgbfDV7mntKur3ToUVs=; b=D21mfN7XwXr+QTuh+aC35HjJeDw10uJyQ1DaaRjU0BvExWYAVwyYpl9j QeZ6SclNJbkfrXFgxxqUuDQfGoGn9J/sY+kwjW5R79KYbd/aA2jMSiXb5 braXNPl9HnihXhNgkQKVDTj+1UPNun3pgxjsQZ2fMk+bGyXzN/K1PV6Ly c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAF7QRlStJV2Q/2dsb2JhbABcgw5TWATMcgqGeVSBGBYBfYQCAQEBBAEBAWsFEgYBCBEEAQEoLgsUCAEKBAESiD8Nxm4BAQEBAQEBAwEBAQEBAQEBARUEkFkLhEUFiySGXYRGhxOBMINIkS2DeGwBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,764,1406592000"; d="scan'208";a="89133774" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP; 21 Oct 2014 21:34:04 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9LLY3pB017997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 21:34:03 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.202]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 16:34:03 -0500 From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] FW: IETF 91 Final Agenda - SIPREC Thread-Index: AQHP7Xa77eH4F8fIwEGUzbVBKhO/ow== Date: Tue, 21 Oct 2014 21:34:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.144.125] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/xKElHXDjvTvesWflnJ_By1sOXFg Subject: Re: [siprec] FW: IETF 91 Final Agenda - SIPREC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:34:35 -0000 We finally escaped being on Friday, hooray! I=B9m assuming the chairs will cover the status of the protocol draft in their presentation. That being the case, I do not see a need for additional agenda time for the protocol draft. Cheers, Charles On 10/21/14, 3:24 AM, "Hutton, Andrew" wrote: > >SIPREC has a one hour slot on Tuesday morning (See >https://datatracker.ietf.org/meeting/91/agenda.html) > >Please let the chairs know if you want to present. > >Regards >Andy > > > >> -----Original Message----- >> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of IETF Agenda >> Sent: Samstag, 18. Oktober 2014 02:25 >> To: IETF Announcement List >> Cc: ietf@ietf.org >> Subject: IETF 91 Final Agenda >>=20 >> 91st IETF Meeting - Honolulu, HI, USA >> November 9 - 14, 2014 >>=20 >> The final agenda is now available. >>=20 >> https://datatracker.ietf.org/meeting/91/agenda.html >> https://datatracker.ietf.org/meeting/91/agenda.txt >>=20 >> While this is considered the final agenda for printing, changes may be >>made >> to the agenda up until and during the meeting. Updates will be >>reflected on >> the web version of the agenda. >>=20 >> Information about the 91st IETF meeting in Honolulu, HI, USA can be >>found >> here: https://www.ietf.org/meeting/91/index.html >>=20 >> Thank you and see you in Honolulu! >>=20 >> Sincerely, >>=20 >> The IETF Secretariat > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From nobody Wed Oct 22 23:36:02 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62F61A88E3 for ; Wed, 22 Oct 2014 23:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK3lZpXyQ0-i for ; Wed, 22 Oct 2014 23:35:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A561E1A88D8 for ; Wed, 22 Oct 2014 23:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1806; q=dns/txt; s=iport; t=1414046157; x=1415255757; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=LIx1/pLnu67oQ9/ZFMCqdddZNIkJ/Qg+bPthZ18avAE=; b=Wg9t3ShmrtQp7usl+91WaX43Z8ObuucdcAo+oFLFpcB/L+U3PmaDx0t9 hgxt0k4V4sytr+yDaqgYt/Q1S6Z2Y7wRZimJtB4U6dD4xHkhw+dpTtuIv XTix5TOPu9LkvE9bl+kLsTxF6wafK/kfytccF/E8577Bke/rsIoaXKXXt M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFACqhSFStJV2Y/2dsb2JhbABcgw5UWATMbAqGeVSBDxYBfYQCAQEBBAEBATc0BRIGAQgRAwEBAR8JLgsUCAEKBAESiEENx2YBAQEBAQEBAwEBAQEBAQEBAQEUBJArLQcEhEUFkgWERocSgTGDSY0yhAGDeGwBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,774,1406592000"; d="scan'208";a="365675467" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 23 Oct 2014 06:35:56 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9N6Zti9010033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 06:35:55 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.26]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 01:35:55 -0500 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] FW: IETF 91 Final Agenda - SIPREC Thread-Index: AQHP7ouZvYCKBkPadUyvkyAKljrqxA== Date: Thu, 23 Oct 2014 06:35:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.79.6] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/SBRoF946y4CUk6ecHhghVJpk2uI Subject: Re: [siprec] FW: IETF 91 Final Agenda - SIPREC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 06:36:01 -0000 Hi Andy, Couple of weeks we brought up including Session-ID in the metadata. I have not seen any objections for this, however we can present this in the meeting and get consensus to add to metadata. Let me know your opinion on whether this needs to be presented in room. If yes we would need 10 mins for this. Regards, Ram -----Original Message----- From: , Andrew Date: Tuesday, 21 October 2014 3:54 pm To: "siprec@ietf.org" Subject: [siprec] FW: IETF 91 Final Agenda - SIPREC > >SIPREC has a one hour slot on Tuesday morning (See >https://datatracker.ietf.org/meeting/91/agenda.html) > >Please let the chairs know if you want to present. > >Regards >Andy > > > >> -----Original Message----- >> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of IETF Agenda >> Sent: Samstag, 18. Oktober 2014 02:25 >> To: IETF Announcement List >> Cc: ietf@ietf.org >> Subject: IETF 91 Final Agenda >>=20 >> 91st IETF Meeting - Honolulu, HI, USA >> November 9 - 14, 2014 >>=20 >> The final agenda is now available. >>=20 >> https://datatracker.ietf.org/meeting/91/agenda.html >> https://datatracker.ietf.org/meeting/91/agenda.txt >>=20 >> While this is considered the final agenda for printing, changes may be >>made >> to the agenda up until and during the meeting. Updates will be >>reflected on >> the web version of the agenda. >>=20 >> Information about the 91st IETF meeting in Honolulu, HI, USA can be >>found >> here: https://www.ietf.org/meeting/91/index.html >>=20 >> Thank you and see you in Honolulu! >>=20 >> Sincerely, >>=20 >> The IETF Secretariat > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From nobody Thu Oct 23 03:07:36 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE0D1A8AA4 for ; Thu, 23 Oct 2014 03:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUGW3X5Q_8Ie for ; Thu, 23 Oct 2014 03:07:28 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 55BA11A8AC3 for ; Thu, 23 Oct 2014 03:07:17 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 91A0023F0531; Thu, 23 Oct 2014 12:07:16 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 12:07:16 +0200 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" Thread-Topic: [siprec] FW: IETF 91 Final Agenda - SIPREC Thread-Index: AQHP7ouZvYCKBkPadUyvkyAKljrqxJw9dHKw Date: Thu, 23 Oct 2014 10:07:15 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5D2073@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/hlcEm1H4ozU5yanYB8tDQ1ncg0E Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: IETF 91 Final Agenda - SIPREC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 10:07:32 -0000 Hi Ram, As you say there has not been any objections on the list so I suggest you g= o ahead and make a proposal for some text and submit a draft. Unless your proposed text brings up some issues then personally I don't thi= nk we need meeting time for that. Regards Andy > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 23 October 2014 07:36 > To: Hutton, Andrew; siprec@ietf.org > Subject: Re: [siprec] FW: IETF 91 Final Agenda - SIPREC >=20 > Hi Andy, >=20 > Couple of weeks we brought up including Session-ID in the metadata. I > have > not seen any objections for this, however we can present this in the > meeting and get consensus to add to metadata. Let me know your opinion > on > whether this needs to be presented in room. If yes we would need 10 > mins > for this. >=20 > Regards, > Ram >=20 > -----Original Message----- > From: , Andrew > Date: Tuesday, 21 October 2014 3:54 pm > To: "siprec@ietf.org" > Subject: [siprec] FW: IETF 91 Final Agenda - SIPREC >=20 > > > >SIPREC has a one hour slot on Tuesday morning (See > >https://datatracker.ietf.org/meeting/91/agenda.html) > > > >Please let the chairs know if you want to present. > > > >Regards > >Andy > > > > > > > >> -----Original Message----- > >> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of IETF Agenda > >> Sent: Samstag, 18. Oktober 2014 02:25 > >> To: IETF Announcement List > >> Cc: ietf@ietf.org > >> Subject: IETF 91 Final Agenda > >> > >> 91st IETF Meeting - Honolulu, HI, USA > >> November 9 - 14, 2014 > >> > >> The final agenda is now available. > >> > >> https://datatracker.ietf.org/meeting/91/agenda.html > >> https://datatracker.ietf.org/meeting/91/agenda.txt > >> > >> While this is considered the final agenda for printing, changes may > be > >>made > >> to the agenda up until and during the meeting. Updates will be > >>reflected on > >> the web version of the agenda. > >> > >> Information about the 91st IETF meeting in Honolulu, HI, USA can be > >>found > >> here: https://www.ietf.org/meeting/91/index.html > >> > >> Thank you and see you in Honolulu! > >> > >> Sincerely, > >> > >> The IETF Secretariat > > > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec From nobody Thu Oct 23 07:28:37 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEF81A9023 for ; Thu, 23 Oct 2014 07:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mr-HDiqCBrqD for ; Thu, 23 Oct 2014 07:28:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C130E1A8F4F for ; Thu, 23 Oct 2014 07:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3131; q=dns/txt; s=iport; t=1414074514; x=1415284114; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=J1pYAdyeGfQTf93CUKrXYX+TpHlkvVKYH+hYEJu/7lw=; b=Rsh2U98hwzjmNxX1QOj8dL0BEq30BGLTQpVWrsJB8J8K+GpCv2y1G8FJ 7qnnNd/d75LL2HIt8Llj5Y6fSnFW0J/TpB+okghHe1zwdtI33qD/NB17K gz2ng7bNrsQGJIXmQumo6AFW/jk37U8JgMf1Mjuur1vPTpYufnJvL1QRS g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAIwPSVStJA2L/2dsb2JhbABcgw5UXMx0CoZ5VAKBEhYBfYQCAQEBBAEBATc0BQYMBAIBCBEDAQEBHwkHJwsUCAEIAgQOBYhBDcd3AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPdhEBJSsCBQIEhEUFkgWERocSgTGDSY0yhAGDeGwBgQ45gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,775,1406592000"; d="scan'208";a="365860295" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 23 Oct 2014 14:28:34 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9NESXKs031342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 14:28:33 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.26]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 09:28:33 -0500 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" Thread-Topic: [siprec] FW: IETF 91 Final Agenda - SIPREC Thread-Index: AQHP7s2fVao2TvlAwkeyVh1CHZHD6w== Date: Thu, 23 Oct 2014 14:28:32 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF1E5D2073@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E5D2073@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.70.62] Content-Type: text/plain; charset="us-ascii" Content-ID: <1F5A118D494BDB4489BE74EA4A41E23F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/dtbk9KVzFGUk2qz8dckxvV8ejJ8 Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: IETF 91 Final Agenda - SIPREC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 14:28:36 -0000 Hi Andy, Sure. I will send the proposed text to the mailing list. I think we can add Carrying Session-ID in the Metadata as another section to Metadata draft. I see your below email says "make a proposal for some text and submit a draft" Did you meant a separate draft ? This should just another section to the metadata draft. Ram -----Original Message----- From: , Andrew Date: Thursday, 23 October 2014 3:37 pm To: Cisco Employee Cc: "siprec@ietf.org" Subject: RE: [siprec] FW: IETF 91 Final Agenda - SIPREC >Hi Ram, > >As you say there has not been any objections on the list so I suggest you >go ahead and make a proposal for some text and submit a draft. > >Unless your proposed text brings up some issues then personally I don't >think we need meeting time for that. > >Regards >Andy > > > >> -----Original Message----- >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> Sent: 23 October 2014 07:36 >> To: Hutton, Andrew; siprec@ietf.org >> Subject: Re: [siprec] FW: IETF 91 Final Agenda - SIPREC >>=20 >> Hi Andy, >>=20 >> Couple of weeks we brought up including Session-ID in the metadata. I >> have >> not seen any objections for this, however we can present this in the >> meeting and get consensus to add to metadata. Let me know your opinion >> on >> whether this needs to be presented in room. If yes we would need 10 >> mins >> for this. >>=20 >> Regards, >> Ram >>=20 >> -----Original Message----- >> From: , Andrew >> Date: Tuesday, 21 October 2014 3:54 pm >> To: "siprec@ietf.org" >> Subject: [siprec] FW: IETF 91 Final Agenda - SIPREC >>=20 >> > >> >SIPREC has a one hour slot on Tuesday morning (See >> >https://datatracker.ietf.org/meeting/91/agenda.html) >> > >> >Please let the chairs know if you want to present. >> > >> >Regards >> >Andy >> > >> > >> > >> >> -----Original Message----- >> >> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of IETF Agenda >> >> Sent: Samstag, 18. Oktober 2014 02:25 >> >> To: IETF Announcement List >> >> Cc: ietf@ietf.org >> >> Subject: IETF 91 Final Agenda >> >> >> >> 91st IETF Meeting - Honolulu, HI, USA >> >> November 9 - 14, 2014 >> >> >> >> The final agenda is now available. >> >> >> >> https://datatracker.ietf.org/meeting/91/agenda.html >> >> https://datatracker.ietf.org/meeting/91/agenda.txt >> >> >> >> While this is considered the final agenda for printing, changes may >> be >> >>made >> >> to the agenda up until and during the meeting. Updates will be >> >>reflected on >> >> the web version of the agenda. >> >> >> >> Information about the 91st IETF meeting in Honolulu, HI, USA can be >> >>found >> >> here: https://www.ietf.org/meeting/91/index.html >> >> >> >> Thank you and see you in Honolulu! >> >> >> >> Sincerely, >> >> >> >> The IETF Secretariat >> > >> >_______________________________________________ >> >siprec mailing list >> >siprec@ietf.org >> >https://www.ietf.org/mailman/listinfo/siprec > From nobody Thu Oct 23 07:38:13 2014 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F92C1A8F49 for ; Thu, 23 Oct 2014 07:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhGxziCM0BUD for ; Thu, 23 Oct 2014 07:38:01 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 636A61A9039 for ; Thu, 23 Oct 2014 07:38:01 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 49A7123F0655; Thu, 23 Oct 2014 16:38:00 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 16:37:59 +0200 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" Thread-Topic: [siprec] FW: IETF 91 Final Agenda - SIPREC Thread-Index: AQHP7ouZvYCKBkPadUyvkyAKljrqxJw9dHKwgAAoLQCAACPr0A== Date: Thu, 23 Oct 2014 14:37:59 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5D27EC@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E5D2073@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/cJw9GL4NN1Krh0bpxwuCrhkQIPc Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: IETF 91 Final Agenda - SIPREC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 14:38:11 -0000 Sorry I meant submit an update to the draft. Not a separate draft. Andy > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 23 October 2014 15:29 > To: Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] FW: IETF 91 Final Agenda - SIPREC >=20 > Hi Andy, >=20 > Sure. I will send the proposed text to the mailing list. I think we can > add Carrying Session-ID in the Metadata as another section to Metadata > draft. I see your below email says "make a proposal for some text and > submit a draft" Did you meant a separate draft ? >=20 > This should just another section to the metadata draft. >=20 > Ram >=20 > -----Original Message----- > From: , Andrew > Date: Thursday, 23 October 2014 3:37 pm > To: Cisco Employee > Cc: "siprec@ietf.org" > Subject: RE: [siprec] FW: IETF 91 Final Agenda - SIPREC >=20 > >Hi Ram, > > > >As you say there has not been any objections on the list so I suggest > you > >go ahead and make a proposal for some text and submit a draft. > > > >Unless your proposed text brings up some issues then personally I > don't > >think we need meeting time for that. > > > >Regards > >Andy > > > > > > > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >> Sent: 23 October 2014 07:36 > >> To: Hutton, Andrew; siprec@ietf.org > >> Subject: Re: [siprec] FW: IETF 91 Final Agenda - SIPREC > >> > >> Hi Andy, > >> > >> Couple of weeks we brought up including Session-ID in the metadata. > I > >> have > >> not seen any objections for this, however we can present this in the > >> meeting and get consensus to add to metadata. Let me know your > opinion > >> on > >> whether this needs to be presented in room. If yes we would need 10 > >> mins > >> for this. > >> > >> Regards, > >> Ram > >> > >> -----Original Message----- > >> From: , Andrew > >> Date: Tuesday, 21 October 2014 3:54 pm > >> To: "siprec@ietf.org" > >> Subject: [siprec] FW: IETF 91 Final Agenda - SIPREC > >> > >> > > >> >SIPREC has a one hour slot on Tuesday morning (See > >> >https://datatracker.ietf.org/meeting/91/agenda.html) > >> > > >> >Please let the chairs know if you want to present. > >> > > >> >Regards > >> >Andy > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of IETF > Agenda > >> >> Sent: Samstag, 18. Oktober 2014 02:25 > >> >> To: IETF Announcement List > >> >> Cc: ietf@ietf.org > >> >> Subject: IETF 91 Final Agenda > >> >> > >> >> 91st IETF Meeting - Honolulu, HI, USA > >> >> November 9 - 14, 2014 > >> >> > >> >> The final agenda is now available. > >> >> > >> >> https://datatracker.ietf.org/meeting/91/agenda.html > >> >> https://datatracker.ietf.org/meeting/91/agenda.txt > >> >> > >> >> While this is considered the final agenda for printing, changes > may > >> be > >> >>made > >> >> to the agenda up until and during the meeting. Updates will be > >> >>reflected on > >> >> the web version of the agenda. > >> >> > >> >> Information about the 91st IETF meeting in Honolulu, HI, USA can > be > >> >>found > >> >> here: https://www.ietf.org/meeting/91/index.html > >> >> > >> >> Thank you and see you in Honolulu! > >> >> > >> >> Sincerely, > >> >> > >> >> The IETF Secretariat > >> > > >> >_______________________________________________ > >> >siprec mailing list > >> >siprec@ietf.org > >> >https://www.ietf.org/mailman/listinfo/siprec > >