From rifatyu@avaya.com Sun May 1 08:41:21 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB3DE06CD for ; Sun, 1 May 2011 08:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oqz23i6UWDN4 for ; Sun, 1 May 2011 08:41:20 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 66687E0659 for ; Sun, 1 May 2011 08:41:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIB9vU2HCzI1/2dsb2JhbACmHXepIQKZBYYABJMvigg X-IronPort-AV: E=Sophos;i="4.64,298,1301889600"; d="scan'208";a="186612616" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 01 May 2011 11:41:16 -0400 X-IronPort-AV: E=Sophos;i="4.64,298,1301889600"; d="scan'208";a="645768352" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 May 2011 11:41:16 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Sun, 1 May 2011 11:41:15 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat Date: Sun, 1 May 2011 11:41:14 -0400 Thread-Topic: [splices] Answering a Call Using Two Separate Devices proposal Thread-Index: AcwFAXKAyZ5nmzYAQ5eLfIWePgR6tQDE5OMg Message-ID: <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> In-Reply-To: <4DB853B0.5060506@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 15:41:21 -0000 Hi, In the following flow, I have tried to incorporate all the feedback that I = received so far. The only open issue that I am aware of is the issue of what to present to t= he user on the PC when the phone initiates a video call to the PC (see (#) = below). Can you please review the flow below and let me know if we have any other o= pen issues? Regards, Rifaat Alice Alice Proxy Bob PC Desk Phone =20 | | | | | | | | Both Alice's devices subscribe to the reg event package, which allows each = device to=20 discover the capabilities of the other device based on the feature tags pro= vided by each device. The Desk Phone knows that the PC supports Video, while the PC knows that th= e Desk Phone only supports audio. | | | | | | SUBSCRIBE reg | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | SUBSCRIBE reg | | | |------------------------------------------>| | | 200 OK | | | |<------------------------------------------| | | | | | | | | | The two devices also subscribe to the dialog of each other. | | | | | | | | | SUBSCRIBE dialog | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | | SUBSCRIBE dialog | | | |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | | | | | The scenario starts with an audio call from Bob to Alice | | | | | | | INVITE Alice [Audio]| | | |<--------------------| | | INVITE Alice [Audio]| | | |<--------------------| | | INVITE Alice [Audio]| | | |<------------------------------------------| | | | | | Let's assume that Alice used her PC to instruct the phone to answer the cal= l =20 | | | | | REFER Refer-To: urn:sip-action:call:answer;transducer=3Dspeaker|heads= et |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | | | 200 OK [Audio] | | | |-------------------->| | | | | 200 OK [Audio] | | | |-------------------->| | CANCEL | | | |<------------------------------------------| | | | | | | |<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | | | | =20 (*) | | | | | | | | | | | | The following is a re-INVITE from the remote party (Bob) to add video to th= e existing audio call | | | | | | | reINVITE Alice [A/V]| | | |<--------------------| | | reINVITE Alice [A/V]| | | |<--------------------| | | | 100 Trying | | | |-------------------->| | | | | 100 Trying | | | |-------------------->| | | | | The Desk Phone cannot handle video, but it knows that the PC can handle vid= eo,=20 so the Desk Phone initiates a new video INVITE to the PC. Alert-Info is used to control the alerting level.=20 | | | | | | | | (#) | INVITE [Video] | | | | Alert-Info: whatever | | |<--------------------| | | | 180 | | | |-------------------->| | | | | | | The user can answer the video call using his PC, which would result on=20 200 OK with video answer being sent to the phone. If the user chose to answer the incoming video call using his Desk Phone,=20 the following REFER will be sent to the PC, before the 200 OK with the=20 video answer is sent from the PC. | | | | | REFER Refer-To: urn:sip-action:call:answer | |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | | 200 OK [Video] | | | |-------------------->| | | | | | | | | 200 OK [A/V] | | | |-------------------->| | | | | 200 OK [A/V] | | | |-------------------->| | | | | |<----dialog2-------->|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | | | | =20 =20 Now let's assume that Alice is the side that wants to add video to the=20 existing audio call. The scenario continues after the (*) above. Alice can use her phone to add video to the existing audio call. The phone must present a UI to Alice to allow her to do just that. If Alice chooses to use her phone, the following REFER will be sent from the phone to the PC= ,=20 which will instruct the PC to immediately send an INVITE with video offer | REFER Refer-To: urn:sip-action:call:join;dialog=3Ddialog1;media=3Dvid= eo |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | Alice can use her PC to add video to the existing audio call. The PC knows that there is an existing dialog between the Desk Phone=20 and Bob and present this to Alice for her to choose if she wants to=20 add video to the existing audio call or not. In this case Alice chose=20 to add video to the existing audio call, so the PC sends the following request: | | | | | | | | | INVITE with Join [Video] | | |-------------------->| | | | 100 | | | |<--------------------| | | | | re-INVITE [A/V] | | | |-------------------->| | | | | re-INVITE [A/V] | | | |-------------------->| | | | 200 OK [A/V] | | | 200 OK [A/V] |<--------------------| | |<--------------------| | | 200 OK [Video] | | | |<--------------------| | | | | | | | | | | |<----dialog2-------->|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | | | | | | | | From pkyzivat@cisco.com Sun May 1 15:09:47 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF07E06D3 for ; Sun, 1 May 2011 15:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ah1a0UJlAg6 for ; Sun, 1 May 2011 15:09:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 92368E06CC for ; Sun, 1 May 2011 15:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=13701; q=dns/txt; s=iport; t=1304287785; x=1305497385; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SrEHOwnQ4Xg+h/IoW3DpqDdYs6bx4dmXOo+N5hY51a8=; b=POKi1VKr+UsVlL2O0dUjDjUD45xu5tGlyEIwmGBTrKv1fT9FbVRwT/Cr VFmU0VQQmTfpQUKZ6NIRQGfHYREgPnCTqG47eGyhgKZppx/gQhgiQMOy/ pE6GnH3gCGOJmw7BaI7fmocaaW1VcQfMwS3bbQIowR+kKB5V1CgQIsNpD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJbZvU2tJV2Y/2dsb2JhbACmHXelWZsshgAEjnmEGYol X-IronPort-AV: E=Sophos;i="4.64,299,1301875200"; d="scan'208";a="690135450" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 01 May 2011 22:09:44 +0000 Received: from [10.86.253.168] ([10.86.253.168]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p41M9hiO004237; Sun, 1 May 2011 22:09:44 GMT Message-ID: <4DBDDA27.5060804@cisco.com> Date: Sun, 01 May 2011 18:09:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "splices@ietf.org" Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 22:09:47 -0000 Yes, this seems reasonable to me. The specific refer actions are a little speculative and can be debated, but for now they're just examples, and I think we could work them out. I've included one suggested wording revision inline below. Thanks, Paul P.S. While we don't necessarily need to deal with it here and now, ISTM it would be useful to work out some best practices for how to manage multiple media in order to get the best user experience. E.g.: - when/how do devices with multiple media capabilities announce those capabilities? (This scenario has suggested doing so in registrations. Are the same capabilities announced as contact params on INVITEs, etc.?) - Should media capabilities be announced in SDP, even if there is no intent to use them at the moment? E.g. using the SDP capneg framework, or perhaps by "offering" extra media with port set to zero, or with a=inactive? - when forced to make an offer (by receipt of an INVITE without offer), what media should be offered? Should the UAS defer the decision until it can alert and get feedback to the alert about which media the callee wants to use? Or should UAs be user configurable with the media to initially offer, so they can offer *something* quickly. - in the latter case, should the UAS, while alerting, provide a way for the user to influence which media are used in the call? (via another o/a before answer). Not having anything like this opens call flows such as this one up to much haggling over what assumptions it makes about behavior of the UAs. On 5/1/2011 11:41 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Hi, > > In the following flow, I have tried to incorporate all the feedback that I received so far. > The only open issue that I am aware of is the issue of what to present to the user on the PC when the phone initiates a video call to the PC (see (#) below). > > Can you please review the flow below and let me know if we have any other open issues? > > Regards, > Rifaat > > > > Alice Alice Proxy Bob > PC Desk Phone > | | | | > | | | | > Both Alice's devices subscribe to the reg event package, which allows each device to > discover the capabilities of the other device based on the feature tags provided by each device. > The Desk Phone knows that the PC supports Video, while the PC knows that the Desk Phone only supports audio. In the last sentence above, it might be clearer to say "The Desk Phone *learns* that the PC supports Video, while the PC *learns* that the Desk Phone only supports Audio." > | | | | > | | SUBSCRIBE reg | | > | |-------------------->| | > | | 200 OK | | > | |<--------------------| | > | | | | > | SUBSCRIBE reg | | | > |------------------------------------------>| | > | 200 OK | | | > |<------------------------------------------| | > | | | | > | | | | > The two devices also subscribe to the dialog of each other. > | | | | > | | | | > | SUBSCRIBE dialog | | | > |-------------------->| | | > | 200 OK | | | > |<--------------------| | | > | | | | > | SUBSCRIBE dialog | | | > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | > | | | | > The scenario starts with an audio call from Bob to Alice > | | | | > | | | INVITE Alice [Audio]| > | | |<--------------------| > | | INVITE Alice [Audio]| | > | |<--------------------| | > | INVITE Alice [Audio]| | | > |<------------------------------------------| | > | | | | > Let's assume that Alice used her PC to instruct the phone to answer the call > | | | | > | REFER Refer-To: urn:sip-action:call:answer;transducer=speaker|headset > |-------------------->| | | > | 200 OK | | | > |<--------------------| | | > | | | | > | | 200 OK [Audio] | | > | |-------------------->| | > | | | 200 OK [Audio] | > | | |-------------------->| > | CANCEL | | | > |<------------------------------------------| | > | | | | > | |<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > | | | | > | | | | > > (*) > > | | | | > | | | | > | | | | > The following is a re-INVITE from the remote party (Bob) to add video to the existing audio call > | | | | > | | | reINVITE Alice [A/V]| > | | |<--------------------| > | | reINVITE Alice [A/V]| | > | |<--------------------| | > | | 100 Trying | | > | |-------------------->| | > | | | 100 Trying | > | | |-------------------->| > | | | | > The Desk Phone cannot handle video, but it knows that the PC can handle video, > so the Desk Phone initiates a new video INVITE to the PC. > Alert-Info is used to control the alerting level. > | | | | > | | | | > (#) | INVITE [Video] | | | > | Alert-Info: whatever | | > |<--------------------| | | > | 180 | | | > |-------------------->| | | > | | | | > The user can answer the video call using his PC, which would result on > 200 OK with video answer being sent to the phone. > If the user chose to answer the incoming video call using his Desk Phone, > the following REFER will be sent to the PC, before the 200 OK with the > video answer is sent from the PC. > | | | | > | REFER Refer-To: urn:sip-action:call:answer | > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | > | 200 OK [Video] | | | > |-------------------->| | | > | | | | > | | 200 OK [A/V] | | > | |-------------------->| | > | | | 200 OK [A/V] | > | | |-------------------->| > | | | | > |<----dialog2-------->|<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > |<============================video==============================>| > | | | | > | | | | > > > > Now let's assume that Alice is the side that wants to add video to the > existing audio call. The scenario continues after the (*) above. > > Alice can use her phone to add video to the existing audio call. The phone > must present a UI to Alice to allow her to do just that. If Alice chooses > to use her phone, the following REFER will be sent from the phone to the PC, > which will instruct the PC to immediately send an INVITE with video offer > > | REFER Refer-To: urn:sip-action:call:join;dialog=dialog1;media=video > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | > > Alice can use her PC to add video to the existing audio call. > The PC knows that there is an existing dialog between the Desk Phone > and Bob and present this to Alice for her to choose if she wants to > add video to the existing audio call or not. In this case Alice chose > to add video to the existing audio call, so the PC sends the following > request: > | | | | > | | | | > | INVITE with Join [Video] | | > |-------------------->| | | > | 100 | | | > |<--------------------| | | > | | re-INVITE [A/V] | | > | |-------------------->| | > | | | re-INVITE [A/V] | > | | |-------------------->| > | | | 200 OK [A/V] | > | | 200 OK [A/V] |<--------------------| > | |<--------------------| | > | 200 OK [Video] | | | > |<--------------------| | | > | | | | > | | | | > |<----dialog2-------->|<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > |<============================video==============================>| > | | | | > | | | | > | | | | > > > > From spromano@unina.it Mon May 2 04:04:40 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F67E06A4 for ; Mon, 2 May 2011 04:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.789 X-Spam-Level: X-Spam-Status: No, score=-99.789 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMMFcRXlPLL4 for ; Mon, 2 May 2011 04:04:39 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id AA544E0682 for ; Mon, 2 May 2011 04:04:36 -0700 (PDT) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id p42B4RAS021459 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 2 May 2011 13:04:27 +0200 Message-ID: <4DBE8FB0.7040304@unina.it> Date: Mon, 02 May 2011 13:04:16 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" , Salvatore Loreto References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "splices@ietf.org" Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 11:04:40 -0000 Hi Rifaat, my personal feeling (as an individual) is that most of the open issues that arose on the ML have been successfully tackled now. Indeed, this thread is extremely interesting and sheds light on the main features that any solution should provide. With my chair hat on, I would suggest that you and Salvatore work together on a framework document which does not contain any pointer to already identified solutions, but rather highlights the issues and defines the requirements. Such document would actually fulfill the envisaged milestone of our charter. Once done with this, we can rapidly move to subsequent documents which start delving into the details of the poptential solutions. Cheers, Simon Il 01/05/2011 17:41, Shekh-Yusef, Rifaat (Rifaat) ha scritto: > Hi, > > In the following flow, I have tried to incorporate all the feedback that I received so far. > The only open issue that I am aware of is the issue of what to present to the user on the PC when the phone initiates a video call to the PC (see (#) below). > > Can you please review the flow below and let me know if we have any other open issues? > > Regards, > Rifaat > > > > Alice Alice Proxy Bob > PC Desk Phone > | | | | > | | | | > Both Alice's devices subscribe to the reg event package, which allows each device to > discover the capabilities of the other device based on the feature tags provided by each device. > The Desk Phone knows that the PC supports Video, while the PC knows that the Desk Phone only supports audio. > | | | | > | | SUBSCRIBE reg | | > | |-------------------->| | > | | 200 OK | | > | |<--------------------| | > | | | | > | SUBSCRIBE reg | | | > |------------------------------------------>| | > | 200 OK | | | > |<------------------------------------------| | > | | | | > | | | | > The two devices also subscribe to the dialog of each other. > | | | | > | | | | > | SUBSCRIBE dialog | | | > |-------------------->| | | > | 200 OK | | | > |<--------------------| | | > | | | | > | SUBSCRIBE dialog | | | > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | > | | | | > The scenario starts with an audio call from Bob to Alice > | | | | > | | | INVITE Alice [Audio]| > | | |<--------------------| > | | INVITE Alice [Audio]| | > | |<--------------------| | > | INVITE Alice [Audio]| | | > |<------------------------------------------| | > | | | | > Let's assume that Alice used her PC to instruct the phone to answer the call > | | | | > | REFER Refer-To: urn:sip-action:call:answer;transducer=speaker|headset > |-------------------->| | | > | 200 OK | | | > |<--------------------| | | > | | | | > | | 200 OK [Audio] | | > | |-------------------->| | > | | | 200 OK [Audio] | > | | |-------------------->| > | CANCEL | | | > |<------------------------------------------| | > | | | | > | |<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > | | | | > | | | | > > (*) > > | | | | > | | | | > | | | | > The following is a re-INVITE from the remote party (Bob) to add video to the existing audio call > | | | | > | | | reINVITE Alice [A/V]| > | | |<--------------------| > | | reINVITE Alice [A/V]| | > | |<--------------------| | > | | 100 Trying | | > | |-------------------->| | > | | | 100 Trying | > | | |-------------------->| > | | | | > The Desk Phone cannot handle video, but it knows that the PC can handle video, > so the Desk Phone initiates a new video INVITE to the PC. > Alert-Info is used to control the alerting level. > | | | | > | | | | > (#) | INVITE [Video] | | | > | Alert-Info: whatever | | > |<--------------------| | | > | 180 | | | > |-------------------->| | | > | | | | > The user can answer the video call using his PC, which would result on > 200 OK with video answer being sent to the phone. > If the user chose to answer the incoming video call using his Desk Phone, > the following REFER will be sent to the PC, before the 200 OK with the > video answer is sent from the PC. > | | | | > | REFER Refer-To: urn:sip-action:call:answer | > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | > | 200 OK [Video] | | | > |-------------------->| | | > | | | | > | | 200 OK [A/V] | | > | |-------------------->| | > | | | 200 OK [A/V] | > | | |-------------------->| > | | | | > |<----dialog2-------->|<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > |<============================video==============================>| > | | | | > | | | | > > > > Now let's assume that Alice is the side that wants to add video to the > existing audio call. The scenario continues after the (*) above. > > Alice can use her phone to add video to the existing audio call. The phone > must present a UI to Alice to allow her to do just that. If Alice chooses > to use her phone, the following REFER will be sent from the phone to the PC, > which will instruct the PC to immediately send an INVITE with video offer > > | REFER Refer-To: urn:sip-action:call:join;dialog=dialog1;media=video > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | > > Alice can use her PC to add video to the existing audio call. > The PC knows that there is an existing dialog between the Desk Phone > and Bob and present this to Alice for her to choose if she wants to > add video to the existing audio call or not. In this case Alice chose > to add video to the existing audio call, so the PC sends the following > request: > | | | | > | | | | > | INVITE with Join [Video] | | > |-------------------->| | | > | 100 | | | > |<--------------------| | | > | | re-INVITE [A/V] | | > | |-------------------->| | > | | | re-INVITE [A/V] | > | | |-------------------->| > | | | 200 OK [A/V] | > | | 200 OK [A/V] |<--------------------| > | |<--------------------| | > | 200 OK [Video] | | | > |<--------------------| | | > | | | | > | | | | > |<----dialog2-------->|<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > |<============================video==============================>| > | | | | > | | | | > | | | | > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From peter.musgrave@magorcorp.com Mon May 2 06:45:50 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBFFE06EA for ; Mon, 2 May 2011 06:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wTMw+B3Z9uA for ; Mon, 2 May 2011 06:45:49 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAC9E0688 for ; Mon, 2 May 2011 06:45:49 -0700 (PDT) Received: by gyf3 with SMTP id 3so2393972gyf.31 for ; Mon, 02 May 2011 06:45:48 -0700 (PDT) Received: by 10.151.62.14 with SMTP id p14mr6709019ybk.30.1304343947100; Mon, 02 May 2011 06:45:47 -0700 (PDT) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id v15sm2361389ybk.21.2011.05.02.06.45.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2011 06:45:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> Date: Mon, 2 May 2011 09:45:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> To: "Shekh-Yusef, Rifaat (Rifaat)" X-Mailer: Apple Mail (2.1084) Cc: "splices@ietf.org" Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 13:45:50 -0000 Hi Rifaat,=20 I think this works well. Thanks for re-stating this clearly.=20 I see a couple of next steps here: - how is in incoming call which has an initial A+V answered? - how is an outgoing call which has an initial A+V audio created? - if both ends are "loosely coupled" are there any optimizations or = shortcuts that seem worthwhile? I don't think there is anything too tricky about these - but they will = need to be worked through. I agree with Simon that it seems time to = start to capture this work in a draft.=20 Regards,=20 Peter Musgrave On 2011-05-01, at 11:41 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Hi, >=20 > In the following flow, I have tried to incorporate all the feedback = that I received so far. > The only open issue that I am aware of is the issue of what to present = to the user on the PC when the phone initiates a video call to the PC = (see (#) below). >=20 > Can you please review the flow below and let me know if we have any = other open issues? >=20 > Regards, > Rifaat >=20 >=20 >=20 > Alice Alice Proxy = Bob > PC Desk Phone =20= > | | | | > | | | | > Both Alice's devices subscribe to the reg event package, which allows = each device to=20 > discover the capabilities of the other device based on the feature = tags provided by each device. > The Desk Phone knows that the PC supports Video, while the PC knows = that the Desk Phone only supports audio. > | | | | > | | SUBSCRIBE reg | | > | |-------------------->| | > | | 200 OK | | > | |<--------------------| | > | | | | > | SUBSCRIBE reg | | | > |------------------------------------------>| | > | 200 OK | | | > |<------------------------------------------| | > | | | | > | | | | > The two devices also subscribe to the dialog of each other. > | | | | > | | | | > | SUBSCRIBE dialog | | | > |-------------------->| | | > | 200 OK | | | > |<--------------------| | | > | | | | > | SUBSCRIBE dialog | | | > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | > | | | | > The scenario starts with an audio call from Bob to Alice > | | | | > | | | INVITE Alice [Audio]| > | | |<--------------------| > | | INVITE Alice [Audio]| | > | |<--------------------| | > | INVITE Alice [Audio]| | | > |<------------------------------------------| | > | | | | > Let's assume that Alice used her PC to instruct the phone to answer = the call =20 > | | | | > | REFER Refer-To: = urn:sip-action:call:answer;transducer=3Dspeaker|headset > |-------------------->| | | > | 200 OK | | | > |<--------------------| | | > | | | | > | | 200 OK [Audio] | | > | |-------------------->| | > | | | 200 OK [Audio] | > | | |-------------------->| > | CANCEL | | | > |<------------------------------------------| | > | | | | > | |<---dialog1------------------------------->| > | | | | > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > | | | | > | | | | >=20 > (*) >=20 > | | | | > | | | | > | | | | > The following is a re-INVITE from the remote party (Bob) to add video = to the existing audio call > | | | | > | | | reINVITE Alice [A/V]| > | | |<--------------------| > | | reINVITE Alice [A/V]| | > | |<--------------------| | > | | 100 Trying | | > | |-------------------->| | > | | | 100 Trying | > | | |-------------------->| > | | | | > The Desk Phone cannot handle video, but it knows that the PC can = handle video,=20 > so the Desk Phone initiates a new video INVITE to the PC. > Alert-Info is used to control the alerting level.=20 > | | | | > | | | | > (#) | INVITE [Video] | | = | > | Alert-Info: whatever | | > |<--------------------| | | > | 180 | | | > |-------------------->| | | > | | | | > The user can answer the video call using his PC, which would result on=20= > 200 OK with video answer being sent to the phone. > If the user chose to answer the incoming video call using his Desk = Phone,=20 > the following REFER will be sent to the PC, before the 200 OK with the=20= > video answer is sent from the PC. > | | | | > | REFER Refer-To: urn:sip-action:call:answer | > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | > | 200 OK [Video] | | | > |-------------------->| | | > | | | | > | | 200 OK [A/V] | | > | |-------------------->| | > | | | 200 OK [A/V] | > | | |-------------------->| > | | | | > |<----dialog2-------->|<---dialog1------------------------------->| > | | | | > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > | | | | > | | | | >=20 >=20 >=20 > Now let's assume that Alice is the side that wants to add video to the=20= > existing audio call. The scenario continues after the (*) above. >=20 > Alice can use her phone to add video to the existing audio call. The = phone > must present a UI to Alice to allow her to do just that. If Alice = chooses > to use her phone, the following REFER will be sent from the phone to = the PC,=20 > which will instruct the PC to immediately send an INVITE with video = offer >=20 > | REFER Refer-To: = urn:sip-action:call:join;dialog=3Ddialog1;media=3Dvideo > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | >=20 > Alice can use her PC to add video to the existing audio call. > The PC knows that there is an existing dialog between the Desk Phone=20= > and Bob and present this to Alice for her to choose if she wants to=20 > add video to the existing audio call or not. In this case Alice chose=20= > to add video to the existing audio call, so the PC sends the following > request: > | | | | > | | | | > | INVITE with Join [Video] | | > |-------------------->| | | > | 100 | | | > |<--------------------| | | > | | re-INVITE [A/V] | | > | |-------------------->| | > | | | re-INVITE [A/V] | > | | |-------------------->| > | | | 200 OK [A/V] | > | | 200 OK [A/V] |<--------------------| > | |<--------------------| | > | 200 OK [Video] | | | > |<--------------------| | | > | | | | > | | | | > |<----dialog2-------->|<---dialog1------------------------------->| > | | | | > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > | | | | > | | | | > | | | | >=20 >=20 >=20 > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From salvatore.loreto@ericsson.com Mon May 2 07:13:46 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F3AE0678 for ; Mon, 2 May 2011 07:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZwWZYoKSG+h for ; Mon, 2 May 2011 07:13:45 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0F085E0675 for ; Mon, 2 May 2011 07:13:44 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-de-4dbebc170b3f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5A.5E.28525.71CBEBD4; Mon, 2 May 2011 16:13:43 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 2 May 2011 16:13:43 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EEA7A246A for ; Mon, 2 May 2011 17:13:42 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A359050623 for ; Mon, 2 May 2011 17:13:42 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2B89F4F9EF for ; Mon, 2 May 2011 17:13:42 +0300 (EEST) Message-ID: <4DBEBC15.5050600@ericsson.com> Date: Mon, 2 May 2011 16:13:41 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: splices@ietf.org References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 14:13:46 -0000 I think it is a good step forward, the only comment I have it is that in order to call it a "loosely coupled" scenario we have still to define what happens if "Alice Desk phone" can not remain in the session for the entire session duration... as the charter defines: The objective of this working group is to develop a framework for disaggregated media in "loosely-coupled" scenarios, where no single device needs to remain in the session for its entire duration and no single device needs to act as a master. /Sal On 5/2/11 3:45 PM, Peter Musgrave wrote: > Hi Rifaat, > > I think this works well. Thanks for re-stating this clearly. > > I see a couple of next steps here: > - how is in incoming call which has an initial A+V answered? > - how is an outgoing call which has an initial A+V audio created? > - if both ends are "loosely coupled" are there any optimizations or shortcuts that seem worthwhile? > > I don't think there is anything too tricky about these - but they will need to be worked through. I agree with Simon that it seems time to start to capture this work in a draft. > > Regards, > > Peter Musgrave > > On 2011-05-01, at 11:41 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > >> Hi, >> >> In the following flow, I have tried to incorporate all the feedback that I received so far. >> The only open issue that I am aware of is the issue of what to present to the user on the PC when the phone initiates a video call to the PC (see (#) below). >> >> Can you please review the flow below and let me know if we have any other open issues? >> >> Regards, >> Rifaat >> >> >> >> Alice Alice Proxy Bob >> PC Desk Phone >> | | | | >> | | | | >> Both Alice's devices subscribe to the reg event package, which allows each device to >> discover the capabilities of the other device based on the feature tags provided by each device. >> The Desk Phone knows that the PC supports Video, while the PC knows that the Desk Phone only supports audio. >> | | | | >> | | SUBSCRIBE reg | | >> | |-------------------->| | >> | | 200 OK | | >> | |<--------------------| | >> | | | | >> | SUBSCRIBE reg | | | >> |------------------------------------------>| | >> | 200 OK | | | >> |<------------------------------------------| | >> | | | | >> | | | | >> The two devices also subscribe to the dialog of each other. >> | | | | >> | | | | >> | SUBSCRIBE dialog | | | >> |-------------------->| | | >> | 200 OK | | | >> |<--------------------| | | >> | | | | >> | SUBSCRIBE dialog | | | >> |<--------------------| | | >> | 200 OK | | | >> |-------------------->| | | >> | | | | >> | | | | >> The scenario starts with an audio call from Bob to Alice >> | | | | >> | | | INVITE Alice [Audio]| >> | | |<--------------------| >> | | INVITE Alice [Audio]| | >> | |<--------------------| | >> | INVITE Alice [Audio]| | | >> |<------------------------------------------| | >> | | | | >> Let's assume that Alice used her PC to instruct the phone to answer the call >> | | | | >> | REFER Refer-To: urn:sip-action:call:answer;transducer=speaker|headset >> |-------------------->| | | >> | 200 OK | | | >> |<--------------------| | | >> | | | | >> | | 200 OK [Audio] | | >> | |-------------------->| | >> | | | 200 OK [Audio] | >> | | |-------------------->| >> | CANCEL | | | >> |<------------------------------------------| | >> | | | | >> | |<---dialog1------------------------------->| >> | | | | >> | |<======audio==============================>| >> | | | | >> | | | | >> >> (*) >> >> | | | | >> | | | | >> | | | | >> The following is a re-INVITE from the remote party (Bob) to add video to the existing audio call >> | | | | >> | | | reINVITE Alice [A/V]| >> | | |<--------------------| >> | | reINVITE Alice [A/V]| | >> | |<--------------------| | >> | | 100 Trying | | >> | |-------------------->| | >> | | | 100 Trying | >> | | |-------------------->| >> | | | | >> The Desk Phone cannot handle video, but it knows that the PC can handle video, >> so the Desk Phone initiates a new video INVITE to the PC. >> Alert-Info is used to control the alerting level. >> | | | | >> | | | | >> (#) | INVITE [Video] | | | >> | Alert-Info: whatever | | >> |<--------------------| | | >> | 180 | | | >> |-------------------->| | | >> | | | | >> The user can answer the video call using his PC, which would result on >> 200 OK with video answer being sent to the phone. >> If the user chose to answer the incoming video call using his Desk Phone, >> the following REFER will be sent to the PC, before the 200 OK with the >> video answer is sent from the PC. >> | | | | >> | REFER Refer-To: urn:sip-action:call:answer | >> |<--------------------| | | >> | 200 OK | | | >> |-------------------->| | | >> | | | | >> | 200 OK [Video] | | | >> |-------------------->| | | >> | | | | >> | | 200 OK [A/V] | | >> | |-------------------->| | >> | | | 200 OK [A/V] | >> | | |-------------------->| >> | | | | >> |<----dialog2-------->|<---dialog1------------------------------->| >> | | | | >> | |<======audio==============================>| >> |<============================video==============================>| >> | | | | >> | | | | >> >> >> >> Now let's assume that Alice is the side that wants to add video to the >> existing audio call. The scenario continues after the (*) above. >> >> Alice can use her phone to add video to the existing audio call. The phone >> must present a UI to Alice to allow her to do just that. If Alice chooses >> to use her phone, the following REFER will be sent from the phone to the PC, >> which will instruct the PC to immediately send an INVITE with video offer >> >> | REFER Refer-To: urn:sip-action:call:join;dialog=dialog1;media=video >> |<--------------------| | | >> | 200 OK | | | >> |-------------------->| | | >> | | | | >> >> Alice can use her PC to add video to the existing audio call. >> The PC knows that there is an existing dialog between the Desk Phone >> and Bob and present this to Alice for her to choose if she wants to >> add video to the existing audio call or not. In this case Alice chose >> to add video to the existing audio call, so the PC sends the following >> request: >> | | | | >> | | | | >> | INVITE with Join [Video] | | >> |-------------------->| | | >> | 100 | | | >> |<--------------------| | | >> | | re-INVITE [A/V] | | >> | |-------------------->| | >> | | | re-INVITE [A/V] | >> | | |-------------------->| >> | | | 200 OK [A/V] | >> | | 200 OK [A/V] |<--------------------| >> | |<--------------------| | >> | 200 OK [Video] | | | >> |<--------------------| | | >> | | | | >> | | | | >> |<----dialog2-------->|<---dialog1------------------------------->| >> | | | | >> | |<======audio==============================>| >> |<============================video==============================>| >> | | | | >> | | | | >> | | | | >> >> >> >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> https://www.ietf.org/mailman/listinfo/splices > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From pkyzivat@cisco.com Mon May 2 12:54:06 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366BCE06B2 for ; Mon, 2 May 2011 12:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.493 X-Spam-Level: X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbGkmVYDJ6Xv for ; Mon, 2 May 2011 12:54:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 31FD0E0693 for ; Mon, 2 May 2011 12:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=8873; q=dns/txt; s=iport; t=1304366045; x=1305575645; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=AR2Uvt9wosHl9+USdDEY0F92cUOE1gheknvaaVQHXWg=; b=CPfdGtzy3pI21nAjE0Mo4oswwgAWmknSIBswYjvDlWAIOdoekX5AZO+5 FZ8Z6PlU0Kd1kXduwshOZTPKUPKx7hpT4H2zxAr9vncEJD+GzmD+3C9l7 +qO4L2bGAKUlNj/YUJDzsouAqBWHANq4rGCAFQqbsABxuyERDfjzKhzzw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHULv02tJXHA/2dsb2JhbACmDXeIcZxbnCqGAASOeYQZiiU X-IronPort-AV: E=Sophos;i="4.64,304,1301875200"; d="scan'208";a="355294151" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-5.cisco.com with ESMTP; 02 May 2011 19:54:04 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p42Js3ng001205 for ; Mon, 2 May 2011 19:54:04 GMT Message-ID: <4DBF0BDB.6080308@cisco.com> Date: Mon, 02 May 2011 15:54:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: splices@ietf.org References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> <4DBEBC15.5050600@ericsson.com> In-Reply-To: <4DBEBC15.5050600@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 19:54:06 -0000 On 5/2/2011 10:13 AM, Salvatore Loreto wrote: > I think it is a good step forward, > > the only comment I have > it is that in order to call it a "loosely coupled" scenario we have > still to define what happens > if "Alice Desk phone" can not remain in the session for the entire > session duration... > > as the charter defines: > > The objective of this working group is to develop a framework for > disaggregated media in "loosely-coupled" scenarios, where no single > device needs to remain in the session for its entire duration and no > single device needs to act as a master. Well, one obvious thing to do is, when Alice's desk phone needs to leave, it can do a transfer to get out, leaving Bob talking to the PC. (This may not be very satisfactory unless the PC can take over the audio.) And of course it isn't sufficient if the phone departs unexpectedly. Another possibility is for one of Alice's devices to *attempt* to set up a "conference" with Bob's phone as the focus. That of course requires Alice to depend upon Bob's device to have the necessary capabilities. IMO a solution that *depends* on that is a bad solution. But it could be an optional alternative. So, for instance, perhaps we start with a call flow such as has been presented, that doesn't depend on Bob to do anything special. Once that is up and running, if Alice's devices are concerned about their stability and want to delegate the coordination to Bob, one of them can initiate a call flow to transfer the focus responsibility to Bob. (It may take an interesting negotiation to decide which device is best suited to this.) Thanks, Paul > /Sal > > On 5/2/11 3:45 PM, Peter Musgrave wrote: >> Hi Rifaat, >> >> I think this works well. Thanks for re-stating this clearly. >> >> I see a couple of next steps here: >> - how is in incoming call which has an initial A+V answered? >> - how is an outgoing call which has an initial A+V audio created? >> - if both ends are "loosely coupled" are there any optimizations or >> shortcuts that seem worthwhile? >> >> I don't think there is anything too tricky about these - but they will >> need to be worked through. I agree with Simon that it seems time to >> start to capture this work in a draft. >> >> Regards, >> >> Peter Musgrave >> >> On 2011-05-01, at 11:41 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> >>> Hi, >>> >>> In the following flow, I have tried to incorporate all the feedback >>> that I received so far. >>> The only open issue that I am aware of is the issue of what to >>> present to the user on the PC when the phone initiates a video call >>> to the PC (see (#) below). >>> >>> Can you please review the flow below and let me know if we have any >>> other open issues? >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> Alice Alice Proxy Bob >>> PC Desk Phone >>> | | | | >>> | | | | >>> Both Alice's devices subscribe to the reg event package, which allows >>> each device to >>> discover the capabilities of the other device based on the feature >>> tags provided by each device. >>> The Desk Phone knows that the PC supports Video, while the PC knows >>> that the Desk Phone only supports audio. >>> | | | | >>> | | SUBSCRIBE reg | | >>> | |-------------------->| | >>> | | 200 OK | | >>> | |<--------------------| | >>> | | | | >>> | SUBSCRIBE reg | | | >>> |------------------------------------------>| | >>> | 200 OK | | | >>> |<------------------------------------------| | >>> | | | | >>> | | | | >>> The two devices also subscribe to the dialog of each other. >>> | | | | >>> | | | | >>> | SUBSCRIBE dialog | | | >>> |-------------------->| | | >>> | 200 OK | | | >>> |<--------------------| | | >>> | | | | >>> | SUBSCRIBE dialog | | | >>> |<--------------------| | | >>> | 200 OK | | | >>> |-------------------->| | | >>> | | | | >>> | | | | >>> The scenario starts with an audio call from Bob to Alice >>> | | | | >>> | | | INVITE Alice [Audio]| >>> | | |<--------------------| >>> | | INVITE Alice [Audio]| | >>> | |<--------------------| | >>> | INVITE Alice [Audio]| | | >>> |<------------------------------------------| | >>> | | | | >>> Let's assume that Alice used her PC to instruct the phone to answer >>> the call >>> | | | | >>> | REFER Refer-To: urn:sip-action:call:answer;transducer=speaker|headset >>> |-------------------->| | | >>> | 200 OK | | | >>> |<--------------------| | | >>> | | | | >>> | | 200 OK [Audio] | | >>> | |-------------------->| | >>> | | | 200 OK [Audio] | >>> | | |-------------------->| >>> | CANCEL | | | >>> |<------------------------------------------| | >>> | | | | >>> | |<---dialog1------------------------------->| >>> | | | | >>> | |<======audio==============================>| >>> | | | | >>> | | | | >>> >>> (*) >>> >>> | | | | >>> | | | | >>> | | | | >>> The following is a re-INVITE from the remote party (Bob) to add video >>> to the existing audio call >>> | | | | >>> | | | reINVITE Alice [A/V]| >>> | | |<--------------------| >>> | | reINVITE Alice [A/V]| | >>> | |<--------------------| | >>> | | 100 Trying | | >>> | |-------------------->| | >>> | | | 100 Trying | >>> | | |-------------------->| >>> | | | | >>> The Desk Phone cannot handle video, but it knows that the PC can >>> handle video, >>> so the Desk Phone initiates a new video INVITE to the PC. >>> Alert-Info is used to control the alerting level. >>> | | | | >>> | | | | >>> (#) | INVITE [Video] | | | >>> | Alert-Info: whatever | | >>> |<--------------------| | | >>> | 180 | | | >>> |-------------------->| | | >>> | | | | >>> The user can answer the video call using his PC, which would result on >>> 200 OK with video answer being sent to the phone. >>> If the user chose to answer the incoming video call using his Desk >>> Phone, >>> the following REFER will be sent to the PC, before the 200 OK with the >>> video answer is sent from the PC. >>> | | | | >>> | REFER Refer-To: urn:sip-action:call:answer | >>> |<--------------------| | | >>> | 200 OK | | | >>> |-------------------->| | | >>> | | | | >>> | 200 OK [Video] | | | >>> |-------------------->| | | >>> | | | | >>> | | 200 OK [A/V] | | >>> | |-------------------->| | >>> | | | 200 OK [A/V] | >>> | | |-------------------->| >>> | | | | >>> |<----dialog2-------->|<---dialog1------------------------------->| >>> | | | | >>> | |<======audio==============================>| >>> |<============================video==============================>| >>> | | | | >>> | | | | >>> >>> >>> >>> Now let's assume that Alice is the side that wants to add video to the >>> existing audio call. The scenario continues after the (*) above. >>> >>> Alice can use her phone to add video to the existing audio call. The >>> phone >>> must present a UI to Alice to allow her to do just that. If Alice >>> chooses >>> to use her phone, the following REFER will be sent from the phone to >>> the PC, >>> which will instruct the PC to immediately send an INVITE with video >>> offer >>> >>> | REFER Refer-To: urn:sip-action:call:join;dialog=dialog1;media=video >>> |<--------------------| | | >>> | 200 OK | | | >>> |-------------------->| | | >>> | | | | >>> >>> Alice can use her PC to add video to the existing audio call. >>> The PC knows that there is an existing dialog between the Desk Phone >>> and Bob and present this to Alice for her to choose if she wants to >>> add video to the existing audio call or not. In this case Alice chose >>> to add video to the existing audio call, so the PC sends the following >>> request: >>> | | | | >>> | | | | >>> | INVITE with Join [Video] | | >>> |-------------------->| | | >>> | 100 | | | >>> |<--------------------| | | >>> | | re-INVITE [A/V] | | >>> | |-------------------->| | >>> | | | re-INVITE [A/V] | >>> | | |-------------------->| >>> | | | 200 OK [A/V] | >>> | | 200 OK [A/V] |<--------------------| >>> | |<--------------------| | >>> | 200 OK [Video] | | | >>> |<--------------------| | | >>> | | | | >>> | | | | >>> |<----dialog2-------->|<---dialog1------------------------------->| >>> | | | | >>> | |<======audio==============================>| >>> |<============================video==============================>| >>> | | | | >>> | | | | >>> | | | | >>> >>> >>> >>> _______________________________________________ >>> splices mailing list >>> splices@ietf.org >>> https://www.ietf.org/mailman/listinfo/splices >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> https://www.ietf.org/mailman/listinfo/splices > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > From rifatyu@avaya.com Mon May 2 17:54:03 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E4BE07F4 for ; Mon, 2 May 2011 17:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipqv5fJV6zVQ for ; Mon, 2 May 2011 17:54:02 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id C0F7DE07F1 for ; Mon, 2 May 2011 17:54:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8BAMRRv02HCzI1/2dsb2JhbACYBo4Kd6pXApoHhgAEky+KCA X-IronPort-AV: E=Sophos;i="4.64,306,1301889600"; d="scan'208";a="244533742" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 May 2011 20:53:47 -0400 X-IronPort-AV: E=Sophos;i="4.64,306,1301889600"; d="scan'208";a="646239058" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 May 2011 20:53:46 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 2 May 2011 20:53:46 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat Date: Mon, 2 May 2011 20:53:44 -0400 Thread-Topic: [splices] Answering a Call Using Two Separate Devices proposal Thread-Index: AcwITHxwRqy8BMQ/ReOUjn3IeqIaLgA35B1g Message-ID: <6369CB70BFD88942B9705AC1E639A33822CB54B660@DC-US1MBEX4.global.avaya.com> References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> <4DBDDA27.5060804@cisco.com> In-Reply-To: <4DBDDA27.5060804@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 00:54:03 -0000 Thanks Paul, Yes, the actions are just examples and they are open for discussion. The questions you listed below are good questions that must be answered in = a future document that will define the overall solution. Regards, Rifaat > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Sunday, May 01, 2011 6:10 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org > Subject: Re: [splices] Answering a Call Using Two Separate Devices propos= al > > Yes, this seems reasonable to me. The specific refer actions are a > little speculative and can be debated, but for now they're just > examples, and I think we could work them out. > > I've included one suggested wording revision inline below. > > Thanks, > Paul > > P.S. While we don't necessarily need to deal with it here and now, ISTM > it would be useful to work out some best practices for how to manage > multiple media in order to get the best user experience. E.g.: > > - when/how do devices with multiple media capabilities announce those > capabilities? (This scenario has suggested doing so in registrations. > Are the same capabilities announced as contact params on INVITEs, > etc.?) > > - Should media capabilities be announced in SDP, even if there is no > intent to use them at the moment? E.g. using the SDP capneg framework, > or perhaps by "offering" extra media with port set to zero, or with > a=3Dinactive? > > - when forced to make an offer (by receipt of an INVITE without offer), > what media should be offered? Should the UAS defer the decision until > it can alert and get feedback to the alert about which media the > callee wants to use? Or should UAs be user configurable with the media > to initially offer, so they can offer *something* quickly. > > - in the latter case, should the UAS, while alerting, provide a way > for the user to influence which media are used in the call? > (via another o/a before answer). > > Not having anything like this opens call flows such as this one up to > much haggling over what assumptions it makes about behavior of the UAs. > > > > On 5/1/2011 11:41 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi, > > > > In the following flow, I have tried to incorporate all the feedback tha= t I > received so far. > > The only open issue that I am aware of is the issue of what to present = to > the user on the PC when the phone initiates a video call to the PC (see (= #) > below). > > > > Can you please review the flow below and let me know if we have any oth= er > open issues? > > > > Regards, > > Rifaat > > > > > > > > Alice Alice Proxy B= ob > > PC Desk Phone > > | | | = | > > | | | = | > > Both Alice's devices subscribe to the reg event package, which allows e= ach > device to > > discover the capabilities of the other device based on the feature tags > provided by each device. > > The Desk Phone knows that the PC supports Video, while the PC knows tha= t the > Desk Phone only supports audio. > > In the last sentence above, it might be clearer to say "The Desk Phone > *learns* that the PC supports Video, while the PC *learns* that the Desk > Phone only supports Audio." > > > | | | = | > > | | SUBSCRIBE reg | = | > > | |-------------------->| = | > > | | 200 OK | = | > > | |<--------------------| = | > > | | | = | > > | SUBSCRIBE reg | | = | > > |------------------------------------------>| = | > > | 200 OK | | = | > > |<------------------------------------------| = | > > | | | = | > > | | | = | > > The two devices also subscribe to the dialog of each other. > > | | | = | > > | | | = | > > | SUBSCRIBE dialog | | = | > > |-------------------->| | = | > > | 200 OK | | = | > > |<--------------------| | = | > > | | | = | > > | SUBSCRIBE dialog | | = | > > |<--------------------| | = | > > | 200 OK | | = | > > |-------------------->| | = | > > | | | = | > > | | | = | > > The scenario starts with an audio call from Bob to Alice > > | | | = | > > | | | INVITE Alice [Audio]= | > > | | |<--------------------= | > > | | INVITE Alice [Audio]| = | > > | |<--------------------| = | > > | INVITE Alice [Audio]| | = | > > |<------------------------------------------| = | > > | | | = | > > Let's assume that Alice used her PC to instruct the phone to answer the= call > > | | | = | > > | REFER Refer-To: urn:sip-action:call:answer;transducer=3Dspeaker|= headset > > |-------------------->| | = | > > | 200 OK | | = | > > |<--------------------| | = | > > | | | = | > > | | 200 OK [Audio] | = | > > | |-------------------->| = | > > | | | 200 OK [Audio] = | > > | | |-------------------->= | > > | CANCEL | | = | > > |<------------------------------------------| = | > > | | | = | > > | |<---dialog1------------------------------->= | > > | | | = | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | = | > > | | | = | > > > > (*) > > > > | | | = | > > | | | = | > > | | | = | > > The following is a re-INVITE from the remote party (Bob) to add video t= o the > existing audio call > > > | | | = | > > | | | reINVITE Alice [A/V]= | > > | | |<--------------------= | > > | | reINVITE Alice [A/V]| = | > > | |<--------------------| = | > > | | 100 Trying | = | > > | |-------------------->| = | > > | | | 100 Trying = | > > | | |-------------------->= | > > | | | = | > > The Desk Phone cannot handle video, but it knows that the PC can handle > video, > > so the Desk Phone initiates a new video INVITE to the PC. > > Alert-Info is used to control the alerting level. > > | | | = | > > | | | = | > > (#) | INVITE [Video] | | | > > | Alert-Info: whatever | = | > > |<--------------------| | = | > > | 180 | | = | > > |-------------------->| | = | > > | | | = | > > The user can answer the video call using his PC, which would result on > > 200 OK with video answer being sent to the phone. > > If the user chose to answer the incoming video call using his Desk Phon= e, > > the following REFER will be sent to the PC, before the 200 OK with the > > video answer is sent from the PC. > > | | | = | > > | REFER Refer-To: urn:sip-action:call:answer = | > > |<--------------------| | = | > > | 200 OK | | = | > > |-------------------->| | = | > > | | | = | > > | 200 OK [Video] | | = | > > |-------------------->| | = | > > | | | = | > > | | 200 OK [A/V] | = | > > | |-------------------->| = | > > | | | 200 OK [A/V] = | > > | | |-------------------->= | > > | | | = | > > |<----dialog2-------->|<---dialog1------------------------------->= | > > | | | = | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | = | > > | | | = | > > > > > > > > Now let's assume that Alice is the side that wants to add video to the > > existing audio call. The scenario continues after the (*) above. > > > > Alice can use her phone to add video to the existing audio call. The ph= one > > must present a UI to Alice to allow her to do just that. If Alice choos= es > > to use her phone, the following REFER will be sent from the phone to th= e PC, > > which will instruct the PC to immediately send an INVITE with video off= er > > > > | REFER Refer-To: urn:sip-action:call:join;dialog=3Ddialog1;media= =3Dvideo > > |<--------------------| | = | > > | 200 OK | | = | > > |-------------------->| | = | > > | | | = | > > > > Alice can use her PC to add video to the existing audio call. > > The PC knows that there is an existing dialog between the Desk Phone > > and Bob and present this to Alice for her to choose if she wants to > > add video to the existing audio call or not. In this case Alice chose > > to add video to the existing audio call, so the PC sends the following > > request: > > | | | = | > > | | | = | > > | INVITE with Join [Video] | = | > > |-------------------->| | = | > > | 100 | | = | > > |<--------------------| | = | > > | | re-INVITE [A/V] | = | > > | |-------------------->| = | > > | | | re-INVITE [A/V] = | > > | | |-------------------->= | > > | | | 200 OK [A/V] = | > > | | 200 OK [A/V] |<--------------------= | > > | |<--------------------| = | > > | 200 OK [Video] | | = | > > |<--------------------| | = | > > | | | = | > > | | | = | > > |<----dialog2-------->|<---dialog1------------------------------->= | > > | | | = | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | = | > > | | | = | > > | | | = | > > > > > > > > From rifatyu@avaya.com Mon May 2 17:55:02 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4DBE07D7 for ; Mon, 2 May 2011 17:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2Amu2x2dcKo for ; Mon, 2 May 2011 17:55:00 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6CECBE072D for ; Mon, 2 May 2011 17:54:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8BAMRRv02HCzI1/2dsb2JhbACYBo4Kd6pXApoHAoV+BJMvigg X-IronPort-AV: E=Sophos;i="4.64,306,1301889600"; d="scan'208";a="186770429" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 02 May 2011 20:54:58 -0400 X-IronPort-AV: E=Sophos;i="4.64,306,1301889600"; d="scan'208";a="646239527" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 May 2011 20:54:57 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 2 May 2011 20:54:57 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Simon Pietro Romano , Salvatore Loreto Date: Mon, 2 May 2011 20:54:55 -0400 Thread-Topic: [splices] Answering a Call Using Two Separate Devices proposal Thread-Index: AcwIuLZ9LZeT6a5bRqCuLiYWsuvSFgAc9zIA Message-ID: <6369CB70BFD88942B9705AC1E639A33822CB54B661@DC-US1MBEX4.global.avaya.com> References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> <4DBE8FB0.7040304@unina.it> In-Reply-To: <4DBE8FB0.7040304@unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 00:55:02 -0000 Thanks Simon, I will work with Sal on the new document. Regards, Rifaat > -----Original Message----- > From: Simon Pietro Romano [mailto:spromano@unina.it] > Sent: Monday, May 02, 2011 7:04 AM > To: Shekh-Yusef, Rifaat (Rifaat); Salvatore Loreto > Cc: Paul Kyzivat; splices@ietf.org > Subject: Re: [splices] Answering a Call Using Two Separate Devices propos= al >=20 > Hi Rifaat, >=20 > my personal feeling (as an individual) is that most of the open issues > that arose on the ML have been successfully tackled now. Indeed, this > thread is extremely interesting and sheds light on the main features > that any solution should provide. >=20 > With my chair hat on, I would suggest that you and Salvatore work > together on a framework document which does not contain any pointer to > already identified solutions, but rather highlights the issues and > defines the requirements. Such document would actually fulfill the > envisaged milestone of our charter. Once done with this, we can rapidly > move to subsequent documents which start delving into the details of the > poptential solutions. >=20 > Cheers, >=20 > Simon >=20 > Il 01/05/2011 17:41, Shekh-Yusef, Rifaat (Rifaat) ha scritto: > > Hi, > > > > In the following flow, I have tried to incorporate all the feedback tha= t I > received so far. > > The only open issue that I am aware of is the issue of what to present = to > the user on the PC when the phone initiates a video call to the PC (see (= #) > below). > > > > Can you please review the flow below and let me know if we have any oth= er > open issues? > > > > Regards, > > Rifaat > > > > > > > > Alice Alice Proxy B= ob > > PC Desk Phone > > | | | = | > > | | | = | > > Both Alice's devices subscribe to the reg event package, which allows e= ach > device to > > discover the capabilities of the other device based on the feature tags > provided by each device. > > The Desk Phone knows that the PC supports Video, while the PC knows tha= t the > Desk Phone only supports audio. > > | | | = | > > | | SUBSCRIBE reg | = | > > | |-------------------->| = | > > | | 200 OK | = | > > | |<--------------------| = | > > | | | = | > > | SUBSCRIBE reg | | = | > > |------------------------------------------>| = | > > | 200 OK | | = | > > |<------------------------------------------| = | > > | | | = | > > | | | = | > > The two devices also subscribe to the dialog of each other. > > | | | = | > > | | | = | > > | SUBSCRIBE dialog | | = | > > |-------------------->| | = | > > | 200 OK | | = | > > |<--------------------| | = | > > | | | = | > > | SUBSCRIBE dialog | | = | > > |<--------------------| | = | > > | 200 OK | | = | > > |-------------------->| | = | > > | | | = | > > | | | = | > > The scenario starts with an audio call from Bob to Alice > > | | | = | > > | | | INVITE Alice [Audio]= | > > | | |<--------------------= | > > | | INVITE Alice [Audio]| = | > > | |<--------------------| = | > > | INVITE Alice [Audio]| | = | > > |<------------------------------------------| = | > > | | | = | > > Let's assume that Alice used her PC to instruct the phone to answer the= call > > | | | = | > > | REFER Refer-To: urn:sip-action:call:answer;transducer=3Dspeaker|= headset > > |-------------------->| | = | > > | 200 OK | | = | > > |<--------------------| | = | > > | | | = | > > | | 200 OK [Audio] | = | > > | |-------------------->| = | > > | | | 200 OK [Audio] = | > > | | |-------------------->= | > > | CANCEL | | = | > > |<------------------------------------------| = | > > | | | = | > > | |<---dialog1------------------------------->= | > > | | | = | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | = | > > | | | = | > > > > (*) > > > > | | | = | > > | | | = | > > | | | = | > > The following is a re-INVITE from the remote party (Bob) to add video t= o the > existing audio call > > | | | = | > > | | | reINVITE Alice [A/V]= | > > | | |<--------------------= | > > | | reINVITE Alice [A/V]| = | > > | |<--------------------| = | > > | | 100 Trying | = | > > | |-------------------->| = | > > | | | 100 Trying = | > > | | |-------------------->= | > > | | | = | > > The Desk Phone cannot handle video, but it knows that the PC can handle > video, > > so the Desk Phone initiates a new video INVITE to the PC. > > Alert-Info is used to control the alerting level. > > | | | = | > > | | | = | > > (#) | INVITE [Video] | | | > > | Alert-Info: whatever | = | > > |<--------------------| | = | > > | 180 | | = | > > |-------------------->| | = | > > | | | = | > > The user can answer the video call using his PC, which would result on > > 200 OK with video answer being sent to the phone. > > If the user chose to answer the incoming video call using his Desk Phon= e, > > the following REFER will be sent to the PC, before the 200 OK with the > > video answer is sent from the PC. > > | | | = | > > | REFER Refer-To: urn:sip-action:call:answer = | > > |<--------------------| | = | > > | 200 OK | | = | > > |-------------------->| | = | > > | | | = | > > | 200 OK [Video] | | = | > > |-------------------->| | = | > > | | | = | > > | | 200 OK [A/V] | = | > > | |-------------------->| = | > > | | | 200 OK [A/V] = | > > | | |-------------------->= | > > | | | = | > > |<----dialog2-------->|<---dialog1------------------------------->= | > > | | | = | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | = | > > | | | = | > > > > > > > > Now let's assume that Alice is the side that wants to add video to the > > existing audio call. The scenario continues after the (*) above. > > > > Alice can use her phone to add video to the existing audio call. The ph= one > > must present a UI to Alice to allow her to do just that. If Alice choos= es > > to use her phone, the following REFER will be sent from the phone to th= e PC, > > which will instruct the PC to immediately send an INVITE with video off= er > > > > | REFER Refer-To: urn:sip-action:call:join;dialog=3Ddialog1;media= =3Dvideo > > |<--------------------| | = | > > | 200 OK | | = | > > |-------------------->| | = | > > | | | = | > > > > Alice can use her PC to add video to the existing audio call. > > The PC knows that there is an existing dialog between the Desk Phone > > and Bob and present this to Alice for her to choose if she wants to > > add video to the existing audio call or not. In this case Alice chose > > to add video to the existing audio call, so the PC sends the following > > request: > > | | | = | > > | | | = | > > | INVITE with Join [Video] | = | > > |-------------------->| | = | > > | 100 | | = | > > |<--------------------| | = | > > | | re-INVITE [A/V] | = | > > | |-------------------->| = | > > | | | re-INVITE [A/V] = | > > | | |-------------------->= | > > | | | 200 OK [A/V] = | > > | | 200 OK [A/V] |<--------------------= | > > | |<--------------------| = | > > | 200 OK [Video] | | = | > > |<--------------------| | = | > > | | | = | > > | | | = | > > |<----dialog2-------->|<---dialog1------------------------------->= | > > | | | = | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | = | > > | | | = | > > | | | = | > > > > > > > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > > >=20 > -- > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- Fax: +39 081 7684219 > e-mail: spromano@unina.it > http://www.comics.unina.it/simonpietro.romano >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ >=20 From rifatyu@avaya.com Mon May 2 17:58:24 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90727E0697 for ; Mon, 2 May 2011 17:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8lQyyB0sGr9 for ; Mon, 2 May 2011 17:58:23 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 94491E072D for ; Mon, 2 May 2011 17:58:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8BAA9Sv02HCzI1/2dsb2JhbACYBo4Kd6pXApoIhgAEky+KCA X-IronPort-AV: E=Sophos;i="4.64,306,1301889600"; d="scan'208";a="277824141" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 May 2011 20:58:22 -0400 X-IronPort-AV: E=Sophos;i="4.64,306,1301889600"; d="scan'208";a="646240527" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 May 2011 20:58:22 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 2 May 2011 20:58:22 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Peter Musgrave Date: Mon, 2 May 2011 20:58:20 -0400 Thread-Topic: [splices] Answering a Call Using Two Separate Devices proposal Thread-Index: AcwIz0C59V3zPCeKT+yd8AhkbJXOBAAXYbbA Message-ID: <6369CB70BFD88942B9705AC1E639A33822CB54B667@DC-US1MBEX4.global.avaya.com> References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 00:58:24 -0000 Thanks Peter, Yes, these are good next steps. I started working on some of those and I wi= ll post them on the list for discussion later on. Regards, Rifaat > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: Monday, May 02, 2011 9:46 AM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: Paul Kyzivat; splices@ietf.org > Subject: Re: [splices] Answering a Call Using Two Separate Devices propos= al >=20 > Hi Rifaat, >=20 > I think this works well. Thanks for re-stating this clearly. >=20 > I see a couple of next steps here: > - how is in incoming call which has an initial A+V answered? > - how is an outgoing call which has an initial A+V audio created? > - if both ends are "loosely coupled" are there any optimizations or short= cuts > that seem worthwhile? >=20 > I don't think there is anything too tricky about these - but they will ne= ed to > be worked through. I agree with Simon that it seems time to start to capt= ure > this work in a draft. >=20 > Regards, >=20 > Peter Musgrave >=20 > On 2011-05-01, at 11:41 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >=20 > > Hi, > > > > In the following flow, I have tried to incorporate all the feedback tha= t I > received so far. > > The only open issue that I am aware of is the issue of what to present = to > the user on the PC when the phone initiates a video call to the PC (see (= #) > below). > > > > Can you please review the flow below and let me know if we have any oth= er > open issues? > > > > Regards, > > Rifaat > > > > > > > > Alice Alice Proxy Bob > > PC Desk Phone > > | | | | > > | | | | > > Both Alice's devices subscribe to the reg event package, which allows e= ach > device to > > discover the capabilities of the other device based on the feature tags > provided by each device. > > The Desk Phone knows that the PC supports Video, while the PC knows tha= t the > Desk Phone only supports audio. > > | | | | > > | | SUBSCRIBE reg | | > > | |-------------------->| | > > | | 200 OK | | > > | |<--------------------| | > > | | | | > > | SUBSCRIBE reg | | | > > |------------------------------------------>| | > > | 200 OK | | | > > |<------------------------------------------| | > > | | | | > > | | | | > > The two devices also subscribe to the dialog of each other. > > | | | | > > | | | | > > | SUBSCRIBE dialog | | | > > |-------------------->| | | > > | 200 OK | | | > > |<--------------------| | | > > | | | | > > | SUBSCRIBE dialog | | | > > |<--------------------| | | > > | 200 OK | | | > > |-------------------->| | | > > | | | | > > | | | | > > The scenario starts with an audio call from Bob to Alice > > | | | | > > | | | INVITE Alice [Audio]| > > | | |<--------------------| > > | | INVITE Alice [Audio]| | > > | |<--------------------| | > > | INVITE Alice [Audio]| | | > > |<------------------------------------------| | > > | | | | > > Let's assume that Alice used her PC to instruct the phone to answer the= call > > | | | | > > | REFER Refer-To: urn:sip-action:call:answer;transducer=3Dspeaker|he= adset > > |-------------------->| | | > > | 200 OK | | | > > |<--------------------| | | > > | | | | > > | | 200 OK [Audio] | | > > | |-------------------->| | > > | | | 200 OK [Audio] | > > | | |-------------------->| > > | CANCEL | | | > > |<------------------------------------------| | > > | | | | > > | |<---dialog1------------------------------->| > > | | | | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | | > > | | | | > > > > (*) > > > > | | | | > > | | | | > > | | | | > > The following is a re-INVITE from the remote party (Bob) to add video t= o the > existing audio call > > | | | | > > | | | reINVITE Alice [A/V]| > > | | |<--------------------| > > | | reINVITE Alice [A/V]| | > > | |<--------------------| | > > | | 100 Trying | | > > | |-------------------->| | > > | | | 100 Trying | > > | | |-------------------->| > > | | | | > > The Desk Phone cannot handle video, but it knows that the PC can handle > video, > > so the Desk Phone initiates a new video INVITE to the PC. > > Alert-Info is used to control the alerting level. > > | | | | > > | | | | > > (#) | INVITE [Video] | | | > > | Alert-Info: whatever | | > > |<--------------------| | | > > | 180 | | | > > |-------------------->| | | > > | | | | > > The user can answer the video call using his PC, which would result on > > 200 OK with video answer being sent to the phone. > > If the user chose to answer the incoming video call using his Desk Phon= e, > > the following REFER will be sent to the PC, before the 200 OK with the > > video answer is sent from the PC. > > | | | | > > | REFER Refer-To: urn:sip-action:call:answer | > > |<--------------------| | | > > | 200 OK | | | > > |-------------------->| | | > > | | | | > > | 200 OK [Video] | | | > > |-------------------->| | | > > | | | | > > | | 200 OK [A/V] | | > > | |-------------------->| | > > | | | 200 OK [A/V] | > > | | |-------------------->| > > | | | | > > |<----dialog2-------->|<---dialog1------------------------------->| > > | | | | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | | > > | | | | > > > > > > > > Now let's assume that Alice is the side that wants to add video to the > > existing audio call. The scenario continues after the (*) above. > > > > Alice can use her phone to add video to the existing audio call. The ph= one > > must present a UI to Alice to allow her to do just that. If Alice choos= es > > to use her phone, the following REFER will be sent from the phone to th= e PC, > > which will instruct the PC to immediately send an INVITE with video off= er > > > > | REFER Refer-To: urn:sip-action:call:join;dialog=3Ddialog1;media=3D= video > > |<--------------------| | | > > | 200 OK | | | > > |-------------------->| | | > > | | | | > > > > Alice can use her PC to add video to the existing audio call. > > The PC knows that there is an existing dialog between the Desk Phone > > and Bob and present this to Alice for her to choose if she wants to > > add video to the existing audio call or not. In this case Alice chose > > to add video to the existing audio call, so the PC sends the following > > request: > > | | | | > > | | | | > > | INVITE with Join [Video] | | > > |-------------------->| | | > > | 100 | | | > > |<--------------------| | | > > | | re-INVITE [A/V] | | > > | |-------------------->| | > > | | | re-INVITE [A/V] | > > | | |-------------------->| > > | | | 200 OK [A/V] | > > | | 200 OK [A/V] |<--------------------| > > | |<--------------------| | > > | 200 OK [Video] | | | > > |<--------------------| | | > > | | | | > > | | | | > > |<----dialog2-------->|<---dialog1------------------------------->| > > | | | | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | | > > | | | | > > | | | | > > > > > > > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices From rifatyu@avaya.com Mon May 2 18:11:32 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABADE06EC for ; Mon, 2 May 2011 18:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yZvyxt90m52 for ; Mon, 2 May 2011 18:11:31 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id CA0A0E06A7 for ; Mon, 2 May 2011 18:11:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8BAEtVv03GmAcF/2dsb2JhbACYB44Kd6pQApoIhgAEky+KCA X-IronPort-AV: E=Sophos;i="4.64,306,1301889600"; d="scan'208";a="186771228" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 02 May 2011 21:11:29 -0400 X-IronPort-AV: E=Sophos;i="4.64,306,1301889600"; d="scan'208";a="615752313" Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 May 2011 21:11:29 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 2 May 2011 21:11:29 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Salvatore Loreto , "splices@ietf.org" Date: Mon, 2 May 2011 21:11:28 -0400 Thread-Topic: [splices] Answering a Call Using Two Separate Devices proposal Thread-Index: AcwI0yk2AcpdaZplTYOgtbesquWFugAWhevg Message-ID: <6369CB70BFD88942B9705AC1E639A33822CB54B67C@DC-US1MBEX4.global.avaya.com> References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> <4DBEBC15.5050600@ericsson.com> In-Reply-To: <4DBEBC15.5050600@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 01:11:32 -0000 How about the following: Alice Alice Proxy Bob PC Desk Phone | | | | Alice is on a call with Bob as described below (the result of the previously discussed flows) | | | | |<----dialog2-------->|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | Alice's devices have a keep-alive mechanism that allows each one of them to discover if the other is gone (the mechanism is TBD). Let us assume that the PC discovers that the phone is gone. The PC is aware of the dialog with Bob because of the subscription to the dialog event package. The PC then clears dialog2, but Bob's phone is not yet aware that Alice's phone is gone and it still has dialog1. The PC can do the following: | | | | | | | | | INVITE Replaces dialog1 | | |------------------------------------------>| | | | | INVITE Replaces dialog1 | | |-------------------->| | | | BYE | | | BYE |<--------------------| | | x <-----------------| | | | | 200 OK | | | |<--------------------| | 200 OK | | | |<------------------------------------------| | | ACK | | | |------------------------------------------>| | | | | ACK | | | |-------------------->| | | | | Regards, Rifaat > -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Salvatore Loreto > Sent: Monday, May 02, 2011 10:14 AM > To: splices@ietf.org > Subject: Re: [splices] Answering a Call Using Two Separate Devices propos= al > > I think it is a good step forward, > > the only comment I have > it is that in order to call it a "loosely coupled" scenario we have > still to define what happens > if "Alice Desk phone" can not remain in the session for the entire > session duration... > > as the charter defines: > > The objective of this working group is to develop a framework for > disaggregated media in "loosely-coupled" scenarios, where no single > device needs to remain in the session for its entire duration and no > single device needs to act as a master. > > > /Sal > > On 5/2/11 3:45 PM, Peter Musgrave wrote: > > Hi Rifaat, > > > > I think this works well. Thanks for re-stating this clearly. > > > > I see a couple of next steps here: > > - how is in incoming call which has an initial A+V answered? > > - how is an outgoing call which has an initial A+V audio created? > > - if both ends are "loosely coupled" are there any optimizations or > shortcuts that seem worthwhile? > > > > I don't think there is anything too tricky about these - but they will = need > to be worked through. I agree with Simon that it seems time to start to > capture this work in a draft. > > > > Regards, > > > > Peter Musgrave > > > > On 2011-05-01, at 11:41 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > >> Hi, > >> > >> In the following flow, I have tried to incorporate all the feedback th= at I > received so far. > >> The only open issue that I am aware of is the issue of what to present= to > the user on the PC when the phone initiates a video call to the PC (see (= #) > below). > >> > >> Can you please review the flow below and let me know if we have any ot= her > open issues? > >> > >> Regards, > >> Rifaat > >> > >> > >> > >> Alice Alice Proxy B= ob > >> PC Desk Phone > >> | | | = | > >> | | | = | > >> Both Alice's devices subscribe to the reg event package, which allows = each > device to > >> discover the capabilities of the other device based on the feature tag= s > provided by each device. > >> The Desk Phone knows that the PC supports Video, while the PC knows th= at > the Desk Phone only supports audio. > >> | | | = | > >> | | SUBSCRIBE reg | = | > >> | |-------------------->| = | > >> | | 200 OK | = | > >> | |<--------------------| = | > >> | | | = | > >> | SUBSCRIBE reg | | = | > >> |------------------------------------------>| = | > >> | 200 OK | | = | > >> |<------------------------------------------| = | > >> | | | = | > >> | | | = | > >> The two devices also subscribe to the dialog of each other. > >> | | | = | > >> | | | = | > >> | SUBSCRIBE dialog | | = | > >> |-------------------->| | = | > >> | 200 OK | | = | > >> |<--------------------| | = | > >> | | | = | > >> | SUBSCRIBE dialog | | = | > >> |<--------------------| | = | > >> | 200 OK | | = | > >> |-------------------->| | = | > >> | | | = | > >> | | | = | > >> The scenario starts with an audio call from Bob to Alice > >> | | | = | > >> | | | INVITE Alice [Audio]= | > >> | | |<--------------------= | > >> | | INVITE Alice [Audio]| = | > >> | |<--------------------| = | > >> | INVITE Alice [Audio]| | = | > >> |<------------------------------------------| = | > >> | | | = | > >> Let's assume that Alice used her PC to instruct the phone to answer th= e > call > >> | | | = | > >> | REFER Refer-To: urn:sip-action:call:answer;transducer=3Dspeaker|= headset > >> |-------------------->| | = | > >> | 200 OK | | = | > >> |<--------------------| | = | > >> | | | = | > >> | | 200 OK [Audio] | = | > >> | |-------------------->| = | > >> | | | 200 OK [Audio] = | > >> | | |-------------------->= | > >> | CANCEL | | = | > >> |<------------------------------------------| = | > >> | | | = | > >> | |<---dialog1------------------------------->= | > >> | | | = | > >> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > >> | | | = | > >> | | | = | > >> > >> (*) > >> > >> | | | = | > >> | | | = | > >> | | | = | > >> The following is a re-INVITE from the remote party (Bob) to add video = to > the existing audio call > >> | | | = | > >> | | | reINVITE Alice [A/V]= | > >> | | |<--------------------= | > >> | | reINVITE Alice [A/V]| = | > >> | |<--------------------| = | > >> | | 100 Trying | = | > >> | |-------------------->| = | > >> | | | 100 Trying = | > >> | | |-------------------->= | > >> | | | = | > >> The Desk Phone cannot handle video, but it knows that the PC can handl= e > video, > >> so the Desk Phone initiates a new video INVITE to the PC. > >> Alert-Info is used to control the alerting level. > >> | | | = | > >> | | | = | > >> (#) | INVITE [Video] | | = | > >> | Alert-Info: whatever | = | > >> |<--------------------| | = | > >> | 180 | | = | > >> |-------------------->| | = | > >> | | | = | > >> The user can answer the video call using his PC, which would result on > >> 200 OK with video answer being sent to the phone. > >> If the user chose to answer the incoming video call using his Desk Pho= ne, > >> the following REFER will be sent to the PC, before the 200 OK with the > >> video answer is sent from the PC. > >> | | | = | > >> | REFER Refer-To: urn:sip-action:call:answer = | > >> |<--------------------| | = | > >> | 200 OK | | = | > >> |-------------------->| | = | > >> | | | = | > >> | 200 OK [Video] | | = | > >> |-------------------->| | = | > >> | | | = | > >> | | 200 OK [A/V] | = | > >> | |-------------------->| = | > >> | | | 200 OK [A/V] = | > >> | | |-------------------->= | > >> | | | = | > >> |<----dialog2-------->|<---dialog1------------------------------->= | > >> | | | = | > >> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > >> |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > >> | | | = | > >> | | | = | > >> > >> > >> > >> Now let's assume that Alice is the side that wants to add video to the > >> existing audio call. The scenario continues after the (*) above. > >> > >> Alice can use her phone to add video to the existing audio call. The p= hone > >> must present a UI to Alice to allow her to do just that. If Alice choo= ses > >> to use her phone, the following REFER will be sent from the phone to t= he > PC, > >> which will instruct the PC to immediately send an INVITE with video of= fer > >> > >> | REFER Refer-To: urn:sip-action:call:join;dialog=3Ddialog1;media= =3Dvideo > >> |<--------------------| | = | > >> | 200 OK | | = | > >> |-------------------->| | = | > >> | | | = | > >> > >> Alice can use her PC to add video to the existing audio call. > >> The PC knows that there is an existing dialog between the Desk Phone > >> and Bob and present this to Alice for her to choose if she wants to > >> add video to the existing audio call or not. In this case Alice chose > >> to add video to the existing audio call, so the PC sends the following > >> request: > >> | | | = | > >> | | | = | > >> | INVITE with Join [Video] | = | > >> |-------------------->| | = | > >> | 100 | | = | > >> |<--------------------| | = | > >> | | re-INVITE [A/V] | = | > >> | |-------------------->| = | > >> | | | re-INVITE [A/V] = | > >> | | |-------------------->= | > >> | | | 200 OK [A/V] = | > >> | | 200 OK [A/V] |<--------------------= | > >> | |<--------------------| = | > >> | 200 OK [Video] | | = | > >> |<--------------------| | = | > >> | | | = | > >> | | | = | > >> |<----dialog2-------->|<---dialog1------------------------------->= | > >> | | | = | > >> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > >> |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > >> | | | = | > >> | | | = | > >> | | | = | > >> > >> > >> > >> _______________________________________________ > >> splices mailing list > >> splices@ietf.org > >> https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From pkyzivat@cisco.com Mon May 2 18:46:09 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5034FE0664 for ; Mon, 2 May 2011 18:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+aPOpNL4Q2h for ; Mon, 2 May 2011 18:46:08 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 42343E0782 for ; Mon, 2 May 2011 18:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=17496; q=dns/txt; s=iport; t=1304387167; x=1305596767; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=56Zcfa4w4hTgyW5JNuESRJ8vjx6ludpMNwYvlaMDXp4=; b=h75hqAqB1xzgMYcQjv1dpt0oNWRlLnYbZ+aUbDU/4xJW2H59Wd7R71zM heUGUCNZ9ymPl0X1Nl6qhqWdD4LpO+r12T+/Ey3ybxWfJ500xDl4jGhUP 7F+agfTzRqQf97G7Cx00Df1q4yZ/hUInEWAn02GQWHjFBHu72WYg2xdyt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAABhdv02Q/khMgWdsb2JhbACYB44KFAEBFiYlqC6cRIYABI55hBmKJQ Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 03 May 2011 01:46:05 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p431k5wr004264 for ; Tue, 3 May 2011 01:46:05 GMT Message-ID: <4DBF5E5C.9000700@cisco.com> Date: Mon, 02 May 2011 21:46:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: splices@ietf.org References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> <4DBEBC15.5050600@ericsson.com> <6369CB70BFD88942B9705AC1E639A33822CB54B67C@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CB54B67C@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 01:46:09 -0000 The trouble with this is that it depends on the PC discovering the problem before Bob does. If Bob notices first then he will abort the call. Thanks, Paul On 5/2/2011 9:11 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > How about the following: > > Alice Alice Proxy Bob > PC Desk Phone > | | | | > Alice is on a call with Bob as described below (the result of the > previously discussed flows) > | | | | > |<----dialog2-------->|<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > |<============================video==============================>| > | | | | > Alice's devices have a keep-alive mechanism that allows each one of them > to discover if the other is gone (the mechanism is TBD). > Let us assume that the PC discovers that the phone is gone. The PC is > aware of the dialog with Bob because of the subscription to the dialog > event package. The PC then clears dialog2, but Bob's phone is not yet > aware that Alice's phone is gone and it still has dialog1. > The PC can do the following: > | | | | > | | | | > | INVITE Replaces dialog1 | | > |------------------------------------------>| | > | | | INVITE Replaces dialog1 > | | |-------------------->| > | | | BYE | > | | BYE |<--------------------| > | | x<-----------------| | > | | | 200 OK | > | | |<--------------------| > | 200 OK | | | > |<------------------------------------------| | > | ACK | | | > |------------------------------------------>| | > | | | ACK | > | | |-------------------->| > | | | | > > > Regards, > Rifaat > > >> -----Original Message----- >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf Of >> Salvatore Loreto >> Sent: Monday, May 02, 2011 10:14 AM >> To: splices@ietf.org >> Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal >> >> I think it is a good step forward, >> >> the only comment I have >> it is that in order to call it a "loosely coupled" scenario we have >> still to define what happens >> if "Alice Desk phone" can not remain in the session for the entire >> session duration... >> >> as the charter defines: >> >> The objective of this working group is to develop a framework for >> disaggregated media in "loosely-coupled" scenarios, where no single >> device needs to remain in the session for its entire duration and no >> single device needs to act as a master. >> >> >> /Sal >> >> On 5/2/11 3:45 PM, Peter Musgrave wrote: >>> Hi Rifaat, >>> >>> I think this works well. Thanks for re-stating this clearly. >>> >>> I see a couple of next steps here: >>> - how is in incoming call which has an initial A+V answered? >>> - how is an outgoing call which has an initial A+V audio created? >>> - if both ends are "loosely coupled" are there any optimizations or >> shortcuts that seem worthwhile? >>> >>> I don't think there is anything too tricky about these - but they will need >> to be worked through. I agree with Simon that it seems time to start to >> capture this work in a draft. >>> >>> Regards, >>> >>> Peter Musgrave >>> >>> On 2011-05-01, at 11:41 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>> >>>> Hi, >>>> >>>> In the following flow, I have tried to incorporate all the feedback that I >> received so far. >>>> The only open issue that I am aware of is the issue of what to present to >> the user on the PC when the phone initiates a video call to the PC (see (#) >> below). >>>> >>>> Can you please review the flow below and let me know if we have any other >> open issues? >>>> >>>> Regards, >>>> Rifaat >>>> >>>> >>>> >>>> Alice Alice Proxy Bob >>>> PC Desk Phone >>>> | | | | >>>> | | | | >>>> Both Alice's devices subscribe to the reg event package, which allows each >> device to >>>> discover the capabilities of the other device based on the feature tags >> provided by each device. >>>> The Desk Phone knows that the PC supports Video, while the PC knows that >> the Desk Phone only supports audio. >>>> | | | | >>>> | | SUBSCRIBE reg | | >>>> | |-------------------->| | >>>> | | 200 OK | | >>>> | |<--------------------| | >>>> | | | | >>>> | SUBSCRIBE reg | | | >>>> |------------------------------------------>| | >>>> | 200 OK | | | >>>> |<------------------------------------------| | >>>> | | | | >>>> | | | | >>>> The two devices also subscribe to the dialog of each other. >>>> | | | | >>>> | | | | >>>> | SUBSCRIBE dialog | | | >>>> |-------------------->| | | >>>> | 200 OK | | | >>>> |<--------------------| | | >>>> | | | | >>>> | SUBSCRIBE dialog | | | >>>> |<--------------------| | | >>>> | 200 OK | | | >>>> |-------------------->| | | >>>> | | | | >>>> | | | | >>>> The scenario starts with an audio call from Bob to Alice >>>> | | | | >>>> | | | INVITE Alice [Audio]| >>>> | | |<--------------------| >>>> | | INVITE Alice [Audio]| | >>>> | |<--------------------| | >>>> | INVITE Alice [Audio]| | | >>>> |<------------------------------------------| | >>>> | | | | >>>> Let's assume that Alice used her PC to instruct the phone to answer the >> call >>>> | | | | >>>> | REFER Refer-To: urn:sip-action:call:answer;transducer=speaker|headset >>>> |-------------------->| | | >>>> | 200 OK | | | >>>> |<--------------------| | | >>>> | | | | >>>> | | 200 OK [Audio] | | >>>> | |-------------------->| | >>>> | | | 200 OK [Audio] | >>>> | | |-------------------->| >>>> | CANCEL | | | >>>> |<------------------------------------------| | >>>> | | | | >>>> | |<---dialog1------------------------------->| >>>> | | | | >>>> | |<======audio==============================>| >>>> | | | | >>>> | | | | >>>> >>>> (*) >>>> >>>> | | | | >>>> | | | | >>>> | | | | >>>> The following is a re-INVITE from the remote party (Bob) to add video to >> the existing audio call >>>> | | | | >>>> | | | reINVITE Alice [A/V]| >>>> | | |<--------------------| >>>> | | reINVITE Alice [A/V]| | >>>> | |<--------------------| | >>>> | | 100 Trying | | >>>> | |-------------------->| | >>>> | | | 100 Trying | >>>> | | |-------------------->| >>>> | | | | >>>> The Desk Phone cannot handle video, but it knows that the PC can handle >> video, >>>> so the Desk Phone initiates a new video INVITE to the PC. >>>> Alert-Info is used to control the alerting level. >>>> | | | | >>>> | | | | >>>> (#) | INVITE [Video] | | | >>>> | Alert-Info: whatever | | >>>> |<--------------------| | | >>>> | 180 | | | >>>> |-------------------->| | | >>>> | | | | >>>> The user can answer the video call using his PC, which would result on >>>> 200 OK with video answer being sent to the phone. >>>> If the user chose to answer the incoming video call using his Desk Phone, >>>> the following REFER will be sent to the PC, before the 200 OK with the >>>> video answer is sent from the PC. >>>> | | | | >>>> | REFER Refer-To: urn:sip-action:call:answer | >>>> |<--------------------| | | >>>> | 200 OK | | | >>>> |-------------------->| | | >>>> | | | | >>>> | 200 OK [Video] | | | >>>> |-------------------->| | | >>>> | | | | >>>> | | 200 OK [A/V] | | >>>> | |-------------------->| | >>>> | | | 200 OK [A/V] | >>>> | | |-------------------->| >>>> | | | | >>>> |<----dialog2-------->|<---dialog1------------------------------->| >>>> | | | | >>>> | |<======audio==============================>| >>>> |<============================video==============================>| >>>> | | | | >>>> | | | | >>>> >>>> >>>> >>>> Now let's assume that Alice is the side that wants to add video to the >>>> existing audio call. The scenario continues after the (*) above. >>>> >>>> Alice can use her phone to add video to the existing audio call. The phone >>>> must present a UI to Alice to allow her to do just that. If Alice chooses >>>> to use her phone, the following REFER will be sent from the phone to the >> PC, >>>> which will instruct the PC to immediately send an INVITE with video offer >>>> >>>> | REFER Refer-To: urn:sip-action:call:join;dialog=dialog1;media=video >>>> |<--------------------| | | >>>> | 200 OK | | | >>>> |-------------------->| | | >>>> | | | | >>>> >>>> Alice can use her PC to add video to the existing audio call. >>>> The PC knows that there is an existing dialog between the Desk Phone >>>> and Bob and present this to Alice for her to choose if she wants to >>>> add video to the existing audio call or not. In this case Alice chose >>>> to add video to the existing audio call, so the PC sends the following >>>> request: >>>> | | | | >>>> | | | | >>>> | INVITE with Join [Video] | | >>>> |-------------------->| | | >>>> | 100 | | | >>>> |<--------------------| | | >>>> | | re-INVITE [A/V] | | >>>> | |-------------------->| | >>>> | | | re-INVITE [A/V] | >>>> | | |-------------------->| >>>> | | | 200 OK [A/V] | >>>> | | 200 OK [A/V] |<--------------------| >>>> | |<--------------------| | >>>> | 200 OK [Video] | | | >>>> |<--------------------| | | >>>> | | | | >>>> | | | | >>>> |<----dialog2-------->|<---dialog1------------------------------->| >>>> | | | | >>>> | |<======audio==============================>| >>>> |<============================video==============================>| >>>> | | | | >>>> | | | | >>>> | | | | >>>> >>>> >>>> >>>> _______________________________________________ >>>> splices mailing list >>>> splices@ietf.org >>>> https://www.ietf.org/mailman/listinfo/splices >>> _______________________________________________ >>> splices mailing list >>> splices@ietf.org >>> https://www.ietf.org/mailman/listinfo/splices >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> https://www.ietf.org/mailman/listinfo/splices > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > From rifatyu@avaya.com Tue May 3 08:28:46 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E01E07E7 for ; Tue, 3 May 2011 08:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ak3no3acXD3 for ; Tue, 3 May 2011 08:28:45 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4A58CE07B3 for ; Tue, 3 May 2011 08:28:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsBAOMdwE2HCzI1/2dsb2JhbACYCI4Ud6sIApo7hgIEk0+KFw X-IronPort-AV: E=Sophos;i="4.64,310,1301889600"; d="scan'208";a="244640787" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 May 2011 11:28:41 -0400 X-IronPort-AV: E=Sophos;i="4.64,309,1301889600"; d="scan'208";a="646617690" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 May 2011 11:28:41 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 3 May 2011 11:28:40 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat , "splices@ietf.org" Date: Tue, 3 May 2011 11:28:08 -0400 Thread-Topic: [splices] Answering a Call Using Two Separate Devices proposal Thread-Index: AcwJM+NJEnPo6fEJRZaptYN4gYHQ7QAb8/nw Message-ID: <6369CB70BFD88942B9705AC1E639A33822CB54BAEF@DC-US1MBEX4.global.avaya.com> References: <4DB56C9C.1080004@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> <4DB853B0.5060506@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CB33B18C@DC-US1MBEX4.global.avaya.com> <4DBEBC15.5050600@ericsson.com> <6369CB70BFD88942B9705AC1E639A33822CB54B67C@DC-US1MBEX4.global.avaya.com> <4DBF5E5C.9000700@cisco.com> In-Reply-To: <4DBF5E5C.9000700@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 15:28:46 -0000 We should be able to come up with a mechanism that allows for a quick failu= re discovery between the federated devices that minimizes the chances of th= e remote party discovering the failure before the other federated device. But I agree with you that no matter how good is the discovery mechanism, it= will not completely eliminate the remote party chances. Regards, Rifaat > -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Paul Kyzivat > Sent: Monday, May 02, 2011 9:46 PM > To: splices@ietf.org > Subject: Re: [splices] Answering a Call Using Two Separate Devices propos= al > > The trouble with this is that it depends on the PC discovering the > problem before Bob does. If Bob notices first then he will abort the call= . > > Thanks, > Paul > > On 5/2/2011 9:11 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > How about the following: > > > > Alice Alice Proxy B= ob > > PC Desk Phone > > | | | = | > > Alice is on a call with Bob as described below (the result of the > > previously discussed flows) > > | | | = | > > |<----dialog2-------->|<---dialog1------------------------------->= | > > | | | = | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | = | > > Alice's devices have a keep-alive mechanism that allows each one of the= m > > to discover if the other is gone (the mechanism is TBD). > > Let us assume that the PC discovers that the phone is gone. The PC is > > aware of the dialog with Bob because of the subscription to the dialog > > event package. The PC then clears dialog2, but Bob's phone is not yet > > aware that Alice's phone is gone and it still has dialog1. > > The PC can do the following: > > | | | = | > > | | | = | > > | INVITE Replaces dialog1 | = | > > |------------------------------------------>| = | > > | | | INVITE Replaces dial= og1 > > | | |-------------------->= | > > | | | BYE = | > > | | BYE |<--------------------= | > > | | x<-----------------| | > > | | | 200 OK = | > > | | |<--------------------= | > > | 200 OK | | = | > > |<------------------------------------------| = | > > | ACK | | = | > > |------------------------------------------>| = | > > | | | ACK = | > > | | |-------------------->= | > > | | | = | > > > > > > Regards, > > Rifaat > > > > > >> -----Original Message----- > >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Be= half > Of > >> Salvatore Loreto > >> Sent: Monday, May 02, 2011 10:14 AM > >> To: splices@ietf.org > >> Subject: Re: [splices] Answering a Call Using Two Separate Devices pro= posal > >> > >> I think it is a good step forward, > >> > >> the only comment I have > >> it is that in order to call it a "loosely coupled" scenario we have > >> still to define what happens > >> if "Alice Desk phone" can not remain in the session for the entire > >> session duration... > >> > >> as the charter defines: > >> > >> The objective of this working group is to develop a framework for > >> disaggregated media in "loosely-coupled" scenarios, where no singl= e > >> device needs to remain in the session for its entire duration and = no > >> single device needs to act as a master. > >> > >> > >> /Sal > >> > >> On 5/2/11 3:45 PM, Peter Musgrave wrote: > >>> Hi Rifaat, > >>> > >>> I think this works well. Thanks for re-stating this clearly. > >>> > >>> I see a couple of next steps here: > >>> - how is in incoming call which has an initial A+V answered? > >>> - how is an outgoing call which has an initial A+V audio created? > >>> - if both ends are "loosely coupled" are there any optimizations or > >> shortcuts that seem worthwhile? > >>> > >>> I don't think there is anything too tricky about these - but they wil= l > need > >> to be worked through. I agree with Simon that it seems time to start t= o > >> capture this work in a draft. > >>> > >>> Regards, > >>> > >>> Peter Musgrave > >>> > >>> On 2011-05-01, at 11:41 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > >>> > >>>> Hi, > >>>> > >>>> In the following flow, I have tried to incorporate all the feedback = that > I > >> received so far. > >>>> The only open issue that I am aware of is the issue of what to prese= nt to > >> the user on the PC when the phone initiates a video call to the PC (se= e (#) > >> below). > >>>> > >>>> Can you please review the flow below and let me know if we have any = other > >> open issues? > >>>> > >>>> Regards, > >>>> Rifaat > >>>> > >>>> > >>>> > >>>> Alice Alice Proxy = Bob > >>>> PC Desk Phone > >>>> | | | = | > >>>> | | | = | > >>>> Both Alice's devices subscribe to the reg event package, which allow= s > each > >> device to > >>>> discover the capabilities of the other device based on the feature t= ags > >> provided by each device. > >>>> The Desk Phone knows that the PC supports Video, while the PC knows = that > >> the Desk Phone only supports audio. > >>>> | | | = | > >>>> | | SUBSCRIBE reg | = | > >>>> | |-------------------->| = | > >>>> | | 200 OK | = | > >>>> | |<--------------------| = | > >>>> | | | = | > >>>> | SUBSCRIBE reg | | = | > >>>> |------------------------------------------>| = | > >>>> | 200 OK | | = | > >>>> |<------------------------------------------| = | > >>>> | | | = | > >>>> | | | = | > >>>> The two devices also subscribe to the dialog of each other. > >>>> | | | = | > >>>> | | | = | > >>>> | SUBSCRIBE dialog | | = | > >>>> |-------------------->| | = | > >>>> | 200 OK | | = | > >>>> |<--------------------| | = | > >>>> | | | = | > >>>> | SUBSCRIBE dialog | | = | > >>>> |<--------------------| | = | > >>>> | 200 OK | | = | > >>>> |-------------------->| | = | > >>>> | | | = | > >>>> | | | = | > >>>> The scenario starts with an audio call from Bob to Alice > >>>> | | | = | > >>>> | | | INVITE Alice [Aud= io]| > >>>> | | |<-----------------= ---| > >>>> | | INVITE Alice [Audio]| = | > >>>> | |<--------------------| = | > >>>> | INVITE Alice [Audio]| | = | > >>>> |<------------------------------------------| = | > >>>> | | | = | > >>>> Let's assume that Alice used her PC to instruct the phone to answer = the > >> call > >>>> | | | = | > >>>> | REFER Refer-To: urn:sip- > action:call:answer;transducer=3Dspeaker|headset > >>>> |-------------------->| | = | > >>>> | 200 OK | | = | > >>>> |<--------------------| | = | > >>>> | | | = | > >>>> | | 200 OK [Audio] | = | > >>>> | |-------------------->| = | > >>>> | | | 200 OK [Audio] = | > >>>> | | |------------------= -->| > >>>> | CANCEL | | = | > >>>> |<------------------------------------------| = | > >>>> | | | = | > >>>> | |<---dialog1-----------------------------= -->| > >>>> | | | = | > >>>> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >| > >>>> | | | = | > >>>> | | | = | > >>>> > >>>> (*) > >>>> > >>>> | | | = | > >>>> | | | = | > >>>> | | | = | > >>>> The following is a re-INVITE from the remote party (Bob) to add vide= o to > >> the existing audio call > >>>> | | | = | > >>>> | | | reINVITE Alice [A= /V]| > >>>> | | |<-----------------= ---| > >>>> | | reINVITE Alice [A/V]| = | > >>>> | |<--------------------| = | > >>>> | | 100 Trying | = | > >>>> | |-------------------->| = | > >>>> | | | 100 Trying = | > >>>> | | |------------------= -->| > >>>> | | | = | > >>>> The Desk Phone cannot handle video, but it knows that the PC can han= dle > >> video, > >>>> so the Desk Phone initiates a new video INVITE to the PC. > >>>> Alert-Info is used to control the alerting level. > >>>> | | | = | > >>>> | | | = | > >>>> (#) | INVITE [Video] | | = | > >>>> | Alert-Info: whatever | = | > >>>> |<--------------------| | = | > >>>> | 180 | | = | > >>>> |-------------------->| | = | > >>>> | | | = | > >>>> The user can answer the video call using his PC, which would result = on > >>>> 200 OK with video answer being sent to the phone. > >>>> If the user chose to answer the incoming video call using his Desk P= hone, > >>>> the following REFER will be sent to the PC, before the 200 OK with t= he > >>>> video answer is sent from the PC. > >>>> | | | = | > >>>> | REFER Refer-To: urn:sip-action:call:answer = | > >>>> |<--------------------| | = | > >>>> | 200 OK | | = | > >>>> |-------------------->| | = | > >>>> | | | = | > >>>> | 200 OK [Video] | | = | > >>>> |-------------------->| | = | > >>>> | | | = | > >>>> | | 200 OK [A/V] | = | > >>>> | |-------------------->| = | > >>>> | | | 200 OK [A/V] = | > >>>> | | |------------------= -->| > >>>> | | | = | > >>>> |<----dialog2-------->|<---dialog1-----------------------------= -->| > >>>> | | | = | > >>>> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >| > >>>> |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > >>>> | | | = | > >>>> | | | = | > >>>> > >>>> > >>>> > >>>> Now let's assume that Alice is the side that wants to add video to t= he > >>>> existing audio call. The scenario continues after the (*) above. > >>>> > >>>> Alice can use her phone to add video to the existing audio call. The > phone > >>>> must present a UI to Alice to allow her to do just that. If Alice ch= ooses > >>>> to use her phone, the following REFER will be sent from the phone to= the > >> PC, > >>>> which will instruct the PC to immediately send an INVITE with video = offer > >>>> > >>>> | REFER Refer-To: urn:sip- > action:call:join;dialog=3Ddialog1;media=3Dvideo > >>>> |<--------------------| | = | > >>>> | 200 OK | | = | > >>>> |-------------------->| | = | > >>>> | | | = | > >>>> > >>>> Alice can use her PC to add video to the existing audio call. > >>>> The PC knows that there is an existing dialog between the Desk Phone > >>>> and Bob and present this to Alice for her to choose if she wants to > >>>> add video to the existing audio call or not. In this case Alice chos= e > >>>> to add video to the existing audio call, so the PC sends the followi= ng > >>>> request: > >>>> | | | = | > >>>> | | | = | > >>>> | INVITE with Join [Video] | = | > >>>> |-------------------->| | = | > >>>> | 100 | | = | > >>>> |<--------------------| | = | > >>>> | | re-INVITE [A/V] | = | > >>>> | |-------------------->| = | > >>>> | | | re-INVITE [A/V] = | > >>>> | | |------------------= -->| > >>>> | | | 200 OK [A/V] = | > >>>> | | 200 OK [A/V] |<-----------------= ---| > >>>> | |<--------------------| = | > >>>> | 200 OK [Video] | | = | > >>>> |<--------------------| | = | > >>>> | | | = | > >>>> | | | = | > >>>> |<----dialog2-------->|<---dialog1-----------------------------= -->| > >>>> | | | = | > >>>> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >| > >>>> |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > >>>> | | | = | > >>>> | | | = | > >>>> | | | = | > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> splices mailing list > >>>> splices@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/splices > >>> _______________________________________________ > >>> splices mailing list > >>> splices@ietf.org > >>> https://www.ietf.org/mailman/listinfo/splices > >> _______________________________________________ > >> splices mailing list > >> splices@ietf.org > >> https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From rifatyu@avaya.com Tue May 17 06:15:09 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA982E0811 for ; Tue, 17 May 2011 06:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8q6uEwaEPUD for ; Tue, 17 May 2011 06:15:08 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id CB117E073E for ; Tue, 17 May 2011 06:15:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG500k3GmAcF/2dsb2JhbACCZaM0d6hUg1kCm2iGGQSUXYpF X-IronPort-AV: E=Sophos;i="4.65,225,1304308800"; d="scan'208,217";a="188723502" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 17 May 2011 09:15:04 -0400 X-IronPort-AV: E=Sophos;i="4.65,225,1304308800"; d="scan'208,217";a="622774029" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 May 2011 09:15:04 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 17 May 2011 09:15:03 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "splices@ietf.org" Date: Tue, 17 May 2011 09:15:02 -0400 Thread-Topic: SIP INVOKE method Thread-Index: AcwUlG21RcTDGyn+QBi7uyh9D1M1iw== Message-ID: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822CBDA8EBFDCUS1MBEX4glo_" MIME-Version: 1.0 Subject: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 13:15:09 -0000 --_000_6369CB70BFD88942B9705AC1E639A33822CBDA8EBFDCUS1MBEX4glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As discussed in the last SPLICES WG meeting in Prague, the REFER method is = overloaded and has limitations that prevents it from being the ideal method= for action invocation. We have worked on the following new draft that defines a new SIP method to = be used for invoking actions: https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ We would appreciate it if people review the document and provide us with th= eir feedback. Regards, Rifaat --_000_6369CB70BFD88942B9705AC1E639A33822CBDA8EBFDCUS1MBEX4glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As discuss= ed in the last SPLICES WG meeting in Prague, the REFER method is overloaded= and has limitations that prevents it from being the ideal method for actio= n invocation.

We have worked on the foll= owing new draft that defines a new SIP method to be used for invoking actio= ns:

https://datatracker.ietf.org/doc/draft= -yusef-splices-invoke/

 

We would appreciate it if people review the do= cument and provide us with their feedback.

 

Regards,

Rifaat

 <= /p>

 

&nbs= p;

 

=  

 

= --_000_6369CB70BFD88942B9705AC1E639A33822CBDA8EBFDCUS1MBEX4glo_-- From christer.holmberg@ericsson.com Tue May 17 06:26:43 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FB3E06D5 for ; Tue, 17 May 2011 06:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmoydma3nk1J for ; Tue, 17 May 2011 06:26:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE39E06B8 for ; Tue, 17 May 2011 06:26:42 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae0000076dc-ea-4dd27790d28e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.A1.30428.09772DD4; Tue, 17 May 2011 15:26:40 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 17 May 2011 15:26:40 +0200 From: Christer Holmberg To: "Shekh-Yusef, Rifaat (Rifaat)" , "splices@ietf.org" Date: Tue, 17 May 2011 15:26:38 +0200 Thread-Topic: SIP INVOKE method - implicit registrations Thread-Index: AcwUlG21RcTDGyn+QBi7uyh9D1M1iwAAS2xw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E1859C2@ESESSCMS0356.eemea.ericsson.se> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [splices] SIP INVOKE method - implicit registrations X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 13:26:43 -0000 Hi, =20 Section 3 says: =20 "An INVOKE request implicitly establishes a subscription to the 'invoke' ev= ent." However, section 4.2.1 of the 3265bis draft (latest version has expired, bu= t I assume it's still intended to be moved forward) has removed implicit re= gistrations, saying that only SUBSCRIBE can be used to create subscriptions= . Regards, Christer ________________________________ From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf= Of Shekh-Yusef, Rifaat (Rifaat) Sent: 17. toukokuuta 2011 16:15 To: splices@ietf.org Subject: [splices] SIP INVOKE method =09 =09 Hi, =20 As discussed in the last SPLICES WG meeting in Prague, the REFER method is= overloaded and has limitations that prevents it from being the ideal metho= d for action invocation. We have worked on the following new draft that defines a new SIP method to= be used for invoking actions: https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ =20 We would appreciate it if people review the document and provide us with t= heir feedback. =20 Regards, Rifaat =20 =20 =20 =20 =20 =20 From adam@nostrum.com Tue May 17 06:34:57 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDECE06A2 for ; Tue, 17 May 2011 06:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-ve6w61SzRU for ; Tue, 17 May 2011 06:34:56 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 156B8E06A1 for ; Tue, 17 May 2011 06:34:53 -0700 (PDT) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4HDYmrI050620 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 May 2011 08:34:49 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4DD27978.6060200@nostrum.com> Date: Tue, 17 May 2011 08:34:48 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <7F2072F1E0DE894DA4B517B93C6A0585194E1859C2@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E1859C2@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method - implicit registrations X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 13:34:57 -0000 And, to be clear, experience has shown that this kind of dual action (do the invoke thing *and* create a subscription) ends up being a really bad idea. I haven't read the draft yet, so I don't have an opinion on the INVOKE mechanism itself, but the way we would do something like REFER with the tools we have today would involve explicit subscriptions to a GRUU associated with the UAS if (and only if) the UA sending the REFER has an interest in the outcome. /a On 5/17/11 08:26, May 17, Christer Holmberg wrote: > Hi, > > Section 3 says: > > "An INVOKE request implicitly establishes a subscription to the 'invoke' event." > > However, section 4.2.1 of the 3265bis draft (latest version has expired, but I assume it's still intended to be moved forward) has removed implicit registrations, saying that only SUBSCRIBE can be used to create subscriptions. > > Regards, > > Christer > > > > ________________________________ > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf Of Shekh-Yusef, Rifaat (Rifaat) > Sent: 17. toukokuuta 2011 16:15 > To: splices@ietf.org > Subject: [splices] SIP INVOKE method > > > > Hi, > > > > As discussed in the last SPLICES WG meeting in Prague, the REFER method is overloaded and has limitations that prevents it from being the ideal method for action invocation. > > We have worked on the following new draft that defines a new SIP method to be used for invoking actions: > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > > > We would appreciate it if people review the document and provide us with their feedback. > > > > Regards, > > Rifaat > > > > > > > > > > > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From pkyzivat@cisco.com Tue May 17 06:51:18 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E350DE067B for ; Tue, 17 May 2011 06:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESiVJ+v9IXJd for ; Tue, 17 May 2011 06:51:15 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0DE0769 for ; Tue, 17 May 2011 06:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2062; q=dns/txt; s=iport; t=1305640275; x=1306849875; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=wrYGb4Q74JRhQ47zkzGVbdxCiimJrS+W0hsUcifYj2o=; b=SK9J6yK7asjUIhS6c/vfKogIShfBSXgnLpTFanaylqLmR6HzkcGWudyJ Oh2lVjrP8lahtyp6B/s5+SvGUTLLaa/U3FQVADmEIicU1MoPlb2UW8xY2 wjxfhBcJzsgBNcsuBkWMSepnIVgj08zmYxOinCtCGk5g/hdTRw+4BALEa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEIAOJ80k2rRDoJ/2dsb2JhbACYDY4Md6oJniGGGQSQEYQvimI X-IronPort-AV: E=Sophos;i="4.65,225,1304294400"; d="scan'208";a="698741291" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 17 May 2011 13:51:15 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4HDpEoD029827 for ; Tue, 17 May 2011 13:51:14 GMT Message-ID: <4DD27D52.9030509@cisco.com> Date: Tue, 17 May 2011 09:51:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: splices@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 13:51:19 -0000 Rifaat, I just did a quick read of this. Some things I like, others not so much. I like using something other than REFER. I don't like defining something new that creates an implicit subscription. In retrospect the implicit subscription of REFER is widely thought to have been a mistake - one we won't do again. As co-chair of sipcore I can safely promise that it won't be approved in that form. Some off-the-cuff thoughts about how to change this to address the concern: Define an event package. (You already have that.) But require a subscription to that package to be overtly established (with subscribe). Then do one of the following to deliver the action: - make the action a header in the subscribe request - encode the action in the body of the subscribe request - define an in-dialog method to deliver the action within the subscribe request. Of those, I'm tending to the method approach. It would allow use of the body to convey extra information about the action. Perhaps there are cases where the method could be sent without a subscription when there is no need to learn the outcome. In cases where you want to have an ongoing control relationship with another device you could just establish the subscription once, and then send a series of action requests to it. Thanks, Paul On 5/17/2011 9:15 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Hi, > > As discussed in the last SPLICES WG meeting in Prague, the REFER method > is overloaded and has limitations that prevents it from being the ideal > method for action invocation. > > We have worked on the following new draft that defines a new SIP method > to be used for invoking actions: > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > We would appreciate it if people review the document and provide us with > their feedback. > > Regards, > > Rifaat > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From musgravepj@gmail.com Tue May 17 08:38:02 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EF0E06C6 for ; Tue, 17 May 2011 08:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrNlpuG0ohRN for ; Tue, 17 May 2011 08:38:02 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A316E069C for ; Tue, 17 May 2011 08:38:01 -0700 (PDT) Received: by fxm15 with SMTP id 15so641553fxm.31 for ; Tue, 17 May 2011 08:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jjKqyXCLCWKYqqznadcq3ZjZ2NElfmwmF3KPPNVFU5o=; b=eDeVW2/DcLD65OHTRxX23lBbj9J/yuPDkHJfIwbrygysKhAWhcJR5OBCnoLCPE2w+b YU7ck46O0dq8VUxLI2J7LXWh7dmsphT3b+HrTCg1nKMx1Xinnurxk0Z4oBWd+sTEXw9v OiJOwKm22d8eXgTBU2xz9Ypcg/cixJcePqOss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cp6pwhI7cMiN/bd8ieECL0g/SjAnaN+ikIib22Vtoh9IRi2SHrpLB7zZ5KxlyNW5dw /6rSFzJX/O2yfrVCFJzaHssd/bIBte3Gw4XvRVYsZDz8WRginmzEAOTV5WFP1lA8gD9p wEOoz8h6mWJTeB0Popk5b9qQvPC+8d9Q+Wi/Q= MIME-Version: 1.0 Received: by 10.223.62.194 with SMTP id y2mr967040fah.123.1305646679172; Tue, 17 May 2011 08:37:59 -0700 (PDT) Received: by 10.223.103.67 with HTTP; Tue, 17 May 2011 08:37:59 -0700 (PDT) In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> Date: Tue, 17 May 2011 11:37:59 -0400 Message-ID: From: Peter Musgrave To: "Shekh-Yusef, Rifaat (Rifaat)" Content-Type: multipart/alternative; boundary=00151747698083a56a04a37a8e15 Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 15:53:01 -0000 --00151747698083a56a04a37a8e15 Content-Type: text/plain; charset=ISO-8859-1 Hi Rifaat, Overall this is clearly described and I can see the utility. I agree with other comments that explicit subscriptions are evil. If find the method name INVOKE very unfortunate - since my brain when parsing the example actually skipped the INVOKE message thinking it was an INVITE. Semantically this method is somewhat like HTTP POST - but I think overloading that term might not be viewed favourably. Maybe ACTION? Do you foresee having actions which accept parameters? For example there is a special case of an action 'sendvm' that could be generalized to something like 'redirect vm'. I could also see a case where terminate might wish to specify the error code to be used to reject the call. Will the gory details of what a UA must do for each action be something which is added to the document? Regards, Peter Musgrave On Tue, May 17, 2011 at 9:15 AM, Shekh-Yusef, Rifaat (Rifaat) < rifatyu@avaya.com> wrote: > Hi, > > > > As discussed in the last SPLICES WG meeting in Prague, the REFER method is > overloaded and has limitations that prevents it from being the ideal method > for action invocation. > > We have worked on the following new draft that defines a new SIP method to > be used for invoking actions: > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > > > We would appreciate it if people review the document and provide us with > their feedback. > > > > Regards, > > Rifaat > > > > > > > > > > > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > --00151747698083a56a04a37a8e15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rifaat,=A0

Overall this is clearly described and I ca= n see the utility.=A0

I agree with other comments = that explicit subscriptions are evil.

If find the = method name INVOKE very unfortunate - since my brain when parsing the examp= le actually skipped the INVOKE message thinking it was an INVITE. Semantica= lly this method is somewhat like HTTP POST - but I think overloading that t= erm might not be viewed favourably. Maybe ACTION?

Do you foresee having actions which accept parameters? = For example there is a special case of an action 'sendvm' that coul= d be generalized to something like 'redirect vm'. I could also see = a case where terminate might wish to specify the error code to be used to r= eject the call.=A0

Will the gory details of what a UA must do for each act= ion be something which is added to the document?

R= egards,=A0

Peter Musgrave



On Tue, May 17, 2011 at 9:15 AM, Shekh-Y= usef, Rifaat (Rifaat) <rifatyu@avaya.com> wrote:

Hi,

=A0

As discusse= d in the last SPLICES WG meeting in Prague, the REFER method is overloaded = and has limitations that prevents it from being the ideal method for action= invocation.

We have worked on the following new draft that defin= es a new SIP method to be used for invoking actions:

https://datatracker.ietf.org/doc/draft-yusef-splices-in= voke/

=A0

We would appreciate it= if people review the document and provide us with their feedback.

=A0

Regards,

Rifaat

=A0

=A0

=A0

=A0

=A0

=A0

_______________________________________________
splices mailing list
splices@ietf.org
https://www.ietf.org/mailman/listinfo/splices


--00151747698083a56a04a37a8e15-- From musgravepj@gmail.com Tue May 17 10:13:40 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEA5E071C for ; Tue, 17 May 2011 10:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZBRJ5c7lf+w for ; Tue, 17 May 2011 10:13:40 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0AECE0774 for ; Tue, 17 May 2011 10:13:39 -0700 (PDT) Received: by fxm15 with SMTP id 15so714821fxm.31 for ; Tue, 17 May 2011 10:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NS8fbdmnt4Dotgq/KArPU2kCXP0aoE9kG3AxHWJUAs0=; b=rXIFggHDrS61i2e20kS2LhPQXMf1qCAZkhTPmvJY04IKC6duH5Em30Yqqjaq96jnFU h2Xfc5H491n3cjS4N9fc46iB11plQt4F2nbnxXDfBn/iXQUmEzMDFQoN3qYKBU7wbFmb NE6bQeMUx7zwDqkfXVbg25h39zlnrXEghxv8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gHFLvUGhLnirD2ecooP6/lgNciH97VF61MwjxSqxJtcDYkeiiKjwWSOUgQuPRbuMMW Yu5AyygOGMF28CCwI4pr0wqzZgvf8aEC9c/+TIplA1NW4d9gFWd8GmZjR1caUAnjEBqS xZkmTJMSA5fysyFkXu5TvsSHxyDORWGrjBMcw= MIME-Version: 1.0 Received: by 10.223.62.194 with SMTP id y2mr1084197fah.123.1305652418833; Tue, 17 May 2011 10:13:38 -0700 (PDT) Received: by 10.223.103.67 with HTTP; Tue, 17 May 2011 10:13:38 -0700 (PDT) In-Reply-To: References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> Date: Tue, 17 May 2011 13:13:38 -0400 Message-ID: From: Peter Musgrave To: "Shekh-Yusef, Rifaat (Rifaat)" Content-Type: multipart/alternative; boundary=0015174769809ff16404a37be498 Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 17:13:40 -0000 --0015174769809ff16404a37be498 Content-Type: text/plain; charset=ISO-8859-1 Doh! I meant implicit subscriptions. On Tue, May 17, 2011 at 11:37 AM, Peter Musgrave wrote: > I agree with other comments that explicit subscriptions are evil. > > --0015174769809ff16404a37be498 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Doh! I meant implicit subscriptions.=A0

O= n Tue, May 17, 2011 at 11:37 AM, Peter Musgrave <musgravepj@gmail.com> wrot= e:
I agree with other comments that expli= cit subscriptions are evil.

--0015174769809ff16404a37be498-- From rifatyu@avaya.com Tue May 17 10:27:23 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30974E06C8 for ; Tue, 17 May 2011 10:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glgHJy8Xj33F for ; Tue, 17 May 2011 10:27:21 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id DEE2FE06B0 for ; Tue, 17 May 2011 10:27:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAD6v0k2HCzI1/2dsb2JhbACCZZRpjWNrd6wIAptqhhkElF2KRQ X-IronPort-AV: E=Sophos;i="4.65,226,1304308800"; d="scan'208,217";a="246898008" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 May 2011 13:27:18 -0400 X-IronPort-AV: E=Sophos;i="4.65,226,1304308800"; d="scan'208,217";a="652979498" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 May 2011 13:27:17 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 17 May 2011 13:27:17 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "Shekh-Yusef, Rifaat (Rifaat)" , "splices@ietf.org" Date: Tue, 17 May 2011 13:27:15 -0400 Thread-Topic: SIP INVOKE method Thread-Index: AcwUlG21RcTDGyn+QBi7uyh9D1M1iwAIncUg Message-ID: <6369CB70BFD88942B9705AC1E639A33822CBDA9433@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822CBDA9433DCUS1MBEX4glo_" MIME-Version: 1.0 Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 17:27:23 -0000 --_000_6369CB70BFD88942B9705AC1E639A33822CBDA9433DCUS1MBEX4glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you all for your quick review and feedback so far. I will work on a new version of the draft that removes the implicit subscri= ption. Please, let me know if you have any other comments beside the implicit subs= cription issue. Regards, Rifaat From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf = Of Shekh-Yusef, Rifaat (Rifaat) Sent: Tuesday, May 17, 2011 9:15 AM To: splices@ietf.org Subject: [splices] SIP INVOKE method Hi, As discussed in the last SPLICES WG meeting in Prague, the REFER method is = overloaded and has limitations that prevents it from being the ideal method= for action invocation. We have worked on the following new draft that defines a new SIP method to = be used for invoking actions: https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ We would appreciate it if people review the document and provide us with th= eir feedback. Regards, Rifaat --_000_6369CB70BFD88942B9705AC1E639A33822CBDA9433DCUS1MBEX4glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you all for your quick review and feedback so far.=

I will = work on a new version of the draft that removes the implicit subscription.<= o:p>

 

Please, let me know if you have any other comments beside the implicit sub= scription issue.

 

Regards,

Rifaat

=  

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in'>

From: splices-bounces@ietf.org [mailto:splices-b= ounces@ietf.org] On Behalf Of Shekh-Yusef, Rifaat (Rifaat)
Sen= t: Tuesday, May 17, 2011 9:15 AM
To: splices@ietf.org
S= ubject: [splices] SIP INVOKE method

 

Hi,=

 

As discu= ssed in the last SPLICES WG meeting in Prague, the REFER method is overload= ed and has limitations that prevents it from being the ideal method for act= ion invocation.

We have worked on the fo= llowing new draft that defines a new SIP method to be used for invoking act= ions:

https://datatracker.ietf.org/doc/dra= ft-yusef-splices-invoke/

 =

We would appreciate it if people review the = document and provide us with their feedback.

 

Regards,

Rifaat

 =

 

&nb= sp;

 

 

 

= --_000_6369CB70BFD88942B9705AC1E639A33822CBDA9433DCUS1MBEX4glo_-- From rifatyu@avaya.com Tue May 17 11:21:01 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F62E073C for ; Tue, 17 May 2011 11:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLTc2wfYE0cS for ; Tue, 17 May 2011 11:21:01 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBB3E06DE for ; Tue, 17 May 2011 11:20:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYBACm80k3GmAcF/2dsb2JhbACXUINBiw13iHCiegKbYIYZBJRdg3+GRg X-IronPort-AV: E=Sophos;i="4.65,226,1304308800"; d="scan'208";a="246907221" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 May 2011 14:20:47 -0400 X-IronPort-AV: E=Sophos;i="4.65,226,1304308800"; d="scan'208";a="622921260" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 May 2011 14:20:46 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 17 May 2011 14:20:46 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Peter Musgrave Date: Tue, 17 May 2011 14:20:45 -0400 Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwUqGmWp13eUW/uR4utewPD9pKxiQAELGQQ Message-ID: <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 18:21:02 -0000 Inline... > -----Original Message----- > From: Peter Musgrave [mailto:musgravepj@gmail.com] > Sent: Tuesday, May 17, 2011 11:38 AM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org > Subject: Re: [splices] SIP INVOKE method >=20 > Hi Rifaat, >=20 > Overall this is clearly described and I can see the utility. >=20 > I agree with other comments that explicit subscriptions are evil. >=20 > If find the method name INVOKE very unfortunate - since my brain when par= sing > the example actually skipped the INVOKE message thinking it was an INVITE= . > Semantically this method is somewhat like HTTP POST - but I think overloa= ding > that term might not be viewed favourably. Maybe ACTION? >=20 I am not sure that the fact that INVOKE is close to INVITE is an enough jus= tification to change the name. Anybody else has an opinion on this? > Do you foresee having actions which accept parameters? For example there = is a > special case of an action 'sendvm' that could be generalized to something= like > 'redirect vm'. I could also see a case where terminate might wish to spec= ify > the error code to be used to reject the call. >=20 Yes, and I have the following open question about these parameters: Should a separate header be defined for action parameters? > Will the gory details of what a UA must do for each action be something w= hich > is added to the document? >=20 Yes, these details will come.=20 I just wanted to get something out there to start a discussion on the idea = of a new SIP method for invoking actions. > Regards, >=20 > Peter Musgrave >=20 >=20 > On Tue, May 17, 2011 at 9:15 AM, Shekh-Yusef, Rifaat (Rifaat) > wrote: > Hi, >=20 > As discussed in the last SPLICES WG meeting in Prague, the REFER method i= s > overloaded and has limitations that prevents it from being the ideal meth= od > for action invocation. > We have worked on the following new draft that defines a new SIP method t= o be > used for invoking actions: > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ >=20 > We would appreciate it if people review the document and provide us with = their > feedback. >=20 > Regards, > Rifaat >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From partr@cisco.com Tue May 17 11:56:39 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E1CE077A for ; Tue, 17 May 2011 11:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdrA8gL2EtlR for ; Tue, 17 May 2011 11:56:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id BF156E074F for ; Tue, 17 May 2011 11:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=15009; q=dns/txt; s=iport; t=1305658595; x=1306868195; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=0NkyqDARKr33/b8adndKVFa9zfk0aKcwE3aWWmMyiXE=; b=WkMUqwMod1NRE6E0uTQv2d0KHWnpEAV0OGo3gHC1HRou2pyoVrPBwUfv hlbCHo+TRuy+twnee3S4tc8l7GBpsPaOs1ZqbbQsXq60yyNzsilBvOSvq h860L8y+poqz0v2QerbrtBgicCmVv8cOT5pP10glWYKyNUn3tN/IR0zXn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAG/E0k1Io8US/2dsb2JhbACCZZRrjk53qSGeGIYZBIZOjXuKRQ X-IronPort-AV: E=Sophos;i="4.65,226,1304294400"; d="scan'208,217";a="89036406" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 17 May 2011 18:56:33 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4HIuWWg032486; Tue, 17 May 2011 18:56:32 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 May 2011 00:26:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC14C4.22F3CB86" Date: Wed, 18 May 2011 00:26:30 +0530 Message-ID: In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBDA9433@DC-US1MBEX4.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwUlG21RcTDGyn+QBi7uyh9D1M1iwAIncUgAAH/MEA= References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9433@DC-US1MBEX4.global.avaya.com> From: "Parthasarathi R (partr)" To: "Shekh-Yusef, Rifaat (Rifaat)" , X-OriginalArrivalTime: 17 May 2011 18:56:32.0211 (UTC) FILETIME=[231C6230:01CC14C4] Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 18:56:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC14C4.22F3CB86 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rifaat, =20 I skimmed through your draft. I like the idea of controlling remote UA action using new method (INVOKE). Few comments in the draft: =20 1) Sec 4.1: SUBSCRIBE with expire=3D0 is used to terminate INVOKE dialog by INVOKE-Issuer. Whether it is ok to "INVOKE with expire=3D0" terminate INVOKE dialog as it avoids the dependency on SUBSCRIBE message to terminate. =20 2) I foresee the complexity in creating explicit subscription because two dialog creation methods (INVOKE & SUBSCRIBE) are used to make the single action. It will be good in case INVOKE acts similar to INVITE (Dialog creation & Action). INVITE has the implicit action like "ring the phone" or "auto-answer" whereas INVOKE has explicitly mention the action to be done in INVOKE-recipient. =20 3) Do you foresee INVOKE dialog creation which change the action within INVOKE dialog. For example: Following three actions using single INVOKE dialog creation but updating the action based on the application information.. =20 Action 1: Create the call Action 2: Hold the call Action 3: Terminate the call =20 Thanks Partha ________________________________ From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf Of Shekh-Yusef, Rifaat (Rifaat) Sent: Tuesday, May 17, 2011 10:57 PM To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org Subject: Re: [splices] SIP INVOKE method Thank you all for your quick review and feedback so far. I will work on a new version of the draft that removes the implicit subscription. =20 Please, let me know if you have any other comments beside the implicit subscription issue. =20 Regards, Rifaat =20 =20 From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf Of Shekh-Yusef, Rifaat (Rifaat) Sent: Tuesday, May 17, 2011 9:15 AM To: splices@ietf.org Subject: [splices] SIP INVOKE method =20 Hi, =20 As discussed in the last SPLICES WG meeting in Prague, the REFER method is overloaded and has limitations that prevents it from being the ideal method for action invocation. We have worked on the following new draft that defines a new SIP method to be used for invoking actions: https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ =20 We would appreciate it if people review the document and provide us with their feedback. =20 Regards, Rifaat =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CC14C4.22F3CB86 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Rifaat,
 
I skimmed through your draft. I like the idea of = controlling=20 remote UA action using new method (INVOKE). Few comments in the=20 draft:
 
1) Sec 4.1: SUBSCRIBE with expire=3D0 is used to = terminate=20 INVOKE dialog by INVOKE-Issuer. Whether it is ok = to "INVOKE with=20 expire=3D0" terminate INVOKE dialog as it avoids the dependency on = SUBSCRIBE=20 message to terminate.
 
2) I foresee the complexity in creating explicit = subscription=20 because two dialog creation methods (INVOKE & SUBSCRIBE) are = used to=20 make the single action. It will be good in case INVOKE acts similar to = INVITE=20 (Dialog creation & Action). INVITE has the implicit action like = "ring the=20 phone" or "auto-answer" whereas INVOKE has explicitly mention=20 the action to be done in = INVOKE-recipient.
 
3) Do you foresee INVOKE dialog creation which = change the=20 action within INVOKE dialog. For example: Following three actions = using=20 single INVOKE dialog creation but updating the action based on the = application=20 information..
 
     Action 1:  Create = the=20 call
     Action 2:  Hold the=20 call
     Action 3:  Terminate = the=20 call
 
Thanks
Partha

From: splices-bounces@ietf.org=20 [mailto:splices-bounces@ietf.org] On Behalf Of Shekh-Yusef, = Rifaat=20 (Rifaat)
Sent: Tuesday, May 17, 2011 10:57 PM
To:=20 Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org
Subject: Re: = [splices]=20 SIP INVOKE method

Thank you all for = your quick=20 review and feedback so far.

I will work on a new = version of=20 the draft that removes the implicit subscription.

 

Please, let me know = if you have=20 any other comments beside the implicit subscription = issue.

 

Regards,

Rifaat

 

 

From:=20 splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf = Of=20 Shekh-Yusef, Rifaat (Rifaat)
Sent: Tuesday, May 17, 2011 = 9:15=20 AM
To: splices@ietf.org
Subject: [splices] SIP = INVOKE=20 method

 

Hi,

 

As discussed in the last SPLICES WG meeting in = Prague, the=20 REFER method is overloaded and has limitations that prevents it from = being the=20 ideal method for action invocation.

We have worked on the following new draft that = defines a new=20 SIP method to be used for invoking actions:

htt= ps://datatracker.ietf.org/doc/draft-yusef-splices-invoke/<= /P>

 

We would appreciate it if people review the = document and=20 provide us with their feedback.

 

Regards,

Rifaat

 

 

 

 

 

 

------_=_NextPart_001_01CC14C4.22F3CB86-- From pkyzivat@cisco.com Tue May 17 12:08:53 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51846E0780 for ; Tue, 17 May 2011 12:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.547 X-Spam-Level: X-Spam-Status: No, score=-109.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWpm+SeOR7nD for ; Tue, 17 May 2011 12:08:52 -0700 (PDT) Received: from rtp-iport-2.cisco.com (unknown [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id 999E3E0748 for ; Tue, 17 May 2011 12:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=359; q=dns/txt; s=iport; t=1305659332; x=1306868932; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=IAGrCoe/a/2eYmHZm7vgwT43Tq5Kp4EDI92ssn+7agU=; b=UsK0ZMob4Bj6rf3ohehlyXh43oBvR52K6R9iVCHSpc3zvauwpsticpqV Fh90cpaeSFVHIhgRQgkEH5dU7P8sq7HYWgv1YcKXUbcN+Xz+orFAyrnLC bjd++6WhRlnwiwpo1yYV7azJFpEbjAGJBnAgr406hbhtsQwFnhUKdlEca U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogIAPnG0k2tJV2d/2dsb2JhbACYEI4Nd4hwoEOeGIYZBJARhC+KYg X-IronPort-AV: E=Sophos;i="4.65,226,1304294400"; d="scan'208";a="233776986" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 17 May 2011 19:08:51 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p4HJ8lOP023032 for ; Tue, 17 May 2011 19:08:47 GMT Message-ID: <4DD2C7BF.1030000@cisco.com> Date: Tue, 17 May 2011 15:08:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: splices@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 19:08:53 -0000 On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Yes, and I have the following open question about these parameters: > Should a separate header be defined for action parameters? I can be convinced otherwise (by a good justification), but I'm inclined toward describing the action and any parameters in a body part. Thanks, Paul From rifatyu@avaya.com Wed May 18 04:29:34 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19AEE06B6 for ; Wed, 18 May 2011 04:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFP8zoVq4fL9 for ; Wed, 18 May 2011 04:29:34 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6BDE06A3 for ; Wed, 18 May 2011 04:29:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABAGSs003GmAcF/2dsb2JhbACXTI5Ld6xDAptOhhkElF2KRQ X-IronPort-AV: E=Sophos;i="4.65,231,1304308800"; d="scan'208";a="280525994" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 May 2011 07:29:32 -0400 X-IronPort-AV: E=Sophos;i="4.65,231,1304308800"; d="scan'208";a="623263251" Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 May 2011 07:29:32 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 18 May 2011 07:29:32 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat , "splices@ietf.org" Date: Wed, 18 May 2011 07:29:30 -0400 Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwUxd4Jpp/zCEJrQRuyU21E2rS/BQAiF90w Message-ID: <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> In-Reply-To: <4DD2C7BF.1030000@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 11:29:34 -0000 Hi Paul, I think that the main reason for using Headers for actions and parameters i= s to allow for proxy applications on the call path to recognize the request= ed action, as some UAs might encrypt the body part. Regards, Rifaat > -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Paul Kyzivat > Sent: Tuesday, May 17, 2011 3:09 PM > To: splices@ietf.org > Subject: Re: [splices] SIP INVOKE method >=20 >=20 >=20 > On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >=20 > > Yes, and I have the following open question about these parameters: > > Should a separate header be defined for action parameters? >=20 > I can be convinced otherwise (by a good justification), but I'm inclined > toward describing the action and any parameters in a body part. >=20 > Thanks, > Paul > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From rifatyu@avaya.com Wed May 18 04:37:22 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE55E06BC for ; Wed, 18 May 2011 04:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rqbnjB95P-E for ; Wed, 18 May 2011 04:37:21 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id BBAF3E06B7 for ; Wed, 18 May 2011 04:37:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABAL2u002HCzI1/2dsb2JhbACXTI5Ld4hwo0UCm0+GGQSUXYpF X-IronPort-AV: E=Sophos;i="4.65,231,1304308800"; d="scan'208";a="280527158" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 May 2011 07:37:21 -0400 X-IronPort-AV: E=Sophos;i="4.65,231,1304308800"; d="scan'208";a="653297414" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 May 2011 07:37:20 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 18 May 2011 07:37:20 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "Parthasarathi R (partr)" , "splices@ietf.org" Date: Wed, 18 May 2011 07:37:18 -0400 Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwUlG21RcTDGyn+QBi7uyh9D1M1iwAIncUgAAH/MEAAJAxbgA== Message-ID: <6369CB70BFD88942B9705AC1E639A33822CBE5C341@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9433@DC-US1MBEX4.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 11:37:22 -0000 Inline... > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Tuesday, May 17, 2011 2:57 PM > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > Subject: RE: [splices] SIP INVOKE method >=20 > Rifaat, >=20 > I skimmed through your draft. I like the idea of controlling remote UA ac= tion > using new method (INVOKE). Few comments in the draft: >=20 > 1) Sec 4.1: SUBSCRIBE with expire=3D0 is used to terminate INVOKE dialog = by > INVOKE-Issuer. Whether=A0it is=A0ok to=A0"INVOKE with expire=3D0" termina= te INVOKE > dialog as it avoids the dependency on SUBSCRIBE message=A0to terminate. >=20 The new plan is to remove the implicit subscription. > 2) I foresee the complexity in creating explicit subscription because two > dialog creation methods (INVOKE & SUBSCRIBE)=A0are used to make the singl= e > action. It will be good in case INVOKE acts similar to INVITE (Dialog cre= ation > & Action). INVITE has the implicit action like "ring the phone" or "auto- > answer" whereas INVOKE has explicitly mention the=A0action=A0to be=A0done= in INVOKE- > recipient. >=20 I am not sure that I understand your comment, but with the new plan the INV= OKE will NOT create a dialog. > 3) Do you foresee INVOKE dialog creation which change the action within= =A0INVOKE > dialog. For example: Following three actions using single INVOKE dialog > creation but updating the action based on the application information.. >=20 > =A0=A0=A0=A0 Action 1:=A0 Create the call > =A0=A0=A0=A0 Action 2:=A0 Hold the call > =A0=A0=A0=A0 Action 3:=A0 Terminate the call >=20 In this case, I expect the INVOKE-Issuer to first create a subscription and= then to send the INVOKE requests in the context of that dialog. > Thanks > Partha >=20 > ________________________________________ > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Shekh-Yusef, Rifaat (Rifaat) > Sent: Tuesday, May 17, 2011 10:57 PM > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > Subject: Re: [splices] SIP INVOKE method > Thank you all for your quick review and feedback so far. > I will work on a new version of the draft that removes the implicit > subscription. >=20 > Please, let me know if you have any other comments beside the implicit > subscription issue. >=20 > Regards, > Rifaat >=20 >=20 > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Shekh-Yusef, Rifaat (Rifaat) > Sent: Tuesday, May 17, 2011 9:15 AM > To: splices@ietf.org > Subject: [splices] SIP INVOKE method >=20 > Hi, >=20 > As discussed in the last SPLICES WG meeting in Prague, the REFER method i= s > overloaded and has limitations that prevents it from being the ideal meth= od > for action invocation. > We have worked on the following new draft that defines a new SIP method t= o be > used for invoking actions: > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ >=20 > We would appreciate it if people review the document and provide us with = their > feedback. >=20 > Regards, > Rifaat >=20 >=20 >=20 >=20 >=20 From partr@cisco.com Wed May 18 05:26:53 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA2AE06EA for ; Wed, 18 May 2011 05:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwZKAUtrw++i for ; Wed, 18 May 2011 05:26:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 19631E0689 for ; Wed, 18 May 2011 05:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=4169; q=dns/txt; s=iport; t=1305721612; x=1306931212; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=1ElSvb/x7JV/MIt5jZ0XlwDusRsSXSD8pY3FlPCx2M4=; b=cjPOsEvdn3nK8dkKPOSlYoLLiEClk5RS3txBQvc50akOMlJgK8LVkkUO 8eieqNrPjMihY2SSU1AE5kyG0ipfxZAjErDMDZXcY3sdfs6bFOijH1NiK 3gameCYLgKzOJ94PzKTLZ7Fqy9ze2MQb1nkciETqJDO4Sd1YdwYb2HK75 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABAHe6001Io8UT/2dsb2JhbACXTI5Ld4hwoH2eEIYZBIZOjXuKRQ X-IronPort-AV: E=Sophos;i="4.65,231,1304294400"; d="scan'208";a="89212131" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 18 May 2011 12:26:47 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4ICQkad019828; Wed, 18 May 2011 12:26:46 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 May 2011 17:56:46 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2011 17:56:45 +0530 Message-ID: In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBE5C341@DC-US1MBEX4.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwUlG21RcTDGyn+QBi7uyh9D1M1iwAIncUgAAH/MEAAJAxbgAABYJew References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9433@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C341@DC-US1MBEX4.global.avaya.com> From: "Parthasarathi R (partr)" To: "Shekh-Yusef, Rifaat (Rifaat)" , X-OriginalArrivalTime: 18 May 2011 12:26:46.0387 (UTC) FILETIME=[DA7C9430:01CC1556] Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 12:26:53 -0000 Rifaat, SUBSCRIBE creates the dialog and within the created subscribe based = dialog, INVOKE method (transaction) is sent from subscriber to perform = the specific action based on the mentioned URN. Please correct me in = case I misunderstand your proposal. Please read inline Thanks Partha -----Original Message----- From: Shekh-Yusef, Rifaat (Rifaat) [mailto:rifatyu@avaya.com]=20 Sent: Wednesday, May 18, 2011 5:07 PM To: Parthasarathi R (partr); splices@ietf.org Subject: RE: [splices] SIP INVOKE method Inline... > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Tuesday, May 17, 2011 2:57 PM > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > Subject: RE: [splices] SIP INVOKE method >=20 > Rifaat, >=20 > I skimmed through your draft. I like the idea of controlling remote UA = > action using new method (INVOKE). Few comments in the draft: >=20 > 1) Sec 4.1: SUBSCRIBE with expire=3D0 is used to terminate INVOKE = dialog=20 > by INVOKE-Issuer. Whether=A0it is=A0ok to=A0"INVOKE with expire=3D0" = terminate=20 > INVOKE dialog as it avoids the dependency on SUBSCRIBE message=A0to = terminate. >=20 The new plan is to remove the implicit subscription. How is it possible for INVOKE-Issuer to abort or stop the = action in case required? =20 > 2) I foresee the complexity in creating explicit subscription because=20 > two dialog creation methods (INVOKE & SUBSCRIBE)=A0are used to make = the=20 > single action. It will be good in case INVOKE acts similar to INVITE=20 > (Dialog creation & Action). INVITE has the implicit action like "ring=20 > the phone" or "auto- answer" whereas INVOKE has explicitly mention = the=A0 > action=A0to be=A0done in INVOKE- recipient. >=20 I am not sure that I understand your comment, but with the new plan the = INVOKE will NOT create a dialog. > 3) Do you foresee INVOKE dialog creation which change the action=20 > within=A0INVOKE dialog. For example: Following three actions using=20 > single INVOKE dialog creation but updating the action based on the = application information.. >=20 > =A0=A0=A0=A0 Action 1:=A0 Create the call > =A0=A0=A0=A0 Action 2:=A0 Hold the call > =A0=A0=A0=A0 Action 3:=A0 Terminate the call >=20 In this case, I expect the INVOKE-Issuer to first create a subscription = and then to send the INVOKE requests in the context of that dialog. In case INVOKE is mid-dialog transaction within SUBSCRIBE dialog, then = whether multiple simultaneous INVOKE operation is allowed or not. = Example 1) INVOKE hold action 2) Even before INVOKE hold completion NOTIFY receives, = INVOKE terminate call action > Thanks > Partha >=20 > ________________________________________ > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On=20 > Behalf Of Shekh-Yusef, Rifaat (Rifaat) > Sent: Tuesday, May 17, 2011 10:57 PM > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > Subject: Re: [splices] SIP INVOKE method Thank you all for your quick=20 > review and feedback so far. > I will work on a new version of the draft that removes the implicit=20 > subscription. >=20 > Please, let me know if you have any other comments beside the implicit = > subscription issue. >=20 > Regards, > Rifaat >=20 >=20 > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On=20 > Behalf Of Shekh-Yusef, Rifaat (Rifaat) > Sent: Tuesday, May 17, 2011 9:15 AM > To: splices@ietf.org > Subject: [splices] SIP INVOKE method >=20 > Hi, >=20 > As discussed in the last SPLICES WG meeting in Prague, the REFER=20 > method is overloaded and has limitations that prevents it from being=20 > the ideal method for action invocation. > We have worked on the following new draft that defines a new SIP=20 > method to be used for invoking actions: > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ >=20 > We would appreciate it if people review the document and provide us=20 > with their feedback. >=20 > Regards, > Rifaat >=20 >=20 >=20 >=20 >=20 From rifatyu@avaya.com Wed May 18 05:54:54 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55457E06AC for ; Wed, 18 May 2011 05:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2VYnU2xLqZa for ; Wed, 18 May 2011 05:54:53 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 85D3EE06DD for ; Wed, 18 May 2011 05:54:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABAEXB002HCzI1/2dsb2JhbACXTI5Md4hwozECm0uGGQSUXYpF X-IronPort-AV: E=Sophos;i="4.65,231,1304308800"; d="scan'208";a="188909964" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 18 May 2011 08:54:52 -0400 X-IronPort-AV: E=Sophos;i="4.65,231,1304308800"; d="scan'208";a="653324707" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 May 2011 08:54:52 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 18 May 2011 08:54:51 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "Parthasarathi R (partr)" , "splices@ietf.org" Date: Wed, 18 May 2011 08:54:34 -0400 Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwUlG21RcTDGyn+QBi7uyh9D1M1iwAIncUgAAH/MEAAJAxbgAABYJewAADBXvA= Message-ID: <6369CB70BFD88942B9705AC1E639A33822CBE5C3E5@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9433@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C341@DC-US1MBEX4.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 12:54:54 -0000 Inline... > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Wednesday, May 18, 2011 8:27 AM > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > Subject: RE: [splices] SIP INVOKE method >=20 > Rifaat, >=20 > SUBSCRIBE creates the dialog and within the created subscribe based dialo= g, > INVOKE method (transaction) is sent from subscriber to perform the specif= ic > action based on the mentioned URN. Please correct me in case I misunderst= and > your proposal. >=20 Yes, that is correct. > Please read inline >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Shekh-Yusef, Rifaat (Rifaat) [mailto:rifatyu@avaya.com] > Sent: Wednesday, May 18, 2011 5:07 PM > To: Parthasarathi R (partr); splices@ietf.org > Subject: RE: [splices] SIP INVOKE method >=20 > Inline... >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: Tuesday, May 17, 2011 2:57 PM > > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > > Subject: RE: [splices] SIP INVOKE method > > > > Rifaat, > > > > I skimmed through your draft. I like the idea of controlling remote UA > > action using new method (INVOKE). Few comments in the draft: > > > > 1) Sec 4.1: SUBSCRIBE with expire=3D0 is used to terminate INVOKE dialo= g > > by INVOKE-Issuer. Whether=A0it is=A0ok to=A0"INVOKE with expire=3D0" te= rminate > > INVOKE dialog as it avoids the dependency on SUBSCRIBE message=A0to ter= minate. > > > The new plan is to remove the implicit subscription. >=20 > How is it possible for INVOKE-Issuer to abort or stop the action= in > case required? >=20 One possible way is to define a parameter to the URN and then resend the IN= VOKE request. For example, urn:invoke:whatever;abort >=20 > > 2) I foresee the complexity in creating explicit subscription because > > two dialog creation methods (INVOKE & SUBSCRIBE)=A0are used to make the > > single action. It will be good in case INVOKE acts similar to INVITE > > (Dialog creation & Action). INVITE has the implicit action like "ring > > the phone" or "auto- answer" whereas INVOKE has explicitly mention the > > action=A0to be=A0done in INVOKE- recipient. > > > I am not sure that I understand your comment, but with the new plan the I= NVOKE > will NOT create a dialog. >=20 >=20 > > 3) Do you foresee INVOKE dialog creation which change the action > > within=A0INVOKE dialog. For example: Following three actions using > > single INVOKE dialog creation but updating the action based on the > application information.. > > > > =A0=A0=A0=A0 Action 1:=A0 Create the call > > =A0=A0=A0=A0 Action 2:=A0 Hold the call > > =A0=A0=A0=A0 Action 3:=A0 Terminate the call > > > In this case, I expect the INVOKE-Issuer to first create a subscription a= nd > then to send the INVOKE requests in the context of that dialog. >=20 > > In case INVOKE is mid-dialog transaction within SUBSCRIBE dialog, then wh= ether > multiple simultaneous INVOKE operation is allowed or not. Example > 1) INVOKE hold action > 2) Even before INVOKE hold completion NOTIFY receives, INVO= KE > terminate call action >=20 > >=20 Yes, that should be possible. > > Thanks > > Partha > > > > ________________________________________ > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On > > Behalf Of Shekh-Yusef, Rifaat (Rifaat) > > Sent: Tuesday, May 17, 2011 10:57 PM > > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method Thank you all for your quick > > review and feedback so far. > > I will work on a new version of the draft that removes the implicit > > subscription. > > > > Please, let me know if you have any other comments beside the implicit > > subscription issue. > > > > Regards, > > Rifaat > > > > > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On > > Behalf Of Shekh-Yusef, Rifaat (Rifaat) > > Sent: Tuesday, May 17, 2011 9:15 AM > > To: splices@ietf.org > > Subject: [splices] SIP INVOKE method > > > > Hi, > > > > As discussed in the last SPLICES WG meeting in Prague, the REFER > > method is overloaded and has limitations that prevents it from being > > the ideal method for action invocation. > > We have worked on the following new draft that defines a new SIP > > method to be used for invoking actions: > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > > > We would appreciate it if people review the document and provide us > > with their feedback. > > > > Regards, > > Rifaat > > > > > > > > > > From pkyzivat@cisco.com Wed May 18 05:58:23 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66151E06C7 for ; Wed, 18 May 2011 05:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-0+ddNb-35G for ; Wed, 18 May 2011 05:58:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 59947E06AC for ; Wed, 18 May 2011 05:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1535; q=dns/txt; s=iport; t=1305723502; x=1306933102; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tUQmepYw/hknb8laZHg7f6Mh5y/0NtUhihU8xyGp6Nw=; b=Kv0pp/MFi6FAIhX8FtlBlpFcDiJtdevU7dxJlT25XK5/LFfbxwy9a6SB 1KrzjiorPNuVCAT4KCgW1Rg18IEWzMEZexuL9gFHqjdabn/8VbzOek8Ty irxf//+erbytvUfOCEcLNNv1SgZ0uIuJcZFo/LSRljQKITQ59TdXbPWBP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABAH/B001Io8UT/2dsb2JhbACXTI5Md4hwoHieCYYZBJARhC+KYg X-IronPort-AV: E=Sophos;i="4.65,231,1304294400"; d="scan'208";a="89218693" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 18 May 2011 12:58:20 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4ICwI98024537; Wed, 18 May 2011 12:58:19 GMT Message-ID: <4DD3C26A.9050705@cisco.com> Date: Wed, 18 May 2011 08:58:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 12:58:23 -0000 On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Hi Paul, > > I think that the main reason for using Headers for actions and parameters is to allow for proxy applications on the call path to recognize the requested action, as some UAs might encrypt the body part. Hmm. That seems to me to be more reason to use a body part! What possible reason would an intermediary have for snooping into these actions? Note that this functionality is *very* sensitive - in the wrong hands this stuff can do great damage. I predict that there will be a lot of demand for very strong security considerations. Putting the action in a body and encrypting it might be a good approach. Thanks, Paul > Regards, > Rifaat > > >> -----Original Message----- >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Tuesday, May 17, 2011 3:09 PM >> To: splices@ietf.org >> Subject: Re: [splices] SIP INVOKE method >> >> >> >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> >>> Yes, and I have the following open question about these parameters: >>> Should a separate header be defined for action parameters? >> >> I can be convinced otherwise (by a good justification), but I'm inclined >> toward describing the action and any parameters in a body part. >> >> Thanks, >> Paul >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> https://www.ietf.org/mailman/listinfo/splices > From partr@cisco.com Wed May 18 06:06:44 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454E8E0737 for ; Wed, 18 May 2011 06:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pH-kH5k4J6zq for ; Wed, 18 May 2011 06:06:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id F2A95E0714 for ; Wed, 18 May 2011 06:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=5267; q=dns/txt; s=iport; t=1305724003; x=1306933603; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=xhNAUvm9u+m1DyMvM4YBI+x4EOqU61prYAkFs7R0vAU=; b=RMG/co/n/7ZZcQmpkno1wTng9R6YwgAcI5mxP00/qEQYViIFj+VwEfF0 e1ehbsXKYCwdqpa7FFRCfsU4wteUq3x6jg0OVBu8Ao69sfu0fIYKuYR0k QBYc/M0gPLZi2+adehyJNOzgMPJ2bGue6guCzoZuGGJywTNxg1I5xW2zF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABANXD001Io8UT/2dsb2JhbACXTI5Md4hwoHeeCYYZBIZOjXuKRQ X-IronPort-AV: E=Sophos;i="4.65,231,1304294400"; d="scan'208";a="89220534" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 18 May 2011 13:06:41 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4ID6eWJ025745; Wed, 18 May 2011 13:06:40 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 May 2011 18:36:40 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2011 18:36:39 +0530 Message-ID: In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBE5C3E5@DC-US1MBEX4.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwUlG21RcTDGyn+QBi7uyh9D1M1iwAIncUgAAH/MEAAJAxbgAABYJewAADBXvAAAQFB4A== References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9433@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C341@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C3E5@DC-US1MBEX4.global.avaya.com> From: "Parthasarathi R (partr)" To: "Shekh-Yusef, Rifaat (Rifaat)" , X-OriginalArrivalTime: 18 May 2011 13:06:40.0059 (UTC) FILETIME=[6D39F0B0:01CC155C] Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 13:06:44 -0000 Rifaat, Thanks for the clarification. Please include the text in the next = revision to show how multiple simultaneous INVOKE operation happens = within the dialog & abort opertion parameter in action URN. Thanks Partha=20 -----Original Message----- From: Shekh-Yusef, Rifaat (Rifaat) [mailto:rifatyu@avaya.com]=20 Sent: Wednesday, May 18, 2011 6:25 PM To: Parthasarathi R (partr); splices@ietf.org Subject: RE: [splices] SIP INVOKE method Inline... > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Wednesday, May 18, 2011 8:27 AM > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > Subject: RE: [splices] SIP INVOKE method >=20 > Rifaat, >=20 > SUBSCRIBE creates the dialog and within the created subscribe based=20 > dialog, INVOKE method (transaction) is sent from subscriber to perform = > the specific action based on the mentioned URN. Please correct me in=20 > case I misunderstand your proposal. >=20 Yes, that is correct. > Please read inline >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Shekh-Yusef, Rifaat (Rifaat) [mailto:rifatyu@avaya.com] > Sent: Wednesday, May 18, 2011 5:07 PM > To: Parthasarathi R (partr); splices@ietf.org > Subject: RE: [splices] SIP INVOKE method >=20 > Inline... >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: Tuesday, May 17, 2011 2:57 PM > > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > > Subject: RE: [splices] SIP INVOKE method > > > > Rifaat, > > > > I skimmed through your draft. I like the idea of controlling remote=20 > > UA action using new method (INVOKE). Few comments in the draft: > > > > 1) Sec 4.1: SUBSCRIBE with expire=3D0 is used to terminate INVOKE=20 > > dialog by INVOKE-Issuer. Whether=A0it is=A0ok to=A0"INVOKE with = expire=3D0"=20 > > terminate INVOKE dialog as it avoids the dependency on SUBSCRIBE = message=A0to terminate. > > > The new plan is to remove the implicit subscription. >=20 > How is it possible for INVOKE-Issuer to abort or stop the=20 > action in case required? >=20 One possible way is to define a parameter to the URN and then resend the = INVOKE request. For example, urn:invoke:whatever;abort >=20 > > 2) I foresee the complexity in creating explicit subscription=20 > > because two dialog creation methods (INVOKE & SUBSCRIBE)=A0are used = to=20 > > make the single action. It will be good in case INVOKE acts similar=20 > > to INVITE (Dialog creation & Action). INVITE has the implicit action = > > like "ring the phone" or "auto- answer" whereas INVOKE has=20 > > explicitly mention the action=A0to be=A0done in INVOKE- recipient. > > > I am not sure that I understand your comment, but with the new plan=20 > the INVOKE will NOT create a dialog. >=20 >=20 > > 3) Do you foresee INVOKE dialog creation which change the action=20 > > within=A0INVOKE dialog. For example: Following three actions using=20 > > single INVOKE dialog creation but updating the action based on the > application information.. > > > > =A0=A0=A0=A0 Action 1:=A0 Create the call > > =A0=A0=A0=A0 Action 2:=A0 Hold the call > > =A0=A0=A0=A0 Action 3:=A0 Terminate the call > > > In this case, I expect the INVOKE-Issuer to first create a=20 > subscription and then to send the INVOKE requests in the context of = that dialog. >=20 > > In case INVOKE is mid-dialog transaction within SUBSCRIBE dialog, then = > whether multiple simultaneous INVOKE operation is allowed or not. = Example > 1) INVOKE hold action > 2) Even before INVOKE hold completion NOTIFY receives,=20 > INVOKE terminate call action >=20 > >=20 Yes, that should be possible. > > Thanks > > Partha > > > > ________________________________________ > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On=20 > > Behalf Of Shekh-Yusef, Rifaat (Rifaat) > > Sent: Tuesday, May 17, 2011 10:57 PM > > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method Thank you all for your=20 > > quick review and feedback so far. > > I will work on a new version of the draft that removes the implicit=20 > > subscription. > > > > Please, let me know if you have any other comments beside the=20 > > implicit subscription issue. > > > > Regards, > > Rifaat > > > > > > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On=20 > > Behalf Of Shekh-Yusef, Rifaat (Rifaat) > > Sent: Tuesday, May 17, 2011 9:15 AM > > To: splices@ietf.org > > Subject: [splices] SIP INVOKE method > > > > Hi, > > > > As discussed in the last SPLICES WG meeting in Prague, the REFER=20 > > method is overloaded and has limitations that prevents it from being = > > the ideal method for action invocation. > > We have worked on the following new draft that defines a new SIP=20 > > method to be used for invoking actions: > > https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/ > > > > We would appreciate it if people review the document and provide us=20 > > with their feedback. > > > > Regards, > > Rifaat > > > > > > > > > > From rifatyu@avaya.com Wed May 18 06:26:07 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF2BE06C0 for ; Wed, 18 May 2011 06:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMhN7VRtbu24 for ; Wed, 18 May 2011 06:26:07 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id B0473E06BD for ; Wed, 18 May 2011 06:26:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABAJjI002HCzI1/2dsb2JhbACXTI5Md6whAptLhhkElF2KRQ X-IronPort-AV: E=Sophos;i="4.65,231,1304308800"; d="scan'208";a="247031203" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 May 2011 09:25:57 -0400 X-IronPort-AV: E=Sophos;i="4.65,231,1304308800"; d="scan'208";a="653337535" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 May 2011 09:25:36 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 18 May 2011 09:25:36 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat Date: Wed, 18 May 2011 09:25:35 -0400 Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwVW0WMIcLzebK1RGWHDTXEYztIagAAEYnQ Message-ID: <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> In-Reply-To: <4DD3C26A.9050705@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 13:26:07 -0000 Paul, I am not talking about any intermediary, but about application servers on t= he call path in an enterprise. Some application servers might be interested in a specific action to push a= pplication to the phone. I agree that strong security is required and we are asking the client to on= ly allow authorized users to invoke an action by challenging the INVOKE-Iss= uer. Regards, Rifaat > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, May 18, 2011 8:58 AM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org > Subject: Re: [splices] SIP INVOKE method >=20 >=20 >=20 > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi Paul, > > > > I think that the main reason for using Headers for actions and paramete= rs is > to allow for proxy applications on the call path to recognize the request= ed > action, as some UAs might encrypt the body part. >=20 > Hmm. That seems to me to be more reason to use a body part! >=20 > What possible reason would an intermediary have for snooping into these > actions? >=20 > Note that this functionality is *very* sensitive - in the wrong hands > this stuff can do great damage. I predict that there will be a lot of > demand for very strong security considerations. Putting the action in a > body and encrypting it might be a good approach. >=20 > Thanks, > Paul >=20 > > Regards, > > Rifaat > > > > > >> -----Original Message----- > >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Be= half > Of > >> Paul Kyzivat > >> Sent: Tuesday, May 17, 2011 3:09 PM > >> To: splices@ietf.org > >> Subject: Re: [splices] SIP INVOKE method > >> > >> > >> > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > >> > >>> Yes, and I have the following open question about these parameters: > >>> Should a separate header be defined for action parameters? > >> > >> I can be convinced otherwise (by a good justification), but I'm inclin= ed > >> toward describing the action and any parameters in a body part. > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> splices mailing list > >> splices@ietf.org > >> https://www.ietf.org/mailman/listinfo/splices > > From musgravepj@gmail.com Wed May 18 06:41:26 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A7AE06FB for ; Wed, 18 May 2011 06:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e99QuyokY9mG for ; Wed, 18 May 2011 06:41:26 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0926E06C5 for ; Wed, 18 May 2011 06:41:25 -0700 (PDT) Received: by fxm15 with SMTP id 15so1375773fxm.31 for ; Wed, 18 May 2011 06:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3uuUUhJcfSpYHxsAc8jwLmdJDB5N1cfxwzZUVYHYpmw=; b=dFkdhE8HDVmnHJU9ctq0HalZQRH57Jqjr3Xs33NlEeNinU7wpkXOYyFPH4qWRdCcGx ywMm0g+bIkZDtN28nkcmUbuLMlmE0lj8yWgD4nd8DoyQNo9JI4hUyEbZ1R3lsopYe5da xqiB3npKg99C65hdCcYQeFq69Mhvrw9UPP6Wc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j9sM0CcK3EUxoDMlqA8nap7UB+IfwrllYOesGbxIRjM6KvMBK8020tPZMpisW9/rRq uUVDNP+1XO0m7egVIiIg2jcry3j0rDY9wTClPnIuKlSwB0iTaJ33Ur9ixN/NSR6RDhHx 8K6fEtHTVxWNC9DwgeDg2L0q8kmt9RJm6oTi8= MIME-Version: 1.0 Received: by 10.223.117.137 with SMTP id r9mr2394378faq.28.1305725518790; Wed, 18 May 2011 06:31:58 -0700 (PDT) Received: by 10.223.103.67 with HTTP; Wed, 18 May 2011 06:31:58 -0700 (PDT) In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> Date: Wed, 18 May 2011 09:31:58 -0400 Message-ID: From: Peter Musgrave To: "Shekh-Yusef, Rifaat (Rifaat)" Content-Type: multipart/alternative; boundary=001636c5974cb8bf7204a38ce96f Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 13:41:27 -0000 --001636c5974cb8bf7204a38ce96f Content-Type: text/plain; charset=ISO-8859-1 Rifaat, I agree with Paul - a body may make sense. If we are going as far as defining a new SIP METHOD - does it make sense to have separate problem domains for the URNs? Do we think in the future others might want a different "package" of actions for some other purpose? If so, I think this strengthens the case for using a body. Peter On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) < rifatyu@avaya.com> wrote: > Paul, > > I am not talking about any intermediary, but about application servers on > the call path in an enterprise. > Some application servers might be interested in a specific action to push > application to the phone. > I agree that strong security is required and we are asking the client to > only allow authorized users to invoke an action by challenging the > INVOKE-Issuer. > > Regards, > Rifaat > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, May 18, 2011 8:58 AM > > To: Shekh-Yusef, Rifaat (Rifaat) > > Cc: splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > Hi Paul, > > > > > > I think that the main reason for using Headers for actions and > parameters is > > to allow for proxy applications on the call path to recognize the > requested > > action, as some UAs might encrypt the body part. > > > > Hmm. That seems to me to be more reason to use a body part! > > > > What possible reason would an intermediary have for snooping into these > > actions? > > > > Note that this functionality is *very* sensitive - in the wrong hands > > this stuff can do great damage. I predict that there will be a lot of > > demand for very strong security considerations. Putting the action in a > > body and encrypting it might be a good approach. > > > > Thanks, > > Paul > > > > > Regards, > > > Rifaat > > > > > > > > >> -----Original Message----- > > >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On > Behalf > > Of > > >> Paul Kyzivat > > >> Sent: Tuesday, May 17, 2011 3:09 PM > > >> To: splices@ietf.org > > >> Subject: Re: [splices] SIP INVOKE method > > >> > > >> > > >> > > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > >> > > >>> Yes, and I have the following open question about these parameters: > > >>> Should a separate header be defined for action parameters? > > >> > > >> I can be convinced otherwise (by a good justification), but I'm > inclined > > >> toward describing the action and any parameters in a body part. > > >> > > >> Thanks, > > >> Paul > > >> _______________________________________________ > > >> splices mailing list > > >> splices@ietf.org > > >> https://www.ietf.org/mailman/listinfo/splices > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > --001636c5974cb8bf7204a38ce96f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rifaat,=A0

I agree with Paul - a body may make sense.=A0=

If we are going as far as defining a new SIP METH= OD - does it make sense to have=A0separate=A0problem domains for the URNs? = Do we think in the future others might want a different "package"= of actions for some other purpose? If so, I think this=A0strengthens=A0the= case for using a body.=A0

Peter

On Wed, May 18,= 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) <rifatyu@avaya.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;"> Paul,

I am not talking about any intermediary, but about application servers on t= he call path in an enterprise.
Some application servers might be interested in a specific action to push a= pplication to the phone.
I agree that strong security is required and we are asking the client to on= ly allow authorized users to invoke an action by challenging the INVOKE-Iss= uer.

Regards,
=A0Rifaat

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzi= vat@cisco.com]
> Sent: Wednesday, May 18, 2011 8:58 AM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: splices@ietf.org
> Subject: Re: [splices] SIP INVOKE method
>
>
>
> On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> > Hi Paul,
> >
> > I think that the main reason for using Headers for actions and pa= rameters is
> to allow for proxy applications on the call path to recognize the requ= ested
> action, as some UAs might encrypt the body part.
>
> Hmm. That seems to me to be more reason to use a body part!
>
> What possible reason would an intermediary have for snooping into thes= e
> actions?
>
> Note that this functionality is *very* sensitive - in the wrong hands<= br> > this stuff can do great damage. I predict that there will be a lot of<= br> > demand for very strong security considerations. Putting the action in = a
> body and encrypting it might be a good approach.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
> > Regards,
> > =A0 Rifaat
> >
> >
> >> -----Original Message-----
> >> From: splices-bou= nces@ietf.org [mailto:splic= es-bounces@ietf.org] On Behalf
> Of
> >> Paul Kyzivat
> >> Sent: Tuesday, May 17, 2011 3:09 PM
> >> To: splices@ietf.org<= br> > >> Subject: Re: [splices] SIP INVOKE method
> >>
> >>
> >>
> >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> >>
> >>> Yes, and I have the following open question about these p= arameters:
> >>> Should a separate header be defined for action parameters= ?
> >>
> >> I can be convinced otherwise (by a good justification), but I= 'm inclined
> >> toward describing the action and any parameters in a body par= t.
> >>
> >> =A0 =A0Thanks,
> >> =A0 =A0Paul
> >> _______________________________________________
> >> splices mailing list
> >> splices@ietf.org
> >> https://www.ietf.org/mailman/listinfo/splices
> >
_______________________________________________
splices mailing list
splices@ietf.org
https://www.ietf.org/mailman/listinfo/splices

--001636c5974cb8bf7204a38ce96f-- From rifatyu@avaya.com Wed May 18 08:02:25 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33008E076B for ; Wed, 18 May 2011 08:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvpR5YIXa-CP for ; Wed, 18 May 2011 08:02:24 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id EED06E0741 for ; Wed, 18 May 2011 08:02:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUBAJHe002HCzI1/2dsb2JhbACCZZRng0CKImp3iHCjBwKbUIYZBJRdg3+GRg X-IronPort-AV: E=Sophos;i="4.65,231,1304308800"; d="scan'208,217";a="188935868" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 18 May 2011 11:02:22 -0400 X-IronPort-AV: E=Sophos;i="4.65,231,1304308800"; d="scan'208,217";a="653381783" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 May 2011 11:02:02 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 18 May 2011 11:02:02 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Peter Musgrave Date: Wed, 18 May 2011 11:02:01 -0400 Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwVYUmfYMosWeuyS6OWDjqUl/SR6QACtHEg Message-ID: <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822CBE5C63FDCUS1MBEX4glo_" MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 15:02:25 -0000 --_000_6369CB70BFD88942B9705AC1E639A33822CBE5C63FDCUS1MBEX4glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, Yes, I expect others to try to define new category of actions, but these mu= st be registered with IANA. I am not clear on how this strengthens the case for using a body. Regards, Rifaat From: Peter Musgrave [mailto:musgravepj@gmail.com] Sent: Wednesday, May 18, 2011 9:32 AM To: Shekh-Yusef, Rifaat (Rifaat) Cc: Paul Kyzivat; splices@ietf.org Subject: Re: [splices] SIP INVOKE method Rifaat, I agree with Paul - a body may make sense. If we are going as far as defining a new SIP METHOD - does it make sense to= have separate problem domains for the URNs? Do we think in the future othe= rs might want a different "package" of actions for some other purpose? If s= o, I think this strengthens the case for using a body. Peter On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) > wrote: Paul, I am not talking about any intermediary, but about application servers on t= he call path in an enterprise. Some application servers might be interested in a specific action to push a= pplication to the phone. I agree that strong security is required and we are asking the client to on= ly allow authorized users to invoke an action by challenging the INVOKE-Iss= uer. Regards, Rifaat > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, May 18, 2011 8:58 AM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org > Subject: Re: [splices] SIP INVOKE method > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi Paul, > > > > I think that the main reason for using Headers for actions and paramete= rs is > to allow for proxy applications on the call path to recognize the request= ed > action, as some UAs might encrypt the body part. > > Hmm. That seems to me to be more reason to use a body part! > > What possible reason would an intermediary have for snooping into these > actions? > > Note that this functionality is *very* sensitive - in the wrong hands > this stuff can do great damage. I predict that there will be a lot of > demand for very strong security considerations. Putting the action in a > body and encrypting it might be a good approach. > > Thanks, > Paul > > > Regards, > > Rifaat > > > > > >> -----Original Message----- > >> From: splices-bounces@ietf.org [mailt= o:splices-bounces@ietf.org] On Behalf > Of > >> Paul Kyzivat > >> Sent: Tuesday, May 17, 2011 3:09 PM > >> To: splices@ietf.org > >> Subject: Re: [splices] SIP INVOKE method > >> > >> > >> > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > >> > >>> Yes, and I have the following open question about these parameters: > >>> Should a separate header be defined for action parameters? > >> > >> I can be convinced otherwise (by a good justification), but I'm inclin= ed > >> toward describing the action and any parameters in a body part. > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> splices mailing list > >> splices@ietf.org > >> https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ splices mailing list splices@ietf.org https://www.ietf.org/mailman/listinfo/splices --_000_6369CB70BFD88942B9705AC1E639A33822CBE5C63FDCUS1MBEX4glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,=

 <= /p>

Yes, I expect others to try to define new ca= tegory of actions, but these must be registered with IANA.

I am not clear on how this strengthens the= case for using a body.

 

Regards,

Rifaat

 

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = Peter Musgrave [mailto:musgravepj@gmail.com]
Sent: Wednesday, Ma= y 18, 2011 9:32 AM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc:= Paul Kyzivat; splices@ietf.org
Subject: Re: [splices] SIP INVOKE= method

 

Rifaat, 

 

I agree with P= aul - a body may make sense. 

 

If we are going = as far as defining a new SIP METHOD - does it make sense to have separ= ate problem domains for the URNs? Do we think in the future others mig= ht want a different "package" of actions for some other purpose? = If so, I think this strengthens the case for using a body. <= o:p>

 

Peter

=

On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rif= aat (Rifaat) <rifatyu@avaya.com= > wrote:

Paul,

I am not talkin= g about any intermediary, but about application servers on the call path in= an enterprise.
Some application servers might be interested in a specif= ic action to push application to the phone.
I agree that strong security= is required and we are asking the client to only allow authorized users to= invoke an action by challenging the INVOKE-Issuer.

Regards,
 Rifaat


> -----Original Message-----
> From: Paul Kyzivat= [mailto:pkyzivat@cisco.com]
&= gt; Sent: Wednesday, May 18, 2011 8:58 AM
> To: Shekh-Yusef, Rifaat (= Rifaat)

> Cc: splices@ietf.org
> Subject: Re: [spl= ices] SIP INVOKE method
>
>
>
> On 5/18/2011 7:29 A= M, Shekh-Yusef, Rifaat (Rifaat) wrote:
> > Hi Paul,
> >> > I think that the main reason for using Headers for actions and = parameters is
> to allow for proxy applications on the call path to r= ecognize the requested
> action, as some UAs might encrypt the body p= art.
>
> Hmm. That seems to me to be more reason to use a body = part!
>
> What possible reason would an intermediary have for s= nooping into these
> actions?
>
> Note that this function= ality is *very* sensitive - in the wrong hands
> this stuff can do gr= eat damage. I predict that there will be a lot of
> demand for very s= trong security considerations. Putting the action in a
> body and enc= rypting it might be a good approach.
>
>       T= hanks,
>       Paul
>
> > Regards,
&= gt; >   Rifaat
> >
> >
> >> -----Orig= inal Message-----
> >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf
> Of
> = >> Paul Kyzivat
> >> Sent: Tuesday, May 17, 2011 3:09 PM<= br>> >> To: splices@ietf.org
> >> Subject: Re: [splices] SIP INVOKE method
> >&g= t;
> >>
> >>
> >> On 5/17/2011 2:20 PM,= Shekh-Yusef, Rifaat (Rifaat) wrote:
> >>
> >>> = Yes, and I have the following open question about these parameters:
>= >>> Should a separate header be defined for action parameters?> >>
> >> I can be convinced otherwise (by a good jus= tification), but I'm inclined
> >> toward describing the action= and any parameters in a body part.
> >>
> >>  = ;  Thanks,
> >>    Paul
> >> _______= ________________________________________
> >> splices mailing l= ist
> >> splices@ietf.org
> >> https://www.ietf.org/mailman/listinfo/splices
&= gt; >
_______________________________________________
splices mail= ing list
splices@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/splices

<= /div>

 

= --_000_6369CB70BFD88942B9705AC1E639A33822CBE5C63FDCUS1MBEX4glo_-- From musgravepj@gmail.com Wed May 18 08:43:18 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0D4E06A0 for ; Wed, 18 May 2011 08:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyOxEH9Tr8ut for ; Wed, 18 May 2011 08:43:17 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4F3E067E for ; Wed, 18 May 2011 08:43:16 -0700 (PDT) Received: by fxm15 with SMTP id 15so1494028fxm.31 for ; Wed, 18 May 2011 08:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=djNC+tGL9Cb/wnZVibuDdDhUoxRkiIh1sHMYTBmDEcw=; b=e2Re8SvPxFEa6CiIqCcKqnVlhwPt5GsU7Jm9tsaljluGm3TIbiKXAgrYnQn7oxbZEO GQ2cUDGo0Q51EyRL1h8H5ZZZtrJxPQ2qcu9GDB3Qj9osl8PSyCIpq4OYyWErznVSenNk +RLqBZvkrMqJk5PAXITC1mpbK191lmb2cjzpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZoFDWRsaSj29vAoDIw/ZLB7vpXxlc4QvzLpzp6VY46Xf8uHlskOFVBoPG7jMeUo6NY JV/Fcbrs2zu/JofF8Xni+WpxMFjFRPJit79ZfQOJ7oKieT7zOmzMQa/WPqtNmRzWYuvs iC5hfm62ZRcbT16BvmRJxg62YqrsFXhTopIOM= MIME-Version: 1.0 Received: by 10.223.117.137 with SMTP id r9mr2555416faq.28.1305733395368; Wed, 18 May 2011 08:43:15 -0700 (PDT) Received: by 10.223.103.67 with HTTP; Wed, 18 May 2011 08:43:15 -0700 (PDT) In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> Date: Wed, 18 May 2011 11:43:15 -0400 Message-ID: From: Peter Musgrave To: "Shekh-Yusef, Rifaat (Rifaat)" Content-Type: multipart/alternative; boundary=001636c5974c33cba204a38ebfaa Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 15:43:18 -0000 --001636c5974c33cba204a38ebfaa Content-Type: text/plain; charset=ISO-8859-1 If INVOKE is to become a general method, then I could easily see people wanting to use e.g. an XML body to specify an action. If a new method is being defined then I would think making it fairly general would be a good idea - and limiting an action to one text line in a header might be considered limiting. Hence a body would be more flexible. One the other hand being too general will likely get is into trouble again (e.g. the five uses of REFER) - so maybe being very specific is a good thing. In this case I could see just a header sufficing. A very classic dilemma... Do people feel that a general INVOKE mechanism is missing in SIP - or do we want to just focus on UA actions and the SPLICES requirement? Does this debate need to include sipcore? Peter On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) < rifatyu@avaya.com> wrote: > Hi Peter, > > > > Yes, I expect others to try to define new category of actions, but these > must be registered with IANA. > > I am not clear on how this strengthens the case for using a body. > > > > Regards, > > Rifaat > > > > > > *From:* Peter Musgrave [mailto:musgravepj@gmail.com] > *Sent:* Wednesday, May 18, 2011 9:32 AM > > *To:* Shekh-Yusef, Rifaat (Rifaat) > *Cc:* Paul Kyzivat; splices@ietf.org > > *Subject:* Re: [splices] SIP INVOKE method > > > > Rifaat, > > > > I agree with Paul - a body may make sense. > > > > If we are going as far as defining a new SIP METHOD - does it make sense to > have separate problem domains for the URNs? Do we think in the future others > might want a different "package" of actions for some other purpose? If so, I > think this strengthens the case for using a body. > > > > Peter > > On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) < > rifatyu@avaya.com> wrote: > > Paul, > > I am not talking about any intermediary, but about application servers on > the call path in an enterprise. > Some application servers might be interested in a specific action to push > application to the phone. > I agree that strong security is required and we are asking the client to > only allow authorized users to invoke an action by challenging the > INVOKE-Issuer. > > Regards, > Rifaat > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, May 18, 2011 8:58 AM > > To: Shekh-Yusef, Rifaat (Rifaat) > > > Cc: splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > Hi Paul, > > > > > > I think that the main reason for using Headers for actions and > parameters is > > to allow for proxy applications on the call path to recognize the > requested > > action, as some UAs might encrypt the body part. > > > > Hmm. That seems to me to be more reason to use a body part! > > > > What possible reason would an intermediary have for snooping into these > > actions? > > > > Note that this functionality is *very* sensitive - in the wrong hands > > this stuff can do great damage. I predict that there will be a lot of > > demand for very strong security considerations. Putting the action in a > > body and encrypting it might be a good approach. > > > > Thanks, > > Paul > > > > > Regards, > > > Rifaat > > > > > > > > >> -----Original Message----- > > >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On > Behalf > > Of > > >> Paul Kyzivat > > >> Sent: Tuesday, May 17, 2011 3:09 PM > > >> To: splices@ietf.org > > >> Subject: Re: [splices] SIP INVOKE method > > >> > > >> > > >> > > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > >> > > >>> Yes, and I have the following open question about these parameters: > > >>> Should a separate header be defined for action parameters? > > >> > > >> I can be convinced otherwise (by a good justification), but I'm > inclined > > >> toward describing the action and any parameters in a body part. > > >> > > >> Thanks, > > >> Paul > > >> _______________________________________________ > > >> splices mailing list > > >> splices@ietf.org > > >> https://www.ietf.org/mailman/listinfo/splices > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > > --001636c5974c33cba204a38ebfaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If INVOKE is to become a general method, then I could easily see people wan= ting to use e.g. an XML body to specify an action. If a new method is being= defined then I would think making it fairly general would be a good idea -= and limiting an action to one text line in a header =A0might be considered= limiting. Hence a body would be more flexible.

One the other hand being too general will likely get is into= trouble again (e.g. the five uses of REFER) - so maybe being very specific= is a good thing. In this case I could see just a header sufficing.=A0

A very classic dilemma...

Do p= eople feel that a general INVOKE mechanism is missing in SIP - or do we wan= t to just focus on UA actions and the SPLICES requirement? Does this debate= need to include sipcore?

Peter



On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat= ) <rifatyu@avaya.= com> wrote:

Hi Peter,

=A0

Yes, I expect others to try to define new category of actions, but thes= e must be registered with IANA.

I am = not clear on how this strengthens the case for using a body.

=A0

Regards,

Rifaat

= =A0

=A0

From:= Peter Musgrave [mailto:musgravepj@gmail.com]
Se= nt: Wednesday, May 18, 2011 9:32 AM


To: Shekh-Yusef, Rifaat (Rifaat)
C= c: Paul Kyzivat; = splices@ietf.org

Subject: R= e: [splices] SIP INVOKE method

=A0

Rifaat,=A0

=A0

I agree with Paul - a body may= make sense.=A0

=A0

= If we are going as far as defining a new SIP METHOD - does it make sense to= have=A0separate=A0problem domains for the URNs? Do we think in the future = others might want a different "package" of actions for some other= purpose? If so, I think this=A0strengthens=A0the case for using a body.=A0=

=A0

Peter

On Wed,= May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) <rifatyu@avaya.com> wrote:

Paul,

I am not talking about any intermediary= , but about application servers on the call path in an enterprise.
Some = application servers might be interested in a specific action to push applic= ation to the phone.
I agree that strong security is required and we are asking the client to on= ly allow authorized users to invoke an action by challenging the INVOKE-Iss= uer.

Regards,
=A0Rifaat

<= div>


> -----Original Message-----
> From: Pa= ul Kyzivat [mailto:= pkyzivat@cisco.com]
> Sent: Wednesday, May 18, 2011 8:58 AM
&g= t; To: Shekh-Yusef, Rifaat (Rifaat)

> Cc: splices@ietf.org
> Subject: Re: [splic= es] SIP INVOKE method
>
>
>
> On 5/18/2011 7:29 AM,= Shekh-Yusef, Rifaat (Rifaat) wrote:
> > Hi Paul,
> >
> > I think that the main reason f= or using Headers for actions and parameters is
> to allow for proxy a= pplications on the call path to recognize the requested
> action, as = some UAs might encrypt the body part.
>
> Hmm. That seems to me to be more reason to use a body part!>
> What possible reason would an intermediary have for snooping = into these
> actions?
>
> Note that this functionality is= *very* sensitive - in the wrong hands
> this stuff can do great damage. I predict that there will be a lot of<= br>> demand for very strong security considerations. Putting the action = in a
> body and encrypting it might be a good approach.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
> > Rega= rds,
> > =A0 Rifaat
> >
> >
> >> ---= --Original Message-----
> >> From: splices-bounces@ietf.org [mailto:splices-bounces@i= etf.org] On Behalf
> Of
> >> Paul Kyzivat
> >> Sent: Tuesday, May 1= 7, 2011 3:09 PM
> >> To: splices@ietf.org
> >> Subject: Re: [splices= ] SIP INVOKE method
> >>
> >>
> >>
> >> On 5/17/20= 11 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> >>
> &g= t;>> Yes, and I have the following open question about these paramete= rs:
> >>> Should a separate header be defined for action parameters= ?
> >>
> >> I can be convinced otherwise (by a good= justification), but I'm inclined
> >> toward describing th= e action and any parameters in a body part.
> >>
> >> =A0 =A0Thanks,
> >> =A0 =A0Paul<= br>> >> _______________________________________________
> &g= t;> splices mailing list
> >> splices@ietf.org
> >> https://www.ietf.org/mailman/listinfo/splices
> &g= t;
_______________________________________________
splices mailing li= st
splices@ietf.org<= br>https://www.ietf.org/mailman/listinfo/splices

=

=A0


--001636c5974c33cba204a38ebfaa-- From salvatore.loreto@ericsson.com Wed May 18 09:26:49 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660DBE0703 for ; Wed, 18 May 2011 09:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4Hn4RZwQyO9 for ; Wed, 18 May 2011 09:26:48 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A3024E0665 for ; Wed, 18 May 2011 09:26:47 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-f8-4dd3f3466b7d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C6.62.09774.643F3DD4; Wed, 18 May 2011 18:26:46 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Wed, 18 May 2011 18:26:45 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E82442441 for ; Wed, 18 May 2011 19:26:45 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D55D250F2D for ; Wed, 18 May 2011 19:26:45 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 88F6850F2C for ; Wed, 18 May 2011 19:26:45 +0300 (EEST) Message-ID: <4DD3F344.4050208@ericsson.com> Date: Wed, 18 May 2011 19:26:44 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: splices@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090500080302090808090406" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 16:26:49 -0000 --------------090500080302090808090406 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I tend to agree that putting the action in the body seems to make more sense; even if I have to admit I haven't had time to think more about the issue. /Sal On 5/18/11 6:43 PM, Peter Musgrave wrote: > If INVOKE is to become a general method, then I could easily see > people wanting to use e.g. an XML body to specify an action. If a new > method is being defined then I would think making it fairly general > would be a good idea - and limiting an action to one text line in a > header might be considered limiting. Hence a body would be more > flexible. > > One the other hand being too general will likely get is into trouble > again (e.g. the five uses of REFER) - so maybe being very specific is > a good thing. In this case I could see just a header sufficing. > > A very classic dilemma... > > Do people feel that a general INVOKE mechanism is missing in SIP - or > do we want to just focus on UA actions and the SPLICES requirement? > Does this debate need to include sipcore? > > Peter > > > > On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) > > wrote: > > Hi Peter, > > Yes, I expect others to try to define new category of actions, but > these must be registered with IANA. > > I am not clear on how this strengthens the case for using a body. > > Regards, > > Rifaat > > *From:*Peter Musgrave [mailto:musgravepj@gmail.com > ] > *Sent:* Wednesday, May 18, 2011 9:32 AM > > > *To:* Shekh-Yusef, Rifaat (Rifaat) > *Cc:* Paul Kyzivat; splices@ietf.org > > *Subject:* Re: [splices] SIP INVOKE method > > Rifaat, > > I agree with Paul - a body may make sense. > > If we are going as far as defining a new SIP METHOD - does it make > sense to have separate problem domains for the URNs? Do we think > in the future others might want a different "package" of actions > for some other purpose? If so, I think this strengthens the case > for using a body. > > Peter > > On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) > > wrote: > > Paul, > > I am not talking about any intermediary, but about application > servers on the call path in an enterprise. > Some application servers might be interested in a specific action > to push application to the phone. > I agree that strong security is required and we are asking the > client to only allow authorized users to invoke an action by > challenging the INVOKE-Issuer. > > Regards, > Rifaat > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > ] > > Sent: Wednesday, May 18, 2011 8:58 AM > > To: Shekh-Yusef, Rifaat (Rifaat) > > > Cc: splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > Hi Paul, > > > > > > I think that the main reason for using Headers for actions and > parameters is > > to allow for proxy applications on the call path to recognize > the requested > > action, as some UAs might encrypt the body part. > > > > Hmm. That seems to me to be more reason to use a body part! > > > > What possible reason would an intermediary have for snooping > into these > > actions? > > > > Note that this functionality is *very* sensitive - in the wrong > hands > > this stuff can do great damage. I predict that there will be a > lot of > > demand for very strong security considerations. Putting the > action in a > > body and encrypting it might be a good approach. > > > > Thanks, > > Paul > > > > > Regards, > > > Rifaat > > > > > > > > >> -----Original Message----- > > >> From: splices-bounces@ietf.org > [mailto:splices-bounces@ietf.org > ] On Behalf > > Of > > >> Paul Kyzivat > > >> Sent: Tuesday, May 17, 2011 3:09 PM > > >> To: splices@ietf.org > > >> Subject: Re: [splices] SIP INVOKE method > > >> > > >> > > >> > > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > >> > > >>> Yes, and I have the following open question about these > parameters: > > >>> Should a separate header be defined for action parameters? > > >> > > >> I can be convinced otherwise (by a good justification), but > I'm inclined > > >> toward describing the action and any parameters in a body part. > > >> > > >> Thanks, > > >> Paul > > >> _______________________________________________ > > >> splices mailing list > > >> splices@ietf.org > > >> https://www.ietf.org/mailman/listinfo/splices > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > -- Salvatore Loreto www.sloreto.com --------------090500080302090808090406 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I tend to agree that
putting the action in the body seems to make more sense;
even if I have to admit I haven't had time to think more about the issue.


/Sal
 



On 5/18/11 6:43 PM, Peter Musgrave wrote:
If INVOKE is to become a general method, then I could easily see people wanting to use e.g. an XML body to specify an action. If a new method is being defined then I would think making it fairly general would be a good idea - and limiting an action to one text line in a header  might be considered limiting. Hence a body would be more flexible.

One the other hand being too general will likely get is into trouble again (e.g. the five uses of REFER) - so maybe being very specific is a good thing. In this case I could see just a header sufficing. 

A very classic dilemma...

Do people feel that a general INVOKE mechanism is missing in SIP - or do we want to just focus on UA actions and the SPLICES requirement? Does this debate need to include sipcore?

Peter



On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) <rifatyu@avaya.com> wrote:

Hi Peter,

 

Yes, I expect others to try to define new category of actions, but these must be registered with IANA.

I am not clear on how this strengthens the case for using a body.

 

Regards,

Rifaat

 

 

From: Peter Musgrave [mailto:musgravepj@gmail.com]
Sent: Wednesday, May 18, 2011 9:32 AM


To: Shekh-Yusef, Rifaat (Rifaat)
Cc: Paul Kyzivat; splices@ietf.org

Subject: Re: [splices] SIP INVOKE method

 

Rifaat, 

 

I agree with Paul - a body may make sense. 

 

If we are going as far as defining a new SIP METHOD - does it make sense to have separate problem domains for the URNs? Do we think in the future others might want a different "package" of actions for some other purpose? If so, I think this strengthens the case for using a body. 

 

Peter

On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) <rifatyu@avaya.com> wrote:

Paul,

I am not talking about any intermediary, but about application servers on the call path in an enterprise.
Some application servers might be interested in a specific action to push application to the phone.
I agree that strong security is required and we are asking the client to only allow authorized users to invoke an action by challenging the INVOKE-Issuer.

Regards,
 Rifaat


> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Wednesday, May 18, 2011 8:58 AM
> To: Shekh-Yusef, Rifaat (Rifaat)

> Cc: splices@ietf.org
> Subject: Re: [splices] SIP INVOKE method
>
>
>
> On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> > Hi Paul,
> >
> > I think that the main reason for using Headers for actions and parameters is
> to allow for proxy applications on the call path to recognize the requested
> action, as some UAs might encrypt the body part.
>
> Hmm. That seems to me to be more reason to use a body part!
>
> What possible reason would an intermediary have for snooping into these
> actions?
>
> Note that this functionality is *very* sensitive - in the wrong hands
> this stuff can do great damage. I predict that there will be a lot of
> demand for very strong security considerations. Putting the action in a
> body and encrypting it might be a good approach.
>
>       Thanks,
>       Paul
>
> > Regards,
> >   Rifaat
> >
> >
> >> -----Original Message-----
> >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf
> Of
> >> Paul Kyzivat
> >> Sent: Tuesday, May 17, 2011 3:09 PM
> >> To: splices@ietf.org
> >> Subject: Re: [splices] SIP INVOKE method
> >>
> >>
> >>
> >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> >>
> >>> Yes, and I have the following open question about these parameters:
> >>> Should a separate header be defined for action parameters?
> >>
> >> I can be convinced otherwise (by a good justification), but I'm inclined
> >> toward describing the action and any parameters in a body part.
> >>
> >>    Thanks,
> >>    Paul
> >> _______________________________________________
> >> splices mailing list
> >> splices@ietf.org
> >> https://www.ietf.org/mailman/listinfo/splices
> >
_______________________________________________
splices mailing list
splices@ietf.org
https://www.ietf.org/mailman/listinfo/splices

 




-- 
Salvatore Loreto
www.sloreto.com
--------------090500080302090808090406-- From pkyzivat@cisco.com Wed May 18 10:29:26 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BE4E06C2 for ; Wed, 18 May 2011 10:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML9SokNTP3nu for ; Wed, 18 May 2011 10:29:25 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id BF737E06BE for ; Wed, 18 May 2011 10:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6745; q=dns/txt; s=iport; t=1305739765; x=1306949365; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OfH9d36zBupzYtF/8dpUAJ+DvHpT9fjAuVEbCnwQcBI=; b=b9L4mdT2xPmQlCR+nlgG27uI789vvvwhgObJncK5S23Rga74V6a8LOCT i24V2GCtvqwNYdzXgDWJdtCjU+9CAWwXpy+7LzDwuElZvevzRIAZmSWee GUjP16e0O78/w5kIFv+BMEBbi5uCCvCH+Sxt05RhvnTNKPuEao4l5zNmQ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAMUA1E2rRDoJ/2dsb2JhbACXT45Nd4hwn3ueAIYZBJARhC+EHIZG X-IronPort-AV: E=Sophos;i="4.65,232,1304294400"; d="scan'208";a="359705677" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 18 May 2011 17:29:25 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4IHTOZo016673; Wed, 18 May 2011 17:29:24 GMT Message-ID: <4DD401F4.6050502@cisco.com> Date: Wed, 18 May 2011 13:29:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Peter Musgrave References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 17:29:26 -0000 On 5/18/2011 11:43 AM, Peter Musgrave wrote: > If INVOKE is to become a general method, then I could easily see people > wanting to use e.g. an XML body to specify an action. If a new method is > being defined then I would think making it fairly general would be a > good idea - and limiting an action to one text line in a header might > be considered limiting. Hence a body would be more flexible. > > One the other hand being too general will likely get is into trouble > again (e.g. the five uses of REFER) - so maybe being very specific is a > good thing. In this case I could see just a header sufficing. > > A very classic dilemma... > > Do people feel that a general INVOKE mechanism is missing in SIP - or do > we want to just focus on UA actions and the SPLICES requirement? I think it needs to be general in the sense of not limited to the set of things decided at this time. But not so general that it becomes a general purpose tunnel-over-sip mechanism. There needs to be a scope of applicability. I'm thinking its limited to controlling the behavior of a sip device with respect to the mapping of call streams to devices, initiating, terminating and otherwise managing calls, ... AFAIK the main objection to bodies is the need to create a new parser. With a sip header you take advantage of the sip parser, though you may need to extend it to handle a new method. Some might object to XML bodies in particular because they require a fairly heavy parser, which can be a problem in limited devices. In some other devices of course that stuff is already present and so no burden. Of course sip headers are just a special case of mime headers. Were we to choose as a body type another extension of mime, then it might still be possible to reuse a parser. This clearly requires more discussion. We might want to bring in a security guru sooner rather than later. I think there will likely be many concerns to be addressed, and addressing them may constrain the shape of the solution. > Does this debate need to include sipcore? You have me. :-) It will certainly involve sipcore at some point. I think we can explore the options for awhile before worrying too much about that. I'm more worried about security. Thanks, Paul > Peter > > > > On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) > > wrote: > > Hi Peter, > > Yes, I expect others to try to define new category of actions, but > these must be registered with IANA. > > I am not clear on how this strengthens the case for using a body. > > Regards, > > Rifaat > > *From:*Peter Musgrave [mailto:musgravepj@gmail.com > ] > *Sent:* Wednesday, May 18, 2011 9:32 AM > > > *To:* Shekh-Yusef, Rifaat (Rifaat) > *Cc:* Paul Kyzivat; splices@ietf.org > > *Subject:* Re: [splices] SIP INVOKE method > > Rifaat, > > I agree with Paul - a body may make sense. > > If we are going as far as defining a new SIP METHOD - does it make > sense to have separate problem domains for the URNs? Do we think in > the future others might want a different "package" of actions for > some other purpose? If so, I think this strengthens the case for > using a body. > > Peter > > On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) > > wrote: > > Paul, > > I am not talking about any intermediary, but about application > servers on the call path in an enterprise. > Some application servers might be interested in a specific action to > push application to the phone. > I agree that strong security is required and we are asking the > client to only allow authorized users to invoke an action by > challenging the INVOKE-Issuer. > > Regards, > Rifaat > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > ] > > Sent: Wednesday, May 18, 2011 8:58 AM > > To: Shekh-Yusef, Rifaat (Rifaat) > > > Cc: splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > Hi Paul, > > > > > > I think that the main reason for using Headers for actions and > parameters is > > to allow for proxy applications on the call path to recognize the > requested > > action, as some UAs might encrypt the body part. > > > > Hmm. That seems to me to be more reason to use a body part! > > > > What possible reason would an intermediary have for snooping into > these > > actions? > > > > Note that this functionality is *very* sensitive - in the wrong hands > > this stuff can do great damage. I predict that there will be a lot of > > demand for very strong security considerations. Putting the > action in a > > body and encrypting it might be a good approach. > > > > Thanks, > > Paul > > > > > Regards, > > > Rifaat > > > > > > > > >> -----Original Message----- > > >> From: splices-bounces@ietf.org > [mailto:splices-bounces@ietf.org > ] On Behalf > > Of > > >> Paul Kyzivat > > >> Sent: Tuesday, May 17, 2011 3:09 PM > > >> To: splices@ietf.org > > >> Subject: Re: [splices] SIP INVOKE method > > >> > > >> > > >> > > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > >> > > >>> Yes, and I have the following open question about these > parameters: > > >>> Should a separate header be defined for action parameters? > > >> > > >> I can be convinced otherwise (by a good justification), but > I'm inclined > > >> toward describing the action and any parameters in a body part. > > >> > > >> Thanks, > > >> Paul > > >> _______________________________________________ > > >> splices mailing list > > >> splices@ietf.org > > >> https://www.ietf.org/mailman/listinfo/splices > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > From musgravepj@gmail.com Wed May 18 10:37:35 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E17E06C8 for ; Wed, 18 May 2011 10:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLwqA-uduAAV for ; Wed, 18 May 2011 10:37:35 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7A9E06C3 for ; Wed, 18 May 2011 10:37:34 -0700 (PDT) Received: by fxm15 with SMTP id 15so1589175fxm.31 for ; Wed, 18 May 2011 10:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mnWpWrzmEDJRecpgnnG7A23wwzboqq0JlWa/+TVr/hk=; b=EJV5XhtoqiRErWKmc4fR08x5Q33aFmqwrLyDBHdaqz4/XkF3Ln55NYYfENbHutpkbe 6RDo+/2Tp/0+E0PDvqyLUy9kGStRsXRo1YZbBjCoYGYJmqRC124MJzv3qs0OETxdos1/ LT8BvjokvJ2ePQLNYgivPTYh4urPRs8V/jmsg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=d2/qsFFD6Nc+SKgXIc03UOxMAQmeOAj53AxLvyWrA2BYcp7mDst2UOyVyrVU+TUsi0 WtcypeHU2FL8XI2VUXglvxOhWj3/q3/nEmF67nqZO1dCL4CtPtumXwMgJB3bp46RwsPZ Uzu2rR81yAwXwiRMWR86xcP7PS1S41nJY+Zlo= MIME-Version: 1.0 Received: by 10.223.113.193 with SMTP id b1mr2699456faq.47.1305740254186; Wed, 18 May 2011 10:37:34 -0700 (PDT) Received: by 10.223.103.67 with HTTP; Wed, 18 May 2011 10:37:34 -0700 (PDT) In-Reply-To: <4DD401F4.6050502@cisco.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> <4DD401F4.6050502@cisco.com> Date: Wed, 18 May 2011 13:37:34 -0400 Message-ID: From: Peter Musgrave To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001636c594e3050d1704a39058db Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 17:37:35 -0000 --001636c594e3050d1704a39058db Content-Type: text/plain; charset=ISO-8859-1 Do you think it has relevance to CLUE? [For which we *also* have you as representative ;-) ] > But not so general that it becomes a general purpose tunnel-over-sip > mechanism. There needs to be a scope of applicability. I'm thinking its > limited to controlling the behavior of a sip device with respect to the > mapping of call streams to devices, initiating, terminating and otherwise > managing calls, ... > > --001636c594e3050d1704a39058db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Do you think it has relevance to CLUE? [For which we *also* have you as=A0r= epresentative=A0;-) ]


But not so general that it becomes a general purpose tunnel-over-sip mechan= ism. There needs to be a scope of applicability. I'm thinking its limit= ed to controlling the behavior of a sip device with respect to the mapping = of call streams to devices, initiating, terminating and otherwise managing = calls, ...

--001636c594e3050d1704a39058db-- From christer.holmberg@ericsson.com Wed May 18 10:37:40 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D276FE06C8 for ; Wed, 18 May 2011 10:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YZShMkeOWYq for ; Wed, 18 May 2011 10:37:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7551BE074D for ; Wed, 18 May 2011 10:37:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-9c-4dd403e2cc91 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 30.A9.09774.2E304DD4; Wed, 18 May 2011 19:37:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 18 May 2011 19:37:37 +0200 From: Christer Holmberg To: Paul Kyzivat , Peter Musgrave Date: Wed, 18 May 2011 19:34:31 +0200 Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwVgSXc7HGaFOYOS82gk0LsXngJ6QAALKRo Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3A6@ESESSCMS0356.eemea.ericsson.se> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> , <4DD401F4.6050502@cisco.com> In-Reply-To: <4DD401F4.6050502@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 17:37:40 -0000 Hi, I have a similar comment, regarding the applicability. The draft says that each "action" must be represented by a URN that is defi= ned by IANA. =20 But, there are no restrictions regarding what types of "actions" are allowe= d - or even a description about what the criterias for an "action" are in t= he first place.=20 =20 Regards, Christer ________________________________________ From: splices-bounces@ietf.org [splices-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] Sent: Wednesday, May 18, 2011 8:29 PM To: Peter Musgrave Cc: splices@ietf.org Subject: Re: [splices] SIP INVOKE method On 5/18/2011 11:43 AM, Peter Musgrave wrote: > If INVOKE is to become a general method, then I could easily see people > wanting to use e.g. an XML body to specify an action. If a new method is > being defined then I would think making it fairly general would be a > good idea - and limiting an action to one text line in a header might > be considered limiting. Hence a body would be more flexible. > > One the other hand being too general will likely get is into trouble > again (e.g. the five uses of REFER) - so maybe being very specific is a > good thing. In this case I could see just a header sufficing. > > A very classic dilemma... > > Do people feel that a general INVOKE mechanism is missing in SIP - or do > we want to just focus on UA actions and the SPLICES requirement? I think it needs to be general in the sense of not limited to the set of things decided at this time. But not so general that it becomes a general purpose tunnel-over-sip mechanism. There needs to be a scope of applicability. I'm thinking its limited to controlling the behavior of a sip device with respect to the mapping of call streams to devices, initiating, terminating and otherwise managing calls, ... AFAIK the main objection to bodies is the need to create a new parser. With a sip header you take advantage of the sip parser, though you may need to extend it to handle a new method. Some might object to XML bodies in particular because they require a fairly heavy parser, which can be a problem in limited devices. In some other devices of course that stuff is already present and so no burden. Of course sip headers are just a special case of mime headers. Were we to choose as a body type another extension of mime, then it might still be possible to reuse a parser. This clearly requires more discussion. We might want to bring in a security guru sooner rather than later. I think there will likely be many concerns to be addressed, and addressing them may constrain the shape of the solution. > Does this debate need to include sipcore? You have me. :-) It will certainly involve sipcore at some point. I think we can explore the options for awhile before worrying too much about that. I'm more worried about security. Thanks, Paul > Peter > > > > On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) > > wrote: > > Hi Peter, > > Yes, I expect others to try to define new category of actions, but > these must be registered with IANA. > > I am not clear on how this strengthens the case for using a body. > > Regards, > > Rifaat > > *From:*Peter Musgrave [mailto:musgravepj@gmail.com > ] > *Sent:* Wednesday, May 18, 2011 9:32 AM > > > *To:* Shekh-Yusef, Rifaat (Rifaat) > *Cc:* Paul Kyzivat; splices@ietf.org > > *Subject:* Re: [splices] SIP INVOKE method > > Rifaat, > > I agree with Paul - a body may make sense. > > If we are going as far as defining a new SIP METHOD - does it make > sense to have separate problem domains for the URNs? Do we think in > the future others might want a different "package" of actions for > some other purpose? If so, I think this strengthens the case for > using a body. > > Peter > > On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) > > wrote: > > Paul, > > I am not talking about any intermediary, but about application > servers on the call path in an enterprise. > Some application servers might be interested in a specific action to > push application to the phone. > I agree that strong security is required and we are asking the > client to only allow authorized users to invoke an action by > challenging the INVOKE-Issuer. > > Regards, > Rifaat > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > ] > > Sent: Wednesday, May 18, 2011 8:58 AM > > To: Shekh-Yusef, Rifaat (Rifaat) > > > Cc: splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > Hi Paul, > > > > > > I think that the main reason for using Headers for actions and > parameters is > > to allow for proxy applications on the call path to recognize the > requested > > action, as some UAs might encrypt the body part. > > > > Hmm. That seems to me to be more reason to use a body part! > > > > What possible reason would an intermediary have for snooping into > these > > actions? > > > > Note that this functionality is *very* sensitive - in the wrong ha= nds > > this stuff can do great damage. I predict that there will be a lot= of > > demand for very strong security considerations. Putting the > action in a > > body and encrypting it might be a good approach. > > > > Thanks, > > Paul > > > > > Regards, > > > Rifaat > > > > > > > > >> -----Original Message----- > > >> From: splices-bounces@ietf.org > [mailto:splices-bounces@ietf.org > ] On Behalf > > Of > > >> Paul Kyzivat > > >> Sent: Tuesday, May 17, 2011 3:09 PM > > >> To: splices@ietf.org > > >> Subject: Re: [splices] SIP INVOKE method > > >> > > >> > > >> > > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > >> > > >>> Yes, and I have the following open question about these > parameters: > > >>> Should a separate header be defined for action parameters? > > >> > > >> I can be convinced otherwise (by a good justification), but > I'm inclined > > >> toward describing the action and any parameters in a body part. > > >> > > >> Thanks, > > >> Paul > > >> _______________________________________________ > > >> splices mailing list > > >> splices@ietf.org > > >> https://www.ietf.org/mailman/listinfo/splices > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ splices mailing list splices@ietf.org https://www.ietf.org/mailman/listinfo/splices= From rifatyu@avaya.com Wed May 18 12:42:11 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8DAE0748 for ; Wed, 18 May 2011 12:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZEcyD800eOk for ; Wed, 18 May 2011 12:42:10 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8F44AE0746 for ; Wed, 18 May 2011 12:42:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlABACwg1E2HCzI1/2dsb2JhbACXT4NAiw13iHCiQAKbRYYZBJRdg3+GRg X-IronPort-AV: E=Sophos;i="4.65,232,1304308800"; d="scan'208";a="188989107" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 18 May 2011 15:42:08 -0400 X-IronPort-AV: E=Sophos;i="4.65,232,1304308800"; d="scan'208";a="653500391" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 May 2011 15:42:08 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 18 May 2011 15:42:08 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Christer Holmberg , Paul Kyzivat , Peter Musgrave Date: Wed, 18 May 2011 15:42:07 -0400 Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwVgSXc7HGaFOYOS82gk0LsXngJ6QAALKRoAARnCWA= Message-ID: <6369CB70BFD88942B9705AC1E639A33822CBE5CBD4@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> , <4DD401F4.6050502@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3A6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3A6@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 19:42:11 -0000 Can you, or someone else, propose some text around this? Regards, Rifaat > -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Christer Holmberg > Sent: Wednesday, May 18, 2011 1:35 PM > To: Paul Kyzivat; Peter Musgrave > Cc: splices@ietf.org > Subject: Re: [splices] SIP INVOKE method >=20 > Hi, >=20 > I have a similar comment, regarding the applicability. >=20 > The draft says that each "action" must be represented by a URN that is de= fined > by IANA. >=20 > But, there are no restrictions regarding what types of "actions" are allo= wed - > or even a description about what the criterias for an "action" are in the > first place. >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: splices-bounces@ietf.org [splices-bounces@ietf.org] On Behalf Of Pa= ul > Kyzivat [pkyzivat@cisco.com] > Sent: Wednesday, May 18, 2011 8:29 PM > To: Peter Musgrave > Cc: splices@ietf.org > Subject: Re: [splices] SIP INVOKE method >=20 > On 5/18/2011 11:43 AM, Peter Musgrave wrote: > > If INVOKE is to become a general method, then I could easily see people > > wanting to use e.g. an XML body to specify an action. If a new method i= s > > being defined then I would think making it fairly general would be a > > good idea - and limiting an action to one text line in a header might > > be considered limiting. Hence a body would be more flexible. > > > > One the other hand being too general will likely get is into trouble > > again (e.g. the five uses of REFER) - so maybe being very specific is a > > good thing. In this case I could see just a header sufficing. > > > > A very classic dilemma... > > > > Do people feel that a general INVOKE mechanism is missing in SIP - or d= o > > we want to just focus on UA actions and the SPLICES requirement? >=20 > I think it needs to be general in the sense of not limited to the set of > things decided at this time. >=20 > But not so general that it becomes a general purpose tunnel-over-sip > mechanism. There needs to be a scope of applicability. I'm thinking its > limited to controlling the behavior of a sip device with respect to the > mapping of call streams to devices, initiating, terminating and > otherwise managing calls, ... >=20 > AFAIK the main objection to bodies is the need to create a new parser. > With a sip header you take advantage of the sip parser, though you may > need to extend it to handle a new method. Some might object to XML > bodies in particular because they require a fairly heavy parser, which > can be a problem in limited devices. In some other devices of course > that stuff is already present and so no burden. >=20 > Of course sip headers are just a special case of mime headers. Were we > to choose as a body type another extension of mime, then it might still > be possible to reuse a parser. >=20 > This clearly requires more discussion. >=20 > We might want to bring in a security guru sooner rather than later. I > think there will likely be many concerns to be addressed, and addressing > them may constrain the shape of the solution. >=20 > > Does this debate need to include sipcore? >=20 > You have me. :-) >=20 > It will certainly involve sipcore at some point. > I think we can explore the options for awhile before worrying too much > about that. I'm more worried about security. >=20 > Thanks, > Paul >=20 > > Peter > > > > > > > > On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) > > > wrote: > > > > Hi Peter, > > > > Yes, I expect others to try to define new category of actions, but > > these must be registered with IANA. > > > > I am not clear on how this strengthens the case for using a body. > > > > Regards, > > > > Rifaat > > > > *From:*Peter Musgrave [mailto:musgravepj@gmail.com > > ] > > *Sent:* Wednesday, May 18, 2011 9:32 AM > > > > > > *To:* Shekh-Yusef, Rifaat (Rifaat) > > *Cc:* Paul Kyzivat; splices@ietf.org > > > > *Subject:* Re: [splices] SIP INVOKE method > > > > Rifaat, > > > > I agree with Paul - a body may make sense. > > > > If we are going as far as defining a new SIP METHOD - does it make > > sense to have separate problem domains for the URNs? Do we think in > > the future others might want a different "package" of actions for > > some other purpose? If so, I think this strengthens the case for > > using a body. > > > > Peter > > > > On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) > > > wrote: > > > > Paul, > > > > I am not talking about any intermediary, but about application > > servers on the call path in an enterprise. > > Some application servers might be interested in a specific action t= o > > push application to the phone. > > I agree that strong security is required and we are asking the > > client to only allow authorized users to invoke an action by > > challenging the INVOKE-Issuer. > > > > Regards, > > Rifaat > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > > ] > > > Sent: Wednesday, May 18, 2011 8:58 AM > > > To: Shekh-Yusef, Rifaat (Rifaat) > > > > > Cc: splices@ietf.org > > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > > Hi Paul, > > > > > > > > I think that the main reason for using Headers for actions and > > parameters is > > > to allow for proxy applications on the call path to recognize th= e > > requested > > > action, as some UAs might encrypt the body part. > > > > > > Hmm. That seems to me to be more reason to use a body part! > > > > > > What possible reason would an intermediary have for snooping int= o > > these > > > actions? > > > > > > Note that this functionality is *very* sensitive - in the wrong = hands > > > this stuff can do great damage. I predict that there will be a l= ot of > > > demand for very strong security considerations. Putting the > > action in a > > > body and encrypting it might be a good approach. > > > > > > Thanks, > > > Paul > > > > > > > Regards, > > > > Rifaat > > > > > > > > > > > >> -----Original Message----- > > > >> From: splices-bounces@ietf.org > > [mailto:splices-bounces@ietf.org > > ] On Behalf > > > Of > > > >> Paul Kyzivat > > > >> Sent: Tuesday, May 17, 2011 3:09 PM > > > >> To: splices@ietf.org > > > >> Subject: Re: [splices] SIP INVOKE method > > > >> > > > >> > > > >> > > > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > >> > > > >>> Yes, and I have the following open question about these > > parameters: > > > >>> Should a separate header be defined for action parameters? > > > >> > > > >> I can be convinced otherwise (by a good justification), but > > I'm inclined > > > >> toward describing the action and any parameters in a body par= t. > > > >> > > > >> Thanks, > > > >> Paul > > > >> _______________________________________________ > > > >> splices mailing list > > > >> splices@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/splices > > > > > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From gao.yang2@zte.com.cn Wed May 18 19:03:08 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37941E06BA for ; Wed, 18 May 2011 19:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQQF--rwYC-5 for ; Wed, 18 May 2011 19:03:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 43E49E0684 for ; Wed, 18 May 2011 19:03:07 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 18341917726163; Thu, 19 May 2011 09:56:23 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 38461.2073369764; Thu, 19 May 2011 10:02:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p4J22ldT047599; Thu, 19 May 2011 10:02:47 +0800 (GMT-8) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4DD3F344.4050208@ericsson.com> To: Salvatore Loreto MIME-Version: 1.0 X-KeepSent: FFB8FF15:8AA3EF9D-48257895:000ADCB1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 19 May 2011 10:02:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-19 10:02:48, Serialize complete at 2011-05-19 10:02:48 Content-Type: multipart/alternative; boundary="=_alternative 000B54CF48257895_=" X-MAIL: mse01.zte.com.cn p4J22ldT047599 Cc: splices@ietf.org Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 02:03:08 -0000 This is a multipart message in MIME format. --=_alternative 000B54CF48257895_= Content-Type: text/plain; charset="US-ASCII" > putting the action in the body seems to make more sense; Agree with this. "Session" and "application based on session" should be treated as two level. Then, making application level indication as body could be more acceptable for me. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000B54CF48257895_= Content-Type: text/html; charset="US-ASCII"

> putting the action in the body seems to make more sense;

Agree with this.
"Session" and "application based on session" should be treated as two level. Then, making application level indication as body could be more acceptable for me.

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000B54CF48257895_=-- From R.Jesske@telekom.de Thu May 19 01:52:19 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADEAE0749 for ; Thu, 19 May 2011 01:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aLMHHCaZ7Mx for ; Thu, 19 May 2011 01:52:18 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id DF7F3E0727 for ; Thu, 19 May 2011 01:52:17 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 19 May 2011 10:51:08 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 19 May 2011 10:50:52 +0200 From: To: , , , , Date: Thu, 19 May 2011 10:50:51 +0200 Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwVgSXc7HGaFOYOS82gk0LsXngJ6QAALKRoAARnCWAAGt3ZsA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E94313@HE111648.emea1.cds.t-internal.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> , <4DD401F4.6050502@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3A6@ESESSCMS0356.eemea.ericsson.se> <6369CB70BFD88942B9705AC1E639A33822CBE5CBD4@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBE5CBD4@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 08:52:19 -0000 Dear Rifaat, I'm a little puzzled about the whole discussion about a new Method INVOKE w= ithout having any defined requirements. Is there anywhere a requirements definition where I can see what is needed. For me it looks that INVOKE is a new Method that is aimed only to be used f= or a "Conferencing (like) service" purposes. Are there any more used cases, like other service invocations like a call f= orwarding, Call Transfer ect.? What is other than I could do with INVITE, REFER, SUBSCRIBE/NOTIFY and INFO= ? I do not want to destroy your new method but I would like to see rational a= round it. And how we could use such method in a general way. Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: splices-bounces@ietf.org > [mailto:splices-bounces@ietf.org] Im Auftrag von Shekh-Yusef, > Rifaat (Rifaat) > Gesendet: Mittwoch, 18. Mai 2011 21:42 > An: Christer Holmberg; Paul Kyzivat; Peter Musgrave > Cc: splices@ietf.org > Betreff: Re: [splices] SIP INVOKE method > > Can you, or someone else, propose some text around this? > > Regards, > Rifaat > > > -----Original Message----- > > From: splices-bounces@ietf.org > [mailto:splices-bounces@ietf.org] On Behalf Of > > Christer Holmberg > > Sent: Wednesday, May 18, 2011 1:35 PM > > To: Paul Kyzivat; Peter Musgrave > > Cc: splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method > > > > Hi, > > > > I have a similar comment, regarding the applicability. > > > > The draft says that each "action" must be represented by a > URN that is defined > > by IANA. > > > > But, there are no restrictions regarding what types of > "actions" are allowed - > > or even a description about what the criterias for an > "action" are in the > > first place. > > > > Regards, > > > > Christer > > > > ________________________________________ > > From: splices-bounces@ietf.org [splices-bounces@ietf.org] > On Behalf Of Paul > > Kyzivat [pkyzivat@cisco.com] > > Sent: Wednesday, May 18, 2011 8:29 PM > > To: Peter Musgrave > > Cc: splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method > > > > On 5/18/2011 11:43 AM, Peter Musgrave wrote: > > > If INVOKE is to become a general method, then I could > easily see people > > > wanting to use e.g. an XML body to specify an action. If > a new method is > > > being defined then I would think making it fairly general > would be a > > > good idea - and limiting an action to one text line in a > header might > > > be considered limiting. Hence a body would be more flexible. > > > > > > One the other hand being too general will likely get is > into trouble > > > again (e.g. the five uses of REFER) - so maybe being very > specific is a > > > good thing. In this case I could see just a header sufficing. > > > > > > A very classic dilemma... > > > > > > Do people feel that a general INVOKE mechanism is missing > in SIP - or do > > > we want to just focus on UA actions and the SPLICES requirement? > > > > I think it needs to be general in the sense of not limited > to the set of > > things decided at this time. > > > > But not so general that it becomes a general purpose tunnel-over-sip > > mechanism. There needs to be a scope of applicability. I'm > thinking its > > limited to controlling the behavior of a sip device with > respect to the > > mapping of call streams to devices, initiating, terminating and > > otherwise managing calls, ... > > > > AFAIK the main objection to bodies is the need to create a > new parser. > > With a sip header you take advantage of the sip parser, > though you may > > need to extend it to handle a new method. Some might object to XML > > bodies in particular because they require a fairly heavy > parser, which > > can be a problem in limited devices. In some other devices of course > > that stuff is already present and so no burden. > > > > Of course sip headers are just a special case of mime > headers. Were we > > to choose as a body type another extension of mime, then it > might still > > be possible to reuse a parser. > > > > This clearly requires more discussion. > > > > We might want to bring in a security guru sooner rather > than later. I > > think there will likely be many concerns to be addressed, > and addressing > > them may constrain the shape of the solution. > > > > > Does this debate need to include sipcore? > > > > You have me. :-) > > > > It will certainly involve sipcore at some point. > > I think we can explore the options for awhile before > worrying too much > > about that. I'm more worried about security. > > > > Thanks, > > Paul > > > > > Peter > > > > > > > > > > > > On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) > > > > wrote: > > > > > > Hi Peter, > > > > > > Yes, I expect others to try to define new category of > actions, but > > > these must be registered with IANA. > > > > > > I am not clear on how this strengthens the case for > using a body. > > > > > > Regards, > > > > > > Rifaat > > > > > > *From:*Peter Musgrave [mailto:musgravepj@gmail.com > > > ] > > > *Sent:* Wednesday, May 18, 2011 9:32 AM > > > > > > > > > *To:* Shekh-Yusef, Rifaat (Rifaat) > > > *Cc:* Paul Kyzivat; splices@ietf.org > > > > > > *Subject:* Re: [splices] SIP INVOKE method > > > > > > Rifaat, > > > > > > I agree with Paul - a body may make sense. > > > > > > If we are going as far as defining a new SIP METHOD - > does it make > > > sense to have separate problem domains for the URNs? > Do we think in > > > the future others might want a different "package" of > actions for > > > some other purpose? If so, I think this strengthens > the case for > > > using a body. > > > > > > Peter > > > > > > On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) > > > > wrote: > > > > > > Paul, > > > > > > I am not talking about any intermediary, but about application > > > servers on the call path in an enterprise. > > > Some application servers might be interested in a > specific action to > > > push application to the phone. > > > I agree that strong security is required and we are asking the > > > client to only allow authorized users to invoke an action by > > > challenging the INVOKE-Issuer. > > > > > > Regards, > > > Rifaat > > > > > > > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > > > ] > > > > Sent: Wednesday, May 18, 2011 8:58 AM > > > > To: Shekh-Yusef, Rifaat (Rifaat) > > > > > > > Cc: splices@ietf.org > > > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > > > > > > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > > > Hi Paul, > > > > > > > > > > I think that the main reason for using Headers > for actions and > > > parameters is > > > > to allow for proxy applications on the call path > to recognize the > > > requested > > > > action, as some UAs might encrypt the body part. > > > > > > > > Hmm. That seems to me to be more reason to use a body part! > > > > > > > > What possible reason would an intermediary have > for snooping into > > > these > > > > actions? > > > > > > > > Note that this functionality is *very* sensitive - > in the wrong hands > > > > this stuff can do great damage. I predict that > there will be a lot of > > > > demand for very strong security considerations. Putting the > > > action in a > > > > body and encrypting it might be a good approach. > > > > > > > > Thanks, > > > > Paul > > > > > > > > > Regards, > > > > > Rifaat > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: splices-bounces@ietf.org > > > > [mailto:splices-bounces@ietf.org > > > ] On Behalf > > > > Of > > > > >> Paul Kyzivat > > > > >> Sent: Tuesday, May 17, 2011 3:09 PM > > > > >> To: splices@ietf.org > > > > >> Subject: Re: [splices] SIP INVOKE method > > > > >> > > > > >> > > > > >> > > > > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat > (Rifaat) wrote: > > > > >> > > > > >>> Yes, and I have the following open question about these > > > parameters: > > > > >>> Should a separate header be defined for action > parameters? > > > > >> > > > > >> I can be convinced otherwise (by a good > justification), but > > > I'm inclined > > > > >> toward describing the action and any parameters > in a body part. > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> _______________________________________________ > > > > >> splices mailing list > > > > >> splices@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/splices > > > > > > > > _______________________________________________ > > > splices mailing list > > > splices@ietf.org > > > https://www.ietf.org/mailman/listinfo/splices > > > > > > > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > From rifatyu@avaya.com Thu May 19 06:11:32 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693A3E0716 for ; Thu, 19 May 2011 06:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXcajaolMIKa for ; Thu, 19 May 2011 06:11:31 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 83ECDE06EA for ; Thu, 19 May 2011 06:11:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkBAFcW1U3GmAcF/2dsb2JhbACXUINAin13riQCm1aGGQSUXYN/hkY X-IronPort-AV: E=Sophos;i="4.65,237,1304308800"; d="pptx'72,48?xml'72,48?scan'72,48,72,48,208,145?jpeg'72,48,72,48,208,145,145?rels'72,48,72,48,208,145,145"; a="189107461" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 May 2011 09:11:28 -0400 X-IronPort-AV: E=Sophos;i="4.65,237,1304308800"; d="pptx'72,48?xml'72,48?scan'72,48,72,48,208,145?jpeg'72,48,72,48,208,145,145?rels'72,48,72,48,208,145,145"; a="623830793" Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 May 2011 09:11:27 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 19 May 2011 09:11:27 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "R.Jesske@telekom.de" , "christer.holmberg@ericsson.com" , "pkyzivat@cisco.com" , "musgravepj@gmail.com" , "splices@ietf.org" Date: Thu, 19 May 2011 09:11:25 -0400 Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwVgSXc7HGaFOYOS82gk0LsXngJ6QAALKRoAARnCWAAGt3ZsAAJEmOQ Message-ID: <6369CB70BFD88942B9705AC1E639A33822CBE5D0D3@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> , <4DD401F4.6050502@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3A6@ESESSCMS0356.eemea.ericsson.se> <6369CB70BFD88942B9705AC1E639A33822CBE5CBD4@DC-US1MBEX4.global.avaya.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E94313@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E94313@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_6369CB70BFD88942B9705AC1E639A33822CBE5D0D3DCUS1MBEX4glo_" MIME-Version: 1.0 Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 13:11:32 -0000 --_002_6369CB70BFD88942B9705AC1E639A33822CBE5D0D3DCUS1MBEX4glo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ronald, During the last SPLICES meeting in Prague, we presented the SIP Action Refe= rral draft, which allows applications to make a request to a user agent to = perform a well defined action. https://datatracker.ietf.org/doc/draft-yusef-dispatch-action-ref/ The SIP Action Referral mechanism uses REFER to invoke an action, but REFER= has many limitation as described in slide 9 of the attached slide deck pre= sented during the SPLICES WG meeting. The response we got from the people t= hat expressed their opinion on this subject was mostly in favor of a new me= thod to avoid the issues with the REFER method. Both the SIP Action Referral and the SIP INVOKE method drafts have a list o= f actions that are either not possible or have a really cumbersome way of i= nvoking them using other SIP methods. Hope this helps. Regards, Rifaat > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Thursday, May 19, 2011 4:51 AM > To: Shekh-Yusef, Rifaat (Rifaat); christer.holmberg@ericsson.com; > pkyzivat@cisco.com; musgravepj@gmail.com; splices@ietf.org > Subject: AW: [splices] SIP INVOKE method >=20 > Dear Rifaat, > I'm a little puzzled about the whole discussion about a new Method INVOKE > without having any defined requirements. > Is there anywhere a requirements definition where I can see what is neede= d. > For me it looks that INVOKE is a new Method that is aimed only to be used= for > a "Conferencing (like) service" purposes. > Are there any more used cases, like other service invocations like a call > forwarding, Call Transfer ect.? >=20 > What is other than I could do with INVITE, REFER, SUBSCRIBE/NOTIFY and IN= FO? >=20 > I do not want to destroy your new method but I would like to see rational > around it. And how we could use such method in a general way. >=20 > Thank you and Best Regards >=20 > Roland >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: splices-bounces@ietf.org > > [mailto:splices-bounces@ietf.org] Im Auftrag von Shekh-Yusef, > > Rifaat (Rifaat) > > Gesendet: Mittwoch, 18. Mai 2011 21:42 > > An: Christer Holmberg; Paul Kyzivat; Peter Musgrave > > Cc: splices@ietf.org > > Betreff: Re: [splices] SIP INVOKE method > > > > Can you, or someone else, propose some text around this? > > > > Regards, > > Rifaat > > > > > -----Original Message----- > > > From: splices-bounces@ietf.org > > [mailto:splices-bounces@ietf.org] On Behalf Of > > > Christer Holmberg > > > Sent: Wednesday, May 18, 2011 1:35 PM > > > To: Paul Kyzivat; Peter Musgrave > > > Cc: splices@ietf.org > > > Subject: Re: [splices] SIP INVOKE method > > > > > > Hi, > > > > > > I have a similar comment, regarding the applicability. > > > > > > The draft says that each "action" must be represented by a > > URN that is defined > > > by IANA. > > > > > > But, there are no restrictions regarding what types of > > "actions" are allowed - > > > or even a description about what the criterias for an > > "action" are in the > > > first place. > > > > > > Regards, > > > > > > Christer > > > > > > ________________________________________ > > > From: splices-bounces@ietf.org [splices-bounces@ietf.org] > > On Behalf Of Paul > > > Kyzivat [pkyzivat@cisco.com] > > > Sent: Wednesday, May 18, 2011 8:29 PM > > > To: Peter Musgrave > > > Cc: splices@ietf.org > > > Subject: Re: [splices] SIP INVOKE method > > > > > > On 5/18/2011 11:43 AM, Peter Musgrave wrote: > > > > If INVOKE is to become a general method, then I could > > easily see people > > > > wanting to use e.g. an XML body to specify an action. If > > a new method is > > > > being defined then I would think making it fairly general > > would be a > > > > good idea - and limiting an action to one text line in a > > header might > > > > be considered limiting. Hence a body would be more flexible. > > > > > > > > One the other hand being too general will likely get is > > into trouble > > > > again (e.g. the five uses of REFER) - so maybe being very > > specific is a > > > > good thing. In this case I could see just a header sufficing. > > > > > > > > A very classic dilemma... > > > > > > > > Do people feel that a general INVOKE mechanism is missing > > in SIP - or do > > > > we want to just focus on UA actions and the SPLICES requirement? > > > > > > I think it needs to be general in the sense of not limited > > to the set of > > > things decided at this time. > > > > > > But not so general that it becomes a general purpose tunnel-over-sip > > > mechanism. There needs to be a scope of applicability. I'm > > thinking its > > > limited to controlling the behavior of a sip device with > > respect to the > > > mapping of call streams to devices, initiating, terminating and > > > otherwise managing calls, ... > > > > > > AFAIK the main objection to bodies is the need to create a > > new parser. > > > With a sip header you take advantage of the sip parser, > > though you may > > > need to extend it to handle a new method. Some might object to XML > > > bodies in particular because they require a fairly heavy > > parser, which > > > can be a problem in limited devices. In some other devices of course > > > that stuff is already present and so no burden. > > > > > > Of course sip headers are just a special case of mime > > headers. Were we > > > to choose as a body type another extension of mime, then it > > might still > > > be possible to reuse a parser. > > > > > > This clearly requires more discussion. > > > > > > We might want to bring in a security guru sooner rather > > than later. I > > > think there will likely be many concerns to be addressed, > > and addressing > > > them may constrain the shape of the solution. > > > > > > > Does this debate need to include sipcore? > > > > > > You have me. :-) > > > > > > It will certainly involve sipcore at some point. > > > I think we can explore the options for awhile before > > worrying too much > > > about that. I'm more worried about security. > > > > > > Thanks, > > > Paul > > > > > > > Peter > > > > > > > > > > > > > > > > On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) > > > > > wrote: > > > > > > > > Hi Peter, > > > > > > > > Yes, I expect others to try to define new category of > > actions, but > > > > these must be registered with IANA. > > > > > > > > I am not clear on how this strengthens the case for > > using a body. > > > > > > > > Regards, > > > > > > > > Rifaat > > > > > > > > *From:*Peter Musgrave [mailto:musgravepj@gmail.com > > > > ] > > > > *Sent:* Wednesday, May 18, 2011 9:32 AM > > > > > > > > > > > > *To:* Shekh-Yusef, Rifaat (Rifaat) > > > > *Cc:* Paul Kyzivat; splices@ietf.org > > > > > > > > *Subject:* Re: [splices] SIP INVOKE method > > > > > > > > Rifaat, > > > > > > > > I agree with Paul - a body may make sense. > > > > > > > > If we are going as far as defining a new SIP METHOD - > > does it make > > > > sense to have separate problem domains for the URNs? > > Do we think in > > > > the future others might want a different "package" of > > actions for > > > > some other purpose? If so, I think this strengthens > > the case for > > > > using a body. > > > > > > > > Peter > > > > > > > > On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) > > > > > wrote: > > > > > > > > Paul, > > > > > > > > I am not talking about any intermediary, but about application > > > > servers on the call path in an enterprise. > > > > Some application servers might be interested in a > > specific action to > > > > push application to the phone. > > > > I agree that strong security is required and we are asking the > > > > client to only allow authorized users to invoke an action by > > > > challenging the INVOKE-Issuer. > > > > > > > > Regards, > > > > Rifaat > > > > > > > > > > > > > -----Original Message----- > > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > > > > ] > > > > > Sent: Wednesday, May 18, 2011 8:58 AM > > > > > To: Shekh-Yusef, Rifaat (Rifaat) > > > > > > > > > Cc: splices@ietf.org > > > > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > > > > > > > > > > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > > > > Hi Paul, > > > > > > > > > > > > I think that the main reason for using Headers > > for actions and > > > > parameters is > > > > > to allow for proxy applications on the call path > > to recognize the > > > > requested > > > > > action, as some UAs might encrypt the body part. > > > > > > > > > > Hmm. That seems to me to be more reason to use a body part! > > > > > > > > > > What possible reason would an intermediary have > > for snooping into > > > > these > > > > > actions? > > > > > > > > > > Note that this functionality is *very* sensitive - > > in the wrong hands > > > > > this stuff can do great damage. I predict that > > there will be a lot of > > > > > demand for very strong security considerations. Putting the > > > > action in a > > > > > body and encrypting it might be a good approach. > > > > > > > > > > Thanks, > > > > > Paul > > > > > > > > > > > Regards, > > > > > > Rifaat > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: splices-bounces@ietf.org > > > > > > [mailto:splices-bounces@ietf.org > > > > ] On Behalf > > > > > Of > > > > > >> Paul Kyzivat > > > > > >> Sent: Tuesday, May 17, 2011 3:09 PM > > > > > >> To: splices@ietf.org > > > > > >> Subject: Re: [splices] SIP INVOKE method > > > > > >> > > > > > >> > > > > > >> > > > > > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat > > (Rifaat) wrote: > > > > > >> > > > > > >>> Yes, and I have the following open question about these > > > > parameters: > > > > > >>> Should a separate header be defined for action > > parameters? > > > > > >> > > > > > >> I can be convinced otherwise (by a good > > justification), but > > > > I'm inclined > > > > > >> toward describing the action and any parameters > > in a body part. > > > > > >> > > > > > >> Thanks, > > > > > >> Paul > > > > > >> _______________________________________________ > > > > > >> splices mailing list > > > > > >> splices@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/splices > > > > > > > > > > _______________________________________________ > > > > splices mailing list > > > > splices@ietf.org > > > > https://www.ietf.org/mailman/listinfo/splices > > > > > > > > > > > _______________________________________________ > > > splices mailing list > > > splices@ietf.org > > > https://www.ietf.org/mailman/listinfo/splices > > > _______________________________________________ > > > splices mailing list > > > splices@ietf.org > > > https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > > --_002_6369CB70BFD88942B9705AC1E639A33822CBE5D0D3DCUS1MBEX4glo_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="splices-3.pptx" Content-Description: splices-3.pptx Content-Disposition: attachment; filename="splices-3.pptx"; size=70343; creation-date="Mon, 18 Apr 2011 08:40:42 GMT"; modification-date="Sat, 16 Apr 2011 21:38:10 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAEE6eqfwIAAAcUAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE WNtymzAQfe9M/4HRa8fITts0zRjnoZenXjKT9ANUWNtqQdJIshv/fYUAW2GwgYCGF4MM2j3aPdo9 Ynn3lKXBHqSinEVoEc5RACzmCWWbCP16/Dq7QYHShCUk5QwidACF7lavXy0fDwJUYGYzFaGt1uIW YxVvISMq5AKYebLmMiPaDOUGCxL/JRvAV/P5NY4508D0TOc20Gr50wCQNIHgnkj9g2TGDxZCY5Wa P1VxeR8aiyj4VEzNvUeICJHSmGiDHe9ZUvM74+s1jSHh8S4z3kIhQZmrfT1LQ2v8TW4Ud0NwPR2C b+TAd7qMRDH44AVNYbtTVBow3UyIiXEN6qEgzOl+MTaik+m2IJ3eVPh0fzUdIEv470Rps9uLPVUM Ro+R46gtSPbVEs3bsUNjjfdB8G4SBHldupdcqLG9Hw13ikHDfvYTj2E1xk8fGIbJT2fohkmblgvY /g6vLdZMJ7aUe9ZP7eiDYPiiX6ILnKgPD0H3qDfsUT/r78Y9W2AbMPmp5M8xfYY12aU6+PJkpGSh Xv8I2NQUIs1y0WkfGJXXMEdCqmpzWlRlqWRDM9NKSbWlQlWMbfBwWba26E+Xmz7aQ6WHw4xQVi3i nBy3KqYSEM5g+A5wl2mkuWO7DdM5Co6OyXF0CZM5bdhejg2LBicMcm4nkMyEkQcgNYUj0c7lyMKs ivN8MIJaYqz1S8uvn9oWfvLQC4KfCtkGQZPfKTzoQwqj6zrHdBsKh7UlKYoq6ikvz0v0RY42tI2F H772AFXGyM/ZulOuSgR+TtJ9EHycpHbsKfzzchY6Gu4UgwZy+olHOzePDSXmEvrnpFIr+eyGNoLt Z7zVfwAAAP//AwBQSwMEFAAGAAgAAAAhAGj4dKEFAQAA4gIAAAsACAJfcmVscy8ucmVscyCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACskttKAzEQhu8F3yHMfTfbKiLSbG9E6J3I+gBjMrsb3RxIptK+vaHgYWEtgr2c0z9f8s96s3ej eKeUbfAKllUNgrwOxvpewXP7sLgFkRm9wTF4UnCgDJvm8mL9RCNyGcqDjVkUFZ8VDMzxTsqsB3KY qxDJl0oXkkMuYeplRP2GPclVXd/I9FMDmomm2BoFaWuuQLSHWDb/R1s6YjTIKHVItIipkCW25S2i xdQTKzBBP5Z0PnZUhRrkPNDqvEA87NyLRzvOoHzVqtdI/W9Ay78Dha6zmu6D3jnyPGOCnHZ8M8XI MibKZexo+6kfuj4nEO2ZvCFz2jSM8ZNITi6z+QAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAA NwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2I SFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0O wZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF 2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD/ /wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQu eG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+D eFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQ yRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxz wWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAI/NwpNcAAADOAQAAIAAA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzrJHBasMwDIbvg72D0X1WmkMZo04vY1DY ae0ewNhKYpbYxnJL8/ZzL8WBwi676ZfQpw+021/nSVwosQtewUY2IMibYJ0fFHyfPl5eQXDW3uop eFKwEMO+e37afdGkc1ni0UUWheJZwZhzfENkM9KsWYZIvkz6kGadS0wDRm1+9EDYNs0WU82AbsUU B6sgHWwL4rTEcvlvduh7Z+g9mPNMPj84gT5k4uPkLBWqTgNlBVJWba7qVhZ3wMdam//U4pvRp17C Oa+8qj5jFe5muPpC9wsAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xp ZGVzL19yZWxzL3NsaWRlNi54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1C Nor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELc u8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3r DB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAA IQDYA4Jr1wAAAM4BAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHOskcFqwzAM hu+DvYPRfVbSQxmjTi+jUOhp7R7A2EpiltjGcsfy9nMvxYHCLrvpl9CnD7Tb/8yT+KbELngFrWxA kDfBOj8o+LwcXl5BcNbe6il4UrAQw757ftp90KRzWeLRRRaF4lnBmHN8Q2Qz0qxZhki+TPqQZp1L TANGbb70QLhpmi2mmgHdiimOVkE62g2IyxLL5b/Zoe+dofdgrjP5/OAE+pCJz5OzVKg6DZQVSFm1 uapbWdwBH2u1/6nFN6OTXsI1r7yqPmMV7ma4+kL3CwAA//8DAFBLAwQUAAYACAAAACEAS/U97L8A AAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5S PYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7o LQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8 McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAA AP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRl Ny54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14 j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQi yxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEp PHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAg AAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTgueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyII nkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokY Ds1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7 BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBL AwQUAAYACAAAACEAS/U97L8AAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMi54bWwu cmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIX vIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cN acRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuoo a5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAhAAAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTExLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJ tm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFf acBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp /s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAG AAgAAAAhAEv1Pey/AAAANwEAACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTAueG1sLnJlbHOE j8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxA kDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTq VETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7n udjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAY7zJggQBAAD/AQAAIAAAAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGU5LnhtbC5yZWxzrJHBSgMxEIbvgu8Qck+y3YOINNuLCgW9SH2AsJnshiaZ kEy1+/ZGRWmh4MXjzDDf//8z680xBvYGpXpMmq9kxxmkEa1Pk+avu0dxy1klk6wJmEDzBSrfDNdX 6xcIhtpSnX2urFFS1XwmyndK1XGGaKrEDKlNHJZoqJVlUtmMezOB6rvuRpVTBh/OmGxrNS9b23O2 W3JT/puNzvkR7nE8REh0QULNjVSCT/sGNWUC+sUSYqjSA7kvmzPFoGwxjsQ7lgCLqD6LaNIiCrh2 LtG1S30zntE2ew9HgpJM4OpyjtV/5qjBW3gyCx7ox4XmUqqTfj0tetne8OlMnb1t+AAAAP//AwBQ SwMEFAAGAAgAAAAhAEWpyX1xAQAAKgoAAB8ACAFwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5y ZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvJbNasMwDIDvg71D8H113P+O pr2MQQ+DsXUP4CVqGpbYwfK69e1n0hLcUrSL8SUgmcgfn2I5y/VvUycHMFhplTExSFkCKtdFpcqM fWyfH+YsQStVIWutIGNHQLZe3d8t36CW1r2E+6rFxFVRmLG9te0j55jvoZE40C0ot7LTppHWhabk rcy/ZAl8mKZTbvwabHVRM9kUGTObwu2/PbZu5/9r692uyuFJ598NKHtjC451VYArKE0JNmNdiKfs bOBIGb8NIUaRKMSQxAgqw8rPGt7tsXYt7ZV4SYoklg9SxyxSU6aUCTGMRCEEiRFUhnXn1zsnXci7 JwkRTQVpYhqyIYcKfl6Nbr0j0qdIipAQ3Zx6kWjBuLL+8DolzyPsFJAdCuqGmKYT0o0ILudKy1mI SCmMSSSKMQUhglK0BvDqa+1TJIW79qPcsguKYhwJYkRBLCJBzCkIEVSF0hbwenx4SeRe0I8PfvGH t/oDAAD//wMAUEsDBBQABgAIAAAAIQC+a+MBogIAAD0OAAAUAAAAcHB0L3ByZXNlbnRhdGlvbi54 bWzsl81uozAQx+8r7TsgX1ctgfAVFFJpd1WpUleKmvYBXJg0qMYg28kmffodG6c4YQ99AG7Yf894 5mfPAMu7Y8O8AwhZt7wgwe2MeMDLtqr5W0Fenu9vMuJJRXlFWcuhICeQ5G71/duyyzsBEriiCk09 dMNlTguyU6rLfV+WO2iovG074KhtW9FQhUPx5leC/kX3DfPD2SzxG1pzYu3FV+zb7bYu4Xdb7hvc vncigJk45K7u5Nlb9xVvbhaXIUl6gM3+VYK6b7mSSIesMG3Jqj9UKhAP1aNUVzNeXRUkDKI0yuZJ hOxErmdwbUD81dL/nzlvFcgrlxdzjpPIernQhzDckB6qPpg4caIItb0J4lNOHXk+lheObHa/sE4i R45H1kngyMlYjh05Hcmpa52N5MRNbDGW547zYDbW3cwCczyXqblggjG4FEtlOF1Drj9e9xA2H155 LMgiiKLZDA3KU0GSLM7MQJ06rChZCgAeHS17c7LW7HOlNjv7MAdYwZbumXqGo9qoE4PVkuY4t14L +/S0Fh6juoiB37xsdPa+u4QdWNDhmoaKx4JgZJS9YQNgxEM3z/R183HeEbNUzCwB+sh/inddCOhb 1dwO0XqHW2FNr/e8VH2hmM10FBI9BZgw8d5B6B6DVY+FRHPZsrq6rxkzA90v4BcT3oHiburY18vV KrOrp7ltaYnsfjT8himdHM2BXglAe6GUV0IpBxwYoSFjeWhH+BgOaKI41QFPfAwUy2c+8Omv5cTn wDQUyyca+ATzNEimC6SrSlOxgGIHUBZmpj1MHUhTsYCSAVAYZniBphaEN0hTsYBSB1AazacebV5c mooFlA2ANB38/pia9IFpKhbQwgGUxOnUpM0N0lTMj8r4ExM/b92/pdU/AAAA//8DAFBLAwQUAAYA CAAAACEAVCLhX98FAABoGQAAFQAAAHBwdC9zbGlkZXMvc2xpZGUxLnhtbOxZS28bNxC+F+h/IPba KHpYfkiwHMh2lDpwHMFSUPRIcbnerbnkluSqsov+934kd/WynLiBkfrgi0SRw+HMfMN5UMfvFrkg c65NpuQgar9tRYRLpuJM3gyiL9NR4ygixlIZU6EkH0R33ETvTn7+6bjoGxET7JamTwdRam3RbzYN S3lOzVtVcIm1ROmcWvzUN81Y07/ANRfNTqt10MxpJqNqv37KfpUkGePnipU5lzYw0VxQC8lNmhWm 5lY8hVuhuQEbv3tDpBNoxiYidt+mmGrO3UjOP+hiUoy1X76ajzXJYtgrIpLmMEvUrBYqMv9TggyD 5tb2m5oT7S8SnZ8c0z50I4tBBOPfuU9son2+sISFSbaaZennHbQsfb+DulkfAAmWhzqtgkYP1enU 6kwzKzhpL7UKpBRbLxW7NUQq6OnUD+qxq3nNzOns2BcpsXcFLMOs9twq0rDuTVJvMd6staxbxmh3 2j34y6ZJeu1ut4VJ4gzT2TvoVBTrCgeuRd8uTlV85ww6w7cHhPaFsRN7J7g3NMxB+xAaH4BVUOf5 XDa+TCIy8xDHmbYeAWJyeyY4xU2pJLInk4sxGTLnhOSaJ1xrKo4hhwXuFVcu4zHV9PobzJ0paR/C wDi10BgGtB7HbK/GbFLOrIet8xywmXIWYIOfwwlrpJ8OX3f/0KHiHLp7hAu/jeEBEMR8wLC9d9iu KJ6CocNKqmFpVZLZYLcArlt4iC38i1BxA9RE8KPdYJt76OlF+irg11lCqSWTlN+mjd9Lw5MNvAOG Hkh8POvJZ6UQXJKPXEoEUvOjjh3iSpCPKpXGKvmjDh1pijSUGTIsY243TkVofORG7UDwO29Vd3mr RBZzclXmM67JWFDGUyVijPee5ZaJGKyRYeF6f5ZUW66j6sL5W+zjpAuoDwIm9FqFiW/EtgSJ2mWr vztHXYTK4WHjfL83anQPT88aR+d7vcZ+d3943u4dtHrD1j9RFbiN01xCup2R8UEkhKtDJhf42iu0 cLKbewSv78Rmf4nN7ohHXPT0McudXaUsdxYS+2aiCpNymby+mok6R739B1FsIxOt5aplFEMM0MZ+ 4ConbjCINGfWm5TOL00VvGoSL+NjictVadifKn0fEXEhzSDypwMv/8MH3Ijo9ZXZxooVZ0q41OXs IlGa/acImlN96TYTDK79QMw9N5JJOApEw1oIs8j5EYl5MqWzCTw7GAmi2UDP6aU81bc+tyZK2qGP zRThHIqhIpPVMvilyMaIdeNSMhzQ9pILOSlYgJaNmSVzCrZt1AMhxcD06xSnPNmmRV5akpqCrSiG CdK2cxk2tibw9XkeLDFXrc7KM6GnC+/ss3JyvxyOoIq/OwmixCAa6oyKiBSZZemI5plAJtxDXGEp 1YZ7c1U8rlBZ+6Gls+ATtA/roWBwDuqziBNL+w9klNsyz3L1RxZAWK9XXBzp+BSGygXmCyTlIJI4 whXyOruFaFJN/Cgit1y7st9nakZR0lWEBfP7nZNQkd3zX/3PGTVcZK4NAG+pxlqpxI93J0wnr5Du U6pRJkTQJswYhfDiJt2y7xo4zBpsbhcBaHhChe7h/hpirsVwxN42G3x4kuB21SYsL2WFTekOqsbe wdZg+iWXDWFDXcDp1gKnYYGZrQVm3AKwQcnoNLAnF++nI3LUekMm48uLs/cTsoqCAThH5grMV/Re IHq/fXjzKGAbHcHqhj3u8xs++Ty+ve5pY01vSr7lXmsp9tXBXo6DrWAJkdwFAd9vus7gNaOGfPv/ Z9SXdsU/Uc1S0um9IZ1We62e9plk5VOvueQFVQIrWF6v+ssrnlfofOPS+Hco9/D3Wj7/gPJ5BUt9 adClb71+YqZ+iHctfPU2z4T+RIvPcx8S8ZcDnk7QE2CqQL/oanOQrkjANMux4F9NJDoE/0ZNsRlk U1k/5selHkSunU0ymVl0TPiXwOJZBn0RR/vtmp6YT/27ts2vlfJ9A04qHCd828DajarjMMT/JCf/ AgAA//8DAFBLAwQUAAYACAAAACEA6Y93O0MDAAAuCAAAFQAAAHBwdC9zbGlkZXMvc2xpZGU4Lnht bLxVXW/TMBR9R+I/WH7PkrZp10ZrUT8YQoIx0fIDPMddLRLb2G5pQfx3jp2EwTbQpEm8JE58fa/P uefee/HqWFfkIKyTWk1p7yyjRCiuS6lup/TT5jIZU+I8UyWrtBJTehKOvpq9fHFhCleVBKeVK9iU 7rw3RZo6vhM1c2faCIW9rbY18/i0t2lp2Vd4rau0n2WjtGZS0fa8fcp5vd1KLlaa72uhfOPEiop5 3NztpHGdN/MUb8YKBzfx9B9XmgEZX1dleDuzsUKElTq8sWZtrm3cvjpcWyJL8EWJYjVooWm70ZrF TwUzLNJ7x287T6w4bm09u2AFsJHjlIL8U3jiECvE0RPe/OR3f/nuwyO2fPf6Eeu0C4Ab/AoaUDWI HsLpd3A20leC9H6hakwZjr7T/LMjSgNngN/A41eHzlnAHNybHfEnA2Z8cNXaNZuRj87egdNIlj8u dHkKwG/wjj9ZUTm/9qdKREJwbbCiymtm2UckoGJBo0Iln9aU3MRklNL6jiugxwkE6zxj2UD/OwGD joClVh7yINcV42Knq1JY0n8eHbJEMjvG/h8TxNV+WQmG6o7CamiJ3DyZzX/6QAIJq27hn3tLYwL3 V+gVQRoIE+TAiuZxP2nu25QO8wyyv5e++wFZ4WcLxj/vDVlXshQuuPYxQPT8N1XcBXiuMvJOGTE+ udrXN5DE7/IYPE8eTbWgp8I1Wi6Y+bJn1gtL0WmCcqL8Yu0ESp9VRFt07tC+vvfHeb+fzc+T1XBy meTni2UyXg0myTAfzle9ySibzLMftK1kF5hXuF1M6INc/imzmPlYtn42vssWIv+jilvJPFa1sXi7 bozW+M4h/SY2yb2VgLJYTEb95XiRLHo5oKwm58n8cjRMLoeDPF8uxvPl4PUPXN308oJbERv/23aA oX+3kwi7D6ZHLbnVTm/9Gdd12oyh1Oivwhot4yTqZe04O7BqSgf9SZ4N8tH5qG17uG6E1F0bWLoJ wyv7npkPh6hiDE7kexl/GYzKQAdM70zQy2SNjYDcq5YCw3AYZhvVjaRyj4EqVSm2UkkvKMGs89DS lCqBUQ8l61Jsmu5cf9Tat/eMnhCxdR1WbTgsoczZTwAAAP//AwBQSwMEFAAGAAgAAAAhAM1p6Po4 BgAAaRQAABUAAABwcHQvc2xpZGVzL3NsaWRlOS54bWzMWF1TKjkQfd+q/Q+ped4RRPCDEm8p6pZV 96ol3od9DDOBSZlJZpOAslv3v+xv2V+2pzMzKAhXKHzYBwFnkk769OmTTp9+eckVmwrrpNG9aH+v GTGhE5NKPe5F3x+v4+OIOc91ypXRohfNhIu+nP36y2nRdSplmK1dl/eizPui22i4JBM5d3umEBrv Rsbm3ONfO26klj/Daq4arWbzsJFzqaNqvt1kvhmNZCIuTTLJhfalESsU99i5y2ThamvFJtYKKxzM hNkLWzqDZ8lApfTtikcrBP3S099tMSjubXh9O723TKbAK2Ka54AlalQvqmHhX41h+NFYmj6uLfHu y8jmZ6e8C9/YSy8C+DP6xCTeFS+eJeXD5PVpkt2tGJtkVytGN+oFsIP5ouRV6dF7d1q1O4/SK8H2 516VQzmmfjXJk2PawE9yv3QvuZ3WxshnMl9kzM8KIOPJVDWufBnwqMc7YBrA8i8XJp2R40N8h4e8 q5wf+JkSARBsm3dhHB+AX3FiqNDx90HEhiEUqbQ+IMVc7vtKcDC6AtOf3YGR7Ma5iTgFLh5hqYwJ nd5zyx8+sEme8i72gO3Xe8XPEsz1kB7UkPaN9iAcu1c8EZlRqbCstRvAMgU96hhsgy1hqJGa5xNv RtKzEfY2SLhCuDqdZhM0VHpQJA8inSSUXr0IKYvHJQZlfMjGpuGZBybE0Z89ZoI9XF1fPbBc+Myk zAmRO+YNGwrGlRU8nTEDVVKGpyJlz9JnbMqtNBPHEl7woVTSS+H22FIwV9Njvv4qYtBmtrNSeTEy ShmSNAZpG/ktjazaSipcYuVQuM1sbcD6jZ1bslW5eC2ngn1DIsFLx8yI+XnkNoJsyeoqn78FBixZ W5eTawNZpmbIT3xQKk9VlRvrNGNui5icKamf+komT8x2SdntTRqyk1SCFI0kozrjlva6DeU2Xsob o9yeFH4Uzs7M44wKLIufjVViFjtZxDnXs9iKEU7vuNlc2tbnQvihtVIagkT/RKfnmK8TgoyDZiAZ AihzWR7PEIaMe4YTewoBdYwEy5ocWkG5R4yUqeCq1hLUHIwXBWIZDnemME0xCfW1PKjZHqOseM1e bgVzJhcVv514u3Z3AdZdaPbGZVLQOptu7x5vrv9g0kH4nvnMwQ3n+Fg0Fhb+kMRMWDsnvD8DPUaW j7ezUe2QodrD32wBxZR7Dh1WiiQ6FQrCYKHMUocAvHVouzU/c98VcltuYEWtsLediQq3f/9ZmPZJ XAn5bUHvwpoxilbwX6c1t8EaqR3o/y4KFa3K8/U3GuVxqhLpMnxDMerQLQxccOBjzn0I3S4YrDos KHF/BohDWltUpzoe3NxjpDMTm+A4pRTXBvU0ikKrZiDwSGrQl5g+QcLT6BX4umUibC2DWx5FFZNu cpIv6JybDKkiKKgII4nAXtPf2HDimXhZM4Tc5FSYiPSzo4k7yZpa+a2u7xLzV41EwOCvNgyaGIJK Oh9qxjgU8ZaqRe6eAvHL5w8ikYWkGhuvnoQowrtU4uY6BiRUyqBMw9FCpuYsSgzAFgTw/wCudfh+ UEctQL66HnF/9aKDQyrtP7BFhc4gMxNc7jcCZK3hKpacafEcEqyq9cP5UabfbgusEggiRZoGmUSU F4/yL0vLrQP7Zx6VSG93BWzXV8CBIqW+neRDkPDtPfBgt3tgedFGOwam0a1BpP+ccAumR6iM6IpY VrLUhqBSdqf79wi8oPr479Zxu9Vqnh/Fl52T67h9dNGPjy8PTuJOu3N+uX9y2Dw5b/6IqiaAI881 dkcF8Lvb+7tjpOwJEBNPXmOGlWn2mqiBbetiE27pdSMHXZWvDrf/IvRXJlbClYuLk8NW//givthv w5XLk6P4/PqwE193Dtrt/sXxef/g6ge2Xuy3uwkupyQWN1XvC62fqomFt+8aT7lMrHFm5PcgM42y g9UooM22MKhI0cTab1adsCnHhaV1cNw+Omp3juuIYbshYPW24UvdnEqU/caLu2nId/TcEO9+eFSg LCY4MPR1CJoWKKj1mDz3uoKg4JiMYY84XMpuVjpBFYkCg85H6UVEZ6gHl3qRRhkNQmmTiseysZM/ GONDTwDtHrKEFSvT9KtaDj/BzLP/AAAA//8DAFBLAwQUAAYACAAAACEAccQfGqcFAAC3JAAAFgAA AHBwdC9zbGlkZXMvc2xpZGUxMC54bWzsWltz6jYQfj6d6X/Q+OE8lXAJJMEJnCEh6TBNCQMkM51O HxRbYE9lyUcSJLTT/95d2Y4NIdcTejIlPGBZllbabz9dd4++3EaczJnSoRQtp7pTcQgTnvRDMW05 l+Oz0oFDtKHCp1wK1nIWTDtf2j/+cBS7mvsEagvt0pYTGBO75bL2AhZRvSNjJuDbRKqIGnhV07Kv 6A1IjXi5VqnslSMaCietr55TX04moce60ptFTJhEiGKcGui5DsJYZ9Li50iLFdMgxtZe6lIbNPNG 3MenjseKMUyJ+c8qHsUDZT/35wNFQh/wcoigEcDilNMPaTH7KqAYJMor1aeZJOreTlTUPqIu6EZu Ww6Av8B/qERddmuIl2R6ea4XXKwp6wWna0qXswagB3eNolaJRvfVqWXqjEPDGaneaZUUpVD1XHp/ aiIk6InqJ+p5/XkmDHVG8XFAzCIGZAyKSsslHy0eWXkNmFqwzO2x9Beo+DU8UQh1BdCnMzNyEhps qPiJazMyC84sVKAQdUEQoXwKLObYHHWtCAW5nCKZmShdjoDMf7Wc2kEFoL629vNDZSy8REfmhDMK AlILmPYokMhZQslAsZJinlQ+88lV6DNJujOVfDuRAkeQ5RL20ti+2uaZ8AdU0eGze5HoCQoBShkk kExs9rDldjPLQV8M8JoMOPVYILnPFKkhHsDqzEovtGPoAwszUz9gQsR7hczVen3f4gzoVqv13Qpg bu2SEXu/ttvETIL0buxXG2mJIm2RHtj3DIoiBQrsIBNQe+RRDoSrWTmEi1HsDZk/83CCgGyQbjvw DBpFVJ3b0RgKH8DEJCpoRWJCx97AM2ROOapWEHxX4nrWh+kyNWZC5ofp2Nh7io62deCXsINqAqZt OWBpLTmFaS8OjRec0SjkAGS9CYAGVGlm+510AUYBijDt3wcB9It0SOHXG4yv/ii8ryaTKsdLzAYQ k0GHYnHk/X8hK73+9w4hWz/dvRm/PnNz2Hr57/PUHBI680P5HSB7bI5OhuZmQMvbtevFOxhPm9Hz bvIZnp6dDsmShR9bpVexZwr2ibDjKq7Tb0bcIZsw9equbaRLpbF03ylaMyVcHcYlahdXdxJy5s5x U+TGnC5WYMx5fn8ntmrjtwQyb3dLxle6cB+iOVr4h2cTcmiomjJT8kM4wk1byaO6ZKP3sZpvePZZ t4zjurN9SNQqte1TGncm6yjwYiTSQ6Zn1H9wKNjwmLjUjNwE1DA4v5JYSSM9yYmRhMGdzzUPdQBH XzuxE8003hGRm9AEJKZwaCbHO6QHJ5Ig1MSjmv1ERr0BgZeZhjPykhATsEzAzosBt2s8nuYw8aqj V74SfKxA62473mwX9ekTIb3+VW98SkbdwTvdvMC9ny8FX92mPHU+3/BQTIbZdxgc31lvYEz+Gydb la7dqrhka/cqOSKF1LrVq5C3nXuZAj558uKX7RtHufaF1EObngJtPpCyeHVOPjiTEKfAjXVJe1VX oNhd8oNIFoonLj8tfHZHvX149S/GvbPftk/vh2bh7UMCnHBkGxfnhybSVzFgjW/xsQMuOigd2Eqn B79vPevlTWW3qi/zVNczT/WIw4Ux6c+ia7h7KLqrd7/NXZ2EHUBwCohO3P1fZ3BdwZQDIRvoybbu cBuEgF5Rm3gyGsE6ru/HHEwgBAbjQP6uHdRrtUpnv9RtNM9K9f3jk9JBd7dZatQbnW61uVdpdir/ OGlIhEbNBfQObXE/QGE1DAHcq7Z5065WcsJA01g9N8fS1UbqebbqZb7zNIzAPpK4FkhmoS4eV7/S +GJuT4MQwQN4ndisGGIcUBoUzYuAQz6M4IN1zYtzDREPEPJBoTIUG4ssNsafgccGfeiTUISGOQSC buA2GhzTAm+cgAnSZ+MkTCQaSmnQ8tCSlQRPk4jGVNocJMGy7X8BAAD//wMAUEsDBBQABgAIAAAA IQCPpBkNJgUAAK4hAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTEyLnhtbOxa33PiNhB+70z/B40f7o0D O5AEJ3BDSNLJNCUMcDfT6fRBsQV4KsuuLGhor/97P0l2+J1LciHXkvoBhC2tdvfb/SR5Of1wF3My ZTKLEtFw3PcVhzARJGEkRg3n4+CydOyQTFERUp4I1nBmLHM+NL//7jT1Mx4SjBaZTxvOWKnUL5ez YMximr1PUibwbJjImCr8lKNyKOkfkBrzslepHJZjGgknHy8fMz4ZDqOAnSfBJGZCWSGScaqgeTaO 0qyQlj5GWipZBjFm9JJKTVgW9Hmov7N0IBnTLTH9Qab9tCvN4860K0kUwl8OETSGW5xy/iDvZn4K dEOjvDJ8VEii/t1Qxs1T6sM2ctdw4PyZ/sQg6rM7RQJ7M5jfDcY3G/oG44sNvcvFBNDgflJtlbVo 3RyvMGcQKc6Ie2+V7Uox9DoJfsuISGCnNt+aF3SmhTBtsxafjomapfCM0qLyfvah8UfRP4NPjbPU 3VkSzrTht/jWQqgvED6tiUqGkdITLT7imeqrGWfGVTCI+hBEKB8hirmejvpGhMRdTnUwM1H62Ecw /9lwvOMKXH1r8AsjqYx7SRarNmcUAnIEVPNKBHyic4FcR1NGPkUhS0gkCCXtROisMfGjNVNGPzMl E2GXStp79MzWNhgBzxRuQNPitB2taoFWn0Mv0pnEt0ySLqcBGyc8RPtAOwLhXMDzLACR5hBtHff7 hErFpIPgR2S63jNwNdCsozcEmeiM+ss7rnpepXVUOq/VL0vVo7N26fj8oF6qVWutc7d+WKm3Kn87 eXBl2nIB7Qzeaw5fBdTGmgbL9eagYWo9fAtszwTnsAAHgaJANEu41L4OF+v8h32vLVphF/fgyD3U gY9wd716rYq2QaNgmqMDtwZudojmm5pXO9JpYu23okxQ2vwu4nQxJxfSlQxhdj+gHAxQ92paKBf9 NOixcBJoxkYSVnDl4ucpvx4ZhnSpb4Zrq7I06AaKTCmHGe6CkPset5MO1qocOMsk27nANco9xAV6 Ur3MCBN0Q6RXwwGqWcIp1pw0UsH4ksYRh9OqdThvTGXGVM4ioAZQkBahmr90x9CLtMjC1W3/uvBr vWmHnM2jFbIg0zKeFrs/7ik9//rG7tm8hrxY3Lzj6qTx9OvdSJ0QiuUr2bF7tjCnWWpteu3GQfN5 13OCxFRemx1VJLBEmHQ0gGgW0o2d0Mhu7LwnkN7F5UWPLKH50DbHsv1cJyax0caWdXGj82JB2mND Jp+t2k5UKg0S/wneMgvBK3lrIoWfRWmJmsXQn+qNpZ9yOlvx4DzE13ex/6dWxez7XmRtzlfeE0Xl iKlSGOG8O2rYL3cJlNdffecxuZM0KUzHNMzuzZbsfZBhXjNncF4PoeH08xPVW93b7ZQGtZKJ4Kt5 /KX95xzinWr3Wftvg3r/Rpr5z6/Wm7azek+2FL57xyZeZeFo/U0OK/Nc2gld6t34Jmj3G9b1kynu XHU+XQ0u3qDhm/BfuLf/Wb4xHG5+fIOhsI0OFsLhDXql1X6LsbCA+abmG6WFL7y5Mq+pzAF4v/Ok czO4uvx5v23cRob7bTUqGWTf176n89mDZ0rUbRxyv1H/2peQ86mKF8HrlVRTu7LlfDSLCn/A5U80 vZma8zn+uIDiZtvcSlH01RUkdJ13QXk2ivFAF1WVuM5Q9EWlm2Iwug1E8ZeAcIL3rPq18zASkWIO wX8N8F4J76AFQ9EYlcEkZANbHY97SaLyUp6RpDW3onUrnw5NlGGb/wAAAP//AwBQSwMEFAAGAAgA AAAhAI7ZcR8TBAAAsgsAABUAAABwcHQvc2xpZGVzL3NsaWRlNy54bWy8VttOIzkQfV9p/8Hq5wkJ AQaISBDDTUgsRIQRz8ZdoS3cdo/t3Ga10v7G/N58yR7b3TAwYcnAah9oHLvquOoc21V7+/NSsSlZ J43uZ+trnYyRFiaX+q6ffb4+ae1kzHmuc66Mpn62IJftD37/ba/qOZUzeGvX4/2s8L7qtdtOFFRy t2Yq0lgbG1tyj5/2rp1bPgNqqdrdTudju+RSZ7W/XcXfjMdS0JERk5K0TyCWFPeI3BWycg1atQpa ZckBJno/CWmAzMRI5eG/q64tURjp6amtRtXQxuWL6dAymYOvjGlegpasXS/UZvGnhhkG7Wfudw0S 783Hthzs8R5yY/N+BvIX4Qsn3qO5ZyJNisdZUVwusRXF8RLrdrMBInjYNGSVMvo5nW6TzrX0itj6 Q1bJlMP13Ih7x7RBniH9lJ64mDZgIecAXxXMLyow4wNUbZcWIx+NvQOnkSw//2TyRUj8Fv/jJO8p 50d+oSgSgrB5D+D4gH7Fwwkl3fo8ylgurY8cMVf6Q0UcZ7mm0Q9uCu6///3NsQtQur8HVjxEqaFI 50Nu+dWLiCFD3sPeCLuJEcNE4stUbjRUHhrtcdDYUHFBhVE5WdZ9H7Eyx7FouP8VTgN3GlfyYOLN WHo2RmwjwRVk2t7e6uD4KT2qxBXlExGuVT/DVcV04iDpEjD+E1kOclOFTZ4IkqiOfOMTRJmqOte3 aU+MW/y5ezw9zBfERsPzs8PjEbs5Zd4wHoLAvHRsZuz9B3ZLgk8csRlhqCRNCau8NoFVgCiN84xX lTWVldxTwMJL9yMMHszGD/YkCq6lK1lOY6kpZ7eLZIw3cewZYDm7J8wZoyJS3AFhOCZ4+Eqd7G9O V2fr1ZP9/K484f4N9+yIWsJMKgWmV4/yDfvcQB2OGxVVSwxCyVsCuykAEDy2poQBMYOPfRA9WkNE CK+UmTHcAYwh5B3KgWNfJlLcq8WHMInCAsdklkAenZOMTNOM8XhRXFQtmeFgKClSWVpbnYj/Xa5L lGh25tyEVg/yDWpdHZ8cX7EnW7x+k8miJUBxXfKaT9fcL4ItAVlDLZix0dkQd9MXJn+G+KoWbywK m01RGCmZE7uYlLc4Yz9Who33VYZUctGYARrsfe1nXybc4iBnaFdC0YiVJxbgUKbfVYnHaP9CD/Rn d2ez2+0cbLeOtnZPWpvbnw5bO0cbu62tza2Do/Xdj53dg85fWd0OuJC5RnRL6/hPUqXuIFTs7UeN sHPwfkGlf9Em1u3U0mHYdHlC2T94dTmNhxvNK+g6jFMVXrKABtNHE3QBssRCaHK8PnfoJdDtcDjD 7Fo3bWE+wQmWOr4U0lPG8MB4SNHPNGoK9NAmp+vUIZVXxvhYZGsk7FhDh1G9HYYQdvAPAAAA//8D AFBLAwQUAAYACAAAACEAaLkJH6sEAADZGgAAFgAAAHBwdC9zbGlkZXMvc2xpZGUxMS54bWzsWVtz 4jYUfu9M/4PGD/vGggkkwQnsJCR0drpNmMA+dHb2QbEF9lSWXEmwSTv97/0k2UCAZHaTsu2Q+gFk WzqX71x0fHT67i7nZM6UzqToBuHbRkCYiGWSiWk3+Dge1I4Dog0VCeVSsG5wz3TwrvfjD6dFpHlC sFroiHaD1Jgiqtd1nLKc6reyYALvJlLl1OBWTeuJol9ANef1ZqNxWM9pJoJyvfqa9XIyyWJ2IeNZ zoTxRBTj1EBynWaFrqgVX0OtUEyDjFv9QKQeNItHPLH/uhgrxuxIzH9SxagYKvf6aj5UJEuAV0AE zQFLUC9flNPcrcA0DOpry6cVJRrdTVTeO6URdCN33QDg39tfLKIRuzMk9g/j5dM4vd4yN04vt8yu VwwgwYKp1cprtKlOs1JnnBnOSLjQyk+lWPpBxr9pIiT0tOp79eKreUXM6mzJFykx9wWQMZZUOc+/ dHhU8zUwdWCZu3OZ3FvFb/FvidBIwH3OZkZOMmMZrb7i2ozMPWcOKihEIxAilE/hxdyyo5EjofCU U+vMTNQ+juDMf3SD5nEDUN86+yWZMg5eonPT54yCQGkB0xsxYSOBUDLIAMhEyRzjYZ9czJR/3pfC Ro/zIyuhcXKCNcYQC7pWimHokX8c/1aF/4hnCSNXs/yWKTLkNGap5AnGB1Y1OGgF+LNMgsAFaQ/F 7zOqDFMB3Bm+FjafYSkH9qY9JkgPNkb+bB63ms3G2VHtot0Z1FpH5/3a8cVBp9Zutc8uws5ho3PW +Cso3UVbzQWkcxbcMN66ibz3WNjDcAk/WNvlMN6QKnqzRgXyPsc4h5VxYHKD1PHALu2X2cWD/zT2 VqO1fBG2WkfOleHAYTPsILFaGsvccdQ86DSsr9sM0g6Pw0M/A/p7Us4pfcRWfroaZd8agJY3F6Mi tgNdxMPYkDnlkC6EGE44sF7MuJ1dYVMp7eFD/vGgDVtWkaeC1nFHJArnSxNETTeAsbTkFJtDkZk4 HdA848Ci1QEmKVWamTLcIRdyhSVhep+GKeQiZ2TlGvY/r9xtDv2S86UTLnKASwQuP+0JPLXnXzuG 55GId0nf+8/2dP9Sz1nyrXLL9zT6bnRaRMMbbk663369mZoTQmdJJv83+g4S4Y6NfnM5uLwhDyz3 VEW1HlxMoaZHdbxaU700yBYOecMmTD1btJ2IVBvL6D+K1kyJSGdFjcb2SymaoJCNjKJCb4K4TGOb NfO6hf9JGJd89zB9lqXCiQW+a3/sFyM5MVRNmaklGT6sp13/t1LC/ivVw45zyraywe4SD0LZl+Z7 tH02G839VtDWB9tMu99a+7B+DTqufeuMU2Y7INUWoonBA5vXyEzbnsiXlBqGnggplDQylvwVYrTf Kl9dj98PfiWf0G4g1z9/3m9lX2d286bdb8tu27O+QzmyLHa3FNmN9o57XEvuVam92aJ2TUF/8oFh dRgSc/ULLa7nrkeGMx50jfvuUYGsb3t4mLqcgr53luOF7VYb8UGjL45DAYrFmDYW1elJMsN3YiYS NslEZlhAcCyDyhhNOWH3ELRcZcLG/iAhv5HSlD1SR8lK7knbUckOQ/S3e38DAAD//wMAUEsDBBQA BgAIAAAAIQCFUoGDsQQAAAUPAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTUueG1srFddb+I4FH1faf+D ledN+Si0EBVGQNvVSLMdVOgPMI4p1jp21jYUZjX/fY+dpB0oUNruSxsS+/iecz9879WXdSbJihsr tOpFjbN6RLhiOhXqsRc9TG/jTkSsoyqlUiveizbcRl/6v/92lSdWpgS7lU1oL1o4lye1mmULnlF7 pnOu8G2uTUYdfprHWmroE1AzWWvW6xe1jAoVlfvNKfv1fC4Yv9ZsmXHlChDDJXWw3C5Ebiu0/BS0 3HALmLB7y6Q+mLGJTP1/m08N5/5Jrf40+SQfm/D5bjU2RKTQKyKKZpAlqpUfymXhp8IyPNR2tj9W SDRZz03Wv6IJuJF1L4L4G/8Xm2jC146w4iV7ecsW3/esZYubPatr1QGw4PlQz6pg9JpOs6IzFU5y 0nhmVSyl2PpNs78tURo8Pf2CHrtbVWCes4fPF8RtcijjPFS5rvgY9KjWW2gaxHLroU43nvgM/8NL mkjrJm4jeRAEZtME4PgD+SX1EcpV/DCJyCy4IhXGBaWIzdxIcoqILsV0/Yf7OzJxZsnc0vArSOPg mRKPq3RMDb1/A9aTpQnMAIPKXDwWeh5W9bxSdaSVQ8yRsaSML7RMuSHNz2ksUkRI5Yb3yOtlVMjO wdLpuXBkDtsmjEp4rNOu1xGJUk1yds9TKBZqA7IWrwsNChd5jFM9dNQ304WwJC0zm6R8LhS3xC04 2XHUh71vRR7TQOQkxKPWhpS3OXx4tgVWxEYIkENxehR3Cr6DYCPxwbqF/SZgyBDXF4rJZVqKVxAO 5v5BUMJJRjdkxuFrKfUTT8lsQyixPBMx0yjvYQ1NU+EdTuU7LdiXdIUFsc05E6je70QsOeVIzYw7 3FHvk2SfQR/3WGmMd9IvupJMPC5Qp3EFCeuInkNQtcxmyGw8f95eRh1/1EZwe7aNthVsqKFErmRZ Cd6MlX3C3KxplqPmI/KS7ZMOwe3WXG5wjeNC3FN7l0YlLxmYoMzIhCr7xM2OQicW4t0zjopxCPNg Lm6h7a84B/f6a+VwNSsSD00QefFrsiXB1tmnuXXXD3v094JvHXPIp0d5JcRpAiT9hAxg3KJCaxCR skwIS+iKCklnCCNfTMjk65g8DI6k3P9HUKs5N2hcd2/2D7hvP83nAz5M9nNx+Obu4mJ+d3PSqpqT iRQpJ3dF7fq1Qzn/XIdSdIGYFQCN4vCjF/2zpAbVPEIH7ZuX0AGFntB3jp9qDueYSHxb/m+z02o2 64PL+LrdvY1bl8NR3Lk+78btVntw3ehe1LuD+s+o7FCtZ46iHe1tLV+lU9Gw+kRvv+QUTva7D3jp iG9C/1hNGWj5v1n0pXlo/pdGgMpw2L1ojjrDeNhogcp19zIe3F6049v2eas1GnYGo/ObnzA9b7QS ZngYaL6WgxnmknLCwtdXU1EmmNFWz90Z01mtGK9qORoDk2sRJqxGvRzTVhSXS6fb6DQu2vXKYbA2 +KuyGlSqwYlJ8xfNv69C+mEehLtH4VWO4ufVwNKXJeimRYYPnrhTpQK49f1vNlXVpJUuccEIFdpD 4XhEMMI5hFIvUhwTLAJZp3xaDB3ZvdYuNKsYRTwSTiyh/VN5HB4RmP3/AAAA//8DAFBLAwQUAAYA CAAAACEA4Ts6k60DAAD+CQAAFQAAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbMRW227jNhB9L9B/IPQc x46T7CZG7IVzKwpss4HtfABNjiw1FMklKa+9Rf+9h5SUbLpxmm6A1g8yJc4Mz5whz/Dsw6ZSbE3O l0aPs4P9QcZICyNLvRpnd4vr3knGfOBacmU0jbMt+ezD5OefzuzIK8ngrf2Ij7MiBDvq970oqOJ+ 31jSmMuNq3jAq1v1peNfELVS/eFg8K5f8VJnrb97jb/J81LQpRF1RTo0QRwpHoDcF6X1XTT7mmjW kUeY5P0E0gSZibmS8d/bhSOKI73+xdm5vXVp+mZ961gpwVfGNK9AS9ZvJ1qz9KphhkH/b+6rLhIf bXJXTc74CLmxzTgD+dv4hBMf0SYw0XwUj19F8ekZW1FcPWPd7xYAgodFY1ZNRt+nM+zSWZRBETt4 yKox5XD9aMS9Z9ogz5h+k564WXfBYs4xvC1Y2FowE2Ko1q6ZTHx09h6cJrLC5tzIbUx8if/0kY+U D/OwVZQIAWw+QnA8QL/icYeS7t3NM7ZMpZClC4kp5qtwoYhjR7dkhsk5F/crZ2otz8BLQFnaYKTl LXd89g8xY6Z8BAyA32HFsCFzN6WHHaUXRgdsOHaruKDCKEmODd9GcCmxPboa/BtuI4caR3NaB5OX gSk9t2JGshbxMCHmAL9Us64a0eO1xXixDHNTEePWqlI0J5dpIsk4q0gUXJe+YsEwR5UJpLaM+3vM 3U3jR0su6gkT5ALEgwVM+v0n1WwqlMq0a6u8iG5REJtdXV/NACcURrLSx20MrApgag+kgMBCwcMe W9YBI/rGVJVVGWI2noFVaSielMB8ba1xjXFulDJRB0e7geNIMLVWbW1/KJFfoR1cx8WX1OBOrH6u yYcHQiGB1mgZueWgPE3uMdpf7TOu/RdsUI4oSu1h8ncS0TG+vkD5f4W8qgN2UULz/9MYHNjKE1t5 qegJIMj4Dnl52Ic/KCxHnbDMVSmJ3dTVEhC+VZfDt6lLI99o8giNO8DXcfa55i6Qy9D6ovAk9Upi HiX/Taqe4yoR++kfw5Oj4XAwfd+7PD697h29P7/onVwenvaOj46nlwen7wan08GfWdtafMxcA92z PeG7HtB0mqj9w8caYeXovaNKL9QmaX9zPcCwuzEI5X7j9tM6tSlchEDXRfpkceRjNJg+mqCTQDH0 KjbMoD96dCV0Tg5nmC10d8WQNS5IpZaUlxr6kuE44krmwjjThKsbNoKRtGi6bTUzJiTpbiNhxTZ0 HLXLYYjCTv4CAAD//wMAUEsDBBQABgAIAAAAIQCTd4VHxAQAAMMNAAAVAAAAcHB0L3NsaWRlcy9z bGlkZTYueG1srFfBbts4EL0vsP9A6LQL1LHjOIltxClspykKpG0Qp9gzQ40sohSpJSnH3kX/fR8p Ka1bJ+ukvdiSSA5n3rzhPJ69XheKrcg6afQkOTzoJYy0MKnUy0ny6fayM0yY81ynXBlNk2RDLnl9 /vtvZ+XYqZRhtXZjPkly78txt+tETgV3B6YkjbHM2IJ7vNplN7X8HlYL1e33eifdgkudNOvtPutN lklBF0ZUBWlfG7GkuIfnLpela62V+1grLTmYiau3XDpHZGKh0vDvyltLFJ706q0tF+W1jcMfVteW yRR4JUzzArAk3WagmRZfNabhofvd8mVriY/XmS3Oz/gYsbH1JAH4m/CLRXxMa89E/VF8/Sryjzvm ivzNjtnddgN48LBpiKqO6Mdw+m04t9IrYocPUdVTOZZeGfHZMW0QZwi/Dk98WLXGQszBfJkzvymB jA+mmnn1YMSjne+AaQTLr2cm3YTA7/AfP/Kxcn7hN4oiIHCbj2EcP4Bf8cBQ0p1Pi4TdxVSk0vqI FHOFnyviYHQDpj//5IjNuSN3Blg8stLYIp1ec8tv/sdkCJSP4QK8b13FY43l44getYjOjfbgG7tW XFBuVEqW9X8OX5mCHW0KngNtgFCjMqeVN5n0LINvC8EVsjXqH/fAQqUXpbihtBKhuiYJKhafawzq 9AQbL8xOTKY/v82lTTvA3m+619asN+y7zLw41dOyVFLUB8OWzTqDMY34CRlfqQbCx5j1JKcW767Z NEK0n+8PxhoIbra8e5ELlJG1XL1sf+lY5SirFChgGWf3MiVmUVjETMZ8SBArQ4IYhsuYI/4NtpjB PdNEKfOGWSqMJ7VhAnSyRoU1UmeqQj8hGEcB2me6uauOp0uU0RZuT2b1ueXdkGMv7jVZvDLGhbjn pioVsNhy7rGk7nNiTbfPqifj3O3wA+F2IfkNe29+IY2EUYpiUbjAItWgIxp0Ig1iEh27z6XI2b2p oCSU/EyBRk1jBmGEMRY6hHtgCppaRuuSrAx02gviJ4M/2DLxq6H9i9gdKUkrhBRqxOfEdsFdkMi5 lq5ggmuWkypRMqwwzr9iMkOb9Ywr9SquBwSYhQbGUnLCyjvAgsnB9FYsP8G4C+n4cmlpGTF/T6nk +9l+EmoIv8yzPxYEULj4XJXMKRw07s8tt+sUPK+7DtruuggG2YequANNvm2xRz/XYmsJA6EL09DB /0ySvyuch2QTyL/QfWMLj4ImyJ748FJlk6EIgqb8tz8c9Pu96Wnn4nh02Rmczuad4cXRqHM8OJ5e HI5OeqNp70vSyKsIpYZ3O3XRDzqoVltBAJ18RR87h9WPHJV119+pfKIAaiUy9OqVg7Aqo3KtrEQo s9nopD8fzjqzwwFCuRiddqaXJ8edy+OjwWA+G07nR2++wPXycDAWlmLLftfcKiCqm+sBRn+Q9IUU 1jiT+QNhim59N+iW5p5saWS8Hhz2mjvGiqPJ9496veHg9HR4GmVMdDImrHUbsbSyXyj7npcfV/FM xW0G+Z7HTyXuLwEOTP06BXpQFhgIkXvdQICuGd7FrW7vCWmFW47UKWVSS08J+iXuVdZPEo1jAoTS JqXbWjIXN8b4xs9oCTs2psNTsx0ewczz/wAAAP//AwBQSwMEFAAGAAgAAAAhAF1mpZvSAwAA4wkA ABUAAABwcHQvc2xpZGVzL3NsaWRlMy54bWy0Vttu4zYQfS/QfyD0XMU3ObaF2Atf4mKBbdawnQ9g KDoiSpFcinbiLfbfe0hJSd3EadC0LxIlDodzzlyvPj0Wkhy4LYVW46hz0Y4IV0xnQt2Po9vtMh5G pHRUZVRqxcfRkZfRp8nPP12ZtJQZwWlVpnQc5c6ZtNUqWc4LWl5owxX2dtoW1OHT3rcySx+gtZCt brt92SqoUFF93r7nvN7tBOMLzfYFV65SYrmkDpaXuTBlo828R5uxvISacPrEpAmQsY3M/Ls0W8u5 X6nDr9ZszMqG7ZvDyhKRga+IKFqAlqhVb9Ri4VNBDIvW347fN5po+rizxeSKpsBGHscRyD/6Jw7R lD86wqqf7Pkvy7++Isvy61ekW80FsODpUo+qQvQSTreBsxVOctJ5QlWJUhz9otnvJVEaOD38Ch67 OTTKPGav3uTEHQ2YcV5VLVdtBj4a+RKcBrLc40xnRw/8Du/wk6aydBt3lDwQArNpCuV4gH5JfYRy Fd9uInIXXJEJ6wJTpCzcXHKKiK7JdBMQxJUPa7K+Xl6vr0COg29qjdhaUUvX/6DYw6UpDAGGxmAs K0bP89preJ1rBSscWUnKeK5lxi3pfoxlkSFGGkf8bwS/Se0252TzeUWmzOciWfMdt5ZKgggGryVx 2A+kk4K7XGfpCfkVoYFVPLwDDrJGdM7db1ozlVI/VJda/m3PS0f0jlBFTm49p/odkVTBfJe2Nw0l 4IqS2+kv5O4IrowUDLlyJNQD8IEaePNkxltNck59tOwER9l1mjCEEkqo17C+OTHmvybUu7dyn+VM GOEDWPga4IgnWFj+bBBzMMjlwmbEUGRjZWlhJHc84KEhRk7sRak7k31P9P3LvEuavNtIkXFysy/u QOFfk6/3seSrShwaIVSjT34fR9/2gM1thPbg8zIkdyh4vix+qPLt4Hffc/7oDpNutz0dxIv+aBkn g9k8Hi56o7if9KeLzuiyPZq2f0R1+S09cgXrXq2bL+pkVY19aew9+wg3+9NnvPSGb0JpbFooqsGX EiXXhM62twJQZrPRZXc+nMWzTgIoi9Egni4v+/Gy30uS+Ww4nfeuf8B000lSZnno1p/rqQNNtx4f sPui5ReCWV3qnbtgumhVs0PL6AdujRZhfOi06xnkQFFvesNk0Om2k9Gg7lUwNzisMRtYmrGASfsb NV8PoRdh2oG/5+GXQdZ6OiD6LIJOIQpseORO1RQgOfw326pmjsj2mIKEyvhOKOF4hNzC3GXdOFIc 8xkiWWd8W7XUYq21q+0MmnBjrdqv6uuwRGRO/gQAAP//AwBQSwMEFAAGAAgAAAAhACIu3ltvBAAA Kw4AABUAAABwcHQvc2xpZGVzL3NsaWRlNC54bWzUV11v4jgUfV9p/4OV5+Gz0AIqVECnq0qzHVRa zbPrOGBtYmdsh4FZzX/fY8ehWwpTmO7L9iENse/xvefeax9fXq2zlKy4NkLJYdSqNyPCJVOxkIth 9PhwU+tFxFgqY5oqyYfRhpvoavT7b5f5wKQxgbU0AzqMltbmg0bDsCXPqKmrnEuMJUpn1OKnXjRi Tb8BNUsb7WbzvJFRIaNgr4+xV0kiGL9WrMi4tCWI5im18NwsRW4qtPwYtFxzAxhv/cKlESJj8zR2 /03+oDl3b3L1h87n+Uz74bvVTBMRg6+ISJqBlqgRBsI0/1NiGl4aO+aLCokO1onORpd0gNjIehiB /I17wogO+NoSVn5kz1/Z8vOeuWz5cc/sRrUAPNgu6qIqI3odTrsK50HYlJPWNqpyKoXpJ8X+MkQq xOnCL8Njd6sKzMXs4PMlsZsczFgHFeaVg56Par4Bp54su56oeOMCf8J//5EOUmPndpNyTwjcpgOA 4wH6U+oqlMva4zwiTz4VsdDWM0VMZqcpp6joQKYdfVlSS4QhVJIxczVzdQl+LNITQLmMZ1TT+zew XcR0AF8QRuUzXktSD1N7VlE7VdKi8MgspYwvVRpzTdrvI1rEKJMqF6dw7LiUaNFxYVUiLEnlPGf3 PC48QcBs4s/nrsqKszg2Kdt0+OzZ0ViSHcqPSmawpt6nowB2Fw5pP8q2GEZGLiKyxdhXS2hNriVN j0L8KRLhK1cM1hWn1WKxwE7sSrT8rPRxjG2XqLgihmvBDVFJiWTKFTLs68nmRMx9BAAm4dp5jrPB YqHTmAhuwjt6ouU+Zx7HL1Yvu9O3KB6um1dpaI9D28eWv33wvL54gf8mSIiuTua3s5KfD+Tx9gPh ltV3wz206Rz06EV0+/vnoK3b7o5twi1IVVK+/QhDbT7xqlR5TLiwS+xgQqLCOGFuc8NJ5DKLIl4L Y3Hko5mgHhYE5awKa0QMgN3Jm93Z/3uqTiuafZUXK3SWVHa3aN5Ie8iY5IwbQ7VI/4uOh1wqUiRW YmuRTh2e3LrBLdcU76dG868FN7a+g/RmO8GJXzm9O9XpPU9d9d4V2ROK/t9H+Nn7jvBSK0FRAxqC +/sw+lpQjVMmgs50p7uXCF45OX31LgmVQLc78fp3u9dpt5vji9p1t39T61xMprXe9Vm/1u10x9et /nmzP27+iIKOMy5yCe/2CrBXgquUdW7H6TznCCs76wNZ+kluvMCqtDg2mE8Gwi33ErnQAqFMJv3z 9rQ3qU1aHYRy3b+ojW/Ou7Wb7lmnM530xtOzjz/get7qDJjmXvbfhusL1Hu4h2D01d0hE0wroxJb ZyprlJeQRq6+cZ0r4e8hrWa4zKwoDppur9dp9vH0usn76PNVeY1QqusFS/WfNP+88v2MWxPSPfWf cvSXYwNTn6dAbooMAy5wKwMDOYUxpj3I6j4SF7hNCRnzREhheUTQuRalNIwkRAXqSaqYP5TSPLtX ygY/PRJWDNDuLSyHVxTm6B8AAAD//wMAUEsDBBQABgAIAAAAIQCZ9pmu1QAAAL8BAAAqAAAAcHB0 L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGUyLnhtbC5yZWxzrJDBasMwDIbvg72D0X1WksMY o04vY9DDLqN7AGMriWliG0st69vPUAYJFHbZSfwS+vSh3f57mdWFCocUDbS6AUXRJR/iaODr+P70 AorFRm/nFMnAlRj2/ePD7pNmK3WJp5BZVUpkA5NIfkVkN9FiWadMsU6GVBYrNZYRs3UnOxJ2TfOM Zc2AfsNUB2+gHHwH6njN9fLf7DQMwdFbcueFotw5gTwHTxVoy0hiQOtbh2+l01UW8L5H+58eMQnx h2WhsrFZ9RlXof01w83b+x8AAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDYueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6 EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3 OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaL KU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD/ /wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDcueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+b YwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXi WcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxj Ip9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLx vgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHOE j8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LIC Qd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJT ryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95 LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw 4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7E sG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZ GsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsD BBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDUueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+ww b3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wp xWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCge naUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcB AAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDkueG1sLnJlbHOEj8EKwjAQ RO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv 4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak 1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfV NuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDEwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOW ZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vm QiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L 83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYA CAAAACEA1dGS8b4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQx MS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9 axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJ WYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNy plSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhAEqvdTnUAAAAvwEAACoA AABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTEueG1sLnJlbHOskMFqwzAMhu+DvYPR fVbSwxijTi9j0EMvpXsAYSuJaWIbyxvt29dQGAkUdtlJ/BL69KHt7jJP6oez+BgMtLoBxcFG58Ng 4Ov0+fIGSgoFR1MMbODKArvu+Wl75IlKXZLRJ1GVEsTAWEp6RxQ78kyiY+JQJ33MM5Ua84CJ7JkG xk3TvGJeMqBbMdXeGch7twF1uqZ6+W927Htv+SPa75lDeXACZfKOK5DywMWA1veO3EurqyzgY4/2 Pz1CLCwHksJ5ZbPoCy7Crxmu3t7dAAAA//8DAFBLAwQUAAYACAAAACEAEDOvZZ4HAABILwAAIQAA AHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxaa27bRhD+X6B3INifhSLxJZJC5MCP KA3gpEbsHGBNrkzWK5IlV66dokDu0Bv0Fm3/9Sg5SWdmdynKlhIZlgHbMGBI5O7s7O5887Zevrqc CeuC101eFmPbeTGwLV4kZZoXZ2P748mkF9lWI1mRMlEWfGxf8cZ+tfP9dy+rUSPSd6yRvLaAR9GM 2NjOpKxG/X6TZHzGmhdlxQuYm5b1jEl4rc/6ac1+A94z0XcHg2F/xvLC1uvrTdaX02me8IMymc94 IRWTmgsm4fxNlleN4VZtwq2qeQNsaPXSkXbgfsmxSPH79Ex9fuBTK08vQUqDgWPvvGQjuiffF7V1 wcTYPj1z7P7Oyz4uAWL9hIub6qTmHJ+Kizd1dVwd1fiSvL84qoEnsLStgs1AvsiAJjQZvRZAphgv LT8znNjoclrP8EQgHgtOCChe4ScsYiN+Ka1EDSaL0ST7eQVtkr1eQd03G8DV2k3xVupGN6/jmuuc 5FJw60iwhGelSEFXSER0Q7UMpFgdlsl5YxUl3BlFoa4KwjGM8f64VZVZ8qoCKUlkq+nUJJysaOkb kq85dCsVPwhB6Ug0bugPvWhZPpHrxkOcRyk5ju8N4AXPsmBU1Y18w8uZhQ9ju+aJJEVgF4eNVKSG hNBXB6lG8nKvTK8QjFP4BszB4mB9VtafbEu8LZqxHTu+D3tLeqGT2lbdnTldmpFivwSVgxWsSIDP 2E5kTWcpwNp257Kc5vpEakvcXDTyWF4JTmoB4LERiBU+4ECCocHzovfxGAx+JvcFZ+AQtArJnX2R J+eWLC2e5tLSdk8wgHsAliglSbIilrxIj1jNPlzjrEVEsjEyAeSUIq1XJ69VJ9Tlrja5CNBdtQkF ZGvTvotSOaA9qGAkXmN1S1rlB24QD72Hr1WoFrdSJLA4S1yQRtL176hYKD3Sq2ZJsUDJSG3Vh9mS PMYtdPmYJ2WRWoJfcLEBe9KxW7A/yfJ6c+6kDLfgPinntcw2PryvtHFjOCb5dCV3CCNbNWnfmPQB k8sBggRyV5NOJXixT+BhmZhq0yYYKUxgMLllvBh6AfxdM23X8bw2YHjDwHGDh2/ZS/GCTNVEBYoQ F8JBU2biDLy/sHEs5VP04yhOB90bjjWlyNNJLgS9YLq3SIPkpcqOZF5IlRiFwSKUtjkTBYsOH7Bt tRNNgC/Bg6hnHbZwL7L8qUgpa/o9cvb3w/hgr+fE8aDnO6+dXrwXT3qx7zjh64m760beHxBUKWlI QdNkPuPqdN8OerA9yUfueH03glTTcRbeAo6Ax9muUQTGKCZliXl1N9KRId/VLKaQIxCQv85ZDTto 01ABCTOoTU3Dc1zf5FKrbSOKgydtGybdenjWsV2dHBqdPAaL59b7+ez0mmaS07urZkIxCaxXKScp /q389jAIvK8r51N33KoSeHiq2TpuN/Jdd7Ab9g4CcNd+uLffiw68uBf4we6BA2VYvDtoHXeDmleA dqDHvY3f/vL57x++fP5nC16bihRVw8Oj6Qwkon7HKgvqfoiVEmp4CH1jOz2Hp9MzF8egEJaX8JSe wxNLEmg2AIV+MCMwr0ZaGs+MQOWjpnwzAomTGgnMCEQNNTI0I2CzmciLc8h/8Mu2pqX4SQ2YJ0xU qIVzyK7KuXybQgF7bYRCrOv4oR95Qz+GcnSErYr6bapreLBZs3qJFvKkBa2u0NbSgqxavjr1W0sL 8mlpdTxcSwuSa2m1h1pLCzJtaYc3JLN8N5B2Sxt+gxZwaGmp2bAk8WW+YYc2/gZf6Mm1fB1KSr/C eAk401zpiEIDn02tLK2powBZAn2n0KLQ3OUlNQ4aVBGq+ukV7VEnajpjxKhogd85YafHkC9SUwO1 QapeBWeHxV4NegmoY8+u0K9AkkEDAhqDR/MigW11f61K9rCPhj2i5CjR2SQdCbJFGNOzp/P30Jyk ZK3j86CfAnzPeY2NzU0TV2CCrLvpLR2UcsgptLHG9o+zX3pCIkSQ/7FrE5ypiaS5NpE0OLEuyV2W KjQQoSVxQ8QzVh+Obc93Y7xYXoBTBFH1zIDJ2e9b/iBK1eS4hsGkhHwfU20lpt06Z8K2qlwm2YTN cgFdNQ8sLclY3XCjWtARm+/DCA2P7S+f/1Ly6+CoYvl94Fisw7HorcGx6H0VRzIHFwsohVUIWKE3 bLFyowCKIXDYur563Fj9eQMrN7ovm9siVgiQdl3eAivT8e2A5UZUwjwNsG4alntvDnKLYCFCGiy/ A5ZutT5VsFZYFjrde4lmWwQLEdJgBQuw3EEQkqot3OATsqz//r3pBR8DVgiQxmrYwSpwfHJ6TxKr VekFpjMP3rAQIQ1W2AErDh0KuM9gfa0ZvVFOv0UviAhpsKIFWCpNX0oGn5AXfLSWhQhpsOIOWFE0 pBbis2U9JMtChKCIXqqPq1EpM1631TJUjkcKUl1Ddn/a0JbgmsR0L1S5di+FWaeSVc76UVay5rcz 26+FHpt8VlePptP1LJ81BZsX4s9j7qPz8dgUaHWR5ERuRLncswatqUwoW3rWIAhZa6qB0Fet0mcN WpOBQ0ZHfYhnAa3JeodB+OykqYnfZprd5BISz8U/wvBfwuYX8Dv/AwAA//8DAFBLAwQUAAYACAAA ACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4Lnht bC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWT ErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+ OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCY esoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBw dC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7S ehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDij tzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2 iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA //8DAFBLAwQUAAYACAAAACEAaaJfIR4BAADHBwAALAAAAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMv c2xpZGVNYXN0ZXIxLnhtbC5yZWxzxNXdasMgFAfw+8HeQc79YpK26Qc1vRmDwq5G9wASTz5YoqJ2 LG8/KQwSKI5CwJuAiuf8+CvmePoZevKNxnZKMsiSFAjKSolONgw+L28vOyDWcSl4ryQyGNHCqXx+ On5gz53fZNtOW+KrSMugdU4fKLVViwO3idIo/UqtzMCdH5qGal598QZpnqYFNdMaUM5qkrNgYM7C 97+M2nf+v7aq667CV1VdB5TuTgtq+07gOx/V1fmy3DToGCTJdN5OB7vE84Hel61iylYh2TambBuS ZfmSNOevGc4O8jZDb98s5FiU8eitykOybMmAHpUFMytiyopgZnFDC6a2iZnaJpiaf+vjPa1ZGrKt Y9LWIdk+pmz/J6Oz32/5CwAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9z bGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCR pl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgG TxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylO VkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8D AFBLAwQUAAYACAAAACEA0y7QoukEAAAVEgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQ4LnhtbMxY3XLaRhS+70zfYUe9Jmj1j8aQsaHuTeJ4CnmARVosNaufSguBdDqT12ofJ0/Sc1Za DDIJwvZFb0CIb789v99Z6ertNhNkw6s6LfKxQd+YBuF5VMRp/jA2Pi5uB4FBasnymIki52Njx2vj 7eTnn67KsBbxO7Yr1pIAR16HbGwkUpbhcFhHCc9Y/aYoeQ7/rYoqYxJ+Vg/DuGKfgTsTQ8s0vWHG 0txo11d91herVRrxWRGtM57LhqTigkmwv07SstZsZR+2suI10KjVxybJXQneFss/FluDKFi1gRvU mIDn0VzEJGcZ3JgWuQQG8jmVCZmyEu1QmLpcVJwjOt/8VpXz8r5SS+829xVJY6RqKYxh+0cLUz9z gMHFsLP8QTOxcLuqsskVCyEiZDs2IHE7/IRFLORbSaLmZvR4N0o+nMBGya8n0EO9AViw3xRyXjYe PXXH0u4sUik4oXuvGiiDpe+K6FNN8gL8RPcb96K7jSZDn5G+TEgTfolULa75U8VD42sVU23oPhKO 60NtqXBYvm26nZjYphnY1DYIRoZSz2oRhx43zGUotzdFvMOILuEbEsfyKCmgUJdNnEUt53InIM0s FBtBwSDCxAN0koAiYGHMV7/DrfrL2ACTwKaldnyPhxzD9QEPRJiFEAf4gKWCYSPyfPBxDo2Yyang DOhbn+RkKtLoE5EF4XEqyXtWS14RFTdoW7AM2aXaQ1HyPL5nFUOjDpkxFSyEnSG+2me4bLL9/ZxD EI+74F6wiCeFiMEI62UVkMZQv7pI+iffdn0XE4rNcCr7LqUUEE323cC1KZRC437TUMrtpg51JHT2 VWsdpqpNeSfTNlZfQ3kAgEurrdfDqggOsRoAWPsE1jnEagBgnRNYrLa9DRoAWPccVgMA653DagBg /XNYDQBscA6rAYAdncM2gFM9BCsJMOyb5YU9hZqqWqo+6qmmb1TzwIfeUhXuBW0851GRx0TwDRc9 6FVvXUC/SNKqP7tqiAvYb4t1BdOvr/EOFuYl9OnqJDuMuVdVM0er2QJTfShlKiAw9vWoetYwwwkC Eg6jIGFiZcAZAAROJVINNZQcdTFXFY/ii7d+NN2oY7u06fPHkX803hxvRE3vxQJHMla9U0eMNI/h tIOXaNpyfQeHQpXNA02jRzqFMxGx0Ikoby2VntG9+I70tKORLd+IOrgr6cV3pI0dHW35qO1Try/h 6Adaq/kCK0Cp72XgEV9Hj1s+ywrAvOfwdTRb8/mOGluX29fR9ZYPyXon5MjfjvZrPs/1n5eP/8d8 gM7Wpwl1wMBj7vfPVa5WohmT/EiJlHa+VIli+USHaHNawKeNk0IEPf7owcnzkFIBdXZdwcMRPuD8 NaKWP70ZOQPfs6yB47p0cGPadGDaU98MZtOp797+bbRn/RhclWnG8QkLhkPngPr06AtaoraUE3to BfAgSOnj4AQTkOV154Ons3JbFHjKPpwQLs60l+ZlJasmMX+uWQU7tDOCnjkFX5Kb142IryMyF2nM yd06W3bi4r1GXOBFA1CfDM2Z+XlJaPZlawWOZZnX/mDmjm4Hjn8zHQQzezRwHfd6RkeeObo292Vb o+c5WHdp1X77+s8v377++wo1qwSledkAl/huQpWiqN6z8sNGDV94GQP1NFW3Snj9AnFB6CMEOfTr nMl/AAAA//8DAFBLAwQUAAYACAAAACEAESBUEqECAAC6BgAAIQAAAHBwdC9zbGlkZUxheW91dHMv c2xpZGVMYXlvdXQ3LnhtbKxVW27bMBD8L9A7EOy3opedyILtwLaU/qSJUScH2EhUJISiVJJ27RYF cq32ODlJl5SVtGkKpKh/bGq1O9yZWVLj023NyYZJVTViQv0jjxImsiavxO2EXl+dORElSoPIgTeC TeiOKXo6fftm3MaK5+ewa9aaIIZQMUxoqXUbu67KSlaDOmpaJvBd0cgaND7KWzeX8Bmxa+4Gnnfs 1lAJuq+Xr6lviqLKWNJk65oJ3YFIxkFj/6qsWtWjta9BayVTCGOrf29J71pke8NB3FFi0+QGAz6d IvNsxXMioMbA3GaYoGqvJGNmJTbvZbtql9LmXmyWklS5qd3XUHf/Yp9mHwWm4cJ9Vn7bI0G8LWQ9 HUOMEpDthKJTO/OLRRCzrSZZF8yeoll5+UJuVqYvZLv9BtjB46aGVcfoTzpBTycBzciSQ8bKhudM Ev+RYFcFiHLeZHeKiAYpGyU6ptnFpsc19M1ObUk66XONg/cFTQReUNQPyfmWrFXIJNtFX69Qbquj 3s6bfGc0ucF/G4SYK73SO86sVsgI4gIdNKZ8jdJhGM3D1BmE6Ykz8LyRM/OjxEmDdOEtFkkaDL1v tG8KqeqqZmYMIJZoLNqPB4UJ53qF/dZ6wRngQdrb0jUFsZ6GbhDhtPr+GIXW2LxtwVon8iVI+PgM zCgEMfaKNHtOuOz8+LsrYe/KWdNo9OJXX4JD+FJo2RnzaQ0Sd+i96T3tjPwvb9hBFRn0iqx4lTNy sa5vnukSHkIXvA0R+kVprO5WkcONbRANgsCbnTjJcHTmDE7mCydKwpEzHAxniT869kazp7FVhrnA 7v51ah/uv797uP9xgJm1o9tdkLg0F6i9A7n8AO3lBk8zxPjFwHla2FCL34j9HfGUYjD6b870JwAA AP//AwBQSwMEFAAGAAgAAAAhALEwkejSAgAADAgAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl TGF5b3V0Ni54bWysVdtymzAQfe9M/0FDnwkXYwcY25nY2H3JxVMnH6CACEyERCXZNe10Jr/Vfk6+ pCsBSZqmM+mUFxDS7tGes7vs9ORQUbQnQpaczSzvyLUQYSnPSnY7s66v1nZoIakwyzDljMyshkjr ZP7+3bSOJc3OcMN3CgEGkzGeWYVSdew4Mi1IheURrwmDs5yLCiv4FLdOJvAXwK6o47vuxKlwyazO X7zFn+d5mZKEp7uKMNWCCEKxgvhlUdayR6vfglYLIgHGeP8ekmpqYKtKRcklo42FjKnYw6ZnzYF9 uqUZYriCjStthYyZPpH1lSBEr9j+o6i39UYYh4v9RqAy0wCdo+V0B52Z+WRgBgvnhfttj4TjQy6q +RTHoAU6zCxIWaOf4IRjclAobTfTp920uHzFNi1Wr1g7/QUQweOlmlXL6E86fk+n1cF7ZNWaYnA9 4+mdRIwDT02/pZde7HswzVnD1wV6Jnxn1x4aPXp7CZoasdRhwbNGE7+Bt9nEMZVqqxpKjCAQNo4B HB4gP8W6rgmzr7dQ15VaUoKh7jvx1HxJy/QOKY5IVip0jqUiApkqgC4AyCmooyA5HSRh2QYL/OkF suaHY7gZgu4jhGUr4d+FHPVCJlgRtKE4JQWnGUTgD6FppoDyV2gLTHMLChGqxDPEjbQ6Af+lcQ79 oKv7m+cvguV4srbXSbiyg9Dz7dCbeLabrKJFtBot1sfRd6tLdAZUVVkR3VRvSVGbeJ2EkeOH0P+e 95QTCEGjDJuVoM/KmnNdDc/zMhoiL7kSbWI+77CAG/rc9H0yQP0Pq8i4V2RLy4ygi11180KXYAhd YL4A9KvSmH4YuGz9MPB99/TYTsbR2g6OF0s7TEaRPQ7Gp4kXTdzo1H0sW6mZM4juX6v24f7Hh4f7 nwPUrPmhtJMGlnocmWFCxTmuL/fmjwczGOppabZqmLrdf/fJRGP0U3z+CwAA//8DAFBLAwQUAAYA CAAAACEAp8d5GGcFAACKGwAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbOxZ 25LaRhB9T1X+QaU8Y9BdUAsuFpa82LtbAX/AIA2LYt0iDSwklSr/VvI5/pJ0tzQgbrZgeXBVeAEh jo76Mn3U07p7v4pCZcmzPEjirqq9a6kKj73ED+KXrvppMmq4qpILFvssTGLeVdc8V9/3fv7pLu3k of+BrZOFUIAjzjusq86FSDvNZu7NecTyd0nKY/hvlmQRE/Aze2n6GXsF7ihs6q2W3YxYEKvl9Vmd 65PZLPD4MPEWEY9FQZLxkAmwP58HaS7Z0jpsacZzoKGrd00S6xS8Fa/JZDV5TZ6mv6sKgbMlnNbU HvjvjUNfiVkEJwZJlLIsyJOY/snTScY5YuLlr1k6Tp8zuuBx+ZwpgY8E5YVqs/yjhNHPGGBw0Ny7 /EUysc5qlkW9O9aBaCirrgpJW+MnXMQ6fCUUrzjpbc9686cjWG/+cATdlDcACzY3hXynhUeH7ujS nUkgQq5oG68KKINLPyTe51yJE/AT3S/c8x6Xkgx9Rvp0rpShR6oSV/xJ8ZD4HGJKwRKr+8Rfo+NT +KaTrBPmYizWIaQAjpehRglgHZ/PfitCWzkN3lbh4CTrgCnwAckKGdYBjxufxlAHkRiEnEGdlKEW vUEYeJ8VkSjcD4TykeWCZ4qgKORowB2wC0hlSclj/5llDIzYYcZosA7cGVyU/sBhEfDTYTc2Ycec P4fM4/Mk9MEC/RoZwHiqsFxhLcmEnUgERmtvSZqWAwVO61KzDEvTDDRpuzrNltnSXBAXXKO20XZs shnCUBCR+8WSkBGRGVZY7M0TUItpQVnNXplsJWLZB6qLIPahwPEQ7z5dPIKKkSHFWlDyP7uqbqKl U+lmZW3QoQ6rpySUXtVibR2yIhXaAWYaW9a2ZpIFdVg195AVqUpWc8uqGY5mI7gWLSF3Q4BcJa1V oXV1l2y4lBa5Slp7S6vrLpjwBmuRq6R1KrSOadA6vNRa5Cpp3S0tctZP2ZHYIldJ267Q2pbzppQh F2lJtSZI0fAmsOo20kV3v1zhUHBI4PIdhbtExUypYoMkFlCrO0JGqgGPWvmgOPNRgtU9Z+GslLFC YvCxSmHCg+rzBBNyWsZ0zTFdx/qGjBltS4PiQEQdHSMZqibq4Em1VaeCsgKAQykmVSXDEtpgJQCw UiIqWFKSDVYCACvrvorFVbnBSgBgZTGfxEoAYGWFnsRKAGBl2Z3ESgBgZS2dxEoAYIsCkZ0AxZdE cuPbj1FB1AzAhyxaev6e0ZaMuZfEvhLyJQ+PFOg+PdXFGfSTeZDVZy+f/LUVZ5QsMjGvbbxZVGR9 +mB2lB16k6t2Z5bUtcl+d0YWXy5qRX9cdGcocH8sWAZtZ6lxFG1qlWtrnG1aLR3MhU7sVK+mOaB8 t16tq956NeiXb71aVzX+j72aLTXtWK9GrdHlsnYoZaSTF0vZqX5tK2W3fg1jvtv/3Pq1EzOdb+54 9huqW7+GI7RiN7gfmx+1X3Oktg2Z4DubUBs7zMuFrejXfAEDxN3tqFbsqU7uR+mu+9MvOLkdWNIP 2t/PYBaNk+W/bOfhvq8P242HtqM1TPNeb/QfDLvh9vW+a7sje2Tbf6vlkNUHV0UQcRxo1xl4woaE bil6RlN3YfquadvtBZiALNftomFCWIzYR0mCs9XqlNO5Rl5mAjrnw2eP9p2R5zm5uW5E2jIi4zDw ufK4iKZ7caEJxFvXK7zdAeqjofnOGOWc0GyWre6aut7qO42h1R41TOd+0HCHRrthmVZ/qLXtVrvf 2izbHD2PwbpzV+3XL//88vXLv1dYszSfLt7ywCG+CiKJCLOPLH1a0mYU3oDBih3QqRTeeUFcELqF IId8h9b7DwAA//8DAFBLAwQUAAYACAAAACEA4FOekg0EAAC7EQAAIQAAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQ0LnhtbOxY3XLaOBS+35l9B4332sU2tjGeQIfyszdtkin0ARRbjr2VLa8k CHRnZ/pau4/TJ+mRbBFCyAIbLnOTGPnTJ53v/OhYV+/XJUUrwkXBqoHlvnMsRKqEpUV1P7C+LGZ2 ZCEhcZViyioysDZEWO+Hv/5yVceCph/xhi0lAo5KxHhg5VLWcacjkpyUWLxjNangXcZ4iSX85Ped lOMH4C5px3OcsFPiorLa+fyU+SzLioRMWLIsSSUbEk4olrB/kRe1MGz1KWw1JwJo9OynW5KbGqyV D+zm7g8LaRxfwYhrDcH0ZE5TVOESBhYPDI1ZJYFGvxL1ghOiQNXqd17P61uuZ1yvbjkqUsXQzrQ6 7YsWpn9WAIOHzt70e8OE43XGy+EVjkEJtB5Y4LCN+guTcEzWEiXNYPI4muQ3B7BJPj2A7pgFYAfb RcHXdWPRc3M8Y86ikJQgd2tVA8Uw9SNLvgpUMbBTmd+Yl1yvDJmyWdHXOWplV1Qtrnmp9TB4AZpq seT6A0s3yvA7+K8HcUyFnMsNJVoQ2DaOgRz+gPwUq6gmlf1lDlFdyjElGKK+FU8Ox7RIviLJEEkL iT5hIQlHUtslFOUVqCPBOS0lqdJbzPHnPWZlH45hZdi02SE8NhK+LGTXCNlGE7qlOCE5oylswnud rOIbZAOmmQURCOFhfPCCtkquvSjzgx7kqw41N3Qc9az1NQHnO90Ixi2kws4PvKAfdrUDDZMWoHGz 0eSg19TadEVdnTY4Tkmm5FX796JmUdB2BwCP3gGsv4s1AMB2D2CdXawBANZ/jnWf7MEAABscwxoA YMNjWAMAbO8Y1gAAGx3DGgBg+8ewDUBp3aaTcozOJpiJgGGbNq/MLhVBOrnEk+xqMmh/SR24ZyT0 nCSsShElK0JPoNdZdgb9Ii/46ew6Ic5gn7Ell/nJm/ebjDzZHbMiO8gOp8hF65r/X3VNawLnqTkM zjwu9uqa9p8+KlSl0Q+7Z8ahuhb60VthgxPhrbDFb4Vt2wi9FbYTGrbAFLYJluRJt6ZL8f+vak0T nEroUff6Nu2glwvcOU1xBl8w6nPkr9GkOwqmztSejrye7fecvt2fdF175oxGYX/iRL2p/7fVduYp mCqLkqjPIDjK9jrf5z015JTuE+Ww2/Ei+Fxz3cdzGLagWC573ITGKzPGVPu+20UH6oh8rV8yyRvH /LnEHFYwPfWRpvoc31xWkZ5RZE6LlKDrZXm3p0t4CV3gOgCoD0pz5Fw+R5pt2HqR73nOqGdPgv4M wvbD2I4m3b4d+MFo4vZDpz9ytmErlOUV7O7cqP3x/Z/ffnz/9wIxqwtKczUAj+oCQYci5Z9wfbPS XRtcmUA8jfVQDZckoIuCPkIUh7l0Gf4EAAD//wMAUEsDBBQABgAIAAAAIQB/aCl1gwQAAKwQAAAh AAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1szFjbbttGEH0v0H9YsM+KSIoXibAU yFbUPjiOETkfsCZXFpHlpeRalVIUyG+1n5MvyZldriS7LqLahuEXidrLzJkzZ3aHOnm7KSRbi6bN q3LseG9ch4kyrbK8vBk7n67mvaHDWsXLjMuqFGNnK1rn7eTnn07qpJXZOd9Wt4rBRtkmfOyslKqT fr9NV6Lg7ZuqFiXmllVTcIWfzU0/a/gfsF3Ivu+6Ub/geel0+5tj9lfLZZ6KWZXeFqJUxkgjJFfA 367yurXW6mOs1Y1oYUbvvgtJbWtE24r0N8Ezh+mFzRpDnjNB7OlCZqzkBQYWIiXnjBaKRs+29VUj BK0r17829aK+bPSmi/Vlw/KMjHSbnX430S3TP0ssw0P/3vYba4knm2VTTE54AjbYZuwgaVv6xCae iI1iqRlM96Pp6sMDa9PVuwdW960DINg5Rb5rE9G/w/FtOFe5koJ5u6jMUo6t51X6uWVlhTgpfBNe erG2xihmMl+vmKFekalunZnUfNj1rebUAt0xEfv+wBtoOoLAjUbuPVLiOPYDDDKixhtEvhuH2om1 BCfGdJ2ozWmVbYnSa3wjc7xMVxVUqmgHT2SrFmorkWc8r6UHRIzLG5SRhAp4konlRwy1X8YOXMLn tU58ysEAl7Jz2+1Euu9aBNk8ASX4gBHJqR5F2fu0QD0W6kwKDkdddGpyJvP0M1MVE1mu2HveKtEw TSGqFxjJutI+tElRZpe84QTv0DJlhSfwDBZs9JoQysx/px98m1K4Iu1dSp6KVSVRDMynIFEtNs+P UgKx76BsoGkrnEcJwh+5UQxx6OTZKrkriNB1vWHcZcYU2TGCuDY2HxJEwZtzXaB5meGkoUfK6fXt BY5TjeRAJjgSzXRbyTyb51LSWn2aijPZsDWXUN+GjiCkMy+VGYkBWysBydst1qk8sIM540lP7FSn peuTdA3SIIyBAnQfAdcbviBcwkhhA/lgD3fkocyPhRu9IFzC2MEN9nC9QewRiuPopci0AF5ADQSy wxse4B36Q0ry68NLIDu80R6v7w9B72vESyA7vPEB3jgYHF9uL6kHAtnhHe7xEtjj6+0l8RLIDu/o AG8Uxq+z3gikOYkPugh95xN6HHK7y12H9fgegC463QK0d3qAx9zzgb3nZ1yJO/e8vlSfes9nCq0N mqUVl0t735trjRphTRc9LDRzpk3T3YXtVGyfpm9VexfrH5rXJTp26r3/PD2No2k0m/ZmwSjqBYP5 u97Uj2a9+cg9i+ZuGLr+/C+na0MzhKryQpg798dpADjtUk0GfX+I9xPP2/MOCKTR5+2+QpuVeVVR 13fYfwXUmDw1L0vVmMT8fssbeLC5+UEzpj0fmZvnZSSyjCzQRQl2cVtc3+NF9/xP5QXvvzD9IDW6 70Xn+Jyy9YeB77vTuDcLR/NeEJ+e9YazwagXBuF05o0idzR1d7JtKfIS6Ehv/0e1377+/cu3r/88 g2Z142zeg/FIL8xairJ5z+sPa32q4T8C6AmdLYZq/CsAydDS/RKyYf9lmHwHAAD//wMAUEsDBBQA BgAIAAAAIQCkCQg9RgMAAOkKAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDIueG1s rFbtbtowFP0/ae9gZb/TQAgQIqACUvZnbdGgD+AmTpPVsTPbMNg0qa+1PU6fZNdOQlfKJBj8yYdz fXzvuSfH7l+uc4pWRMiMs4HVvGhYiLCIxxl7GFh3i6ntW0gqzGJMOSMDa0OkdTl8/65fBJLGn/CG LxUCDCYDPLBSpYrAcWSUkhzLC14QBt8SLnKs4FU8OLHA3wA7p47baHScHGfMquaLQ+bzJMkiEvJo mROmShBBKFaQv0yzQtZoxSFohSASYMzs1ympTQHV8vsvFjJBYgWvTWsIdUdzGiOGcxhYZIoSBOyg CWcKkEyALBaCEB3KVh9FMS9mwsy7Wc0EymKNU823nOpDFWZeGYTBg7Mz/aFGwsE6EfmwjwMgA60H FvRso68wCQdkrVBUDkYvo1F6uyc2Sq/2RDv1ApDBdlFod1FW9LYcty6npKO5raoMxTD1E48eJWIc 6tTll+VFN6saTNes4YsUlcwrzWwVV340fNTxEjg1ZKn1mMcbXfg93M0gDqhUc7WhxBACaeMAwOEC 9FOshU2YfTcHYedqQgkG4VfkqeGEZtEjUhyROFPoGktFBDLJwG8AkH1gR0FzKkjC4hkW+PMOsq4P B7AyJF1nCI8lhf8mslUTWakJzSiOSMppDEm4p9GaxSCKmvkzMAoNQHRFt9SdyLCWrSFYvmK4ZNFQ CZd6SVPGEU2dk4jDP0rJitAD4A3TR8Av0kwcjt7SfTwCfcqXQqUHJ+8dC58le9HBSc6qba/WdogV eSVsQwjYau0G/+UXsYLf+Tt4PqaJBSarxW5+amMb2lxO8o8ELF8794+uN+mE49C3/bHr2Z7fvLLH o27Hnk467Z7rhj7saj+tysRiKFVlOdH7BnR8xyTe2k9patpgWo7rw+bWbL7IFVLQKOftSrvuypRz 7XR/G45R0ql9SZQoG/N1iQWsUPfmjE50XkY6NSNzmsUE3Szz+x1e2qcZcbm/weEJoPdSY+znzLJ1 fc91G6OuHbZ7U9vrjie2H7Z6dttrj8Jmr9PojRpb2UpdOYPsjlXt89OvD89Pv8+gWbNZlqcoeNQn LnNQouIaF7crs9fAARP0NDFDBRwp9Z4LoS8hGqM+og7/AAAA//8DAFBLAwQUAAYACAAAACEANxU8 WzEEAABYEAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbMxY224bNxB9L9B/ ILbPivZ+g6XAlqK+OI4ROR9A71LWItxLSUqVWhTIb7Wfky/pDLnUyo6KuIVQ6EXmcoezZ+bMcGZ8 9XZXc7JlQlZtM3G8N65DWFO0ZdU8TZxPD4tR6hCpaFNS3jZs4uyZdN5Of/zhqsslL2/pvt0oAjoa mdOJs1aqy8djWaxZTeWbtmMNvFu1oqYKHsXTuBT0V9Bd87HvuvG4plXj9OfFa863q1VVsHlbbGrW KKNEME4V4JfrqpNWW/cabZ1gEtTo088hqX0H1qpKceYQLSa2sOE5U7C8WPKSNLSGjQeUIEtelUy/ kt2DYAyFmu3Polt290KfuNveC1KVqKE/6Yz7F72YfmxADBbjF8efrCaa71ainl7RHBxBdhMH+Nrj LxyiOdspUpjNYtgt1h9OyBbrdyekx/YDgODwUaC6MxZ9a45vzTGO8A5WGVEKR2/b4rMkTQt2ovnG vOJua5Whzai+WxPj9UIJra0XNe+1S+wRqd1qsR6cEadR6hqP+F7ghn703C9JkvghCqB3vDBxXSNx bLVR3eVqd9OWe/TqI/zVrNCcS7VUe860t8EnNAfk8APccooZw5rRpyVkTK1mnFHIqJ4ZNZ3xqvhM VEtYWSnynkrFBFE6eiSqvAIQCpjvVbKmvKeCfnyhGZ1Hc/gyuMMihKXh559ZCixLy82j+aZ/DqLk 5tEQBZENYWe5fT1hXpB4cc9YkKYx3AnPGYuBLk2pZiyJfJQ2TjCJoI038WP9cZIxpIlvuQeBQ2oq bnXmVE0J2a+XlD8BWxB5kMWgYHMHt51muWQrIAE3ZQtZvqg41w94xbEZF2RLOVwUO7wZgMGqUWYn idwDVH0forBm70gPcGn1w7LHh3pg6Q9QwyhBz5DLw4sge7zBgDfzQp1ml4cXQfZ4wwHvIQwvDzCi 7AFHR4BTP9VpcXmAEWUPOB4A+34KmXuRIYwoe8DJEeAkDC405xBlDzgdACPaC006RNkDzo4Ax1Gi 7/7Li2FEqa9qW+8R/RnKPdTL/6vih7biz6li5J7Tgq1bXkLPEZyj8pcKmpzfoMWmfAV1SVd/U5ix c9Xew8VSOxL7E91ADT3LyRo9dFUr6K+xWf49WSw8aNoWo/m7JB6FSRCPrmfZzciN5nG6yDLP82d/ OH3fWIKpqqqZKcXfb8oMKGy7grGfwizheUMXBhCQ9fP2YZFlZdG22P8d8xKeg5cVNDCamF82VMAX LDffac3A86/m5rweia1H9AhF7jb14wu/6B4eZi47MPynkQJmVVB90jW6E9bTxfnC1k9D33evk9E8 yhYQtjezUToPslEURtdzL4vd7No9hK3E4bEBdBhv/yZqv37586evX/46Q8zqLtoMrrDE8VbPply8 p92Hrb68YZ6HeIIeFrY6mOCxCQfRQQR12P8ITP8GAAD//wMAUEsDBBQABgAIAAAAIQAYKIR5XgMA ACALAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEwLnhtbKxWzXLaMBC+d6bvoHHP jsFAAh4ggyH0kh+mkN4VW449kSVXEi6005m8Vvs4eZKuZIuUlMxAwsUYeffT7re7n9Q/X+UUlUTI jLOB0zxpOIiwiMcZux84t4up23WQVJjFmHJGBs6aSOd8+PFDvwgkjS/xmi8VAgwmAzxwUqWKwPNk lJIcyxNeEAbfEi5yrOCvuPdigb8Ddk49v9E49XKcMaf2F/v48yTJIjLh0TInTFUgglCsIH6ZZoW0 aMU+aIUgEmCM93ZIal1AtkCMWqwcZOxECStNZwipR3MaI4ZzWFhkihIEBKGvYJxFmKIFWSljJouF IEQ7sPKzKObFTBjv63ImUBZrtBrF8eoPtZn5y8AMXrwX7vcWCQerROTDPg6AFbQaOFC8tX6CEw4g CBRVi9HzapTe7LCN0osd1p7dACLYbAp1L6qM/k/Ht+lUpDQ3WVWmGFwvefQgEeOQp06/Si+6Li2Y zlnDFymqSqA0v7Vd9dHwYe0lcGrIUquQx2ud+B38mkUcUKnmak2JIQTCxgGAwwPop1h3OGHu7Rw6 PFdjSjBMQE2eGo5pFj0gxRGJM4WusFREIBMMzANA9oEdBcWpIQmLZ1jgLy+QdX44gJ0haBshvFYU vk5kyxK51VNoRnFEUk5jCMU/BrmaKgdxkcEQVN3uQF9C09jKHMK4lhFAIVgHraPbxT+UC9GSboh+ Zz10k5tyyK16VJwb4uFhtzRJHdACcxJxmGtKSkL3gDcVOQB+kWZif/RWxejefE35Uqh07+Dbh8Jn yU500J2jTkLbTsIEK7I1AIYQkGKrHW9Sl1jB8P+AowLTxLa+kQAjMlqK3qU2CRwTWud/Tv2w22qN J24Ydi/c9mh04YbNacvtNEZh52zSC3v+9JdTS14MqaosJ/qs2UesKgnUctTy/C6cic3mc7tCCBrl uFXp2KpMOde6+K8wmU56b10SJarCfFtiATvY2rxFl15RouMycmoZmdMsJuh6md+94KVzDMGGOxdA 76TGyM+R29bvtn2/MTpzJ53e1G2fhWO3O2n13E67M5o0e6eN3qixaVupM2cQ3aFd+/T4+9PT458j 9Kw5Wqs7F7zqW5q5VlFxhYub0mgn3Euhn8ZmqYCbqD6hwfTZRGPYm+3wLwAAAP//AwBQSwMEFAAG AAgAAAAhAFa8LnumBAAAhBEAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OS54bWys WNuS2jgQfd+q/QeV99kBG99rIDUDw75MJlQgHyBsMXZFvqwtCGRrq/Jbu5+TL0m3bAGeMBvG8QsY 0zpSd58+3fbN233KyY6VVZJnY814M9QIy8I8SrKnsfZxNdc9jVSCZhHlecbG2oFV2tvJ77/dFEHF owd6yLeCAEZWBXSsxUIUwWBQhTFLafUmL1gG/23yMqUCfpZPg6iknwE75QNzOHQGKU0yrVlfXrM+ 32ySkM3ycJuyTNQgJeNUwPmrOCkqhVZcg1aUrAIYubp9JHEowNsiCVd7jUizcgc3DG0CnodLHpGM pnBjkYRiWzLyORExmdICzyFtqmJVMobW2e7PslgWi1IufdwtSpJECNVAaIPmj8ZM/szADC4Gz5Y/ KSQa7DdlOrmhAUSE7McaJO6An7CIBmwvSFjfDE93w/j9Bdswvr9gPVAbwAmOm0LOi9qjH90xlTur RHBGjKNXtSmFpQ95+KkiWQ5+ovu1e+HjToGhzwhfxKQOv0Coxq7+U8ZD2Vcypuqgx0gYrm+aHvAW PLc8YNnwWVRsy3MsuEkwNrbjuCNPbqKQYJMaugjE/i6PDhjSNXxD5mgWxjkwdY0raMArsRQHDnmG 6x034ESE8icoJQ4soEHENh/gVvVlrAHfYcu18vxoD0lu40CIaQCBgA9YyilWIsv0j0uoxFRMOaMA 37gkJlOehJ+IyAmLEkHe0UqwksjAQd3CyRBdyD0kJMuiBS0pHuocGXNBA9gZfFc+yzBgPl5O+kgl XZXBgtOQxTmP4BAmhgiKRSW4EwWgAjUoF+CyIkw3IjiG6bp2nTRVHS0eWIaBZLmWCC9mP6Xlg6zG JItAWvASU7nePoJ+ylVnnBgBKZodG/agLVyaSKQayrJdtCLX4JknDxqQBm90wvMNS5L/Kjy0rLkB eAjS4FknPGPkGlhi1x0Qi+AIiCgNoH0G6EH1dgNElAbQOQGCGsABO50QURpA9wzQtWTmOriMKA2g dwJEtOuT0oohojSA/hmgY7sdk4IolzWpX+2wlHassB7PhWOEDPlV4UC9BsEE4Y0p3zQaIiVJ9hDp IzbXpXRXKb5qARebiT2CVlH3ilOLbYmIN4TWUm+ikP6nmUg1uNRBXqUhRqtGsQM1dOioIUZLkxCk weuoIUaLrj1oiN+zhLTwelCQFl4PAtLC60E/Wng9yEcL72X1ACIRaCLH0UXSqvuEg6IhB5yqNeF0 mWJspUQzKlhLiaw+lCgSP+iQUTdB1J+LQiT1T81havZsyYX8ISfFDTyL4PPE3/bMdWaeNdPnrnGn W3PX1/1b19XN+9n83nQ9mIDu/tGa0ToCV0WSMnyguWbQhOzJLcVkNDA9eO4yjFPc4QiI0m9/cFRW 5nmOM+15h5CD3K92iI0o68T8taUl7KDmzJ8Mmq/JTb8RcVVEljyJGHncputncXH64Cs81wP0xdD8 pH++JjRH2pqeZZrDW1ef2f5ct9y7qe7NRr5uW/btzPCdoX87PNK2Qs8zON1rWfvt679/fPv6Xw+c lQ29fraHS3wVIIcVXr6jxfudVDV49wF8mspbBbztgLig6ckEMdTbk8l3AAAA//8DAFBLAwQUAAYA CAAAACEAJB7XT6oDAAAADAAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWy0 Vt2O0zoQvkfiHaxwHZLmr2m0Leq2W27YZXVazr1J3E2EYwfbLS0IidfiPA5PcsZO3GW7RbRsuUnT eObzzPfNjH3xalNTtCZCVpwNnd5L30GE5byo2N3QebeYuamDpMKswJQzMnS2RDqvRs+fXTSZpMUb vOUrhQCDyQwPnVKpJvM8mZekxvIlbwiDtSUXNVbwV9x5hcCfALumXuD7iVfjijmdvzjGny+XVU6m PF/VhKkWRBCKFcQvy6qRFq05Bq0RRAKM8X4Ykto2kC0QoxaVomTMisXGQcZerGGl54yAgnxOC8Rw DR/+BdMqxxQZewSMoQXZKGMmm4UgRDuw9WvRzJtbYbxv1rcCVYVG61Acr1vozMxfBmbw4u2531kk nG2Woh5d4AzYQZuhAyJu9ROccAZBoLz9mN9/zcu3B2zz8uqAtWc3gAh2m4L+TZvR43QCm84eKb1d eq0PBow3PP8gEeOQsOahzTO/WVtUnbzepylRq4nSejiIiwqUayXqvFpTQ5P1loZqG/+OoCQJBpHf 0hT0oyRMH3IV+HHfrGvG4jTuxUFsNrFIsEkL3WRqc8mLrWb6PfyCoLpohg7BOvkWlko1V1tKjB7A Gs4gJXiAMcW60Qhz382h0Wo1oQRDI3baqdGEVvkHpDgiRaXQNZaKCGQogLYEyAsQR0FtdJCEFbdY 4H/2kDWrOIOdIW4br0lBM/trHcPHOupquqU4JyWnBYQS6AyhEaxgfySpJm5PUWgLqFlbD8crG8V9 GCym/g8Jm/i9QarX/5awUG+IrulOwScKrek2OssHQrdiGkXhYbc0bJ1QW3OScxhTlKwJPQLeSH0C /KKsxPHoYdsqR/M14yuhyqODj06Fr5YH0WGenrXFIttiU6zIg84yhDy1swoFU+UzHIWYLp2up8xs MVNST1bz8vO4NP1sh4QdamZyPR5jSzj+9Pn1JYx9/zK6CtzpOJi4URSl7jjsp24Y9mdX/myaXKXJ V6eb4AWkqqqa6DP0mCkIBW72V6PQC1I483u9+3KFEDTKeVWJrSozzvXA/XnimUp6qi5LJVphPq6w gB2sNr8ZeKdoc15GEsvInFYFQTer+v0eL+aAfCovcKcE6IPUmPFz5rIN0igI/HHfncaDmRv1Lydu Og0HbhzF42lvkPiDsb8rW6kzZxDdqVX749v3Fz++/XeGmjVndnuXhFd9+zSHLxXXuHm7NrMT7t1Q TxPzqYGbNpSMNr030Rj25j76HwAA//8DAFBLAwQUAAYACAAAACEAN7HtyWMCAADIBQAAHwAAAHBw dC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlMS54bWysVNtuGjEQfa/Uf7D8vlluIbBiiQgkVaSWoJB8 gOP1XlTfahsKrfrvHXt3SZqkJa36ArNzP2fGMznfCY62zNhKyRR3TzoYMUlVVskixfd3V9EII+uI zAhXkqV4zyw+n75/N9GJVI5ZBPHSJiTFpXM6iWNLSyaIPVGaSbDlygji4NMUcWbIV8greNzrdIax IJXETbx5S7zK84qyhaIbwaSrkxjGiYPebVlp22bTb8mmDbOQJkT/0tIUsNE1z/y/1XeGMS/J7Qej 13plgnm5XRlUZcAYRpIIIAbHjaFxC58S3ECIn4UXbSaS7HIjphOSADa0SzHQv/e/EEQStnOI1kr6 qKXlzSu+tLx8xTtuC0AHh6IeVY3oJZxeC2fNq4yha0EKhlacUFYqnjGDugecdTCBZB8V/WyRVIC8 JkTdKtdI85LIgs2sZjSoajboctvW9hT5bnSJ3F4DkZZn16LwZQJt3hqENsDCDGpjDeP3YPotmGXY 1KcwesdhHO/0QWV7DFsAIwq0/LFfnbjdBQT4wfpAj4vAGzJitnEqr5yv99TErVu7PWegJwkMDPZB ZitiyC2sHgdWU8xkdL8OTAUPqN/WAPEYO4OWnXrUy414gPk+Jan/P0iCcUJqOCLfUvxlQ4xjpuUs rPlfkhbYeElNzrPwHL8vOqfdQX+0iGbjq1E0GI7PovFifhEthoPLeed00O0Nz37gw6rBkkvozrNr ntGKrHBzzgicxeY91otHEjft+lG5MDCo/G+zCSOqrwuI7cGh3Hwi+mYbtgPuKNA1DyoNl7NZyUcX T57f7elPAAAA//8DAFBLAwQUAAYACAAAACEAYYsxDG0CAADSBQAAHwAAAHBwdC9ub3Rlc1NsaWRl cy9ub3Rlc1NsaWRlMi54bWysVNluGjEUfa/Uf7D8Phm2EBgxRASSKlJLUEg+wPF4FtVbbUOhVf+9 1x6G0ISGVOoLeHzXc871HV1uBEdrZmylZIrbZy2MmKQqq2SR4seHm2iAkXVEZoQryVK8ZRZfjj9+ GOlEKscsgnhpE5Li0jmdxLGlJRPEninNJNhyZQRx8GmKODPkO+QVPO60Wv1YkEriXbx5T7zK84qy maIrwaSrkxjGiYPebVlp22TT78mmDbOQJkT/0dIYsNElz/y/1Q+GMX+S609GL/XCBPN8vTCoyoAx jCQRQAyOd4adW/iU4AaH+EV40WQiySY3YjwiCWBDmxQD/Vv/C0EkYRuHaH1Jn29peXfEl5bXR7zj pgB0sC/qUdWIXsPpNHCWvMoYuhWkYGjBCWWl4hkzqL3HWQcTSPZZ0a8WSQXIa0LUvXK707QksmAT qxkNVzUbdL5uanuKfDe6RG6rgUjLs1tR+DKBNm8NhybAgga1sYbxdzDdBsw8TOohjM5pGKc7fVLZ FsMUgESBljf71YnbXEGAF9YHelwE3pARk5VTeeV8vUMTt27ptpzBPUlAMJgHmS2IIfcwehxYTTGT 0eMSo6wyrpkPSAG+0ElTDY6neOo1PNWiz1fiCZQ+pKv7P+gCYSE1rJMfKf62IsYx07AXBv4f6Qu8 vCYp51l4mD9nrfN2rzuYRZPhzSDq9YcX0XA2vYpm/d71tHXea3f6F7/wfuhg3CV053k2Lwm2wk05 I7Agdy+zHkGSuHHHi+aCdFD5DZVqeY9qEySq9wwcm9VDuflC9N06zAlsVKBrGq407FCfDVyfXTx5 fsrHvwEAAP//AwBQSwMEFAAGAAgAAAAhALTPWBm7AAAAJAEAACwAAABwcHQvbm90ZXNNYXN0ZXJz L19yZWxzL25vdGVzTWFzdGVyMS54bWwucmVsc4SPwQrCMBBE74L/EPZu0vYgIk16EaFXqR8Q0m0a bJOQRLF/b6AXC4KXhZll38zWzXueyAtDNM5yKGkBBK1yvbGaw727Hk5AYpK2l5OzyGHBCI3Y7+ob TjLlozgaH0mm2MhhTMmfGYtqxFlG6jzavBlcmGXKMmjmpXpIjawqiiML3wwQGyZpew6h7Usg3eJz 8n+2Gwaj8OLUc0abfkSwlHthBsqgMXGgdHXWWdHcFZio2eY38QEAAP//AwBQSwMEFAAGAAgAAAAh AKFV12Z4BgAAAB4AACEAAABwcHQvbm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVyMS54bWzsWetu2zYU /j9g7yBoPwfXli3LshGn8CVuA6RtUKcPQEu0LYQiNZJOkxYF+lrd4/RJdg4vviTpardZsa1BAYfi 5ZDn43cuPD16el2y4IpKVQjeD6MnjTCgPBN5wRf98M3FpJaGgdKE54QJTvvhDVXh0+Nffzmqelxo ql4QpakMQApXPdIPl1pXvXpdZUtaEvVEVJTD2FzIkmj4lIt6LslbkF6yerPRSOolKXjo1st91ov5 vMjoWGSrknJthUjKiAYN1LKolJdW7SOtklSBGLN650jHoGE2ZTn+nS3s72s6D4r8GnBqNKLw+Ij0 jJ50xGRwRVg/nC2isH58VMclMNm1cLGqLiSl2OJXz2Q1rc4lfmQvr84lyASRYcBJCQijADPgpplP DtOs4J3lCy+J9K7nssQTATwBnBDu8QZ/YRHp0WsdZLYz2/Rmy1f3zM2WJ/fMrvsNQLX1pqiV1eiu Ok2vznNKciDIOSMZXQqGbYORUdGuAxirM5FdqoALUBqxsLoCOl4yAoB7VctA31QA0zKXwMx3/fCP FZFAQbfEzoNT8vVSZbD2Cvw9Qs1uJ0obAB7iFLc7QFEjeLO6kko/o6IMsNEPJc20YQK5OlMaj016 foq5frt71dPXQ5Hf4G3M4C9cOhgdrF8K+S4M2ClX/bAbxTFsrc2H2TwM5PbIbGdEs5EAzrk7ZkpP 9Q0DipEeu2IRKB0QtgCjZuZ8OZ2/hi5ELNpo5WaaY29LgHsF2vD8nEiCyxhBf0B57c3U4QEzAGWv FTQtF77MiJZnxJhousOHJor8Xj7kOnS2eTATWmkaJxGcb2Mb3mL+j3yQ38qHOcuNq3rfaZ+cxIOT bi1qDMa1eDIY1gbxCGLFcDgcp8NodNKNPwCRjaHmcN26KOmkWKwkfbWy5iJvkSpQpR4xSoCvjtBA YOO89HGr3kzBz0cRGpc2XIWjPDxDY8/QKStyGpyWZLFL1NbXiQou7LUAu0Z3LkZLMBs6UBU4if28 mmL5ablwTDZ2YVwZ+j7T8O7wCz4tiuJWA90XMDlJ2+jJDIaeztajOffWiptdnGydlo8f3nnt5d8I JAGTgjGzCePBW3QuHZCJl6MEwIij+IFiN2ESgsGl23drFtwu40bRH+A0A8IzcL79MNMmdsDezoMa Zf4BB9j29HqJidOOB4y/Tiy8pS0fiQHuVkTEuLIbEq1DNKw9iEaOOsiiuAX/btOoHacJdtooCaRz RFtnCZsYuBeN4HA/4MaRhhwS0cFKi3nhYrUNxjh09/oxhEKAXHskMELS+7rj0scjVmSXgRYBzQsd uBRZoxEqDNFq48fQrgEsYyHmx29pUiDYbd8tpzQTPA8YvaJsD/HGtRwg/mJZyP2lG8YdIH0iVlIv 9z68sZZDxBfze6U/dIaTeAOfCLDw3Zy3/RAWPgdXtZPzWgM3eBxk4DZCpGDnTch7jMPzIeI/mfGs nfnMKuNtGa3nX5kMdzxVbKrxclXObhEmeQjCQDoBou/jjOHjQZzZzpJ/RuZ8f9o8brQhP0vHtUF3 ktbipNupdcejYW2cxCejRjuOmklnnTYrzEE5XN5+EWCTLX/++Om3zx//3ASBb86VTVj2ZQvwD2cK ku/KVBNWsuiH74fDbtIcpcPaMIontXgMCg0mSbs2abfieDRMB6PWyQdQoIriXiapKbKc5rbYA4UO V/WB0TuVmrLIpFBirp9koqzbkk+9Em+prERhqj5Rw5WOTOEFnrRRlKadyPtCOK5JmPyxQRdfzcmY fEGqAGo18DbWkKjra2jll9CaLZrYB8ULfQ2t/BJaJMugQAQzXMP3wLjtWc9p+R54StohUMw1fE/b 90A2aIcS3wPhY8kKfglg4J8wmAv23Hb4lvUJpvB257FfEnmGqcr61R/Ak/+CzKbw4jeVBRiS2mQz ASVnfChhJ9AZK2fcfcIUfLJAee58xe2bBel3u3YQXFKJ1UKsI+D4Vg5/pyQG4OKpIcvZmWV2NS/E ORSG+uHvJa8xbb03JbcGKLEDmbo1kCkn257QbLMuaRjX38QkzkLjyjmP+DAExYXG1gYfTxJfNfp5 +YOgOHziDT5RqxMl+Op5BAhRcQC1twBKm6kpnj4ChKg4gJINQM1mCgR6ZBC4aETFAdTZAqgTtzCo PJoYQ1QcQOkGIETHVF4eTQxRcQB1twBK2p1HJ21SH0TF5MDb+SI++Tb/b3v8FwAAAP//AwBQSwME FAAGAAgAAAAhAPnPCTmDBgAAXBsAABQAAABwcHQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3 IHRvYyd2Ggd1itixm61NG8Ruhx5piZZYU6JA0kl9G9rjgAHDumGXAbvtMGwr0AK7dJ8mW4etA/oV 9khKshjLSNIG27DFh0Qif3z/3+Mjdf3Go5ihQyIk5Unbq1+teYgkPg9oEra9e8P+lQ0PSYWTADOe kLY3I9K7sfX+e9fxpopITBCsT+QmbnuRUunmyor0YRjLqzwlCcyNuYixglcRrgQCHwHdmK2s1mrr KzGmiYcSHAPZu+Mx9QkaapLeVk68x+A1UVIP+EwMNGnirDDYYFLXCDmTXSbQIWZtD/gE/GhIHikP MSwVTLS9mvl5K1vXV/BmtoipJWtL6/rml63LFgSTVcNThKOCab3faF3bKegbAFOLuF6v1+3VC3oG gH0fNLWylGk2+hv1Tk6zBLKPi7S7tWat4eJL9NcWZG51Op1mK5PFEjUg+9hYwG/U1hvbqw7egCy+ uYBvdLa73XUHb0AWv76A719rrTdcvAFFjCaTBbR2aL+fUS8gY852K+EbAN+oZfA5CqKhiC7NYswT tSzWYvyQiz4ANJBhRROkZikZYx+iuIsZHQmqGeBNgkszdsiXC0OaF5K+oKlqex+mGDJiTu/Ny+/f vHyO3rx8dvz4xfHjn46fPDl+/KOl5SzcxUlYXvj628/+/Ppj9Mfzb14//aIaL8v4X3/45JefP68G QgbNJXr15bPfXjx79dWnv3/3tAK+LfCoDB/SmEh0hxyhAx6DbsYwruRkJM63YhhhWl6xnYQSJ1hz qaDfU5GDvjPDDFfgOsS14H0BFaQKeHP60BF4EImpylzuaHYrih3gHuesw0WlFW5pXiUzD6dJWM1c TMu4A4wPq3h3ceL4tzdNoXTSKpLdiDhi7jOcKByShCik5/iEkAp7PaDUsese9QWXfKzQA4o6mFaa ZEhHTjTNF+3SGPwyqxIQ/O3YZu8+6nBWpfUOOXSRkBWYVQg/JMwx4008VTiuIjnEMSsb/DZWUZWQ g5nwy7ieVODpkDCOegGRsmrNXQH6lpx+C6pHtdv32Cx2kULRSRXN25jzMnKHT7oRjtMq7IAmURn7 gZxAiGK0z1UVfI+7GaLfwQ84Weru+5Q47j69GtyjoSPSPED0zFRoX0K1dopwTJPLinzmirwtaGVK 7J6ow8twJ6tvl4uA/vuL7w6eJvsE4n1xB7qsvZe11/vP195l+XzWijsvslB/dZ9jG2TTLsdLu+Ux ZWygZozclqZhlrBhBH0Y1OvMSZEUp6c0gseswDu4UGCzBgmuPqIqGkQ4hWa77mkiocxIhxKlXMIh zwxX0tZ4aNiVPSI29eHB1gOJ1R4P7PCaHs7PCAUZs+2E5iCaM1rTBM7KbO1aRhTUfhtmdS3UmbnV jWim1DncCpXBh4uqwWBhTehEEPQvYOV1OKtr1nBIwYwE2u52E87dYrxwkS6SEQ5I5iOt96KP6sZJ eayYWwGInQof6QPfKVYrcWtpsu/A7SxOKrNrLGGXe+9dvJRH8NxLOm9PpCNLysnJEnTU9lrN1aaH fJy2vTGcb+ExTsHrUjd/mIVwSeQrYcP+1GQ2WT73ZitXzE2COlxZWLsvKOzUgVRItYNlZEPDTGUh wBLNycq/2gSzXpQCNtLfQoq1DQiGf0wKsKPrWjIeE1+VnV0a0bazr1kp5VNFxCAKjtCITcUBBvfr UAV9AirhmsJUBP0Cd2ra2mbKLc5Z0pVvsgzOjmOWRjgrtzpF80y2cJPHhQzmrSQe6FYpu1Hu/KqY lL8gVcph/D9TRe8ncGWwFmgP+HClKzDS+dr2uFARhyqURtTvC2gcTO2AaIF7WZiGoIKLZfNfkEP9 3+acpWHSGk5+6oCGSFDYj1QkCNmHsmSi7xRi9WzvsiRZRshEVElcmVqxR+SQsKGuget6b/dQBKFu qklWBgzuZPy571kGjULd5JTzzakhxd5rc+Dv7nxsMoNSbh02DU1u/0LEil3VrjfL8723rIiemLdZ jTwrgFlpK2hlaf+WIpxzq7UVa0Hj1WYuHHhxUWMYLBqiFC5+kP4D+x8VPrNfKfSGOuQHUFsRfHTQ xCBsIKqv2MYD6QJpB0fQONlBG0yalDVt1jppq+Wb9QV3ugXfE8bWkp3F3+c0dtGcueycXLxIY2cW dmxtx5aaGjx7MkVhaJwfZIxjzOet8hcoPnoIjt6Bu/4pU9IEE3xfEhhaz4HJA0h+y9Es3foLAAD/ /wMAUEsDBBQABgAIAAAAIQD5zwk5gwYAAFwbAAAUAAAAcHB0L3RoZW1lL3RoZW1lMi54bWzsWU9v 2zYUvw/YdyB0b2MndhoHdYrYsZutTRvEboceaYmWWFOiQNJJfRva44ABw7phlwG77TBsK9ACu3Sf JluHrQP6FfZISrIYy0jSBtuwxYdEIn98/9/jI3X9xqOYoUMiJOVJ26tfrXmIJD4PaBK2vXvD/pUN D0mFkwAznpC2NyPSu7H1/nvX8aaKSEwQrE/kJm57kVLp5sqK9GEYy6s8JQnMjbmIsYJXEa4EAh8B 3ZitrNZq6ysxpomHEhwD2bvjMfUJGmqS3lZOvMfgNVFSD/hMDDRp4qww2GBS1wg5k10m0CFmbQ/4 BPxoSB4pDzEsFUy0vZr5eStb11fwZraIqSVrS+v65petyxYEk1XDU4Sjgmm932hd2ynoGwBTi7he r9ft1Qt6BoB9HzS1spRpNvob9U5OswSyj4u0u7VmreHiS/TXFmRudTqdZiuTxRI1IPvYWMBv1NYb 26sO3oAsvrmAb3S2u911B29AFr++gO9fa603XLwBRYwmkwW0dmi/n1EvIGPOdivhGwDfqGXwOQqi oYguzWLME7Us1mL8kIs+ADSQYUUTpGYpGWMforiLGR0JqhngTYJLM3bIlwtDmheSvqCpansfphgy Yk7vzcvv37x8jt68fHb8+MXx45+Onzw5fvyjpeUs3MVJWF74+tvP/vz6Y/TH829eP/2iGi/L+F9/ +OSXnz+vBkIGzSV69eWz3148e/XVp79/97QCvi3wqAwf0phIdIccoQMeg27GMK7kZCTOt2IYYVpe sZ2EEidYc6mg31ORg74zwwxX4DrEteB9ARWkCnhz+tAReBCJqcpc7mh2K4od4B7nrMNFpRVuaV4l Mw+nSVjNXEzLuAOMD6t4d3Hi+Lc3TaF00iqS3Yg4Yu4znCgckoQopOf4hJAKez2g1LHrHvUFl3ys 0AOKOphWmmRIR040zRft0hj8MqsSEPzt2GbvPupwVqX1Djl0kZAVmFUIPyTMMeNNPFU4riI5xDEr G/w2VlGVkIOZ8Mu4nlTg6ZAwjnoBkbJqzV0B+pacfguqR7Xb99gsdpFC0UkVzduY8zJyh0+6EY7T KuyAJlEZ+4GcQIhitM9VFXyPuxmi38EPOFnq7vuUOO4+vRrco6Ej0jxA9MxUaF9CtXaKcEyTy4p8 5oq8LWhlSuyeqMPLcCerb5eLgP77i+8Onib7BOJ9cQe6rL2Xtdf7z9feZfl81oo7L7JQf3WfYxtk 0y7HS7vlMWVsoGaM3JamYZawYQR9GNTrzEmRFKenNILHrMA7uFBgswYJrj6iKhpEOIVmu+5pIqHM SIcSpVzCIc8MV9LWeGjYlT0iNvXhwdYDidUeD+zwmh7OzwgFGbPthOYgmjNa0wTOymztWkYU1H4b ZnUt1Jm51Y1optQ53AqVwYeLqsFgYU3oRBD0L2DldTira9ZwSMGMBNrudhPO3WK8cJEukhEOSOYj rfeij+rGSXmsmFsBiJ0KH+kD3ylWK3FrabLvwO0sTiqzayxhl3vvXbyUR/DcSzpvT6QjS8rJyRJ0 1PZazdWmh3yctr0xnG/hMU7B61I3f5iFcEnkK2HD/tRkNlk+92YrV8xNgjpcWVi7Lyjs1IFUSLWD ZWRDw0xlIcASzcnKv9oEs16UAjbS30KKtQ0Ihn9MCrCj61oyHhNflZ1dGtG2s69ZKeVTRcQgCo7Q iE3FAQb361AFfQIq4ZrCVAT9Andq2tpmyi3OWdKVb7IMzo5jlkY4K7c6RfNMtnCTx4UM5q0kHuhW KbtR7vyqmJS/IFXKYfw/U0XvJ3BlsBZoD/hwpSsw0vna9rhQEYcqlEbU7wtoHEztgGiBe1mYhqCC i2XzX5BD/d/mnKVh0hpOfuqAhkhQ2I9UJAjZh7Jkou8UYvVs77IkWUbIRFRJXJlasUfkkLChroHr em/3UAShbqpJVgYM7mT8ue9ZBo1C3eSU882pIcXea3Pg7+58bDKDUm4dNg1Nbv9CxIpd1a43y/O9 t6yInpi3WY08K4BZaStoZWn/liKcc6u1FWtB49VmLhx4cVFjGCwaohQufpD+A/sfFT6zXyn0hjrk B1BbEXx00MQgbCCqr9jGA+kCaQdH0DjZQRtMmpQ1bdY6aavlm/UFd7oF3xPG1pKdxd/nNHbRnLns nFy8SGNnFnZsbceWmho8ezJFYWicH2SMY8znrfIXKD56CI7egbv+KVPSBBN8XxIYWs+ByQNIfsvR LN36CwAA//8DAFBLAwQKAAAAAAAAACEAcOnyHABAAAAAQAAAFwAAAGRvY1Byb3BzL3RodW1ibmFp bC5qcGVn/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCADA AQADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIE AwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJico KSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6 /8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNE RUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmq srO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEA PwD+/iiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAorhPiZ8Uvhl8FvA+u/E34 x/EXwJ8Jvht4WitJ/E3xB+Jni7w/4D8D+HYdQ1C00iwm13xZ4p1DStB0iK91W/sdMtJNQv7dLnUL 20soS9zcwxPyFh+0n+zpqnw+8C/FrTPj78FdR+FXxQ8Q6F4R+GfxMsPin4GvPh98RPFfinWZPDvh jwx4F8Z2+uyeHPF3iHxH4gil0LQtF0DUtQ1LV9Zik0zT7a4vUaAEfedo+8/bYfDWjq/rGMn7PCUL L/l9iqn7vD0vjrz9ylGUtBtOKjKScYzjiJwbVlOGEhTqYuUW9JRwtOrSqYiSuqMKtOdRxjOLftVF fLn/AA3F+xV/wuMfs7f8Nf8A7Ln/AA0CfEQ8Hj4F/wDDQHwn/wCFxnxaYxKPC4+GX/CW/wDCanxE YiJBon9if2mYyHFrt5r6bu7u00+0ur+/ureysbK3mu729u5o7a0tLS2jaa4urq4mZIbe3t4UeWaa V0jijRpJGVVJEqcHQjilOLws4ucMSpJ0JwjCFSU41k/ZyiqdSFRyUmlCcJN8sk2v+X08N/zEU+X2 mH/5fQ551KcOel/EjzzpVYR5ormnTqRV3CSViivOPhR8Y/hF8efBGmfEz4G/FT4cfGf4b61PqNro /wAQfhR448M/EXwRq11o9/caVq1tpnivwhqmsaDfz6XqlpdabqMNrfyyWN/bXFncrFcQyRr6PVtO LtJNOydmmnaSUovXpKLUk9mmmtGJSjJXi1JXlG6aa5oycZK66xknGS3Uk09UworhPEPxS+GXhLxn 4B+HPiv4i+BPDPxC+K0viSH4XeBPEPi7w/ovjP4kzeDdJXXvF8XgHwvqWoW2t+MZfCuhumteJI/D tjqLaHpLLqOpi1s2Ex7uizUYyaajNScJWfLJRnKnJxe0lGpCcJWvacZRdpRaVOMo8vNFx54KpC6a 5qbnOmpxv8UHUp1IKSvHnpzjfmhJIoory74v/HH4K/s9+DpfiJ8ffjB8Lvgf8P4NRsdIm8dfF/4g eE/hp4Oh1bU2dNN0uXxP401bRdEj1HUXikSxsnvhc3bRutvFIUYDOdSFNKVScKcXOnTUpyUU51Zx pUoJyaTnUqThTpx3nOUYRTlJJuMZSdoxlJqMpNRTbUYRc5ysrvlhCMpSe0Ypydkmz1GivKfg58d/ gf8AtE+EW+IH7P3xl+FPx08Brql5obeNvg58RPCHxO8IrrenJbyaho7eJPBWsa3ow1Swju7V7zTz e/a7VLm3aeFFmjLdL8RPiF4I+EvgLxn8UfiX4o0fwT8PPh34X13xr448X+ILtLHRPDPhXwzptzrG va5qt3J8tvY6Zptpc3dxJhmEcTBEdyql4icMJTqVsVKOGpUaLxFWriJKjTpYdUvbOvUnUcYwoqi1 VdWTUPZP2nNyak0f9olGND9/KdSVGEaP7yUq0ajoypRUOZyqRqxlSlTV5KonBrmTR2NFfPX7LH7V fwE/bW+B/hH9o/8AZl8ef8LL+DHjybxBB4U8Zf8ACL+M/Bv9qy+FvEWqeFNdT/hHfiB4d8KeK7H7 Dr+i6nYbtS0OzW6+zfarM3FlNb3Mv0LW9ajWw9WpQxFKrQr0pOFWjWpypVac1vGpTmozhJdYySa6 omE4VI81OcakbyjzQkpR5oScJq8W1eM4yjJXvGScXZpoKKK8N/aS/aS+C37InwV8a/tD/tD+M/8A hXvwd+HcWiz+MfGH/CO+LPFn9jxeIfEekeEtHb/hH/A+heJfFGofbPEGvaTp+3S9Evmt/tf2u6EF lBc3MMRjKc6dKEZTqVqtKhSpxTlOrWr1I0qNGnBXlOrWqzhSpU4pzqVJxhBOUkntRo1cRVpUKFKp Xr1qkKVGjRhKrVq1aklCnTpU4KU6lScmowhFOUpNKKbaR7lRUcUsc8Uc0Tbopo0ljbBXdHIodG2s AwypBwwBGcEA8VJSaabTTTTs09Gmt010aMYyjOMZwlGcJxUoTi1KMoyV4yjJNqUZJppptNO6dgoo opFBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH4b/8F5PhP8BPjP8As4/A/wAMfGX9p39mv9mXxT4S /aQ8NfGH4EXf7Z2m6Hq/7Inxf+Kvww8EeO9Uj+Cf7ROn+LLzTfCkvw58e+Fb7xHp2p3GoXzaxp52 6j4T0fxF4htbLQ778f8Aw/8AHbwd8b/+Cb37MFr4N+Af7O3wHg+Dv/Bez9k74NeJP+GNL4X37F/x b8a+FPj14GvfFHxn/ZSIgtYrL4OeOr/Wftek6dawy2trqlvqrf2lql9Nf3bf17/F/wCB3wV/aE8H S/Dv4+/B/wCF3xw+H8+o2OrzeBfi/wDD/wAJ/EvwdNq2mM76bqkvhjxppOtaJJqOnPLI9jevYm5t GkdreWMuxOVa/s5fs9WPgDwH8J7L4D/Bmz+Fnws13w74o+GPw0tfhf4It/AHw48S+D9VbXfCXiLw H4Ni0NPDvhDXfC+tu+s+HdX8Pabp2oaJqrNqOmXFrdsZjGWwjg8fDGVYucKPFfB3EVOhCtUXv8Oc UcFZ9ja7qS96FbGYDhOWUQy2DeWVKlbBZvWUMdgW65jJTxVGjStS56WVZ5lixUoP2sMLmWS8S5dh 8v8AYtzo1KdLMeJK2b/2ovYZjh4QxWU01XwWYVJUf4t9Q/4JUftB/wDBS/8Aa7/4KjeE/Cmgf8E/ Ph38A2/4KdXMHxF/aw8afCnxt4n/AOCl/wAML/wD4W+B3xFm8P8A7NHjvTbK08GaJ4H1yG00TR5t P13xTpU0Enij4gXzw3ST2lnf/wBAP/BfH4933wT/AOCcfjn4a+FNE+JPjL4i/tc+KPBv7HvgbwX8 H/Ceo/ED4x+LNP8Ai7PcW/xct/hp4O0iS1vPEXjyy+Aui/FLVfC9l9qsLSfxLa6TDeXtpBOXH68+ Efhv8O/AF54y1HwH4C8F+CdQ+Iviu68efEG+8I+FtD8N3njvxxfWGnaVe+MvGV1o1jZT+J/Fd5pe kaTpt14i1t77V7iw0zTrOa8e3sraOI8S/Df4d+NNe8D+KvGPgLwX4s8T/DHWr7xJ8NfEniXwtoeu 698PfEWp6NfeHNS1/wAD6xqljdah4T1rUPD2p6loN9qugXGn313o2oX2l3E8ljd3EEnPToVKPDPD XDMZqeCyfBcK4bHxqRpyjjpZdk3C+ScScrnRqf7PmuC4fnQwtCcU6VGtCMqlOvKriTadV/21mufU nOlmGJnnFTLasZOKwNXEY7N8zyarKOqnPA4/MKGIxdv95+runHkpuCX8ef8AwT+/4KB3H7Imgf8A BZv4WfBX9jD9oP8AZe8PfC34E+JP+CkH7Dn7Ln7YHwK1T9n/AMYvoWifBvSfAfxe0a3+Euj6vLbP 8KdM+M/w+07xKLzwL4mSbWYPFvicPJp/idb+auJ/aH+Kv7UP7R3/AARX/wCCh1zq/wDwWt/Zx/bq 1WL9mr4T/HXxxpvwS/Z0+B2j+IfhB4U8S2viiX4g/szeMf8AhXeuT6Zplj45azsrPRfGnivS/DPx q8KX3hLXJLnwlaW+oJDB/Z5qPwu+GesePdE+Kur/AA78C6p8UPDPhvW/Bnhz4kaj4R8P33j3w/4P 8TXNleeJPCmieMLnT5fEOleG/EF3punXWt6FYajb6Xq1zYWU9/a3EtrA0flvw/8A2Pf2SfhN4M+I Xw4+Ff7Lf7Ofwz+Hnxcgu7X4reA/h/8ABH4Z+DPBnxOttQ0660e/t/iF4X8OeGNN0PxpBe6RfXul 3cPiSx1KO5068urGZXtriWJ8s3wc83yLM8rqzdPE4rhbB8PYTE16s8yoUamT1MywuVVq+FxkXTr4 arlX+rlPN8NVVR5j/YuKyrF1MVk2dZhhqk4J0sBi8FLCx9hgqGfVc1r4enCCrShmGGyurmdSGLXL jXiP7Up8R18FhfrdPAYb/WKjjcPTwuN4dyzn/nx8I/Gf4j+Hfjn/AMG+ei3n7U/wQ/4KJ3Hj2w/4 KOTeIf2lfBvwH/ZjivfGX/CB/s+Xet+GvCHwq8U+DdO8ev8AB7VvBksNv8K/Gl98HfH3hbUfH7+G rjT/AImjUllvtEt/jz9mv/grp+2h45+J3/BP/wCPo/4KWfsz/tGy/tz/ALVvgn4MfEj/AII9fDT4 GfC2H4lfsk/Df4jXvi+38SeLNU+I/hnxBqH7S7XnwC0Xwvb634h134m+EtH8I6ld3t3cX13deHX0 qaf+uPwf+yr+y/8ADyH4TW3gD9m/4C+Brf4CSeNJvgXB4P8Ag/8AD3wzD8F5viOl1H8Q5fhNFovh 2yT4cyePUvr5PGj+D10ZvFCXl0uuG+FxMHp+Dv2Rv2UPh58W/Enx/wDh/wDsxfs8+Bvjv4xl16bx d8a/B3wW+G/hn4t+KpvFV7HqXiibxJ8SNF8NWXjHXJfEmoww3+vSanrN0+sXsUd1qBuJ0WQfUYnM MLXzvBZnPDSr4bC4vEV6uGqSjRp4rC1+J8xzvF4CthKC+oz/ALWy7FYTKK2YVKNTMMlhg51slrUp 4zEuplXhTqZLl+W006dbBZFPJ5zhz0IV8VPG59icNnCxOEqYfMMNWyhZnhKmEy7C4ihluYSozweZ 0auX4bAUaP8ALD8Rv29f+Cr2lH9sb9rvw/8AtlfD7TP2dv2Iv+Cwl9+xaf2VLn9lz4aanrHxt+E3 in4/fBfwNaWHi746vc2uv+EY/A/h74swaV4Yn8G+FbTxTqkem3uo+L/GGualc2ktp+ln/Bxl4X8T eOP2LvgJ4M8F+HfhR4v8YeLf+ChP7Fvhvwr4U+PGkah4g+CHibxFrfxTi03RdA+MGhaTb3eqaz8M dX1G5t7Dx3pWnWtzfX/hi41O1tIJZ5Y42/Ye6/Zi/ZrvvDvjfwfe/s9fA678JfEz4kx/GX4j+Frr 4TeArjw78QPi/Fq2ia/F8VfG+iS6A+meK/iTHrvhrw5rUfjnXrW/8Tpq2gaJqK6oLzSrGaDvfG/w 3+HfxNs9E074keAvBfxB0/wz4r8O+PPDdj438LaH4rs/D/jjwhfpqvhPxlolrr1jfwaT4r8L6pHH qXh3xFYJb6vot/Gl5pt5bXCrIPCnhsNPA8M4JqtL+x+IOCc6x+JqVFVxmNhw/PgfHZ1RhiqyqVpT zDOOH+IMfgHipVaeDWdUaPKqVGVNa4mrOfEfFGbYW2Hy3Ocvz3CZZlSXLQyyrmmM4ylh5xo03ChT o4fLM9yLL50sLGknTyW0Ek6TP4hvg98XfjF/wTJ/Zw/4Lk/F7QPBvwD/AGfP+Cgvgn42fsg/Cb4l /s//ALNHwc0HwB+xB+zv4A8Z3Xhn4a/Cv9qb9nzwD4x+ItjpHi3SviB4L+IHiD4m3viP4s6h8NtD HxA0Ww0f4keFNH8L6T4hvNb534rftL/8FAf2rf8AglD/AMFbPAfxG/by+HHx/wDAnwj+DPw++J9n 8bdJ8Nf8Ex9Z+Kvibw7rNx4w074q/s1+Nvhh+wH+2d+1X4D+HXgvxFYeHPDOteAPjFrN3oXxAk1W 68eWVomp2Wk6daad/b1rfwJ+CHibxF418YeJPg38KvEHi34lfDw/CL4jeKNb+HnhHVfEXj/4Tl9R kPww8a63f6Rcan4q+Hhk1jVnPgrXbq/8Nl9U1Fv7M3XtyZfJfBH7Bn7DXwz8JfEbwB8OP2Mf2UPh /wCBPjDpNloPxb8FeCP2dfhB4U8JfFLQ9NN82naL8RvDmg+D7DR/G+k6edT1I2WneJrPU7O1OoXx ghjN3P5nLm+Fq5tkecZbVrJ4vH8NUMmwlbEQp4rBUsTgMtwmX4D2uCq0/ZrL/rOBjm+NoU06mZLH Yrh3OHm2QRr4fMdaOI9ji6NemlSo0s6eYexoUqFOv9XrVcLUxS/tCNJYypWlh41cqwlKvUq08vw+ Dwmb4Grh8+xuPx0f5P8A9tD9uP8A4KT/ALJPxB/Zs/Yasf8Ago9pHwo1DwH+w/4O+O+u/tPap8BP +CXnw/1H9pPxj8RfiP470DRfA03hb9t/9rT9lf4LeBfBHwl8JeE/D3hbSYfgpqPjT4k3c39seIfH el6xBeabf2P354B/ay/4Ka/tU/trfsU/s7+HP2l/g7+y/Y/Ef/glv8Ev26v2hbXwB8J/g7+1H4R8 Q+N9F/aJsPCnxL8LfBX4g6Z8Rdf8N2/hL4weGdXttAsfHdh8QvixoOheE4YNa8EWf/CUXZ8Tj98f jR+yX+yr+0hp/hPSf2iP2Zv2ffj1pXgJL6PwLpnxo+DPw5+KWn+C01SDT7bUk8J2fjjw3rtt4cTU bbSNKt75dHjsxdwaZp8VwJI7K2WLpfCX7PvwF8AeIfDHi3wJ8EfhF4K8V+CfhfY/BDwZ4n8JfDbw Z4b8Q+EfgvpmoW+rab8IfDGtaNotlqWgfC/T9Vs7TU7HwBpVzaeFLTULW3vYNJjuYIpF+ghi6FXG VsVj6U8Rz57nWc+zh7OmqssbgeLo5XSqOEaco4XLsyzfhytVyhutlGLo5BeeFjLETpVOKjRp0str YBtvn4cyrJsM6VOlhngMTg8z4TxOOxNHEYdU69WrjcJkme06OYJ4fMcJT4jrZa6tfCYaFaf8wGs/ ty/t4y/Dr/grD+0z8QP+CkHh/wDZx+A37IX7aP7SH7Enwc8LaL+xT8EPir4ws/FOpfEz4N6d8FvG OreN/iB8T/hL4CurvwrD47Pwx8JW/wARtR8CfDXT5Nfm+I/7QHxI1nRdBmuLD8xfiT+37+0/+1j/ AMElf+C5HwP/AGkP2idI/azh/Zuuv2Ftc+HPx4tvDH7IPhTWNY0P41fFjwdeaz4R1Gy/YV+Mn7QH 7N93ZeFda8CTS6dfeG/i/wCNfEguNa1Sx8W3mj6hZx+FPDv917/s3/s8S+Evin4Al+AvwXk8CfHP xH4h8YfG3wU/wu8Dv4S+MXi3xbHZQ+K/FPxT8NtoR0b4g+I/E8Om6dF4h1vxbZavqetR6fZJqV1c rawCPhtM/Yg/Yt0TwR4r+GejfshfsvaT8N/Hei+EfDfjj4faZ8AfhRYeCPGXh3wBq19r3gPQPFfh S18JxaD4i0XwTrmp6lrXhHS9XsLyx8N6tqF9qOjQWV5dzzSZ5LXwuVYrCV6mGnio4XKuCMKnWxNX EVP7UyDG5HmueZvB4v284Y3NMxy7N/Z4mFeE6uX53Qy+rSw+GyWhTxnvU8zw9DiSGc0MK6OEo8Y4 vifC4WjNUJ4TDVc9o4rD5VTjSUcPUy+lkFNZbQy6UI4LL8fSlmWGhOvjKksN9I6V/wAgvTf+vCz/ APSeOr9NREjVURVREVUREUKqIoAVVUABVUABVAAAAAGKdXJOXNOckrc0pSt2u27Hz2FovD4XDUHJ SdChRouSVlJ0qcYOST1SbjdJhRRRUm4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQBDcTJbQT3DhikE MkzhAC5SJGdgoJUFiFIUFlBOMkDmvnOX9pvwq/jDwn4F0nwr4m1zxJ40+H+k/ETQtMg8R/B3Q9Sv NM1vSdc1ew0uy0Lxl8VPDHiPWdY8jQLuK+Ph3RtZ0TSZJbebVdastP8AtN7bfRlxClzBPbuWCTwy QuUIDhJUZGKkhgGAYlSVYA4yCOK8j0L4PxeGPEPh/W/D/wAQPHel2Gi+EPCXgq/8KRx+ArvQPFOl eCbbV7XQ59euNS8CXvii31BF1m6kupfDHiTw5b3EiQZtVjSSOUgk5SU3JLnw6p8vLy8rhjViHUbU pKMZvBSjyQnN2nFRSlKUW3aDcUnL2da6bd+fmwzo8i0jJuP1lSU5042afOpKKfl+s/tbaD4Z8Lwe LPFnwv8AiH4Q0298baj4A07/AISzxT+z34divtf0RvFEOvKus6r8dLXwxZW2kX3hLU9OkbVte064 1S8lsR4ettZgneeH0b4lfHTw38L9Z8BaFreia9qF78Qrl7XSv7Mv/A9r9nmju9Hs2t0tvEnjPw9q PinU2fWYpYfD3w8svGnia5trW7nttFmT7J9r6rTvhroWmSeH5be71Z28N+NPG/jqxE09mwl1fx7L 4tm1i2uwlhGZNOtm8ZaoNNhhMFzCsFgLq8vDFcG6wviR8G9K+JmqaNqWpeKPFOiRaZZzaZfaVokX g+4sPEGlT6zomvSWF9L4o8I+JdV0R/7S8PaZcJq/gjU/CXiKOa1tLmPWFvNL0a50204+2oJxXsnX Trv3rqisO4qCV2/fxMYzqVI3nGFWfsoP2cacplflq8jtKMK0aXNrzylW/dVHZRtKnQbUabcac6sY +0lGMpNS+B/i/pHjvXbrRbLw54q0eCTT9S1nwvr+tQ+H/wCxPHWhaNrEehatrXhptF8RazqtnaWO o3WmqbfxhpXhXVL231SzvNM0++tUvZbO3dfFGxg+JVx8M7fw34i1C/07wrb+L9a162uvB1toujaV eyaxBYNPp+reLdN8aamt5d6NPYpqHhzwjrmh21/PBZX+rWdzHfR2fJ6L8Fr3wdqVvfeE/HfiWWNN Vt7XT7HxHF4RutO8DeArnxOvizxT4P8ABtvpfgvTdQvrbxPNZ6doD3fjDWdc1nRtLit7/Sdcgu9N a01Xp/EPwrtfFPjnw/4z1rxZ4nurbwrJd3fh7wd9h8CJ4d0nVr/QdT8N3ms2eqjwT/wsGK8udM1e +jubUeODo9yZFjudLmtVFtWL9p9XouPL9YUMRCrF35HNUqssPVvb+WphlUjF8k8woYmmlRwE6dcv RVaylb2b9hOi4Xtr7FVqacndJ1YYi0qilUpYSrTqqFbERVGfOeBPj7oXji80HTJPCHjbwjq3iVtJ n0rTPE48GT3Mui6/4U8ReMNB8RTy+EPGfiuxtdM1fTvCut21vaXF5H4gtr+2RdS0Sxs7m3vJdC9+ NWmpDpx0DwV498aX97deKhd6N4XsvDb6no2jeDfE174T1rxJqS634o0Sym046xZNHpWk6Ne6t4w1 2KQvo3hi+ey1SLT8e2/Zz8FeHvCvg/wv8Nb/AFP4QHwbq0eu2uu/DjQfhtYavrWsN4VuvB2oap4l ttf8A+I/DesanrOjXTDVdUl8Px6lPcxW8sV3brCsVad18EbDyNJXQvHnxC8Iahp0viqO+1rw3eeF I9U8Q6T4y8S3PizWtC1c6t4R1exgsxrF1JLpWqaBY6H4p0KMyJo3iGxe81CS76KnsnWXsrqhGq4t Tv7SUFQqOlUurp03inQWKaVOs8OsTLDUadV0IrOPMoP2jvOUXJezSSh++gpwSle1X6t7V4ZOVWkq /sViKsqaqt8HB+1r4Gu7X4h3dl4a8SXq/DnxTp3g3Ure28T/AAWa+vde1Xxhd+CrC3lsH+LSXfgm C71ayuJbS6+LEPw8gvrQRrYPdahPBp8ntmrfEDTvD0XheXxJper6B/wk1lqtwV1B9DddBvdG8OXX im+0XW7qw1u9sf7TXStN1eSN9GutY0uRtH1Bl1L7MtvcXPEWvwW1PTtJ8S6FpXxo+KWnaP4g1bVd UttPXS/grqcHhxNd1vVte1vS9IOvfB7V5dQ0zVbrWbmC5TxdJ4nvEs44YrW9tn8+WfS1f4I+D9Y+ F/hz4SvcaxY+GfC9r4csdNn0+TSodT+weHoorJrCRpdJn0uKx13Rxe6BrdnY6VZ276Hquo6dpkel xSW5tsbN0eVS5KjqYeKqzSlOFOUYxr1ZUo3pSlSlz1nTVS1a9PD03SVKeIxF3tUbaUoKNafJTbUH OMYOlRVWovaKnVknCNR0eeinVqVFW5qNKlmp8fPDM/h7S9ctPDXjm7vNY0DQtWsvCsWi2EXij+2P EmuXPhvR/BN1Z3msW1hY+K5tb07WLS++2anB4b0OHQ9X1TX/ABHpejWh1F/TfCXiG88TaQuo6h4T 8TeCb9bm5tLvw54tTQ/7XspIHHlu134X1zxN4a1C2u7d4bu2u9D8QarahJjaXM1vqdrf2Fp5y/wH 8JLb+N0sdV8U6VfeM/Fdn4zt9Z07UNPi1PwXrmnXkmr2B8HmbSbixh0238R3uu+I5dH8Q2PiLS9T 1DxP4ksdZtNS8O6pJoiQ/CX4Nn4OldA8NeIZp/A4i13VLvTLnQvAmjXGp+LfEGoaXIdQXTfAPgbw P4b0DT9D07SJYLSz0LTbeLWbrxDqN5q9sL3Tba8v7g4ylUU4+zUozqUpXcowvGlWp4edve9pTbxe FqVkp0qjp5fKCh7TGVlnJTUYtOMnGpThUUU4uUUqtGpWgpN2hVmsLiYULurRjVxkKlWcMPRVXHX9 pjwTZ3OrJ4o8PeOvCNjZ32p2Gg6lfaLp3ic+OpNI8bx/Du9bwj4f+G2t+OfGc7nxZc6dptnY654Z 0LVdTbVLNtN0+723otO1vvjR4A0rUde0vVbjxTpV54d8Pz+J7xdU+HPxG063v9HtRpIupPDF9e+F ILHxnf2s2u6RZ3Oi+ELnXNag1G/g0yXT01BmtlpaJ8CPht4cS8k0LQbLSNV1bxzB8QPEPiLTNL0H T/EfijXLTxVqfi6xj8TavZ6PBc63Y6ffateWVil8ZLy10t/s0N6szS3Mnlfjj9lnR9R174q/ETwz qEl747+JHhPV/C82l+JLTwFYeHXstbl8K/2laXniW0+FmveNb+2e08KWtrpdn42ufiR4T0Vbu7tz 4H1TRJp9CmzUmqcueN5wpYxxnBNqpOnhsPPBRdNc0nKriZ4mjWlHkjKOHhVhRw/1lU6OrSlW91qN Kc8LpLSUFOrUhirNu0Y0qcKVWmpzqO9eUXUqew/eeu6L8cPhtr2kXWt2eraza2Njaa9e3ia94J8c +F9StbfwvrMHh7X2n0XxN4b0jWYpNN1u4TTZoHsBO1ys6wxSC1uWh3/CvxJ8H+NdT1rSfDl9qN3d aFLLFdS3nhvxNo2m36wXlxp1xd+GtZ1vR9O0fxhplrf2s1ld6t4Tvta0y0uvKguLuKW4t1l8K8Kf s7atP4B8H+HvGPi2/wDC+p+HdO8R+HLzTvhrF8OI9C1PwVrOu2mr2nhHUpI/gt4N0SW2sP7MsDDq vgv4ffDPUYt1xbgzPJd6hqPoHwx+AXgj4TeJ/GPijwoBHceM55Zry0bwr8NNNey8/UrrVZo18TeG vAegePPESSXd07F/HXi7xdcLsR0nSbzJZNeVKpCMpLlVPFe1lFqSdaNRvCKm48y5KlGVONbWajiK ddQqew9jVqY3m41ZJJXq0PYRaakqLlyYlVG3HmnBwlUoz5aXPQqUHOhGv7bD0vb6KKKg0CiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPEPEHxs03wp8SdV8FeJNNi0vw9p3gWLxZF4 yk1XzBdasU8S6hceFv7CGnrKl3/wjvhXWddsLu31G8a/i0zU7VrC0ktraS/4m2/ai0XTbP4aL478 KzeFtb+JPjPxB4FttMtvGngC8Gka7ofj9vh6ImsfEniPwV428TrPqclpcXY8D+BvEz6NDPK2qJBb xRXVz7V4i+GXgbxZeS6h4h0CHVLua88J38sk13qKK114Iv8AUtS8NP5MF5FAEsrnWNUW5gWMW+rW d9cadrMWoafIbWue1T4GfDTV9R0XVbvSNaiutA1y98R2SaZ448d6JYXWrah4yHxCuJde0nRvEthp Xii0Xxkv9u2mleJrPV9K0+5LRafZW1o727VT5VOj7ROVNYiPtrfHLDRjVqT5bckXVqVKscOoL2ca eHwtCv7apWq4iEyesZqGk3TXI7pKNV3g1qp2hCMadfnkqjq1qtaj7OjSp0qjwIfjwl9Yw3Wj/Cr4 o6xd6l4q8ReF/DWj2yfDmw1LxVF4TlvrbxD4m0qTXfiNpGlWHhywu9OuLaOXxPqfh7WNTZrefR9G 1CyuYbp5vhZ8YL7x7NqOjap4P1rQNatE8UXelajqEek2XhrxXp/h/wAXal4Wnn0T7H4h8Q+IrNNO uYNPtdSn8Q6Joy38102o+G4dX0grOnVa58IfAmv6Po+h3dlr2n2nh/VtS1vRrvwv438ceC9d07UN YfUZNWa38T+EPEeh+JFtNSfVr43umNqzaZch4Vls3Wzsxb7Wm+AfCmjtE+madNZywaXrejQzxatr P2iHT/EWr/27rEUVy2oNPHNdat/pqXqyC+tJAEsrm3hAjGVp+7dprlrxkr2k74JRw84y5HFT+vwh OqpUpQjQqV3FTk6NGineya5VK8HtLkSeMozqwa5uaaWC+sU6U1KlL2ioqcW3UxC+b/FX7TPiTwV4 euL7xR4T+E2havbeONW8HNf638d7jQvhVcPovhca/ewWXxO134VabNc+KRqIn8Lr4Y/4Q2KBdc07 WbW41+CXR7+GH6XtvEF9rvgqz8U+FNMtLzUNa8N2evaBpPiPUrnw9aTzanp0V/YWWs6pY6R4kutI jPnxxXt1a6JrEtofMaOxuygjbzrTv2ePhrpHheDwXp0nxLtfDNtd291BpSfHL43vHFHbWcthHpS3 EnxEe8/4Rt7WaRLnwqbg+Grx9k93pM88UUqdXJ8ONK1Lw3428JeI73VNY8PeOLjUIb3SbbVda0G0 0jw5d6VY6DB4X8OSaRqtvqPh/S4tJ06I3SaPqFil3q17rOpQQ2EWpGxt7d+TExX8Rwoyw0/gjGcK MKdanNP2zj7evKeIhJqqqUKUoPmdSEFSt7Sg3dUlOtGvG3tJyhUrOdGpvRTVChTVKUYTpSqVK6bv GDqx8Ub9ovxSNGtdTi+HPh68fStB13xn46Nj8Rr+XSbbwRo3iq98OQa78NdXn+HdsfiJLrttpt/r WhQavY/D3Sb+yjtXXX0tr+1vX73Uvi34isdD+Mepx/De8m1D4XX0kGnaLJ4p0SCfxFpy6BYa4mu6 leolxY+HNNaG6mvZLezm8Ua1HoMMN2mkS+IriTwla2T+z98Mni8PQ3Ft41v18MtcLp76p8Wvi1q1 xe2NzfafqMuh+JrrUvG93c+M/C4vNLs5YfCfjCbXfDNsouIbbSYoL6+iuJbn4DfDu8Hjxbg+P3X4 lur+MUX4x/GGJL8LLG4i09IvHaL4btjBFHpj2vhkaPbPoKL4deJtCH9nUp83slGDj7b/AGlupJNQ 1r8+ESgpS0jQUaVa8m+Z1ZxcnUpfV6pOCrudaLlQ9rQapRleapJNYiDqpU+aTbcqclGF0qcGqfs6 lTEesadd/b9Psb7y/K+22dtd+Vv8zyvtMCTeXv2pv2b9u/Ym7Gdq5wLlY3h7QdP8MaJpnh/Sm1N9 N0i1jsrJtY1zW/Emp/Z4siNbzXfEeoarrmpSKDtFxqWo3dxsCoZSiIq7NaVHB1JummqbnJ01L4lB yfKnrLVRsn70ter3MKSqKlTVWSlVVOCqSj8MqiilOUfdjo5Xa92On2VsFFFFQaBRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFZeu/2n/Ymsf2L/yGf7K1D+yebcf8TP7JN9g5uw1qP9K8rm5Vrf8A57Ax 7hUzlyQlPllLljKXLBc05cqb5Yx0vJ2tFXV20ioR55whzRhzyjHnm+WEeZpc05WfLGN7ydnZJuxq UV8W27/tmeG9NW/Eei+OtTtp/C2j/wDCMapF4Gnt76G/8U6cni3xRN4x0q++FHm/2B4Qsb5tLWHw boralrOsSXj+EDbpa6Jo/f8AgvW/2kdVTxdcePfDGk+F4o9K+IFv4S0/w/pfhvUdVnvdO8Q3MXgP Vri4ufizqOlR6jrXhiexnk8PXci6PPqlpeyap4m8JQi306/cm4qpZOUqaxzcY2vL6ioNKnKTjTm8 aqlN4G07VnKcJulOhiY0Yi+ZJtOCcsDFOSd/9utq4x5pRjg/e+vSlFLD8j+Pno+0+k6K+ODrf7Ym i+D9FvdJ8HaD4v1+5j8FWuoeH/HF94OtPEelsuo6DB411fVfEvgvxD4b8G6hNeaPdazdWmkaF4dt 4NB1bTLia11HxbY3GmaPP6FpF9+0ct3p097ovg25t4orrT9U0bV7mLSI76Qz6jNpuv2fjDQb7xHc ae0NhDYwazp0vw+1CPUtW1COz0uLRNN0i68Qa1VvelFNNRqYmnz6xjJ4ZUmpx51GTp4n20fq0+VR m41VN03QrKEc/uRm4VE5U8LU5LJzSxNSVNwlZuKqYaUZSxUHK9Ony1I89OpTlP6For5q8X+If2iv DGkXFn4Q8E/8LE1ue21aSw1i6XwNa6fYS6ZJqOl6XFqun3PxI+H815c+IIYNC8SrDpzQ2ccl74i0 661Hw8sWjWUOl8H7/wDaG17V9W1f4y6P4c8EaVZnxNpOjeEfDy6dqi6vEfFUj+GvFd9r0PiLXLu1 uovCtnb20ujxLa21zc6pdajdRWdwsGj6Wo+/OMfhUqVaq5yvGEPYvldOV1ze1qVHGnRhGMvaJ+3i /qsaleF1HyRlKzny1qVFRprmlL2ypSVWK0/cwhV560217J0qtKaVeKpS+g6KKKBhRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFZ+r3N3ZaVqd5YWjahfWmn3tzZWCkq 17dwW0sttaKyhmDXMyJCCFJBfIBPFaFRyyxQRSzzyJFDDG8s0sjBI4oo1LySO7EKqIilmYkBVBJO BUVGlTm5TVNKEm5yfLGCUW3OT5o2UVq3zRslfmW6qHxw91z96PuLeeq91aPWW2z32Z8n2fxx+IZ0 eygtPA3inxpr1uJdU1TV7f4HfF/4W6XqujC9WGGy0nw14+jurrSNedje6f8AZtS8Xajcf8ShPEku l22heItKWD0H4P8AxS8d/EfT9E1XxX8INb+F9rq/hOPWZrHxFf6rJr+k+II5rFb/AMPajpV54R0S KC2FvqME+k6k+oJqWovaavb3nhvSH07fcY+hftVfBbxBDpUtl4hv5JNe0XWde0K3sNB1fxNJrlh4 d/smPXE0WbwbaeJLLV9T0+71rT7AaLp13c6zqF3Ns0mw1CICZvR9d+Kfg/w7ZaFqepXOqnTPEelj WNKvNO8Pa7rEktk0mkKskuk6Rp97r0CJb6xDqV9PLpS2mjaRZ6pqmu3GmWOnXM6a2lzyjytzqVZR hCUUuScf7SpOlywjTblz0nGUG4yeIyqpCCi54qlLJ6tSU0owpT51G15JSoYmVabd4xcKVW0nCMKc cNiqcnCPJQqR8bt/jx8S77xNregaX8A/GF7pljoNh4m0Xxjrdr4p8GaJr1lf654gWXRRYX/gvVdY 0zxPp3hbS9Pvo9IvrZL6+17UYtI1ax8JW89pfzXtV+M3xM0FNX1jWPhNDaeHNFs5NV1O4fW/EcRs fD9uJbmTWBqcvgUWt5qa2N9o76t4Yey0218PHT/FdwPF2ux6daQ3PTt+0b8K4NNfVL7UPFGnQwQa rPdRXXw7+ILz2v8AY8azzxSCy8M3cU01/bMbzw0lnNdDxlYRzaj4QbXbCCa5Sa2/aF+GNxZw3r3X jCySeztr5Yb/AOGPxLtbkQXN2bXBhfwkS81nH5WratBEZJtG8M3Vj4s1ZLLwxqFlq9xi1KVOmqdS 86ntHRqSUaiquvWlPDe5D2aqxp0qc8PBU3B1oKrUcvbxjUp6c0FKq5q1NKgqkIyUZUfq6pSxLVSS m4Oump1HUUlRdSPKvYt0p5fwJ+NmpfGezuNVfwfFomhHwz4R8Q6N4l0zUPFmseG/Ex8Uf23NPB4f 1nxD8O/A1rqMOjWmn6Y1+YS2sWN/qk2la/oOgXVhEdR+gaKK2m4OcnCLhByk4wcudxi5Nxi5Wjzc sWo8zSbtd6tkQUlGKlLnko01KXKo80o04RqSstEqlRTqKOvIp8ibUU2UUUVJQUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABWbrLaWmj6q+txQT6Mmm3z6vDdWv262m0 xLaVr+O4svKn+1wPaiVZbbyJvPjLReVJv2HSqrfWVrqVleadexCey1C1uLK7gLyRia1uoXguIi8T JKgkikdN8bpIucoysARM+fkl7Pl5+WXJz35Oez5ebl15b25ra2vbUunyKcPac/Jzx5/Z25+S65uT m057X5b6XtfQ8Rt9Y/Zz1DxJo/iS7g+GWkfEHWrSCfS28Y6Bo3g34pPbapBdX1tHNovjDTtF8faf Jf2vhe8vo7S/0+1uLi28Pz3YheHS2khZquqfsveJrRbvXNR+AniCwfRfBipc6rd/DzVbR/Dza/eW 3w8VZryS4hbRW8Um/g8GAMbE6+byLQ/+JiZlrc1P4CfCPVYPC1nP4Ms7TTfBWqR6z4W0fRNQ1rw5 oej6jDoD+Free30Lw/qWmaO6W2gyTafaW1xZTWtqk9xPbwRXVxNO9jUvgn8PNV/tZbmz8Swxa3dQ X2o22l/EL4iaJZyXsNxfzyXlvZ6L4qsLSwutQTU73T9auNPhtZde0WVdA1t9Q0SC30+K1yqpFq6p 08WnStZVKeDUHJTi9IwxftqlWyjalGF587lWlGnhafs2mqbqVcL+/Vn7OWM5oKUWviq4WcIKXNPl qxkoQcJqHtJZd7c/ALxZ4R1m+1DTvh14n8Iw3mjaT4mtLrw5pOuW1jqM9vpkOkaX4n0GTTbq506/ tdP1vS2/s/WtPt7nStLv4Lm5htNPYyilqNz+zN4O1mO/1L/hSfhvXta0fXFbUZ4PBOm6ld+G9Msb rxV4jmvdQ8uKdPDdjZ6vca1rF3ezpo8Da4lxeSrPrcBu9uH4EfCePw/qvhO48Ixax4Y1vxPJ4x1P w/4l1bX/ABVo114ge0gs0uv7O8SarqtpDa2iWtrdabpFvFFo+lapaWms6bYWmr2tvex8zqX7LfwU 1nSb7QtY8PeJNW0fU7bVLPUdN1T4nfFPULO+ttXs/wCzporuG78aTJcDT7AvZ+HDKGbwnbTXEPhd tHS5nEkLnUItKKrRoNpJtQWKeChDljK3NGh9blXpupyuo8Eofu1VnOENXaUkpXdOVVxnezksM8TT TtF+7Oq8FRoycXKFNYmFOHM6VKM37H4e8WeGPFsOoXHhfxBo/iGDSdUutE1ObRtQtdRjsNXskhku tNu3tZZVgvIYri3maCQq/kXEE6gxTRO3QVzfhXwj4f8ABOlLonhmyk03SImia3086hqV9bWaw2Vp YRw2Eeo3l2LC1FvZQu1nZGC1kvHu9RkhfUL++urnpK0nyc37tyceWGs0lJz5I+0dotpRc+ZwV21D lUm3dmcOez9ooKXPUsoNySh7SXsk5SjFuapcntHyxTqczilGyCiiipLCiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAqG4njtbee5lEpit4ZZ5BBBPdTGOFGkcQ21tHNc3 EpVSI4LeKWeZ8RxRvIyqZqiuLeC6gmtbqGK5trmKS3uLe4jSaCeCZGjmhmhkVo5YpY2ZJI3VkdGZ WUqSKmfPyT9m4qpyy5HNNwU7Plc1FqTjzW5kmm1ezT1HHl5o89+W65uW3Ny315b6Xte19L7kdnd2 9/aWt/au0lre20F3bSNHLCz29zEs0LtDOkc0TNG6sY5o45UJ2yIrgqLNVbGxstMsrPTdNs7XT9O0 +1t7GwsLG3itLKxsrSJILWzs7WBI4La1toI44be3hjSKGJEjjRUVVFqtJ8nPL2fMoc0uRTac1C75 eZxSTla3M0km72SREebljz8vPyrn5b8vNZc3LfXlve19bWvqf//ZAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBLAwQUAAYACAAAACEASei8AlQBAACdAgAA EQAAAHBwdC9wcmVzUHJvcHMueG1stJHdaoMwGIbPB7sHyXmaRK1WqRatHQx20IPtAoLGNmB+SNKf MXbvC9qVlp30ZGdfCO+b5/myXJ3FEByZsVzJApAZBgGTreq43BXg4/0FLkBgHZUdHZRkBfhkFqzK 56elzrVhlklHnY9uTeCLpM1pAfbO6Rwh2+6ZoHamNJP+rldGUOePZoc6Q0/+ATGgEOMECcoluOTN I3nV97xljWoPwgNMJYYNI4ndc21/2/Qjbbced0ill2Rn92bdZQoOhhfga5Mm600WVzDB0RrGJA5h nW1qmDQkSjEmuArTb+AzJM47bltquldBd2zTcddQRyfVAlwpSfyHU/DWKKt6N2uVQJMw0urEjFZ8 dCb4srgjHQqAASqXaOS9h20iUuEkrGCaLSoYR2EGq7ppYF1Xi3mShHhO8BWW9fQwuBG20fw/OMPw jnQiHjfsx9uf2JryBwAA//8DAFBLAwQUAAYACAAAACEAKSKakq8BAAD3AwAAEQAAAHBwdC92aWV3 UHJvcHMueG1slFPNT8IwFL+b+D80vevGQMSFQUyMJw8moPemLaOma5u+DsG/3tcN2Pg46K3v7b3f 14PpfFtpspEelDUFHdynlEjDrVCmLOjH8vVuQgkEZgTT1siC7iTQ+ez2ZuryjZLf754ggIGcFXQd gsuTBPhaVgzurZMGv62sr1jA0peJ8OwbgSudZGk6TiqmDN3v+7/s29VKcflieV1JE1oQLzULKB7W ysEBzf0FzXkJCNNsn0iaoTkTZevPxmKscTZYL8WbXAUCPxjVwzjDsFgd7LP4qiEUNKVJf3RpXTP5 NHp4whQvJpNLFtBKyI6UL7ToVe2TbJhfcKbxGAMa+SAWsynLYUvwho8jSgR+Sxs52N1ddpF6v+Vy 61WpDNkW9G6QjnB517yyaAbneCegrFHdG4RI2rwJ7mKCGLb1P5Q4CwXNBuN9Du1I25xMmibidSAR vGcQyzP7tg5amX4enZYz08PhNdOn3UjQRtU3jTdEwwd1R7c4fEFvbJCwlNvQyTjOH7EPZ4j5X7nD Wfu/mq5IKL0SC8c4/rEIxys+TtIM40Z2jsaOVXvNTfuD/gUAAP//AwBQSwMEFAAGAAgAAAAhANj9 jY+sAAAAtgAAABMAAABwcHQvdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNRJBTCICt3 6gEqlCHpQGijEuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAKC3m236U8 cU95c6sUV+vQpmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJnsE3qoIg orTAp8vliGlIA1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAwQUAAYACAAAACEADG1dlGwBAACl AgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAjJJfa8IwFMXfB/sOJe81aTs3F2plfxAGE2Q6NvYWkquGtWlIorXffmmrVdke9th7Tn4596Tp ZF/kwQ6MlaUao2hAUACKl0Kq9Ri9L6fhCAXWMSVYXioYoxosmmTXVynXlJcG5qbUYJwEG3iSspTr Mdo4pynGlm+gYHbgHcqLq9IUzPlPs8aa8W+2BhwTcosLcEwwx3ADDHVPRAek4D1Sb03eAgTHkEMB ylkcDSJ88jowhf3zQKucOQvpau13OsQ9Zwveib17b2VvrKpqUCVtDJ8/wp+z10W7aihV0xUHlKWC UyddDtniZR48cOf7Dd5gBcawPMW92vi4AeZKkxm5Yq7etupx1vScM+tm/klWEsRjfbL9lhq3gZ1s XjOLR8MUnw/8XW0F3YUgAr8U7So4Kh/J0/NyirKYRFFIkpDcLWNCo4jekK8m18X5ZsluUBzS/YMY j5bkng4TmpwTj4CsTXz5Y2U/AAAA//8DAFBLAwQUAAYACAAAACEAGu3+I7ACAAA7BgAAEAAIAWRv Y1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcVc1O20AQ vlfqO6x8ag/BCaQFRRsjaohAAhLFDpy363G8Yr1r7a5d0lNfo6/XJ+nYjkNS3Eo0p/n5PD/fzkzo +XMuSQXGCq2m3uho6BFQXCdCrafeKp4NzjxiHVMJk1rB1NuA9c6D9+/owugCjBNgCYZQduplzhUT 37c8g5zZI3Qr9KTa5Myhata+TlPB4VLzMgfl/OPh8LMPzw5UAsmg2AX02oiTyv1v0ETzuj77EG8K LDigsXZMxiKHYHz6ifovKn3UJrHB6TFaW5FeFIUUnDlkJLgT3GirU0fmTe1kob+BWWihHPX3gcgH WGyq+WzW9BzM1cByA6BIlOlv5MN4cvKR+j1AumCGrQ0rMhuMxkPEvOg0kiIBtB9TfyvSe+3QgoZW oNciSUBtvfj5gU7v7kIpChugoxNpxJmEECkKUiYtYOidgV4Dq59/wYSxAa3cpALutCFWfMcBGHvk K7NQEzv1KmYEUw4JrmGt0siysM4EMU4CxkZfqzfiPmxfFuNg1ABQ+CewjdV0S2LhJNi3pEDWsJ5X OWpj2ycmP2SgzTFP8VFcDyGjk31GmuJaPto6t3PzioodKdHNglzwetrIElIwhsn9fna4L4w/rY0u VdLrvmr2CN+NLK9mV8tezGPGHBGWMLXNeN4LWy3vSeRMyV1pDp5vV8vKAglxCg6Y33nrNL9+/LTk Hpe7P0X7eme96ed4OMiNtWV/7nqX6jYZwU0aGOC4wJCQB9wSTS5L0/pCreqr1qxjb5YIr04LnQkJ JDU6r0OGbwhxo7gsmyC3ooJtBUJhmL9lP5iyP+Yq1HnB1Ca4qNiGUb9T6a1QT3ZVxPqSOejW9dBI o4wZSPCwdv4XA73GTTWyDhJmTK0h6TCvHfXpe2j/C/DeHA3x11y5zlYfr+7qB78BAAD//wMAUEsB Ai0AFAAGAAgAAAAhAAQTp6p/AgAABxQAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz XS54bWxQSwECLQAUAAYACAAAACEAaPh0oQUBAADiAgAACwAAAAAAAAAAAAAAAAC4BAAAX3JlbHMv LnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAADuBwAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAA AAAAAAAAAAAAAADrCAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHNQSwECLQAUAAYA CAAAACEAI/NwpNcAAADOAQAAIAAAAAAAAAAAAAAAAADoCQAAcHB0L3NsaWRlcy9fcmVscy9zbGlk ZTIueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAAD9CgAA cHB0L3NsaWRlcy9fcmVscy9zbGlkZTYueG1sLnJlbHNQSwECLQAUAAYACAAAACEA2AOCa9cAAADO AQAAIAAAAAAAAAAAAAAAAAD6CwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHNQSwEC LQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAAAPDQAAcHB0L3NsaWRlcy9fcmVs cy9zbGlkZTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAA AAAMDgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTcueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U9 7L8AAAA3AQAAIAAAAAAAAAAAAAAAAAAJDwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTgueG1sLnJl bHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIQAAAAAAAAAAAAAAAAAGEAAAcHB0L3NsaWRl cy9fcmVscy9zbGlkZTEyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACEAAAAA AAAAAAAAAAAABBEAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMS54bWwucmVsc1BLAQItABQABgAI AAAAIQBL9T3svwAAADcBAAAhAAAAAAAAAAAAAAAAAAISAABwcHQvc2xpZGVzL19yZWxzL3NsaWRl MTAueG1sLnJlbHNQSwECLQAUAAYACAAAACEAY7zJggQBAAD/AQAAIAAAAAAAAAAAAAAAAAAAEwAA cHB0L3NsaWRlcy9fcmVscy9zbGlkZTkueG1sLnJlbHNQSwECLQAUAAYACAAAACEARanJfXEBAAAq CgAAHwAAAAAAAAAAAAAAAABCFAAAcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVsc1BLAQIt ABQABgAIAAAAIQC+a+MBogIAAD0OAAAUAAAAAAAAAAAAAAAAAPgWAABwcHQvcHJlc2VudGF0aW9u LnhtbFBLAQItABQABgAIAAAAIQBUIuFf3wUAAGgZAAAVAAAAAAAAAAAAAAAAAMwZAABwcHQvc2xp ZGVzL3NsaWRlMS54bWxQSwECLQAUAAYACAAAACEA6Y93O0MDAAAuCAAAFQAAAAAAAAAAAAAAAADe HwAAcHB0L3NsaWRlcy9zbGlkZTgueG1sUEsBAi0AFAAGAAgAAAAhAM1p6Po4BgAAaRQAABUAAAAA AAAAAAAAAAAAVCMAAHBwdC9zbGlkZXMvc2xpZGU5LnhtbFBLAQItABQABgAIAAAAIQBxxB8apwUA ALckAAAWAAAAAAAAAAAAAAAAAL8pAABwcHQvc2xpZGVzL3NsaWRlMTAueG1sUEsBAi0AFAAGAAgA AAAhAI+kGQ0mBQAAriEAABYAAAAAAAAAAAAAAAAAmi8AAHBwdC9zbGlkZXMvc2xpZGUxMi54bWxQ SwECLQAUAAYACAAAACEAjtlxHxMEAACyCwAAFQAAAAAAAAAAAAAAAAD0NAAAcHB0L3NsaWRlcy9z bGlkZTcueG1sUEsBAi0AFAAGAAgAAAAhAGi5CR+rBAAA2RoAABYAAAAAAAAAAAAAAAAAOjkAAHBw dC9zbGlkZXMvc2xpZGUxMS54bWxQSwECLQAUAAYACAAAACEAhVKBg7EEAAAFDwAAFQAAAAAAAAAA AAAAAAAZPgAAcHB0L3NsaWRlcy9zbGlkZTUueG1sUEsBAi0AFAAGAAgAAAAhAOE7OpOtAwAA/gkA ABUAAAAAAAAAAAAAAAAA/UIAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbFBLAQItABQABgAIAAAAIQCT d4VHxAQAAMMNAAAVAAAAAAAAAAAAAAAAAN1GAABwcHQvc2xpZGVzL3NsaWRlNi54bWxQSwECLQAU AAYACAAAACEAXWalm9IDAADjCQAAFQAAAAAAAAAAAAAAAADUSwAAcHB0L3NsaWRlcy9zbGlkZTMu eG1sUEsBAi0AFAAGAAgAAAAhACIu3ltvBAAAKw4AABUAAAAAAAAAAAAAAAAA2U8AAHBwdC9zbGlk ZXMvc2xpZGU0LnhtbFBLAQItABQABgAIAAAAIQCZ9pmu1QAAAL8BAAAqAAAAAAAAAAAAAAAAAHtU AABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTIueG1sLnJlbHNQSwECLQAUAAYACAAA ACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAACYVQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDYueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAA AAAAAACgVgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHNQSwEC LQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAACoVwAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAA LAAAAAAAAAAAAAAAAACwWAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1s LnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAAC4WQAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDUueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS 8b4AAAA3AQAALAAAAAAAAAAAAAAAAADAWgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDkueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAADI WwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEwLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAA0VwAAHBwdC9zbGlkZUxheW91dHMvX3Jl bHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBKr3U51AAAAL8BAAAqAAAA AAAAAAAAAAAAANpdAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTEueG1sLnJlbHNQ SwECLQAUAAYACAAAACEAEDOvZZ4HAABILwAAIQAAAAAAAAAAAAAAAAD2XgAAcHB0L3NsaWRlTWFz dGVycy9zbGlkZU1hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAA AAAAAAAA02YAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA22cAAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGmiXyEeAQAAxwcA ACwAAAAAAAAAAAAAAAAA42gAAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMvc2xpZGVNYXN0ZXIxLnht bC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAS2oAAHBwdC9z bGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANMu 0KLpBAAAFRIAACEAAAAAAAAAAAAAAAAAU2sAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ4 LnhtbFBLAQItABQABgAIAAAAIQARIFQSoQIAALoGAAAhAAAAAAAAAAAAAAAAAHtwAABwcHQvc2xp ZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWxQSwECLQAUAAYACAAAACEAsTCR6NICAAAMCAAAIQAA AAAAAAAAAAAAAABbcwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1sUEsBAi0AFAAG AAgAAAAhAKfHeRhnBQAAihsAACEAAAAAAAAAAAAAAAAAbHYAAHBwdC9zbGlkZUxheW91dHMvc2xp ZGVMYXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQDgU56SDQQAALsRAAAhAAAAAAAAAAAAAAAAABJ8 AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWxQSwECLQAUAAYACAAAACEAf2gpdYME AACsEAAAIQAAAAAAAAAAAAAAAABegAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1s UEsBAi0AFAAGAAgAAAAhAKQJCD1GAwAA6QoAACEAAAAAAAAAAAAAAAAAIIUAAHBwdC9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQyLnhtbFBLAQItABQABgAIAAAAIQA3FTxbMQQAAFgQAAAhAAAAAAAA AAAAAAAAAKWIAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwECLQAUAAYACAAA ACEAGCiEeV4DAAAgCwAAIgAAAAAAAAAAAAAAAAAVjQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDEwLnhtbFBLAQItABQABgAIAAAAIQBWvC57pgQAAIQRAAAhAAAAAAAAAAAAAAAAALOQAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OS54bWxQSwECLQAUAAYACAAAACEAJB7XT6oDAAAA DAAAIgAAAAAAAAAAAAAAAACYlQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbFBL AQItABQABgAIAAAAIQA3se3JYwIAAMgFAAAfAAAAAAAAAAAAAAAAAIKZAABwcHQvbm90ZXNTbGlk ZXMvbm90ZXNTbGlkZTEueG1sUEsBAi0AFAAGAAgAAAAhAGGLMQxtAgAA0gUAAB8AAAAAAAAAAAAA AAAAIpwAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlMi54bWxQSwECLQAUAAYACAAAACEAtM9Y GbsAAAAkAQAALAAAAAAAAAAAAAAAAADMngAAcHB0L25vdGVzTWFzdGVycy9fcmVscy9ub3Rlc01h c3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAoVXXZngGAAAAHgAAIQAAAAAAAAAAAAAAAADR nwAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhAPnPCTmD BgAAXBsAABQAAAAAAAAAAAAAAAAAiKYAAHBwdC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgA AAAhAPnPCTmDBgAAXBsAABQAAAAAAAAAAAAAAAAAPa0AAHBwdC90aGVtZS90aGVtZTIueG1sUEsB Ai0ACgAAAAAAAAAhAHDp8hwAQAAAAEAAABcAAAAAAAAAAAAAAAAA8rMAAGRvY1Byb3BzL3RodW1i bmFpbC5qcGVnUEsBAi0AFAAGAAgAAAAhAEnovAJUAQAAnQIAABEAAAAAAAAAAAAAAAAAJ/QAAHBw dC9wcmVzUHJvcHMueG1sUEsBAi0AFAAGAAgAAAAhACkimpKvAQAA9wMAABEAAAAAAAAAAAAAAAAA qvUAAHBwdC92aWV3UHJvcHMueG1sUEsBAi0AFAAGAAgAAAAhANj9jY+sAAAAtgAAABMAAAAAAAAA AAAAAAAAiPcAAHBwdC90YWJsZVN0eWxlcy54bWxQSwECLQAUAAYACAAAACEADG1dlGwBAAClAgAA EQAAAAAAAAAAAAAAAABl+AAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEAGu3+I7AC AAA7BgAAEAAAAAAAAAAAAAAAAAAI+wAAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAAQgBCAMMTAADu /gAAAAA= --_002_6369CB70BFD88942B9705AC1E639A33822CBE5D0D3DCUS1MBEX4glo_-- From andrew.hutton@siemens-enterprise.com Thu May 19 06:53:21 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3864E06D9 for ; Thu, 19 May 2011 06:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrdACqqO3xNN for ; Thu, 19 May 2011 06:53:20 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id C0624E07CB for ; Thu, 19 May 2011 06:52:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1305813148!25725645!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 9910 invoked from network); 19 May 2011 13:52:28 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-3.tower-27.messagelabs.com with SMTP; 19 May 2011 13:52:28 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 168951EB83F2; Thu, 19 May 2011 15:52:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 19 May 2011 15:52:36 +0200 From: "Hutton, Andrew" To: "Shekh-Yusef, Rifaat (Rifaat)" , "R.Jesske@telekom.de" , "christer.holmberg@ericsson.com" , "pkyzivat@cisco.com" , "musgravepj@gmail.com" , "splices@ietf.org" Date: Thu, 19 May 2011 15:52:34 +0200 Thread-Topic: [splices] SIP INVOKE method Thread-Index: AcwVgSXc7HGaFOYOS82gk0LsXngJ6QAALKRoAARnCWAAGt3ZsAAJEmOQAAGl2kA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30BF81C197E@MCHP058A.global-ad.net> References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> , <4DD401F4.6050502@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3A6@ESESSCMS0356.eemea.ericsson.se> <6369CB70BFD88942B9705AC1E639A33822CBE5CBD4@DC-US1MBEX4.global.avaya.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E94313@HE111648.emea1.cds.t-internal.com> <6369CB70BFD88942B9705AC1E639A33822CBE5D0D3@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBE5D0D3@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] SIP INVOKE method X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 13:53:21 -0000 Hi, I agree with Roland and would also like see a statement on what requirement= s are being addressed by this draft. I also don't see the how this draft relates to the SPLICES WG the charter f= or which states: "The objective of this working group is to develop a framework for disaggre= gated media in "loosely-coupled" scenarios, where no single device needs to= remain in the session for its entire duration and no single device needs t= o act as a master". I was not really convinced that the draft-yusef-dispath-action-ref addresse= d the same problem space as covered by the SPLICES charter however it seeme= d that at least there was a chance that it could be one possible use case. = However the INVOKE draft seems very far removed from what SPLICES was set u= p to achieve. The SPLICES WG charter also states: "While the framework may describe how to use existing mechanisms (e.g., the= SIP REFER method) to coordinate devices, the working group will not develo= p new device coordination mechanisms". Is this draft defining a "new device coordination mechanism" ? How does this draft relate to a framework for disaggregated media in loosel= y-coupled scenarios? It looks like it does not so probably should go back t= o DISPATCH. I also agree with others that a body would seem to make more sense and that= an XML body would most likely be needed. Regards Andy > -----Original Message----- > From: splices-bounces@ietf.org > [mailto:splices-bounces@ietf.org] On Behalf Of Shekh-Yusef, > Rifaat (Rifaat) > Sent: 19 May 2011 14:11 > To: R.Jesske@telekom.de; christer.holmberg@ericsson.com; > pkyzivat@cisco.com; musgravepj@gmail.com; splices@ietf.org > Subject: Re: [splices] SIP INVOKE method > > Hi Ronald, > > During the last SPLICES meeting in Prague, we presented the > SIP Action Referral draft, which allows applications to make > a request to a user agent to perform a well defined action. > https://datatracker.ietf.org/doc/draft-yusef-dispatch-action-ref/ > > The SIP Action Referral mechanism uses REFER to invoke an > action, but REFER has many limitation as described in slide 9 > of the attached slide deck presented during the SPLICES WG > meeting. The response we got from the people that expressed > their opinion on this subject was mostly in favor of a new > method to avoid the issues with the REFER method. > > Both the SIP Action Referral and the SIP INVOKE method drafts > have a list of actions that are either not possible or have a > really cumbersome way of invoking them using other SIP methods. > > Hope this helps. > > Regards, > Rifaat > > > > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > Sent: Thursday, May 19, 2011 4:51 AM > > To: Shekh-Yusef, Rifaat (Rifaat); christer.holmberg@ericsson.com; > > pkyzivat@cisco.com; musgravepj@gmail.com; splices@ietf.org > > Subject: AW: [splices] SIP INVOKE method > > > > Dear Rifaat, > > I'm a little puzzled about the whole discussion about a new > Method INVOKE > > without having any defined requirements. > > Is there anywhere a requirements definition where I can see > what is needed. > > For me it looks that INVOKE is a new Method that is aimed > only to be used for > > a "Conferencing (like) service" purposes. > > Are there any more used cases, like other service > invocations like a call > > forwarding, Call Transfer ect.? > > > > What is other than I could do with INVITE, REFER, > SUBSCRIBE/NOTIFY and INFO? > > > > I do not want to destroy your new method but I would like > to see rational > > around it. And how we could use such method in a general way. > > > > Thank you and Best Regards > > > > Roland > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: splices-bounces@ietf.org > > > [mailto:splices-bounces@ietf.org] Im Auftrag von Shekh-Yusef, > > > Rifaat (Rifaat) > > > Gesendet: Mittwoch, 18. Mai 2011 21:42 > > > An: Christer Holmberg; Paul Kyzivat; Peter Musgrave > > > Cc: splices@ietf.org > > > Betreff: Re: [splices] SIP INVOKE method > > > > > > Can you, or someone else, propose some text around this? > > > > > > Regards, > > > Rifaat > > > > > > > -----Original Message----- > > > > From: splices-bounces@ietf.org > > > [mailto:splices-bounces@ietf.org] On Behalf Of > > > > Christer Holmberg > > > > Sent: Wednesday, May 18, 2011 1:35 PM > > > > To: Paul Kyzivat; Peter Musgrave > > > > Cc: splices@ietf.org > > > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > Hi, > > > > > > > > I have a similar comment, regarding the applicability. > > > > > > > > The draft says that each "action" must be represented by a > > > URN that is defined > > > > by IANA. > > > > > > > > But, there are no restrictions regarding what types of > > > "actions" are allowed - > > > > or even a description about what the criterias for an > > > "action" are in the > > > > first place. > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > ________________________________________ > > > > From: splices-bounces@ietf.org [splices-bounces@ietf.org] > > > On Behalf Of Paul > > > > Kyzivat [pkyzivat@cisco.com] > > > > Sent: Wednesday, May 18, 2011 8:29 PM > > > > To: Peter Musgrave > > > > Cc: splices@ietf.org > > > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > On 5/18/2011 11:43 AM, Peter Musgrave wrote: > > > > > If INVOKE is to become a general method, then I could > > > easily see people > > > > > wanting to use e.g. an XML body to specify an action. If > > > a new method is > > > > > being defined then I would think making it fairly general > > > would be a > > > > > good idea - and limiting an action to one text line in a > > > header might > > > > > be considered limiting. Hence a body would be more flexible. > > > > > > > > > > One the other hand being too general will likely get is > > > into trouble > > > > > again (e.g. the five uses of REFER) - so maybe being very > > > specific is a > > > > > good thing. In this case I could see just a header sufficing. > > > > > > > > > > A very classic dilemma... > > > > > > > > > > Do people feel that a general INVOKE mechanism is missing > > > in SIP - or do > > > > > we want to just focus on UA actions and the SPLICES > requirement? > > > > > > > > I think it needs to be general in the sense of not limited > > > to the set of > > > > things decided at this time. > > > > > > > > But not so general that it becomes a general purpose > tunnel-over-sip > > > > mechanism. There needs to be a scope of applicability. I'm > > > thinking its > > > > limited to controlling the behavior of a sip device with > > > respect to the > > > > mapping of call streams to devices, initiating, terminating and > > > > otherwise managing calls, ... > > > > > > > > AFAIK the main objection to bodies is the need to create a > > > new parser. > > > > With a sip header you take advantage of the sip parser, > > > though you may > > > > need to extend it to handle a new method. Some might > object to XML > > > > bodies in particular because they require a fairly heavy > > > parser, which > > > > can be a problem in limited devices. In some other > devices of course > > > > that stuff is already present and so no burden. > > > > > > > > Of course sip headers are just a special case of mime > > > headers. Were we > > > > to choose as a body type another extension of mime, then it > > > might still > > > > be possible to reuse a parser. > > > > > > > > This clearly requires more discussion. > > > > > > > > We might want to bring in a security guru sooner rather > > > than later. I > > > > think there will likely be many concerns to be addressed, > > > and addressing > > > > them may constrain the shape of the solution. > > > > > > > > > Does this debate need to include sipcore? > > > > > > > > You have me. :-) > > > > > > > > It will certainly involve sipcore at some point. > > > > I think we can explore the options for awhile before > > > worrying too much > > > > about that. I'm more worried about security. > > > > > > > > Thanks, > > > > Paul > > > > > > > > > Peter > > > > > > > > > > > > > > > > > > > > On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) > > > > > > wrote: > > > > > > > > > > Hi Peter, > > > > > > > > > > Yes, I expect others to try to define new category of > > > actions, but > > > > > these must be registered with IANA. > > > > > > > > > > I am not clear on how this strengthens the case for > > > using a body. > > > > > > > > > > Regards, > > > > > > > > > > Rifaat > > > > > > > > > > *From:*Peter Musgrave [mailto:musgravepj@gmail.com > > > > > ] > > > > > *Sent:* Wednesday, May 18, 2011 9:32 AM > > > > > > > > > > > > > > > *To:* Shekh-Yusef, Rifaat (Rifaat) > > > > > *Cc:* Paul Kyzivat; splices@ietf.org > > > > > > > > > > > *Subject:* Re: [splices] SIP INVOKE method > > > > > > > > > > Rifaat, > > > > > > > > > > I agree with Paul - a body may make sense. > > > > > > > > > > If we are going as far as defining a new SIP METHOD - > > > does it make > > > > > sense to have separate problem domains for the URNs? > > > Do we think in > > > > > the future others might want a different "package" of > > > actions for > > > > > some other purpose? If so, I think this strengthens > > > the case for > > > > > using a body. > > > > > > > > > > Peter > > > > > > > > > > On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, > Rifaat (Rifaat) > > > > > > wrote: > > > > > > > > > > Paul, > > > > > > > > > > I am not talking about any intermediary, but > about application > > > > > servers on the call path in an enterprise. > > > > > Some application servers might be interested in a > > > specific action to > > > > > push application to the phone. > > > > > I agree that strong security is required and we > are asking the > > > > > client to only allow authorized users to invoke > an action by > > > > > challenging the INVOKE-Issuer. > > > > > > > > > > Regards, > > > > > Rifaat > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > > > > > ] > > > > > > Sent: Wednesday, May 18, 2011 8:58 AM > > > > > > To: Shekh-Yusef, Rifaat (Rifaat) > > > > > > > > > > > Cc: splices@ietf.org > > > > > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > > > > > > > > > > > > > > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat > (Rifaat) wrote: > > > > > > > Hi Paul, > > > > > > > > > > > > > > I think that the main reason for using Headers > > > for actions and > > > > > parameters is > > > > > > to allow for proxy applications on the call path > > > to recognize the > > > > > requested > > > > > > action, as some UAs might encrypt the body part. > > > > > > > > > > > > Hmm. That seems to me to be more reason to use > a body part! > > > > > > > > > > > > What possible reason would an intermediary have > > > for snooping into > > > > > these > > > > > > actions? > > > > > > > > > > > > Note that this functionality is *very* sensitive - > > > in the wrong hands > > > > > > this stuff can do great damage. I predict that > > > there will be a lot of > > > > > > demand for very strong security > considerations. Putting the > > > > > action in a > > > > > > body and encrypting it might be a good approach. > > > > > > > > > > > > Thanks, > > > > > > Paul > > > > > > > > > > > > > Regards, > > > > > > > Rifaat > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: splices-bounces@ietf.org > > > > > > > > [mailto:splices-bounces@ietf.org > > > > > ] On Behalf > > > > > > Of > > > > > > >> Paul Kyzivat > > > > > > >> Sent: Tuesday, May 17, 2011 3:09 PM > > > > > > >> To: splices@ietf.org > > > > > > >> Subject: Re: [splices] SIP INVOKE method > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat > > > (Rifaat) wrote: > > > > > > >> > > > > > > >>> Yes, and I have the following open > question about these > > > > > parameters: > > > > > > >>> Should a separate header be defined for action > > > parameters? > > > > > > >> > > > > > > >> I can be convinced otherwise (by a good > > > justification), but > > > > > I'm inclined > > > > > > >> toward describing the action and any parameters > > > in a body part. > > > > > > >> > > > > > > >> Thanks, > > > > > > >> Paul > > > > > > >> _______________________________________________ > > > > > > >> splices mailing list > > > > > > >> splices@ietf.org > > > > > > >> https://www.ietf.org/mailman/listinfo/splices > > > > > > > > > > > > _______________________________________________ > > > > > splices mailing list > > > > > splices@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/splices > > > > > > > > > > > > > > _______________________________________________ > > > > splices mailing list > > > > splices@ietf.org > > > > https://www.ietf.org/mailman/listinfo/splices > > > > _______________________________________________ > > > > splices mailing list > > > > splices@ietf.org > > > > https://www.ietf.org/mailman/listinfo/splices > > > _______________________________________________ > > > splices mailing list > > > splices@ietf.org > > > https://www.ietf.org/mailman/listinfo/splices > > > > From rifatyu@avaya.com Sat May 21 05:56:06 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AA2E06B4 for ; Sat, 21 May 2011 05:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCsWz2Wje1cT for ; Sat, 21 May 2011 05:56:05 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 414F4E06AB for ; Sat, 21 May 2011 05:56:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMq1103GmAcF/2dsb2JhbACmHnikMoNZApsPhhkElF2KRQ X-IronPort-AV: E=Sophos;i="4.65,246,1304308800"; d="scan'208";a="189438161" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 May 2011 08:56:03 -0400 X-IronPort-AV: E=Sophos;i="4.65,246,1304308800"; d="scan'208";a="624728611" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 May 2011 08:56:03 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Sat, 21 May 2011 08:56:03 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "splices@ietf.org" Date: Sat, 21 May 2011 08:56:01 -0400 Thread-Topic: [splices] Answering an A/V Call Using Two Separate Devices proposal Thread-Index: AcwXtm++XGJ0x3m2SCeYSbgdzkETtA== Message-ID: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2011 12:56:06 -0000 Hi, We are still working on a new version of the INVOKE document that removes t= he implicit subscription. Meanwhile I would like to continue the discussion of the various possible u= ses cases. The following is a proposal for Answering an A/V Call Using Two Separate De= vices. Regards, Rifaat Alice Alice Proxy Bob PC Desk Phone =20 | | | | | | | | Both Alice's devices subscribe to the reg event package, which allows each = device to=20 discover the capabilities of the other device based on the feature tags pro= vided by each device. The Desk Phone knows that the PC supports Video, while the PC knows that th= e Desk Phone only supports audio. | | | | | | SUBSCRIBE reg | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | SUBSCRIBE reg | | | |------------------------------------------>| | | 200 OK | | | |<------------------------------------------| | | | | | | | | | The two devices also subscribe to the dialog of each other. | | | | | | | | | SUBSCRIBE dialog | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | | SUBSCRIBE dialog | | | |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | | | | | The scenario starts with an A/V call from Bob to Alice | | | | | | | INVITE Alice [A/V] | | | |<--------------------| | | INVITE Alice [A/V] | | | |<--------------------| | | INVITE Alice [A/V] | | | |<------------------------------------------| | | | | | (*) Let's assume that Alice used her PC to answer the incoming call The PC instructs the phone to answer the audio call =20 | | | | | INVOKE Action: urn:invoke:call:answer;media=3Daudio;transducer=3Dspea= ker|headset |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | | | 200 OK [Audio] | | | |-------------------->| | | | | 200 OK [Audio] | | | |-------------------->| | CANCEL | | | |<------------------------------------------| | | | | | | |<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | | | | The PC then adds Video to the existing audio call. | | | | | INVITE with Join [Video] | | |-------------------->| | | | 100 | | | |<--------------------| | | | | re-INVITE [A/V] | | | |-------------------->| | | | | re-INVITE [A/V] | | | |-------------------->| | | | 200 OK [A/V] | | | 200 OK [A/V] |<--------------------| | |<--------------------| | | 200 OK [Video] | | | |<--------------------| | | | | | | |<------dialog2------>|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | | | | The scenario continues after the (*) above Let's assume that Alice used her phone to answer the incoming call. The phone answers the audio call | | | | | | 200 OK [Audio] | | | |-------------------->| | | | | 200 OK [Audio] | | | |-------------------->| | CANCEL | | | |<------------------------------------------| | | | | | | |<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | | | | The phone then instructs the PC to initiate a video call to join the existi= ng call | | | | | INVOKE Action: urn:invoke:call:join;media=3Dvideo;dialog=3Ddialog1 |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | The PC then adds Video to the existing audio call. | | | | | INVITE with Join [Video] | | |-------------------->| | | | 100 | | | |<--------------------| | | | | re-INVITE [A/V] | | | |-------------------->| | | | | re-INVITE [A/V] | | | |-------------------->| | | | 200 OK [A/V] | | | 200 OK [A/V] |<--------------------| | |<--------------------| | | 200 OK [Video] | | | |<--------------------| | | | | | | |<------dialog2------>|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | From pkyzivat@cisco.com Sat May 21 20:15:17 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F283E06BE for ; Sat, 21 May 2011 20:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.495 X-Spam-Level: X-Spam-Status: No, score=-108.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKbB4AYZC71M for ; Sat, 21 May 2011 20:15:16 -0700 (PDT) Received: from ams-iport-2.cisco.com (unknown [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD91E062B for ; Sat, 21 May 2011 20:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=10350; q=dns/txt; s=iport; t=1306034116; x=1307243716; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=V4TXa22vfhh+vyz9NOP29DdDEeK6zJgZK3i4B7NluvY=; b=QDGCMPN6dpDvpiDl7KsT0d0Bz/C3PK6QLPNbmBzC/V3Zl0JBb9s8VL1o i77+WvlXhJnLx795O9v3NDpIpscdud/C4XQRNi3OaDJ6i3XhLgfcIhXqk X892o3pgY4ZV4tWPnd2VvJUvtgVjoB8qLftKI1Dt7j/tqRbToux8wBDuu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsDAJp/2E2Q/khLgWdsb2JhbACmIBQBARYmJqZ1nEKGGQSQEYQvimI X-IronPort-AV: E=Sophos;i="4.65,250,1304294400"; d="scan'208";a="31575163" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 22 May 2011 03:15:13 +0000 Received: from [10.86.241.244] (che-vpn-cluster-1-499.cisco.com [10.86.241.244]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4M3FCl2027691 for ; Sun, 22 May 2011 03:15:12 GMT Message-ID: <4DD87FBF.5010504@cisco.com> Date: Sat, 21 May 2011 23:15:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: splices@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 03:15:17 -0000 I guess all of that can work. But for the last part, if the phone knows enough to send the invoke to the pc, why can't it just send an INVITE to the pc? Thanks, Paul On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Hi, > > We are still working on a new version of the INVOKE document that removes the implicit subscription. > > Meanwhile I would like to continue the discussion of the various possible uses cases. > The following is a proposal for Answering an A/V Call Using Two Separate Devices. > > Regards, > Rifaat > > > > Alice Alice Proxy Bob > PC Desk Phone > | | | | > | | | | > Both Alice's devices subscribe to the reg event package, which allows each device to > discover the capabilities of the other device based on the feature tags provided by each device. > The Desk Phone knows that the PC supports Video, while the PC knows that the Desk Phone only supports audio. > | | | | > | | SUBSCRIBE reg | | > | |-------------------->| | > | | 200 OK | | > | |<--------------------| | > | | | | > | SUBSCRIBE reg | | | > |------------------------------------------>| | > | 200 OK | | | > |<------------------------------------------| | > | | | | > | | | | > The two devices also subscribe to the dialog of each other. > | | | | > | | | | > | SUBSCRIBE dialog | | | > |-------------------->| | | > | 200 OK | | | > |<--------------------| | | > | | | | > | SUBSCRIBE dialog | | | > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | > | | | | > The scenario starts with an A/V call from Bob to Alice > | | | | > | | | INVITE Alice [A/V] | > | | |<--------------------| > | | INVITE Alice [A/V] | | > | |<--------------------| | > | INVITE Alice [A/V] | | | > |<------------------------------------------| | > | | | | > > > (*) > > > Let's assume that Alice used her PC to answer the incoming call > The PC instructs the phone to answer the audio call > | | | | > | INVOKE Action: urn:invoke:call:answer;media=audio;transducer=speaker|headset > |-------------------->| | | > | 200 OK | | | > |<--------------------| | | > | | | | > | | 200 OK [Audio] | | > | |-------------------->| | > | | | 200 OK [Audio] | > | | |-------------------->| > | CANCEL | | | > |<------------------------------------------| | > | | | | > | |<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > | | | | > | | | | > The PC then adds Video to the existing audio call. > | | | | > | INVITE with Join [Video] | | > |-------------------->| | | > | 100 | | | > |<--------------------| | | > | | re-INVITE [A/V] | | > | |-------------------->| | > | | | re-INVITE [A/V] | > | | |-------------------->| > | | | 200 OK [A/V] | > | | 200 OK [A/V] |<--------------------| > | |<--------------------| | > | 200 OK [Video] | | | > |<--------------------| | | > | | | | > |<------dialog2------>|<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > |<============================video==============================>| > | | | | > | | | | > > > > The scenario continues after the (*) above > Let's assume that Alice used her phone to answer the incoming call. > The phone answers the audio call > | | | | > | | 200 OK [Audio] | | > | |-------------------->| | > | | | 200 OK [Audio] | > | | |-------------------->| > | CANCEL | | | > |<------------------------------------------| | > | | | | > | |<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > | | | | > | | | | > The phone then instructs the PC to initiate a video call to join the existing call > | | | | > | INVOKE Action: urn:invoke:call:join;media=video;dialog=dialog1 > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | > The PC then adds Video to the existing audio call. > | | | | > | INVITE with Join [Video] | | > |-------------------->| | | > | 100 | | | > |<--------------------| | | > | | re-INVITE [A/V] | | > | |-------------------->| | > | | | re-INVITE [A/V] | > | | |-------------------->| > | | | 200 OK [A/V] | > | | 200 OK [A/V] |<--------------------| > | |<--------------------| | > | 200 OK [Video] | | | > |<--------------------| | | > | | | | > |<------dialog2------>|<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > |<============================video==============================>| > | | | | > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > From pkyzivat@cisco.com Sun May 22 14:08:48 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5635E06A0 for ; Sun, 22 May 2011 14:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1CvZ87zHNQF for ; Sun, 22 May 2011 14:08:47 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id 70BB2E068F for ; Sun, 22 May 2011 14:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=12113; q=dns/txt; s=iport; t=1306098527; x=1307308127; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZikMHP58NGe4Rfu3/YdK86kEX9dHQytt8z4laiJ7F60=; b=RF4Ob4ekVPZf3GaybowqBnk1sAUZfciV6LBQYuxnnCfSLBSW/P6p2VxB Pq+b2uoaOSgBuWHMK/ta5JGV8h2EG3GiKI1PAlcrQeyvRn41n8geo/YYO gnprdyywc4vhGDC2L8ZB1JxuZE5BPeup7ngUSH52g9ggFYNWIwXkwrV+J s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAKN62U2tJV2c/2dsb2JhbACXZY47eIhwnWmcRIYZBJARhC+KYg X-IronPort-AV: E=Sophos;i="4.65,253,1304294400"; d="scan'208";a="234308625" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 22 May 2011 21:08:46 +0000 Received: from [10.86.244.32] ([10.86.244.32]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p4ML8jEg013169; Sun, 22 May 2011 21:08:45 GMT Message-ID: <4DD97B5D.7040404@cisco.com> Date: Sun, 22 May 2011 17:08:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "splices@ietf.org" Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 21:08:48 -0000 On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Because a new INVITE will probably cause the PC to present the user with a UI component and wait for the users input. Well, I suppose you would want the PC to indicate what is going on in the UI in *some* way. But probably not exactly the same as getting a new call. That could be handled via appropriate Alert-Info. To some extent this is a matter of taste. I am inclined to prefer an economy of mechanism, and I think the alert-info feels like less mechanism than the particular INVOKE mechanism used in this scenario. (The invoke mechanism used here requires the phone to assume that the PC is aware of the dialog, and able to associate it with the appropriate contact address for doing the invite.) Thanks, Paul > Regards, > Rifaat > > >> -----Original Message----- >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Saturday, May 21, 2011 11:15 PM >> To: splices@ietf.org >> Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices >> proposal >> >> I guess all of that can work. But for the last part, if the phone knows >> enough to send the invoke to the pc, why can't it just send an INVITE to >> the pc? >> >> Thanks, >> Paul >> >> On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>> Hi, >>> >>> We are still working on a new version of the INVOKE document that removes >> the implicit subscription. >>> >>> Meanwhile I would like to continue the discussion of the various possible >> uses cases. >>> The following is a proposal for Answering an A/V Call Using Two Separate >> Devices. >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> Alice Alice Proxy Bob >>> PC Desk Phone >>> | | | | >>> | | | | >>> Both Alice's devices subscribe to the reg event package, which allows each >> device to >>> discover the capabilities of the other device based on the feature tags >> provided by each device. >>> The Desk Phone knows that the PC supports Video, while the PC knows that the >> Desk Phone only supports audio. >>> | | | | >>> | | SUBSCRIBE reg | | >>> | |-------------------->| | >>> | | 200 OK | | >>> | |<--------------------| | >>> | | | | >>> | SUBSCRIBE reg | | | >>> |------------------------------------------>| | >>> | 200 OK | | | >>> |<------------------------------------------| | >>> | | | | >>> | | | | >>> The two devices also subscribe to the dialog of each other. >>> | | | | >>> | | | | >>> | SUBSCRIBE dialog | | | >>> |-------------------->| | | >>> | 200 OK | | | >>> |<--------------------| | | >>> | | | | >>> | SUBSCRIBE dialog | | | >>> |<--------------------| | | >>> | 200 OK | | | >>> |-------------------->| | | >>> | | | | >>> | | | | >>> The scenario starts with an A/V call from Bob to Alice >>> | | | | >>> | | | INVITE Alice [A/V] | >>> | | |<--------------------| >>> | | INVITE Alice [A/V] | | >>> | |<--------------------| | >>> | INVITE Alice [A/V] | | | >>> |<------------------------------------------| | >>> | | | | >>> >>> >>> (*) >>> >>> >>> Let's assume that Alice used her PC to answer the incoming call >>> The PC instructs the phone to answer the audio call >>> | | | | >>> | INVOKE Action: >> urn:invoke:call:answer;media=audio;transducer=speaker|headset >>> |-------------------->| | | >>> | 200 OK | | | >>> |<--------------------| | | >>> | | | | >>> | | 200 OK [Audio] | | >>> | |-------------------->| | >>> | | | 200 OK [Audio] | >>> | | |-------------------->| >>> | CANCEL | | | >>> |<------------------------------------------| | >>> | | | | >>> | |<---dialog1------------------------------->| >>> | | | | >>> | |<======audio==============================>| >>> | | | | >>> | | | | >>> The PC then adds Video to the existing audio call. >>> | | | | >>> | INVITE with Join [Video] | | >>> |-------------------->| | | >>> | 100 | | | >>> |<--------------------| | | >>> | | re-INVITE [A/V] | | >>> | |-------------------->| | >>> | | | re-INVITE [A/V] | >>> | | |-------------------->| >>> | | | 200 OK [A/V] | >>> | | 200 OK [A/V] |<--------------------| >>> | |<--------------------| | >>> | 200 OK [Video] | | | >>> |<--------------------| | | >>> | | | | >>> |<------dialog2------>|<---dialog1------------------------------->| >>> | | | | >>> | |<======audio==============================>| >>> |<============================video==============================>| >>> | | | | >>> | | | | >>> >>> >>> >>> The scenario continues after the (*) above >>> Let's assume that Alice used her phone to answer the incoming call. >>> The phone answers the audio call >>> | | | | >>> | | 200 OK [Audio] | | >>> | |-------------------->| | >>> | | | 200 OK [Audio] | >>> | | |-------------------->| >>> | CANCEL | | | >>> |<------------------------------------------| | >>> | | | | >>> | |<---dialog1------------------------------->| >>> | | | | >>> | |<======audio==============================>| >>> | | | | >>> | | | | >>> The phone then instructs the PC to initiate a video call to join the >> existing call >>> | | | | >>> | INVOKE Action: urn:invoke:call:join;media=video;dialog=dialog1 >>> |<--------------------| | | >>> | 200 OK | | | >>> |-------------------->| | | >>> | | | | >>> The PC then adds Video to the existing audio call. >>> | | | | >>> | INVITE with Join [Video] | | >>> |-------------------->| | | >>> | 100 | | | >>> |<--------------------| | | >>> | | re-INVITE [A/V] | | >>> | |-------------------->| | >>> | | | re-INVITE [A/V] | >>> | | |-------------------->| >>> | | | 200 OK [A/V] | >>> | | 200 OK [A/V] |<--------------------| >>> | |<--------------------| | >>> | 200 OK [Video] | | | >>> |<--------------------| | | >>> | | | | >>> |<------dialog2------>|<---dialog1------------------------------->| >>> | | | | >>> | |<======audio==============================>| >>> |<============================video==============================>| >>> | | | | >>> >>> >>> >>> _______________________________________________ >>> splices mailing list >>> splices@ietf.org >>> https://www.ietf.org/mailman/listinfo/splices >>> >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> https://www.ietf.org/mailman/listinfo/splices > From rifatyu@avaya.com Sun May 22 15:08:02 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C04EE06BD for ; Sun, 22 May 2011 15:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tjVw4TKpOQc for ; Sun, 22 May 2011 15:08:01 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id B7B87E068F for ; Sun, 22 May 2011 15:08:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABAONX2U2HCzI1/2dsb2JhbACXY447eKk3Apl+hhkElF2KRQ X-IronPort-AV: E=Sophos;i="4.65,252,1304308800"; d="scan'208";a="189532882" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 May 2011 14:40:10 -0400 X-IronPort-AV: E=Sophos;i="4.65,252,1304308800"; d="scan'208";a="654840578" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 May 2011 14:40:10 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Sun, 22 May 2011 14:40:10 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat , "splices@ietf.org" Date: Sun, 22 May 2011 14:40:07 -0400 Thread-Topic: [splices] Answering an A/V Call Using Two Separate Devices proposal Thread-Index: AcwYLoVKx8Bbr9VlSxmbWISQihJELQAf7vlQ Message-ID: <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> In-Reply-To: <4DD87FBF.5010504@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 22:08:02 -0000 Because a new INVITE will probably cause the PC to present the user with a = UI component and wait for the users input. Regards, Rifaat > -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Paul Kyzivat > Sent: Saturday, May 21, 2011 11:15 PM > To: splices@ietf.org > Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices > proposal >=20 > I guess all of that can work. But for the last part, if the phone knows > enough to send the invoke to the pc, why can't it just send an INVITE to > the pc? >=20 > Thanks, > Paul >=20 > On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi, > > > > We are still working on a new version of the INVOKE document that remov= es > the implicit subscription. > > > > Meanwhile I would like to continue the discussion of the various possib= le > uses cases. > > The following is a proposal for Answering an A/V Call Using Two Separat= e > Devices. > > > > Regards, > > Rifaat > > > > > > > > Alice Alice Proxy B= ob > > PC Desk Phone > > | | | = | > > | | | = | > > Both Alice's devices subscribe to the reg event package, which allows e= ach > device to > > discover the capabilities of the other device based on the feature tags > provided by each device. > > The Desk Phone knows that the PC supports Video, while the PC knows tha= t the > Desk Phone only supports audio. > > | | | = | > > | | SUBSCRIBE reg | = | > > | |-------------------->| = | > > | | 200 OK | = | > > | |<--------------------| = | > > | | | = | > > | SUBSCRIBE reg | | = | > > |------------------------------------------>| = | > > | 200 OK | | = | > > |<------------------------------------------| = | > > | | | = | > > | | | = | > > The two devices also subscribe to the dialog of each other. > > | | | = | > > | | | = | > > | SUBSCRIBE dialog | | = | > > |-------------------->| | = | > > | 200 OK | | = | > > |<--------------------| | = | > > | | | = | > > | SUBSCRIBE dialog | | = | > > |<--------------------| | = | > > | 200 OK | | = | > > |-------------------->| | = | > > | | | = | > > | | | = | > > The scenario starts with an A/V call from Bob to Alice > > | | | = | > > | | | INVITE Alice [A/V] = | > > | | |<--------------------= | > > | | INVITE Alice [A/V] | = | > > | |<--------------------| = | > > | INVITE Alice [A/V] | | = | > > |<------------------------------------------| = | > > | | | = | > > > > > > (*) > > > > > > Let's assume that Alice used her PC to answer the incoming call > > The PC instructs the phone to answer the audio call > > | | | = | > > | INVOKE Action: > urn:invoke:call:answer;media=3Daudio;transducer=3Dspeaker|headset > > |-------------------->| | = | > > | 200 OK | | = | > > |<--------------------| | = | > > | | | = | > > | | 200 OK [Audio] | = | > > | |-------------------->| = | > > | | | 200 OK [Audio] = | > > | | |-------------------->= | > > | CANCEL | | = | > > |<------------------------------------------| = | > > | | | = | > > | |<---dialog1------------------------------->= | > > | | | = | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | = | > > | | | = | > > The PC then adds Video to the existing audio call. > > | | | = | > > | INVITE with Join [Video] | = | > > |-------------------->| | = | > > | 100 | | = | > > |<--------------------| | = | > > | | re-INVITE [A/V] | = | > > | |-------------------->| = | > > | | | re-INVITE [A/V] = | > > | | |-------------------->= | > > | | | 200 OK [A/V] = | > > | | 200 OK [A/V] |<--------------------= | > > | |<--------------------| = | > > | 200 OK [Video] | | = | > > |<--------------------| | = | > > | | | = | > > |<------dialog2------>|<---dialog1------------------------------->= | > > | | | = | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | = | > > | | | = | > > > > > > > > The scenario continues after the (*) above > > Let's assume that Alice used her phone to answer the incoming call. > > The phone answers the audio call > > | | | = | > > | | 200 OK [Audio] | = | > > | |-------------------->| = | > > | | | 200 OK [Audio] = | > > | | |-------------------->= | > > | CANCEL | | = | > > |<------------------------------------------| = | > > | | | = | > > | |<---dialog1------------------------------->= | > > | | | = | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | = | > > | | | = | > > The phone then instructs the PC to initiate a video call to join the > existing call > > | | | = | > > | INVOKE Action: urn:invoke:call:join;media=3Dvideo;dialog=3Ddialo= g1 > > |<--------------------| | = | > > | 200 OK | | = | > > |-------------------->| | = | > > | | | = | > > The PC then adds Video to the existing audio call. > > | | | = | > > | INVITE with Join [Video] | = | > > |-------------------->| | = | > > | 100 | | = | > > |<--------------------| | = | > > | | re-INVITE [A/V] | = | > > | |-------------------->| = | > > | | | re-INVITE [A/V] = | > > | | |-------------------->= | > > | | | 200 OK [A/V] = | > > | | 200 OK [A/V] |<--------------------= | > > | |<--------------------| = | > > | 200 OK [Video] | | = | > > |<--------------------| | = | > > | | | = | > > |<------dialog2------>|<---dialog1------------------------------->= | > > | | | = | > > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | = | > > > > > > > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From rifatyu@avaya.com Sun May 22 17:49:14 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75B6E06A6 for ; Sun, 22 May 2011 17:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.807 X-Spam-Level: X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh5Zx-zY9DQ6 for ; Sun, 22 May 2011 17:49:13 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8B445E06EB for ; Sun, 22 May 2011 17:49:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAKyt2U3GmAcF/2dsb2JhbACXZY47eKhwApoFhhkElF2KRQ X-IronPort-AV: E=Sophos;i="4.65,253,1304308800"; d="scan'208";a="189551739" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 May 2011 20:49:12 -0400 X-IronPort-AV: E=Sophos;i="4.65,253,1304308800"; d="scan'208";a="625009168" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 May 2011 20:49:11 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Sun, 22 May 2011 20:49:11 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat Date: Sun, 22 May 2011 20:49:05 -0400 Thread-Topic: [splices] Answering an A/V Call Using Two Separate Devices proposal Thread-Index: AcwYxHJm3RlB/CYMRgaACXkylS9PhQAG8Gjg Message-ID: <6369CB70BFD88942B9705AC1E639A33822CC7FCE75@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> <4DD97B5D.7040404@cisco.com> In-Reply-To: <4DD97B5D.7040404@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 00:49:15 -0000 You are then proposing the following: Alice used her *phone* to answer the incoming call | | | | | | 200 OK [Audio] | | | |-------------------->| | | | | 200 OK [Audio] | | | |-------------------->| | CANCEL | | | |<------------------------------------------| | | | | | | |<---dialog1------------------------------->| | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | INVITE Alert-Info and [Video] | | |<--------------------| | | What happens here? Will the user be required to take an action on the PC to accept the INVITE? Or you are expecting the PC to provide an answer without user intervention? | 200 OK [Video] | | | |<--------------------| | | | | re-INVITE [A/V] | | | |-------------------->| | | | | re-INVITE [A/V] | | | |-------------------->| | | | 200 OK [A/V] | | | 200 OK [A/V] |<--------------------| | |<--------------------| | | ACK | | | |<--------------------| | | | | | | |<------dialog2------>|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Sunday, May 22, 2011 5:09 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org > Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices > proposal > > > > On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Because a new INVITE will probably cause the PC to present the user wit= h a > UI component and wait for the users input. > > Well, I suppose you would want the PC to indicate what is going on in > the UI in *some* way. But probably not exactly the same as getting a new > call. > > That could be handled via appropriate Alert-Info. To some extent this is > a matter of taste. I am inclined to prefer an economy of mechanism, and > I think the alert-info feels like less mechanism than the particular > INVOKE mechanism used in this scenario. (The invoke mechanism used here > requires the phone to assume that the PC is aware of the dialog, and > able to associate it with the appropriate contact address for doing the > invite.) > > Thanks, > Paul > > > Regards, > > Rifaat > > > > > >> -----Original Message----- > >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Be= half > Of > >> Paul Kyzivat > >> Sent: Saturday, May 21, 2011 11:15 PM > >> To: splices@ietf.org > >> Subject: Re: [splices] Answering an A/V Call Using Two Separate Device= s > >> proposal > >> > >> I guess all of that can work. But for the last part, if the phone know= s > >> enough to send the invoke to the pc, why can't it just send an INVITE = to > >> the pc? > >> > >> Thanks, > >> Paul > >> > >> On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > >>> Hi, > >>> > >>> We are still working on a new version of the INVOKE document that rem= oves > >> the implicit subscription. > >>> > >>> Meanwhile I would like to continue the discussion of the various poss= ible > >> uses cases. > >>> The following is a proposal for Answering an A/V Call Using Two Separ= ate > >> Devices. > >>> > >>> Regards, > >>> Rifaat > >>> > >>> > >>> > >>> Alice Alice Proxy = Bob > >>> PC Desk Phone > >>> | | | = | > >>> | | | = | > >>> Both Alice's devices subscribe to the reg event package, which allows= each > >> device to > >>> discover the capabilities of the other device based on the feature ta= gs > >> provided by each device. > >>> The Desk Phone knows that the PC supports Video, while the PC knows t= hat > the > >> Desk Phone only supports audio. > >>> | | | = | > >>> | | SUBSCRIBE reg | = | > >>> | |-------------------->| = | > >>> | | 200 OK | = | > >>> | |<--------------------| = | > >>> | | | = | > >>> | SUBSCRIBE reg | | = | > >>> |------------------------------------------>| = | > >>> | 200 OK | | = | > >>> |<------------------------------------------| = | > >>> | | | = | > >>> | | | = | > >>> The two devices also subscribe to the dialog of each other. > >>> | | | = | > >>> | | | = | > >>> | SUBSCRIBE dialog | | = | > >>> |-------------------->| | = | > >>> | 200 OK | | = | > >>> |<--------------------| | = | > >>> | | | = | > >>> | SUBSCRIBE dialog | | = | > >>> |<--------------------| | = | > >>> | 200 OK | | = | > >>> |-------------------->| | = | > >>> | | | = | > >>> | | | = | > >>> The scenario starts with an A/V call from Bob to Alice > >>> | | | = | > >>> | | | INVITE Alice [A/V= ] | > >>> | | |<-----------------= ---| > >>> | | INVITE Alice [A/V] | = | > >>> | |<--------------------| = | > >>> | INVITE Alice [A/V] | | = | > >>> |<------------------------------------------| = | > >>> | | | = | > >>> > >>> > >>> (*) > >>> > >>> > >>> Let's assume that Alice used her PC to answer the incoming call > >>> The PC instructs the phone to answer the audio call > >>> | | | = | > >>> | INVOKE Action: > >> urn:invoke:call:answer;media=3Daudio;transducer=3Dspeaker|headset > >>> |-------------------->| | = | > >>> | 200 OK | | = | > >>> |<--------------------| | = | > >>> | | | = | > >>> | | 200 OK [Audio] | = | > >>> | |-------------------->| = | > >>> | | | 200 OK [Audio] = | > >>> | | |------------------= -->| > >>> | CANCEL | | = | > >>> |<------------------------------------------| = | > >>> | | | = | > >>> | |<---dialog1-----------------------------= -->| > >>> | | | = | > >>> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >| > >>> | | | = | > >>> | | | = | > >>> The PC then adds Video to the existing audio call. > >>> | | | = | > >>> | INVITE with Join [Video] | = | > >>> |-------------------->| | = | > >>> | 100 | | = | > >>> |<--------------------| | = | > >>> | | re-INVITE [A/V] | = | > >>> | |-------------------->| = | > >>> | | | re-INVITE [A/V] = | > >>> | | |------------------= -->| > >>> | | | 200 OK [A/V] = | > >>> | | 200 OK [A/V] |<-----------------= ---| > >>> | |<--------------------| = | > >>> | 200 OK [Video] | | = | > >>> |<--------------------| | = | > >>> | | | = | > >>> |<------dialog2------>|<---dialog1-----------------------------= -->| > >>> | | | = | > >>> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >| > >>> |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > >>> | | | = | > >>> | | | = | > >>> > >>> > >>> > >>> The scenario continues after the (*) above > >>> Let's assume that Alice used her phone to answer the incoming call. > >>> The phone answers the audio call > >>> | | | = | > >>> | | 200 OK [Audio] | = | > >>> | |-------------------->| = | > >>> | | | 200 OK [Audio] = | > >>> | | |------------------= -->| > >>> | CANCEL | | = | > >>> |<------------------------------------------| = | > >>> | | | = | > >>> | |<---dialog1-----------------------------= -->| > >>> | | | = | > >>> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >| > >>> | | | = | > >>> | | | = | > >>> The phone then instructs the PC to initiate a video call to join the > >> existing call > >>> | | | = | > >>> | INVOKE Action: urn:invoke:call:join;media=3Dvideo;dialog=3Ddi= alog1 > >>> |<--------------------| | = | > >>> | 200 OK | | = | > >>> |-------------------->| | = | > >>> | | | = | > >>> The PC then adds Video to the existing audio call. > >>> | | | = | > >>> | INVITE with Join [Video] | = | > >>> |-------------------->| | = | > >>> | 100 | | = | > >>> |<--------------------| | = | > >>> | | re-INVITE [A/V] | = | > >>> | |-------------------->| = | > >>> | | | re-INVITE [A/V] = | > >>> | | |------------------= -->| > >>> | | | 200 OK [A/V] = | > >>> | | 200 OK [A/V] |<-----------------= ---| > >>> | |<--------------------| = | > >>> | 200 OK [Video] | | = | > >>> |<--------------------| | = | > >>> | | | = | > >>> |<------dialog2------>|<---dialog1-----------------------------= -->| > >>> | | | = | > >>> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >| > >>> |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > >>> | | | = | > >>> > >>> > >>> > >>> _______________________________________________ > >>> splices mailing list > >>> splices@ietf.org > >>> https://www.ietf.org/mailman/listinfo/splices > >>> > >> _______________________________________________ > >> splices mailing list > >> splices@ietf.org > >> https://www.ietf.org/mailman/listinfo/splices > > From pkyzivat@cisco.com Sun May 22 20:03:06 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BEDE06EE for ; Sun, 22 May 2011 20:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFAJL+T1VG7V for ; Sun, 22 May 2011 20:03:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 54974E06A4 for ; Sun, 22 May 2011 20:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=15962; q=dns/txt; s=iport; t=1306119785; x=1307329385; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cvG+PjofaSea4HPQyIDJTlH4mJa0oTGf9ZgboX73jqo=; b=fOM9L+z4Yba5k52QCKJjSiLwGng7XHszIviY4qkPMJTvKEH1665V+AKt DEjkM7EBTGvHbAofydYg/N8zYHtaHKzUZHMlMm23JHUKL3X6Ckcg5JHkM hAKcIlq8zIrCHUfk9Uqah0CYmcjZ2XKLwGmXxIbC5LEnXC04h2J85U/WF U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUBAOPN2U2tJXHB/2dsb2JhbACXZY47eKUvnEWGGQSQEYQvimI X-IronPort-AV: E=Sophos;i="4.65,254,1304294400"; d="scan'208";a="285661870" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 23 May 2011 03:03:04 +0000 Received: from [10.86.244.32] ([10.86.244.32]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p4N333SX032559; Mon, 23 May 2011 03:03:03 GMT Message-ID: <4DD9CE66.8010204@cisco.com> Date: Sun, 22 May 2011 23:03:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> <4DD97B5D.7040404@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE75@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CC7FCE75@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "splices@ietf.org" Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 03:03:06 -0000 On 5/22/2011 8:49 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > You are then proposing the following: > > > Alice used her *phone* to answer the incoming call > | | | | > | | 200 OK [Audio] | | > | |-------------------->| | > | | | 200 OK [Audio] | > | | |-------------------->| > | CANCEL | | | > |<------------------------------------------| | > | | | | > | |<---dialog1------------------------------->| > | |<======audio==============================>| > | | | | > | INVITE Alert-Info and [Video] | | > |<--------------------| | | > > What happens here? > Will the user be required to take an action on the PC to accept the INVITE? > Or you are expecting the PC to provide an answer without user intervention? Could be handled various ways. The alert-info could suggest auto-answer. (The PC *honoring* such a request might be conditional on who it comes. But even if not honored for auto-answer it might still alert *differently*.) If it wasn't auto-answered, and returned 180, it could be followed up with an INVOKE to force the answer. Thanks, Paul > | 200 OK [Video] | | | > |<--------------------| | | > | | re-INVITE [A/V] | | > | |-------------------->| | > | | | re-INVITE [A/V] | > | | |-------------------->| > | | | 200 OK [A/V] | > | | 200 OK [A/V] |<--------------------| > | |<--------------------| | > | ACK | | | > |<--------------------| | | > | | | | > |<------dialog2------>|<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > |<============================video==============================>| > | | | | > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Sunday, May 22, 2011 5:09 PM >> To: Shekh-Yusef, Rifaat (Rifaat) >> Cc: splices@ietf.org >> Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices >> proposal >> >> >> >> On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>> Because a new INVITE will probably cause the PC to present the user with a >> UI component and wait for the users input. >> >> Well, I suppose you would want the PC to indicate what is going on in >> the UI in *some* way. But probably not exactly the same as getting a new >> call. >> >> That could be handled via appropriate Alert-Info. To some extent this is >> a matter of taste. I am inclined to prefer an economy of mechanism, and >> I think the alert-info feels like less mechanism than the particular >> INVOKE mechanism used in this scenario. (The invoke mechanism used here >> requires the phone to assume that the PC is aware of the dialog, and >> able to associate it with the appropriate contact address for doing the >> invite.) >> >> Thanks, >> Paul >> >>> Regards, >>> Rifaat >>> >>> >>>> -----Original Message----- >>>> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf >> Of >>>> Paul Kyzivat >>>> Sent: Saturday, May 21, 2011 11:15 PM >>>> To: splices@ietf.org >>>> Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices >>>> proposal >>>> >>>> I guess all of that can work. But for the last part, if the phone knows >>>> enough to send the invoke to the pc, why can't it just send an INVITE to >>>> the pc? >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>>>> Hi, >>>>> >>>>> We are still working on a new version of the INVOKE document that removes >>>> the implicit subscription. >>>>> >>>>> Meanwhile I would like to continue the discussion of the various possible >>>> uses cases. >>>>> The following is a proposal for Answering an A/V Call Using Two Separate >>>> Devices. >>>>> >>>>> Regards, >>>>> Rifaat >>>>> >>>>> >>>>> >>>>> Alice Alice Proxy Bob >>>>> PC Desk Phone >>>>> | | | | >>>>> | | | | >>>>> Both Alice's devices subscribe to the reg event package, which allows each >>>> device to >>>>> discover the capabilities of the other device based on the feature tags >>>> provided by each device. >>>>> The Desk Phone knows that the PC supports Video, while the PC knows that >> the >>>> Desk Phone only supports audio. >>>>> | | | | >>>>> | | SUBSCRIBE reg | | >>>>> | |-------------------->| | >>>>> | | 200 OK | | >>>>> | |<--------------------| | >>>>> | | | | >>>>> | SUBSCRIBE reg | | | >>>>> |------------------------------------------>| | >>>>> | 200 OK | | | >>>>> |<------------------------------------------| | >>>>> | | | | >>>>> | | | | >>>>> The two devices also subscribe to the dialog of each other. >>>>> | | | | >>>>> | | | | >>>>> | SUBSCRIBE dialog | | | >>>>> |-------------------->| | | >>>>> | 200 OK | | | >>>>> |<--------------------| | | >>>>> | | | | >>>>> | SUBSCRIBE dialog | | | >>>>> |<--------------------| | | >>>>> | 200 OK | | | >>>>> |-------------------->| | | >>>>> | | | | >>>>> | | | | >>>>> The scenario starts with an A/V call from Bob to Alice >>>>> | | | | >>>>> | | | INVITE Alice [A/V] | >>>>> | | |<--------------------| >>>>> | | INVITE Alice [A/V] | | >>>>> | |<--------------------| | >>>>> | INVITE Alice [A/V] | | | >>>>> |<------------------------------------------| | >>>>> | | | | >>>>> >>>>> >>>>> (*) >>>>> >>>>> >>>>> Let's assume that Alice used her PC to answer the incoming call >>>>> The PC instructs the phone to answer the audio call >>>>> | | | | >>>>> | INVOKE Action: >>>> urn:invoke:call:answer;media=audio;transducer=speaker|headset >>>>> |-------------------->| | | >>>>> | 200 OK | | | >>>>> |<--------------------| | | >>>>> | | | | >>>>> | | 200 OK [Audio] | | >>>>> | |-------------------->| | >>>>> | | | 200 OK [Audio] | >>>>> | | |-------------------->| >>>>> | CANCEL | | | >>>>> |<------------------------------------------| | >>>>> | | | | >>>>> | |<---dialog1------------------------------->| >>>>> | | | | >>>>> | |<======audio==============================>| >>>>> | | | | >>>>> | | | | >>>>> The PC then adds Video to the existing audio call. >>>>> | | | | >>>>> | INVITE with Join [Video] | | >>>>> |-------------------->| | | >>>>> | 100 | | | >>>>> |<--------------------| | | >>>>> | | re-INVITE [A/V] | | >>>>> | |-------------------->| | >>>>> | | | re-INVITE [A/V] | >>>>> | | |-------------------->| >>>>> | | | 200 OK [A/V] | >>>>> | | 200 OK [A/V] |<--------------------| >>>>> | |<--------------------| | >>>>> | 200 OK [Video] | | | >>>>> |<--------------------| | | >>>>> | | | | >>>>> |<------dialog2------>|<---dialog1------------------------------->| >>>>> | | | | >>>>> | |<======audio==============================>| >>>>> |<============================video==============================>| >>>>> | | | | >>>>> | | | | >>>>> >>>>> >>>>> >>>>> The scenario continues after the (*) above >>>>> Let's assume that Alice used her phone to answer the incoming call. >>>>> The phone answers the audio call >>>>> | | | | >>>>> | | 200 OK [Audio] | | >>>>> | |-------------------->| | >>>>> | | | 200 OK [Audio] | >>>>> | | |-------------------->| >>>>> | CANCEL | | | >>>>> |<------------------------------------------| | >>>>> | | | | >>>>> | |<---dialog1------------------------------->| >>>>> | | | | >>>>> | |<======audio==============================>| >>>>> | | | | >>>>> | | | | >>>>> The phone then instructs the PC to initiate a video call to join the >>>> existing call >>>>> | | | | >>>>> | INVOKE Action: urn:invoke:call:join;media=video;dialog=dialog1 >>>>> |<--------------------| | | >>>>> | 200 OK | | | >>>>> |-------------------->| | | >>>>> | | | | >>>>> The PC then adds Video to the existing audio call. >>>>> | | | | >>>>> | INVITE with Join [Video] | | >>>>> |-------------------->| | | >>>>> | 100 | | | >>>>> |<--------------------| | | >>>>> | | re-INVITE [A/V] | | >>>>> | |-------------------->| | >>>>> | | | re-INVITE [A/V] | >>>>> | | |-------------------->| >>>>> | | | 200 OK [A/V] | >>>>> | | 200 OK [A/V] |<--------------------| >>>>> | |<--------------------| | >>>>> | 200 OK [Video] | | | >>>>> |<--------------------| | | >>>>> | | | | >>>>> |<------dialog2------>|<---dialog1------------------------------->| >>>>> | | | | >>>>> | |<======audio==============================>| >>>>> |<============================video==============================>| >>>>> | | | | >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> splices mailing list >>>>> splices@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/splices >>>>> >>>> _______________________________________________ >>>> splices mailing list >>>> splices@ietf.org >>>> https://www.ietf.org/mailman/listinfo/splices >>> > From rifatyu@avaya.com Mon May 23 05:56:22 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9334EE0791 for ; Mon, 23 May 2011 05:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1bG+it1kQmt for ; Mon, 23 May 2011 05:56:21 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6463CE06A8 for ; Mon, 23 May 2011 05:56:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBABJY2k3GmAcF/2dsb2JhbACXZo4+d6ddAppIhhkElF2KRQ X-IronPort-AV: E=Sophos;i="4.65,256,1304308800"; d="scan'208";a="189627015" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 May 2011 08:56:19 -0400 X-IronPort-AV: E=Sophos;i="4.65,256,1304308800"; d="scan'208";a="625173874" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 May 2011 08:56:19 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 23 May 2011 08:56:18 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat Date: Mon, 23 May 2011 08:56:18 -0400 Thread-Topic: [splices] Answering an A/V Call Using Two Separate Devices proposal Thread-Index: AcwY9fMjzXFqQJgZRauC1dkxrEkfoAAUfv8E Message-ID: <6369CB70BFD88942B9705AC1E639A33822CC7FB9A1@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> <4DD97B5D.7040404@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE75@DC-US1MBEX4.global.avaya.com>, <4DD9CE66.8010204@cisco.com> In-Reply-To: <4DD9CE66.8010204@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 12:56:22 -0000 I do not see how this proposal is "less mechanism" than the original propos= al, but I tend to agree with you that this might be "a matter of taste". Regards, Rifaat ________________________________________ From: Paul Kyzivat [pkyzivat@cisco.com] Sent: Sunday, May 22, 2011 11:03 PM To: Shekh-Yusef, Rifaat (Rifaat) Cc: splices@ietf.org Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices pro= posal On 5/22/2011 8:49 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > You are then proposing the following: > > > Alice used her *phone* to answer the incoming call > | | | | > | | 200 OK [Audio] | | > | |-------------------->| | > | | | 200 OK [Audio] | > | | |-------------------->| > | CANCEL | | | > |<------------------------------------------| | > | | | | > | |<---dialog1------------------------------->| > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > | | | | > | INVITE Alert-Info and [Video] | | > |<--------------------| | | > > What happens here? > Will the user be required to take an action on the PC to accept the INVIT= E? > Or you are expecting the PC to provide an answer without user interventio= n? Could be handled various ways. The alert-info could suggest auto-answer. (The PC *honoring* such a request might be conditional on who it comes. But even if not honored for auto-answer it might still alert *differently*.) If it wasn't auto-answered, and returned 180, it could be followed up with an INVOKE to force the answer. Thanks, Paul > | 200 OK [Video] | | | > |<--------------------| | | > | | re-INVITE [A/V] | | > | |-------------------->| | > | | | re-INVITE [A/V] | > | | |-------------------->| > | | | 200 OK [A/V] | > | | 200 OK [A/V] |<--------------------| > | |<--------------------| | > | ACK | | | > |<--------------------| | | > | | | | > |<------dialog2------>|<---dialog1------------------------------->| > | | | | > | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > | | | | > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Sunday, May 22, 2011 5:09 PM >> To: Shekh-Yusef, Rifaat (Rifaat) >> Cc: splices@ietf.org >> Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices >> proposal >> >> >> >> On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>> Because a new INVITE will probably cause the PC to present the user wit= h a >> UI component and wait for the users input. >> >> Well, I suppose you would want the PC to indicate what is going on in >> the UI in *some* way. But probably not exactly the same as getting a new >> call. >> >> That could be handled via appropriate Alert-Info. To some extent this is >> a matter of taste. I am inclined to prefer an economy of mechanism, and >> I think the alert-info feels like less mechanism than the particular >> INVOKE mechanism used in this scenario. (The invoke mechanism used here >> requires the phone to assume that the PC is aware of the dialog, and >> able to associate it with the appropriate contact address for doing the >> invite.) >> >> Thanks, >> Paul >> >>> Regards, >>> Rifaat >>> >>> >>>> -----Original Message----- >>>> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Be= half >> Of >>>> Paul Kyzivat >>>> Sent: Saturday, May 21, 2011 11:15 PM >>>> To: splices@ietf.org >>>> Subject: Re: [splices] Answering an A/V Call Using Two Separate Device= s >>>> proposal >>>> >>>> I guess all of that can work. But for the last part, if the phone know= s >>>> enough to send the invoke to the pc, why can't it just send an INVITE = to >>>> the pc? >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>>>> Hi, >>>>> >>>>> We are still working on a new version of the INVOKE document that rem= oves >>>> the implicit subscription. >>>>> >>>>> Meanwhile I would like to continue the discussion of the various poss= ible >>>> uses cases. >>>>> The following is a proposal for Answering an A/V Call Using Two Separ= ate >>>> Devices. >>>>> >>>>> Regards, >>>>> Rifaat >>>>> >>>>> >>>>> >>>>> Alice Alice Proxy = Bob >>>>> PC Desk Phone >>>>> | | | = | >>>>> | | | = | >>>>> Both Alice's devices subscribe to the reg event package, which allows= each >>>> device to >>>>> discover the capabilities of the other device based on the feature ta= gs >>>> provided by each device. >>>>> The Desk Phone knows that the PC supports Video, while the PC knows t= hat >> the >>>> Desk Phone only supports audio. >>>>> | | | = | >>>>> | | SUBSCRIBE reg | = | >>>>> | |-------------------->| = | >>>>> | | 200 OK | = | >>>>> | |<--------------------| = | >>>>> | | | = | >>>>> | SUBSCRIBE reg | | = | >>>>> |------------------------------------------>| = | >>>>> | 200 OK | | = | >>>>> |<------------------------------------------| = | >>>>> | | | = | >>>>> | | | = | >>>>> The two devices also subscribe to the dialog of each other. >>>>> | | | = | >>>>> | | | = | >>>>> | SUBSCRIBE dialog | | = | >>>>> |-------------------->| | = | >>>>> | 200 OK | | = | >>>>> |<--------------------| | = | >>>>> | | | = | >>>>> | SUBSCRIBE dialog | | = | >>>>> |<--------------------| | = | >>>>> | 200 OK | | = | >>>>> |-------------------->| | = | >>>>> | | | = | >>>>> | | | = | >>>>> The scenario starts with an A/V call from Bob to Alice >>>>> | | | = | >>>>> | | | INVITE Alice [A/= V] | >>>>> | | |<----------------= ----| >>>>> | | INVITE Alice [A/V] | = | >>>>> | |<--------------------| = | >>>>> | INVITE Alice [A/V] | | = | >>>>> |<------------------------------------------| = | >>>>> | | | = | >>>>> >>>>> >>>>> (*) >>>>> >>>>> >>>>> Let's assume that Alice used her PC to answer the incoming call >>>>> The PC instructs the phone to answer the audio call >>>>> | | | = | >>>>> | INVOKE Action: >>>> urn:invoke:call:answer;media=3Daudio;transducer=3Dspeaker|headset >>>>> |-------------------->| | = | >>>>> | 200 OK | | = | >>>>> |<--------------------| | = | >>>>> | | | = | >>>>> | | 200 OK [Audio] | = | >>>>> | |-------------------->| = | >>>>> | | | 200 OK [Audio] = | >>>>> | | |-----------------= --->| >>>>> | CANCEL | | = | >>>>> |<------------------------------------------| = | >>>>> | | | = | >>>>> | |<---dialog1----------------------------= --->| >>>>> | | | = | >>>>> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >| >>>>> | | | = | >>>>> | | | = | >>>>> The PC then adds Video to the existing audio call. >>>>> | | | = | >>>>> | INVITE with Join [Video] | = | >>>>> |-------------------->| | = | >>>>> | 100 | | = | >>>>> |<--------------------| | = | >>>>> | | re-INVITE [A/V] | = | >>>>> | |-------------------->| = | >>>>> | | | re-INVITE [A/V] = | >>>>> | | |-----------------= --->| >>>>> | | | 200 OK [A/V] = | >>>>> | | 200 OK [A/V] |<----------------= ----| >>>>> | |<--------------------| = | >>>>> | 200 OK [Video] | | = | >>>>> |<--------------------| | = | >>>>> | | | = | >>>>> |<------dialog2------>|<---dialog1----------------------------= --->| >>>>> | | | = | >>>>> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >| >>>>> |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| >>>>> | | | = | >>>>> | | | = | >>>>> >>>>> >>>>> >>>>> The scenario continues after the (*) above >>>>> Let's assume that Alice used her phone to answer the incoming call. >>>>> The phone answers the audio call >>>>> | | | = | >>>>> | | 200 OK [Audio] | = | >>>>> | |-------------------->| = | >>>>> | | | 200 OK [Audio] = | >>>>> | | |-----------------= --->| >>>>> | CANCEL | | = | >>>>> |<------------------------------------------| = | >>>>> | | | = | >>>>> | |<---dialog1----------------------------= --->| >>>>> | | | = | >>>>> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >| >>>>> | | | = | >>>>> | | | = | >>>>> The phone then instructs the PC to initiate a video call to join the >>>> existing call >>>>> | | | = | >>>>> | INVOKE Action: urn:invoke:call:join;media=3Dvideo;dialog=3Dd= ialog1 >>>>> |<--------------------| | = | >>>>> | 200 OK | | = | >>>>> |-------------------->| | = | >>>>> | | | = | >>>>> The PC then adds Video to the existing audio call. >>>>> | | | = | >>>>> | INVITE with Join [Video] | = | >>>>> |-------------------->| | = | >>>>> | 100 | | = | >>>>> |<--------------------| | = | >>>>> | | re-INVITE [A/V] | = | >>>>> | |-------------------->| = | >>>>> | | | re-INVITE [A/V] = | >>>>> | | |-----------------= --->| >>>>> | | | 200 OK [A/V] = | >>>>> | | 200 OK [A/V] |<----------------= ----| >>>>> | |<--------------------| = | >>>>> | 200 OK [Video] | | = | >>>>> |<--------------------| | = | >>>>> | | | = | >>>>> |<------dialog2------>|<---dialog1----------------------------= --->| >>>>> | | | = | >>>>> | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >| >>>>> |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| >>>>> | | | = | >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> splices mailing list >>>>> splices@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/splices >>>>> >>>> _______________________________________________ >>>> splices mailing list >>>> splices@ietf.org >>>> https://www.ietf.org/mailman/listinfo/splices >>> > From pkyzivat@cisco.com Mon May 23 06:07:41 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8700EE0796 for ; Mon, 23 May 2011 06:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.199 X-Spam-Level: X-Spam-Status: No, score=-109.199 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRgkxzKKwynU for ; Mon, 23 May 2011 06:07:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (unknown [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 647D1E0783 for ; Mon, 23 May 2011 06:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=17865; q=dns/txt; s=iport; t=1306156059; x=1307365659; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=61fqVAsXEyUgK/VRHFXwQvleeBdz2LT5SBrMbEktLyw=; b=MHNquikHCl6OBDzLRTxLQyp0VwTmKqvf6CM2CVndq92vHutZ+VdpwSz0 tMvWkNlCUZvTItiYad2LS3iQjqjIdpFV2pYbvv+ZJtlB3K9Je0s8juYb1 qdK6FruDoBWUS9lagYBgbUzywhn7063H3VdvqWdGbxyrAsSvdxu4ITC77 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIAAJRb2k2Q/khLgWdsb2JhbACXZo4+FAEBFiYliHCcQ50KhhkEkBGEL4pi X-IronPort-AV: E=Sophos;i="4.65,256,1304294400"; d="scan'208";a="90188979" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 23 May 2011 13:07:38 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4ND7bfT000817; Mon, 23 May 2011 13:07:37 GMT Message-ID: <4DDA5C19.5040405@cisco.com> Date: Mon, 23 May 2011 09:07:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> <4DD97B5D.7040404@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE75@DC-US1MBEX4.global.avaya.com>, <4DD9CE66.8010204@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FB9A1@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CC7FB9A1@DC-US1MBEX4.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "splices@ietf.org" Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 13:07:41 -0000 On 5/23/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > I do not see how this proposal is "less mechanism" than the original proposal, but I tend to agree with you that this might be "a matter of taste". The devil is in the details here, and we don't have enough details. So its all in the set of assumptions one is making. In the end we probably aren't going to standardize services - just mechanisms for creating services. But perhaps we will have an "examples" doc that shows how the mechanisms might be used to create a range of interesting services such as these. If so, I would think we would need to work through each one in detail, carefully defining all the assumptions about the environment. And that is really what it takes to decide on each particular "action", because those seem to be rather specialized. At the moment I don't have a vision of a clear and obvious set of actions that enable all the interesting services. Its more a matter of crafting an action to support one or a few services. I wish it was more clear cut than that. Maybe it will become so with more study. Thanks, Paul > Regards, > Rifaat > > > > ________________________________________ > From: Paul Kyzivat [pkyzivat@cisco.com] > Sent: Sunday, May 22, 2011 11:03 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org > Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal > > On 5/22/2011 8:49 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> >> You are then proposing the following: >> >> >> Alice used her *phone* to answer the incoming call >> | | | | >> | | 200 OK [Audio] | | >> | |-------------------->| | >> | | | 200 OK [Audio] | >> | | |-------------------->| >> | CANCEL | | | >> |<------------------------------------------| | >> | | | | >> | |<---dialog1------------------------------->| >> | |<======audio==============================>| >> | | | | >> | INVITE Alert-Info and [Video] | | >> |<--------------------| | | >> >> What happens here? >> Will the user be required to take an action on the PC to accept the INVITE? >> Or you are expecting the PC to provide an answer without user intervention? > > Could be handled various ways. > > The alert-info could suggest auto-answer. (The PC *honoring* such a > request might be conditional on who it comes. But even if not honored > for auto-answer it might still alert *differently*.) If it wasn't > auto-answered, and returned 180, it could be followed up with an INVOKE > to force the answer. > > Thanks, > Paul > >> | 200 OK [Video] | | | >> |<--------------------| | | >> | | re-INVITE [A/V] | | >> | |-------------------->| | >> | | | re-INVITE [A/V] | >> | | |-------------------->| >> | | | 200 OK [A/V] | >> | | 200 OK [A/V] |<--------------------| >> | |<--------------------| | >> | ACK | | | >> |<--------------------| | | >> | | | | >> |<------dialog2------>|<---dialog1------------------------------->| >> | | | | >> | |<======audio==============================>| >> |<============================video==============================>| >> | | | | >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Sunday, May 22, 2011 5:09 PM >>> To: Shekh-Yusef, Rifaat (Rifaat) >>> Cc: splices@ietf.org >>> Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices >>> proposal >>> >>> >>> >>> On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>>> Because a new INVITE will probably cause the PC to present the user with a >>> UI component and wait for the users input. >>> >>> Well, I suppose you would want the PC to indicate what is going on in >>> the UI in *some* way. But probably not exactly the same as getting a new >>> call. >>> >>> That could be handled via appropriate Alert-Info. To some extent this is >>> a matter of taste. I am inclined to prefer an economy of mechanism, and >>> I think the alert-info feels like less mechanism than the particular >>> INVOKE mechanism used in this scenario. (The invoke mechanism used here >>> requires the phone to assume that the PC is aware of the dialog, and >>> able to associate it with the appropriate contact address for doing the >>> invite.) >>> >>> Thanks, >>> Paul >>> >>>> Regards, >>>> Rifaat >>>> >>>> >>>>> -----Original Message----- >>>>> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf >>> Of >>>>> Paul Kyzivat >>>>> Sent: Saturday, May 21, 2011 11:15 PM >>>>> To: splices@ietf.org >>>>> Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices >>>>> proposal >>>>> >>>>> I guess all of that can work. But for the last part, if the phone knows >>>>> enough to send the invoke to the pc, why can't it just send an INVITE to >>>>> the pc? >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>>>>> Hi, >>>>>> >>>>>> We are still working on a new version of the INVOKE document that removes >>>>> the implicit subscription. >>>>>> >>>>>> Meanwhile I would like to continue the discussion of the various possible >>>>> uses cases. >>>>>> The following is a proposal for Answering an A/V Call Using Two Separate >>>>> Devices. >>>>>> >>>>>> Regards, >>>>>> Rifaat >>>>>> >>>>>> >>>>>> >>>>>> Alice Alice Proxy Bob >>>>>> PC Desk Phone >>>>>> | | | | >>>>>> | | | | >>>>>> Both Alice's devices subscribe to the reg event package, which allows each >>>>> device to >>>>>> discover the capabilities of the other device based on the feature tags >>>>> provided by each device. >>>>>> The Desk Phone knows that the PC supports Video, while the PC knows that >>> the >>>>> Desk Phone only supports audio. >>>>>> | | | | >>>>>> | | SUBSCRIBE reg | | >>>>>> | |-------------------->| | >>>>>> | | 200 OK | | >>>>>> | |<--------------------| | >>>>>> | | | | >>>>>> | SUBSCRIBE reg | | | >>>>>> |------------------------------------------>| | >>>>>> | 200 OK | | | >>>>>> |<------------------------------------------| | >>>>>> | | | | >>>>>> | | | | >>>>>> The two devices also subscribe to the dialog of each other. >>>>>> | | | | >>>>>> | | | | >>>>>> | SUBSCRIBE dialog | | | >>>>>> |-------------------->| | | >>>>>> | 200 OK | | | >>>>>> |<--------------------| | | >>>>>> | | | | >>>>>> | SUBSCRIBE dialog | | | >>>>>> |<--------------------| | | >>>>>> | 200 OK | | | >>>>>> |-------------------->| | | >>>>>> | | | | >>>>>> | | | | >>>>>> The scenario starts with an A/V call from Bob to Alice >>>>>> | | | | >>>>>> | | | INVITE Alice [A/V] | >>>>>> | | |<--------------------| >>>>>> | | INVITE Alice [A/V] | | >>>>>> | |<--------------------| | >>>>>> | INVITE Alice [A/V] | | | >>>>>> |<------------------------------------------| | >>>>>> | | | | >>>>>> >>>>>> >>>>>> (*) >>>>>> >>>>>> >>>>>> Let's assume that Alice used her PC to answer the incoming call >>>>>> The PC instructs the phone to answer the audio call >>>>>> | | | | >>>>>> | INVOKE Action: >>>>> urn:invoke:call:answer;media=audio;transducer=speaker|headset >>>>>> |-------------------->| | | >>>>>> | 200 OK | | | >>>>>> |<--------------------| | | >>>>>> | | | | >>>>>> | | 200 OK [Audio] | | >>>>>> | |-------------------->| | >>>>>> | | | 200 OK [Audio] | >>>>>> | | |-------------------->| >>>>>> | CANCEL | | | >>>>>> |<------------------------------------------| | >>>>>> | | | | >>>>>> | |<---dialog1------------------------------->| >>>>>> | | | | >>>>>> | |<======audio==============================>| >>>>>> | | | | >>>>>> | | | | >>>>>> The PC then adds Video to the existing audio call. >>>>>> | | | | >>>>>> | INVITE with Join [Video] | | >>>>>> |-------------------->| | | >>>>>> | 100 | | | >>>>>> |<--------------------| | | >>>>>> | | re-INVITE [A/V] | | >>>>>> | |-------------------->| | >>>>>> | | | re-INVITE [A/V] | >>>>>> | | |-------------------->| >>>>>> | | | 200 OK [A/V] | >>>>>> | | 200 OK [A/V] |<--------------------| >>>>>> | |<--------------------| | >>>>>> | 200 OK [Video] | | | >>>>>> |<--------------------| | | >>>>>> | | | | >>>>>> |<------dialog2------>|<---dialog1------------------------------->| >>>>>> | | | | >>>>>> | |<======audio==============================>| >>>>>> |<============================video==============================>| >>>>>> | | | | >>>>>> | | | | >>>>>> >>>>>> >>>>>> >>>>>> The scenario continues after the (*) above >>>>>> Let's assume that Alice used her phone to answer the incoming call. >>>>>> The phone answers the audio call >>>>>> | | | | >>>>>> | | 200 OK [Audio] | | >>>>>> | |-------------------->| | >>>>>> | | | 200 OK [Audio] | >>>>>> | | |-------------------->| >>>>>> | CANCEL | | | >>>>>> |<------------------------------------------| | >>>>>> | | | | >>>>>> | |<---dialog1------------------------------->| >>>>>> | | | | >>>>>> | |<======audio==============================>| >>>>>> | | | | >>>>>> | | | | >>>>>> The phone then instructs the PC to initiate a video call to join the >>>>> existing call >>>>>> | | | | >>>>>> | INVOKE Action: urn:invoke:call:join;media=video;dialog=dialog1 >>>>>> |<--------------------| | | >>>>>> | 200 OK | | | >>>>>> |-------------------->| | | >>>>>> | | | | >>>>>> The PC then adds Video to the existing audio call. >>>>>> | | | | >>>>>> | INVITE with Join [Video] | | >>>>>> |-------------------->| | | >>>>>> | 100 | | | >>>>>> |<--------------------| | | >>>>>> | | re-INVITE [A/V] | | >>>>>> | |-------------------->| | >>>>>> | | | re-INVITE [A/V] | >>>>>> | | |-------------------->| >>>>>> | | | 200 OK [A/V] | >>>>>> | | 200 OK [A/V] |<--------------------| >>>>>> | |<--------------------| | >>>>>> | 200 OK [Video] | | | >>>>>> |<--------------------| | | >>>>>> | | | | >>>>>> |<------dialog2------>|<---dialog1------------------------------->| >>>>>> | | | | >>>>>> | |<======audio==============================>| >>>>>> |<============================video==============================>| >>>>>> | | | | >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> splices mailing list >>>>>> splices@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/splices >>>>>> >>>>> _______________________________________________ >>>>> splices mailing list >>>>> splices@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/splices >>>> >> > From musgravepj@gmail.com Tue May 24 05:41:55 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F02E06E9 for ; Tue, 24 May 2011 05:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJjOFfB2+YCN for ; Tue, 24 May 2011 05:41:53 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E370E068C for ; Tue, 24 May 2011 05:41:53 -0700 (PDT) Received: by fxm15 with SMTP id 15so5196277fxm.31 for ; Tue, 24 May 2011 05:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GrB0P4UhpQ35wOWHTnC00mpIp18WzIma9kq4nV5rOzc=; b=aKmvEmiXyGX/pPie7u/OUwls7P6+eZ2BZotCMFFLcmrN4406jdyuP0uvDNSYqDGkt2 TrFa/x6hwF18LFdmWPTXP2PUhclD8W7pj5QEGsrXXmmrLFhaNt11bJYnYoH9hbKd+Jxf d2o5EASBGBu5TBPY2lzMSMClid/0DK7nJc44w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Hq7/ps0vXnIgj4MMo4r8UI9WWKJx7d0Z4GWCDHIPrBwhABAskXw8nOWaF3/uJuqO2G TkD07QaMPj7rxnfjtU/J8TzsOavK6QEPgNV/dmTwCRg5dNldlegp1z1NjBrc7p6mqTQ7 5sc6Mc3PA6JvC88siPXPRCT/oxo662zM9RzQA= MIME-Version: 1.0 Received: by 10.223.33.6 with SMTP id f6mr3685994fad.85.1306240912226; Tue, 24 May 2011 05:41:52 -0700 (PDT) Received: by 10.223.116.209 with HTTP; Tue, 24 May 2011 05:41:52 -0700 (PDT) In-Reply-To: <4DDA5C19.5040405@cisco.com> References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> <4DD97B5D.7040404@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE75@DC-US1MBEX4.global.avaya.com> <4DD9CE66.8010204@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FB9A1@DC-US1MBEX4.global.avaya.com> <4DDA5C19.5040405@cisco.com> Date: Tue, 24 May 2011 08:41:52 -0400 Message-ID: From: Peter Musgrave To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0015174780bc90785a04a404e914 Cc: "splices@ietf.org" Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 12:41:55 -0000 --0015174780bc90785a04a404e914 Content-Type: text/plain; charset=ISO-8859-1 I agree with Paul that: 1) This works ok. 2) INVOKE is more mechanism than a new header. [A method is a bigger deal than a header] I'd also observe in a "real politik" sense that the potential energy barrier to geting a new SIP method in place will likely be significant. I would expect it would have to be a dispatch-ed WG all on it's own. People will decide to either use it to solve world hunger - or decide that it is the root of all evil. Under "out there" ideas - would it be possible to put the Action header in a PUBLISH? Would this allow the same signalling semantics as INVOKE without the need for a new method? Peter Musgrave On Mon, May 23, 2011 at 9:07 AM, Paul Kyzivat wrote: > > > On 5/23/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > >> I do not see how this proposal is "less mechanism" than the original >> proposal, but I tend to agree with you that this might be "a matter of >> taste". >> > > The devil is in the details here, and we don't have enough details. > So its all in the set of assumptions one is making. > > In the end we probably aren't going to standardize services - just > mechanisms for creating services. But perhaps we will have an "examples" doc > that shows how the mechanisms might be used to create a range of interesting > services such as these. If so, I would think we would need to work through > each one in detail, carefully defining all the assumptions about the > environment. > > And that is really what it takes to decide on each particular "action", > because those seem to be rather specialized. At the moment I don't have a > vision of a clear and obvious set of actions that enable all the interesting > services. Its more a matter of crafting an action to support one or a few > services. I wish it was more clear cut than that. Maybe it will become so > with more study. > > Thanks, > Paul > > > Regards, >> Rifaat >> >> >> >> ________________________________________ >> From: Paul Kyzivat [pkyzivat@cisco.com] >> Sent: Sunday, May 22, 2011 11:03 PM >> To: Shekh-Yusef, Rifaat (Rifaat) >> Cc: splices@ietf.org >> Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices >> proposal >> >> On 5/22/2011 8:49 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> >>> >>> You are then proposing the following: >>> >>> >>> Alice used her *phone* to answer the incoming call >>> | | | | >>> | | 200 OK [Audio] | | >>> | |-------------------->| | >>> | | | 200 OK [Audio] | >>> | | |-------------------->| >>> | CANCEL | | | >>> |<------------------------------------------| | >>> | | | | >>> | |<---dialog1------------------------------->| >>> | |<======audio==============================>| >>> | | | | >>> | INVITE Alert-Info and [Video] | | >>> |<--------------------| | | >>> >>> What happens here? >>> Will the user be required to take an action on the PC to accept the >>> INVITE? >>> Or you are expecting the PC to provide an answer without user >>> intervention? >>> >> >> Could be handled various ways. >> >> The alert-info could suggest auto-answer. (The PC *honoring* such a >> request might be conditional on who it comes. But even if not honored >> for auto-answer it might still alert *differently*.) If it wasn't >> auto-answered, and returned 180, it could be followed up with an INVOKE >> to force the answer. >> >> Thanks, >> Paul >> >> | 200 OK [Video] | | | >>> |<--------------------| | | >>> | | re-INVITE [A/V] | | >>> | |-------------------->| | >>> | | | re-INVITE [A/V] | >>> | | |-------------------->| >>> | | | 200 OK [A/V] | >>> | | 200 OK [A/V] |<--------------------| >>> | |<--------------------| | >>> | ACK | | | >>> |<--------------------| | | >>> | | | | >>> |<------dialog2------>|<---dialog1------------------------------->| >>> | | | | >>> | |<======audio==============================>| >>> |<============================video==============================>| >>> | | | | >>> >>> >>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Sunday, May 22, 2011 5:09 PM >>>> To: Shekh-Yusef, Rifaat (Rifaat) >>>> Cc: splices@ietf.org >>>> Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices >>>> proposal >>>> >>>> >>>> >>>> On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>>> >>>>> Because a new INVITE will probably cause the PC to present the user >>>>> with a >>>>> >>>> UI component and wait for the users input. >>>> >>>> Well, I suppose you would want the PC to indicate what is going on in >>>> the UI in *some* way. But probably not exactly the same as getting a new >>>> call. >>>> >>>> That could be handled via appropriate Alert-Info. To some extent this is >>>> a matter of taste. I am inclined to prefer an economy of mechanism, and >>>> I think the alert-info feels like less mechanism than the particular >>>> INVOKE mechanism used in this scenario. (The invoke mechanism used here >>>> requires the phone to assume that the PC is aware of the dialog, and >>>> able to associate it with the appropriate contact address for doing the >>>> invite.) >>>> >>>> Thanks, >>>> Paul >>>> >>>> Regards, >>>>> Rifaat >>>>> >>>>> >>>>> -----Original Message----- >>>>>> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On >>>>>> Behalf >>>>>> >>>>> Of >>>> >>>>> Paul Kyzivat >>>>>> Sent: Saturday, May 21, 2011 11:15 PM >>>>>> To: splices@ietf.org >>>>>> Subject: Re: [splices] Answering an A/V Call Using Two Separate >>>>>> Devices >>>>>> proposal >>>>>> >>>>>> I guess all of that can work. But for the last part, if the phone >>>>>> knows >>>>>> enough to send the invoke to the pc, why can't it just send an INVITE >>>>>> to >>>>>> the pc? >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We are still working on a new version of the INVOKE document that >>>>>>> removes >>>>>>> >>>>>> the implicit subscription. >>>>>> >>>>>>> >>>>>>> Meanwhile I would like to continue the discussion of the various >>>>>>> possible >>>>>>> >>>>>> uses cases. >>>>>> >>>>>>> The following is a proposal for Answering an A/V Call Using Two >>>>>>> Separate >>>>>>> >>>>>> Devices. >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Rifaat >>>>>>> >>>>>>> >>>>>>> >>>>>>> Alice Alice Proxy >>>>>>> Bob >>>>>>> PC Desk Phone >>>>>>> | | | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> Both Alice's devices subscribe to the reg event package, which allows >>>>>>> each >>>>>>> >>>>>> device to >>>>>> >>>>>>> discover the capabilities of the other device based on the feature >>>>>>> tags >>>>>>> >>>>>> provided by each device. >>>>>> >>>>>>> The Desk Phone knows that the PC supports Video, while the PC knows >>>>>>> that >>>>>>> >>>>>> the >>>> >>>>> Desk Phone only supports audio. >>>>>> >>>>>>> | | | >>>>>>> | >>>>>>> | | SUBSCRIBE reg | >>>>>>> | >>>>>>> | |-------------------->| >>>>>>> | >>>>>>> | | 200 OK | >>>>>>> | >>>>>>> | |<--------------------| >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> | SUBSCRIBE reg | | >>>>>>> | >>>>>>> |------------------------------------------>| >>>>>>> | >>>>>>> | 200 OK | | >>>>>>> | >>>>>>> |<------------------------------------------| >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> The two devices also subscribe to the dialog of each other. >>>>>>> | | | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> | SUBSCRIBE dialog | | >>>>>>> | >>>>>>> |-------------------->| | >>>>>>> | >>>>>>> | 200 OK | | >>>>>>> | >>>>>>> |<--------------------| | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> | SUBSCRIBE dialog | | >>>>>>> | >>>>>>> |<--------------------| | >>>>>>> | >>>>>>> | 200 OK | | >>>>>>> | >>>>>>> |-------------------->| | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> The scenario starts with an A/V call from Bob to Alice >>>>>>> | | | >>>>>>> | >>>>>>> | | | INVITE Alice >>>>>>> [A/V] | >>>>>>> | | >>>>>>> |<--------------------| >>>>>>> | | INVITE Alice [A/V] | >>>>>>> | >>>>>>> | |<--------------------| >>>>>>> | >>>>>>> | INVITE Alice [A/V] | | >>>>>>> | >>>>>>> |<------------------------------------------| >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> >>>>>>> >>>>>>> (*) >>>>>>> >>>>>>> >>>>>>> Let's assume that Alice used her PC to answer the incoming call >>>>>>> The PC instructs the phone to answer the audio call >>>>>>> | | | >>>>>>> | >>>>>>> | INVOKE Action: >>>>>>> >>>>>> urn:invoke:call:answer;media=audio;transducer=speaker|headset >>>>>> >>>>>>> |-------------------->| | >>>>>>> | >>>>>>> | 200 OK | | >>>>>>> | >>>>>>> |<--------------------| | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> | | 200 OK [Audio] | >>>>>>> | >>>>>>> | |-------------------->| >>>>>>> | >>>>>>> | | | 200 OK [Audio] >>>>>>> | >>>>>>> | | >>>>>>> |-------------------->| >>>>>>> | CANCEL | | >>>>>>> | >>>>>>> |<------------------------------------------| >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> | >>>>>>> |<---dialog1------------------------------->| >>>>>>> | | | >>>>>>> | >>>>>>> | >>>>>>> |<======audio==============================>| >>>>>>> | | | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> The PC then adds Video to the existing audio call. >>>>>>> | | | >>>>>>> | >>>>>>> | INVITE with Join [Video] | >>>>>>> | >>>>>>> |-------------------->| | >>>>>>> | >>>>>>> | 100 | | >>>>>>> | >>>>>>> |<--------------------| | >>>>>>> | >>>>>>> | | re-INVITE [A/V] | >>>>>>> | >>>>>>> | |-------------------->| >>>>>>> | >>>>>>> | | | re-INVITE [A/V] >>>>>>> | >>>>>>> | | >>>>>>> |-------------------->| >>>>>>> | | | 200 OK [A/V] >>>>>>> | >>>>>>> | | 200 OK [A/V] >>>>>>> |<--------------------| >>>>>>> | |<--------------------| >>>>>>> | >>>>>>> | 200 OK [Video] | | >>>>>>> | >>>>>>> |<--------------------| | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> >>>>>>> |<------dialog2------>|<---dialog1------------------------------->| >>>>>>> | | | >>>>>>> | >>>>>>> | >>>>>>> |<======audio==============================>| >>>>>>> >>>>>>> |<============================video==============================>| >>>>>>> | | | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> >>>>>>> >>>>>>> >>>>>>> The scenario continues after the (*) above >>>>>>> Let's assume that Alice used her phone to answer the incoming call. >>>>>>> The phone answers the audio call >>>>>>> | | | >>>>>>> | >>>>>>> | | 200 OK [Audio] | >>>>>>> | >>>>>>> | |-------------------->| >>>>>>> | >>>>>>> | | | 200 OK [Audio] >>>>>>> | >>>>>>> | | >>>>>>> |-------------------->| >>>>>>> | CANCEL | | >>>>>>> | >>>>>>> |<------------------------------------------| >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> | >>>>>>> |<---dialog1------------------------------->| >>>>>>> | | | >>>>>>> | >>>>>>> | >>>>>>> |<======audio==============================>| >>>>>>> | | | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> The phone then instructs the PC to initiate a video call to join the >>>>>>> >>>>>> existing call >>>>>> >>>>>>> | | | >>>>>>> | >>>>>>> | INVOKE Action: >>>>>>> urn:invoke:call:join;media=video;dialog=dialog1 >>>>>>> |<--------------------| | >>>>>>> | >>>>>>> | 200 OK | | >>>>>>> | >>>>>>> |-------------------->| | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> The PC then adds Video to the existing audio call. >>>>>>> | | | >>>>>>> | >>>>>>> | INVITE with Join [Video] | >>>>>>> | >>>>>>> |-------------------->| | >>>>>>> | >>>>>>> | 100 | | >>>>>>> | >>>>>>> |<--------------------| | >>>>>>> | >>>>>>> | | re-INVITE [A/V] | >>>>>>> | >>>>>>> | |-------------------->| >>>>>>> | >>>>>>> | | | re-INVITE [A/V] >>>>>>> | >>>>>>> | | >>>>>>> |-------------------->| >>>>>>> | | | 200 OK [A/V] >>>>>>> | >>>>>>> | | 200 OK [A/V] >>>>>>> |<--------------------| >>>>>>> | |<--------------------| >>>>>>> | >>>>>>> | 200 OK [Video] | | >>>>>>> | >>>>>>> |<--------------------| | >>>>>>> | >>>>>>> | | | >>>>>>> | >>>>>>> >>>>>>> |<------dialog2------>|<---dialog1------------------------------->| >>>>>>> | | | >>>>>>> | >>>>>>> | >>>>>>> |<======audio==============================>| >>>>>>> >>>>>>> |<============================video==============================>| >>>>>>> | | | >>>>>>> | >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> splices mailing list >>>>>>> splices@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/splices >>>>>>> >>>>>>> _______________________________________________ >>>>>> splices mailing list >>>>>> splices@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/splices >>>>>> >>>>> >>>>> >>> >> _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > --0015174780bc90785a04a404e914 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIFBhdWwgdGhhdDo8ZGl2PjEpIFRoaXMgd29ya3Mgb2suoDwvZGl2PjxkaXY+ MikgSU5WT0tFIGlzIG1vcmUgbWVjaGFuaXNtIHRoYW4gYSBuZXcgaGVhZGVyLiBbQSBtZXRob2Qg aXMgYSBiaWdnZXIgZGVhbCB0aGFuIGEgaGVhZGVyXTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ SSYjMzk7ZCBhbHNvIG9ic2VydmUgaW4gYSAmcXVvdDtyZWFsIHBvbGl0aWsmcXVvdDsgc2Vuc2Ug dGhhdCB0aGUgcG90ZW50aWFsIGVuZXJneSBiYXJyaWVyIHRvIGdldGluZyBhIG5ldyBTSVAgbWV0 aG9kIGluIHBsYWNlIHdpbGwgbGlrZWx5IGJlIHNpZ25pZmljYW50LiBJIHdvdWxkIGV4cGVjdCBp dCB3b3VsZCBoYXZlIHRvIGJlIGEgZGlzcGF0Y2gtZWQgV0cgYWxsIG9uIGl0JiMzOTtzIG93bi4g UGVvcGxlIHdpbGwgZGVjaWRlIHRvIGVpdGhlciB1c2UgaXQgdG8gc29sdmUgd29ybGQgaHVuZ2Vy IC0gb3IgZGVjaWRlIHRoYXQgaXQgaXMgdGhlIHJvb3Qgb2YgYWxsIGV2aWwuPC9kaXY+CjxkaXY+ PGJyPjwvZGl2PjxkaXY+VW5kZXIgJnF1b3Q7b3V0IHRoZXJlJnF1b3Q7IGlkZWFzIC0gd291bGQg aXQgYmUgcG9zc2libGUgdG8gcHV0IHRoZSBBY3Rpb24gaGVhZGVyIGluIGEgUFVCTElTSD8gV291 bGQgdGhpcyBhbGxvdyB0aGUgc2FtZSBzaWduYWxsaW5nIHNlbWFudGljcyBhcyBJTlZPS0Ugd2l0 aG91dCB0aGUgbmVlZCBmb3IgYSBuZXcgbWV0aG9kPzwvZGl2PjxkaXY+PGJyPgo8L2Rpdj48ZGl2 PlBldGVyIE11c2dyYXZlPGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBN YXkgMjMsIDIwMTEgYXQgOTowNyBBTSwgUGF1bCBLeXppdmF0IDxzcGFuIGRpcj0ibHRyIj4mbHQ7 PGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGNpc2NvLmNvbSI+cGt5eml2YXRAY2lzY28uY29tPC9h PiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4OyI+CjxkaXYgY2xhc3M9ImltIj48YnI+Cjxicj4KT24gNS8yMy8yMDExIDg6NTYg QU0sIFNoZWtoLVl1c2VmLCBSaWZhYXQgKFJpZmFhdCkgd3JvdGU6PGJyPgo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KSSBkbyBub3Qgc2VlIGhvdyB0aGlzIHBy b3Bvc2FsIGlzICZxdW90O2xlc3MgbWVjaGFuaXNtJnF1b3Q7IHRoYW4gdGhlIG9yaWdpbmFsIHBy b3Bvc2FsLCBidXQgSSB0ZW5kIHRvIGFncmVlIHdpdGggeW91IHRoYXQgdGhpcyBtaWdodCBiZSAm cXVvdDthIG1hdHRlciBvZiB0YXN0ZSZxdW90Oy48YnI+CjwvYmxvY2txdW90ZT4KPGJyPjwvZGl2 PgpUaGUgZGV2aWwgaXMgaW4gdGhlIGRldGFpbHMgaGVyZSwgYW5kIHdlIGRvbiYjMzk7dCBoYXZl IGVub3VnaCBkZXRhaWxzLjxicj4KU28gaXRzIGFsbCBpbiB0aGUgc2V0IG9mIGFzc3VtcHRpb25z IG9uZSBpcyBtYWtpbmcuPGJyPgo8YnI+CkluIHRoZSBlbmQgd2UgcHJvYmFibHkgYXJlbiYjMzk7 dCBnb2luZyB0byBzdGFuZGFyZGl6ZSBzZXJ2aWNlcyAtIGp1c3QgbWVjaGFuaXNtcyBmb3IgY3Jl YXRpbmcgc2VydmljZXMuIEJ1dCBwZXJoYXBzIHdlIHdpbGwgaGF2ZSBhbiAmcXVvdDtleGFtcGxl cyZxdW90OyBkb2MgdGhhdCBzaG93cyBob3cgdGhlIG1lY2hhbmlzbXMgbWlnaHQgYmUgdXNlZCB0 byBjcmVhdGUgYSByYW5nZSBvZiBpbnRlcmVzdGluZyBzZXJ2aWNlcyBzdWNoIGFzIHRoZXNlLiBJ ZiBzbywgSSB3b3VsZCB0aGluayB3ZSB3b3VsZCBuZWVkIHRvIHdvcmsgdGhyb3VnaCBlYWNoIG9u ZSBpbiBkZXRhaWwsIGNhcmVmdWxseSBkZWZpbmluZyBhbGwgdGhlIGFzc3VtcHRpb25zIGFib3V0 IHRoZSBlbnZpcm9ubWVudC48YnI+Cgo8YnI+CkFuZCB0aGF0IGlzIHJlYWxseSB3aGF0IGl0IHRh a2VzIHRvIGRlY2lkZSBvbiBlYWNoIHBhcnRpY3VsYXIgJnF1b3Q7YWN0aW9uJnF1b3Q7LCBiZWNh dXNlIHRob3NlIHNlZW0gdG8gYmUgcmF0aGVyIHNwZWNpYWxpemVkLiBBdCB0aGUgbW9tZW50IEkg ZG9uJiMzOTt0IGhhdmUgYSB2aXNpb24gb2YgYSBjbGVhciBhbmQgb2J2aW91cyBzZXQgb2YgYWN0 aW9ucyB0aGF0IGVuYWJsZSBhbGwgdGhlIGludGVyZXN0aW5nIHNlcnZpY2VzLiBJdHMgbW9yZSBh IG1hdHRlciBvZiBjcmFmdGluZyBhbiBhY3Rpb24gdG8gc3VwcG9ydCBvbmUgb3IgYSBmZXcgc2Vy dmljZXMuIEkgd2lzaCBpdCB3YXMgbW9yZSBjbGVhciBjdXQgdGhhbiB0aGF0LiBNYXliZSBpdCB3 aWxsIGJlY29tZSBzbyB3aXRoIG1vcmUgc3R1ZHkuPGJyPgoKPGJyPgogoCCgIKAgoFRoYW5rcyw8 YnI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPgogoCCgIKAgoFBhdWw8L2ZvbnQ+PGRpdj48ZGl2Pjwv ZGl2PjxkaXYgY2xhc3M9Img1Ij48YnI+Cjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+ClJlZ2FyZHMsPGJyPgogoFJpZmFhdDxicj4KPGJyPgo8YnI+Cjxi cj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KRnJvbTogUGF1 bCBLeXppdmF0IFs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+cGt5eml2YXRAY2lzY28uY29tPC9hPl08YnI+ClNlbnQ6IFN1bmRheSwgTWF5IDIyLCAy MDExIDExOjAzIFBNPGJyPgpUbzogU2hla2gtWXVzZWYsIFJpZmFhdCAoUmlmYWF0KTxicj4KQ2M6 IDxhIGhyZWY9Im1haWx0bzpzcGxpY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3BsaWNl c0BpZXRmLm9yZzwvYT48YnI+ClN1YmplY3Q6IFJlOiBbc3BsaWNlc10gQW5zd2VyaW5nIGFuIEEv ViBDYWxsIFVzaW5nIFR3byBTZXBhcmF0ZSBEZXZpY2VzIHByb3Bvc2FsPGJyPgo8YnI+Ck9uIDUv MjIvMjAxMSA4OjQ5IFBNLCBTaGVraC1ZdXNlZiwgUmlmYWF0IChSaWZhYXQpIHdyb3RlOjxicj4K PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+Cjxicj4KWW91IGFy ZSB0aGVuIHByb3Bvc2luZyB0aGUgZm9sbG93aW5nOjxicj4KPGJyPgo8YnI+CkFsaWNlIHVzZWQg aGVyICpwaG9uZSogdG8gYW5zd2VyIHRoZSBpbmNvbWluZyBjYWxsPGJyPgogoCCgIKB8IKAgoCCg IKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAg oCB8PGJyPgogoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCAyMDAgT0sgW0F1ZGlvXSCgIKAg oHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCg IKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgMjAwIE9LIFtB dWRpb10goCCgIKB8PGJyPgogoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAg oCCgIKAgoCCgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPgogoCCgIKB8IENBTkNFTCCg IKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8 PGJyPgogoCCgIKB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LXwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKB8 IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCZsdDstLS1kaWFsb2cxLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSZndDt8PGJyPgogoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCZsdDs9PT09 PT1hdWRpbz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSZndDt8PGJyPgogoCCgIKB8IKAg oCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCg IKAgoCB8PGJyPgogoCCgIKB8IElOVklURSBBbGVydC1JbmZvIGFuZCBbVmlkZW9dIKAgoCCgIKAg oCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKB8Jmx0Oy0tLS0tLS0tLS0tLS0t LS0tLS0tfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgo8 YnI+CldoYXQgaGFwcGVucyBoZXJlPzxicj4KV2lsbCB0aGUgdXNlciBiZSByZXF1aXJlZCB0byB0 YWtlIGFuIGFjdGlvbiBvbiB0aGUgUEMgdG8gYWNjZXB0IHRoZSBJTlZJVEU/PGJyPgpPciB5b3Ug YXJlIGV4cGVjdGluZyB0aGUgUEMgdG8gcHJvdmlkZSBhbiBhbnN3ZXIgd2l0aG91dCB1c2VyIGlu dGVydmVudGlvbj88YnI+CjwvYmxvY2txdW90ZT4KPGJyPgpDb3VsZCCgYmUgaGFuZGxlZCB2YXJp b3VzIHdheXMuPGJyPgo8YnI+ClRoZSBhbGVydC1pbmZvIGNvdWxkIHN1Z2dlc3QgYXV0by1hbnN3 ZXIuIChUaGUgUEMgKmhvbm9yaW5nKiBzdWNoIGE8YnI+CnJlcXVlc3QgbWlnaHQgYmUgY29uZGl0 aW9uYWwgb24gd2hvIGl0IGNvbWVzLiBCdXQgZXZlbiBpZiBub3QgaG9ub3JlZDxicj4KZm9yIGF1 dG8tYW5zd2VyIGl0IG1pZ2h0IHN0aWxsIGFsZXJ0ICpkaWZmZXJlbnRseSouKSBJZiBpdCB3YXNu JiMzOTt0PGJyPgphdXRvLWFuc3dlcmVkLCBhbmQgcmV0dXJuZWQgMTgwLCBpdCBjb3VsZCBiZSBm b2xsb3dlZCB1cCB3aXRoIGFuIElOVk9LRTxicj4KdG8gZm9yY2UgdGhlIGFuc3dlci48YnI+Cjxi cj4KIKAgoCCgIKAgVGhhbmtzLDxicj4KIKAgoCCgIKAgUGF1bDxicj4KPGJyPgo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVm dDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KIKAgoCCgfCAyMDAgT0sgW1ZpZGVv XSCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4K IKAgoCCgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLXwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAg oCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgcmUt SU5WSVRFIFtBL1ZdIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgfCCgIKAg oCCgIKAgoCCgIKAgoCCgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8IKAgoCCgIKAgoCCgIKAg oCCgIKAgfDxicj4KIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCg IKAgoCB8IHJlLUlOVklURSBbQS9WXSCgIKAgfDxicj4KIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAg oCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4K IKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IDIwMCBP SyBbQS9WXSCgIKAgoCCgfDxicj4KIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgMjAwIE9L IFtBL1ZdIKAgoCCgIKB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfDxicj4KIKAgoCCgfCCgIKAg oCCgIKAgoCCgIKAgoCCgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18IKAgoCCgIKAgoCCgIKAg oCCgIKAgfDxicj4KIKAgoCCgfCBBQ0sgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCg IKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgfCZsdDstLS0tLS0tLS0tLS0t LS0tLS0tLXwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4K IKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCg IKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgfCZsdDstLS0tLS1kaWFsb2cyLS0tLS0tJmd0O3wm bHQ7LS0tZGlhbG9nMS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4KIKAg oCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAg oCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwmbHQ7PT09PT09 YXVkaW89PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0mZ3Q7fDxicj4KIKAgoCCgfCZsdDs9 PT09PT09PT09PT09PT09PT09PT09PT09PT09dmlkZW89PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0mZ3Q7fDxicj4KIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KPGJyPgo8YnI+CjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBreXpp dmF0QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBreXppdmF0QGNpc2NvLmNvbTwvYT5dPGJy PgpTZW50OiBTdW5kYXksIE1heSAyMiwgMjAxMSA1OjA5IFBNPGJyPgpUbzogU2hla2gtWXVzZWYs IFJpZmFhdCAoUmlmYWF0KTxicj4KQ2M6IDxhIGhyZWY9Im1haWx0bzpzcGxpY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c3BsaWNlc0BpZXRmLm9yZzwvYT48YnI+ClN1YmplY3Q6IFJlOiBb c3BsaWNlc10gQW5zd2VyaW5nIGFuIEEvViBDYWxsIFVzaW5nIFR3byBTZXBhcmF0ZSBEZXZpY2Vz PGJyPgpwcm9wb3NhbDxicj4KPGJyPgo8YnI+Cjxicj4KT24gNS8yMi8yMDExIDI6NDAgUE0sIFNo ZWtoLVl1c2VmLCBSaWZhYXQgKFJpZmFhdCkgd3JvdGU6PGJyPgo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KQmVjYXVzZSBhIG5ldyBJTlZJVEUgd2lsbCBwcm9i YWJseSBjYXVzZSB0aGUgUEMgdG8gcHJlc2VudCB0aGUgdXNlciB3aXRoIGE8YnI+CjwvYmxvY2tx dW90ZT4KVUkgY29tcG9uZW50IGFuZCB3YWl0IGZvciB0aGUgdXNlcnMgaW5wdXQuPGJyPgo8YnI+ CldlbGwsIEkgc3VwcG9zZSB5b3Ugd291bGQgd2FudCB0aGUgUEMgdG8gaW5kaWNhdGUgd2hhdCBp cyBnb2luZyBvbiBpbjxicj4KdGhlIFVJIGluICpzb21lKiB3YXkuIEJ1dCBwcm9iYWJseSBub3Qg ZXhhY3RseSB0aGUgc2FtZSBhcyBnZXR0aW5nIGEgbmV3PGJyPgpjYWxsLjxicj4KPGJyPgpUaGF0 IGNvdWxkIGJlIGhhbmRsZWQgdmlhIGFwcHJvcHJpYXRlIEFsZXJ0LUluZm8uIFRvIHNvbWUgZXh0 ZW50IHRoaXMgaXM8YnI+CmEgbWF0dGVyIG9mIHRhc3RlLiBJIGFtIGluY2xpbmVkIHRvIHByZWZl ciBhbiBlY29ub215IG9mIG1lY2hhbmlzbSwgYW5kPGJyPgpJIHRoaW5rIHRoZSBhbGVydC1pbmZv IGZlZWxzIGxpa2UgbGVzcyBtZWNoYW5pc20gdGhhbiB0aGUgcGFydGljdWxhcjxicj4KSU5WT0tF IG1lY2hhbmlzbSB1c2VkIGluIHRoaXMgc2NlbmFyaW8uIChUaGUgaW52b2tlIG1lY2hhbmlzbSB1 c2VkIGhlcmU8YnI+CnJlcXVpcmVzIHRoZSBwaG9uZSB0byBhc3N1bWUgdGhhdCB0aGUgUEMgaXMg YXdhcmUgb2YgdGhlIGRpYWxvZywgYW5kPGJyPgphYmxlIHRvIGFzc29jaWF0ZSBpdCB3aXRoIHRo ZSBhcHByb3ByaWF0ZSBjb250YWN0IGFkZHJlc3MgZm9yIGRvaW5nIHRoZTxicj4KaW52aXRlLik8 YnI+Cjxicj4KIKAgoCCgIKBUaGFua3MsPGJyPgogoCCgIKAgoFBhdWw8YnI+Cjxicj4KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVy LWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ClJlZ2FyZHMsPGJyPgogoCCg UmlmYWF0PGJyPgo8YnI+Cjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPgpGcm9tOiA8YSBocmVmPSJt YWlsdG86c3BsaWNlcy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3BsaWNlcy1i b3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzcGxpY2VzLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcGxpY2VzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XSBPbiBCZWhhbGY8YnI+CjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+Ck9mPGJyPgo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KUGF1bCBLeXppdmF0PGJyPgpTZW50OiBTYXR1cmRh eSwgTWF5IDIxLCAyMDExIDExOjE1IFBNPGJyPgpUbzogPGEgaHJlZj0ibWFpbHRvOnNwbGljZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcGxpY2VzQGlldGYub3JnPC9hPjxicj4KU3ViamVj dDogUmU6IFtzcGxpY2VzXSBBbnN3ZXJpbmcgYW4gQS9WIENhbGwgVXNpbmcgVHdvIFNlcGFyYXRl IERldmljZXM8YnI+CnByb3Bvc2FsPGJyPgo8YnI+CkkgZ3Vlc3MgYWxsIG9mIHRoYXQgY2FuIHdv cmsuIEJ1dCBmb3IgdGhlIGxhc3QgcGFydCwgaWYgdGhlIHBob25lIGtub3dzPGJyPgplbm91Z2gg dG8gc2VuZCB0aGUgaW52b2tlIHRvIHRoZSBwYywgd2h5IGNhbiYjMzk7dCBpdCBqdXN0IHNlbmQg YW4gSU5WSVRFIHRvPGJyPgp0aGUgcGM/PGJyPgo8YnI+CiCgIKAgVGhhbmtzLDxicj4KIKAgoCBQ YXVsPGJyPgo8YnI+Ck9uIDUvMjEvMjAxMSA4OjU2IEFNLCBTaGVraC1ZdXNlZiwgUmlmYWF0IChS aWZhYXQpIHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+CkhpLDxicj4KPGJyPgpXZSBhcmUgc3RpbGwgd29ya2luZyBvbiBhIG5ldyB2ZXJzaW9u IG9mIHRoZSBJTlZPS0UgZG9jdW1lbnQgdGhhdCByZW1vdmVzPGJyPgo8L2Jsb2NrcXVvdGU+CnRo ZSBpbXBsaWNpdCBzdWJzY3JpcHRpb24uPGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij4KPGJyPgpNZWFud2hpbGUgSSB3b3VsZCBsaWtlIHRvIGNvbnRpbnVl IHRoZSBkaXNjdXNzaW9uIG9mIHRoZSB2YXJpb3VzIHBvc3NpYmxlPGJyPgo8L2Jsb2NrcXVvdGU+ CnVzZXMgY2FzZXMuPGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6 MWV4Ij4KVGhlIGZvbGxvd2luZyBpcyBhIHByb3Bvc2FsIGZvciBBbnN3ZXJpbmcgYW4gQS9WIENh bGwgVXNpbmcgVHdvIFNlcGFyYXRlPGJyPgo8L2Jsb2NrcXVvdGU+CkRldmljZXMuPGJyPgo8Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KPGJyPgpSZWdhcmRzLDxi cj4KIKAgoCBSaWZhYXQ8YnI+Cjxicj4KPGJyPgo8YnI+CiCgIKAgoCBBbGljZSCgIKAgoCCgIKAg oCCgIKAgQWxpY2UgoCCgIKAgoCCgIKAgoCCgUHJveHkgoCCgIKAgoCCgIKAgoCCgIKBCb2I8YnI+ CiCgIKAgoCCgUEMgoCCgIKAgoCCgIKAgoCCgIERlc2sgUGhvbmU8YnI+CiCgIKAgoCCgfCCgIKAg oCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCg IKAgfDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAg oCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgpCb3RoIEFsaWNlJiMzOTtzIGRldmljZXMg c3Vic2NyaWJlIHRvIHRoZSByZWcgZXZlbnQgcGFja2FnZSwgd2hpY2ggYWxsb3dzIGVhY2g8YnI+ CjwvYmxvY2txdW90ZT4KZGV2aWNlIHRvPGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij4KZGlzY292ZXIgdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUgb3RoZXIg ZGV2aWNlIGJhc2VkIG9uIHRoZSBmZWF0dXJlIHRhZ3M8YnI+CjwvYmxvY2txdW90ZT4KcHJvdmlk ZWQgYnkgZWFjaCBkZXZpY2UuPGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4Ij4KVGhlIERlc2sgUGhvbmUga25vd3MgdGhhdCB0aGUgUEMgc3VwcG9ydHMgVmlk ZW8sIHdoaWxlIHRoZSBQQyBrbm93cyB0aGF0PGJyPgo8L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3Rl PjwvYmxvY2txdW90ZT4KdGhlPGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4Ij48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46 MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4K RGVzayBQaG9uZSBvbmx5IHN1cHBvcnRzIGF1ZGlvLjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwg oCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8 IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCBTVUJTQ1JJQkUgcmVnIKAgoCCgIHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8LS0tLS0tLS0tLS0t LS0tLS0tLS0mZ3Q7fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCCgIKAgoCCg IKAgoCCgIKAgoCCgIHwgMjAwIE9LIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCZsdDstLS0tLS0tLS0tLS0tLS0t LS0tLXwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCg IKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCg IKAgoCCgfCBTVUJTQ1JJQkUgcmVnIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCg IKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tJmd0O3wgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwg MjAwIE9LIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCg IKAgoCCgIHw8YnI+CiCgIKAgoCCgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS18IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8IKAgoCCgIKAg oCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8 PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+ClRoZSB0d28gZGV2aWNlcyBhbHNvIHN1YnNjcmli ZSB0byB0aGUgZGlhbG9nIG9mIGVhY2ggb3RoZXIuPGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+ CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAg oCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8IFNVQlNDUklCRSBkaWFsb2cgoCCgfCCg IKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwt LS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAg oCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCAyMDAgT0sgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCg IKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8Jmx0Oy0tLS0t LS0tLS0tLS0tLS0tLS0tfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAg oCB8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCg IKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCBTVUJTQ1JJQkUgZGlhbG9n IKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAg oCCgIKB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCg IKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgMjAwIE9LIKAgoCCgIKAgoCCgIKB8IKAg oCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfC0t LS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCg IKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAg oCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCg IKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8 YnI+ClRoZSBzY2VuYXJpbyBzdGFydHMgd2l0aCBhbiBBL1YgY2FsbCBmcm9tIEJvYiB0byBBbGlj ZTxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCg IHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAg oCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCBJTlZJVEUgQWxpY2UgW0EvVl0goHw8YnI+CiCgIKAg oCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8Jmx0Oy0tLS0t LS0tLS0tLS0tLS0tLS0tfDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCBJTlZJ VEUgQWxpY2UgW0EvVl0goHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCg IKAgoCCgIKAgoCCgIKAgoCB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfCCgIKAgoCCgIKAgoCCg IKAgoCCgIHw8YnI+CiCgIKAgoCCgfCBJTlZJVEUgQWxpY2UgW0EvVl0goHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8Jmx0Oy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8 PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+Cjxicj4KPGJyPgooKik8YnI+Cjxicj4KPGJyPgpM ZXQmIzM5O3MgYXNzdW1lIHRoYXQgQWxpY2UgdXNlZCBoZXIgUEMgdG8gYW5zd2VyIHRoZSBpbmNv bWluZyBjYWxsPGJyPgpUaGUgUEMgaW5zdHJ1Y3RzIHRoZSBwaG9uZSB0byBhbnN3ZXIgdGhlIGF1 ZGlvIGNhbGw8YnI+CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8IElOVk9LRSBBY3Rp b246PGJyPgo8L2Jsb2NrcXVvdGU+CnVybjppbnZva2U6Y2FsbDphbnN3ZXI7bWVkaWE9YXVkaW87 dHJhbnNkdWNlcj1zcGVha2VyfGhlYWRzZXQ8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPgogoCCgIKAgoHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8IKAg oCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCAy MDAgT0sgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAg oCCgIKAgfDxicj4KIKAgoCCgIKB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfCCgIKAgoCCgIKAg oCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCg IKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8 YnI+CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgMjAwIE9LIFtBdWRpb10goCCgIKB8 IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCg IKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCAyMDAgT0sg W0F1ZGlvXSCgIKAgoHw8YnI+CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAg oCCgIKAgoCCgIKAgoCB8LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4KIKAgoCCgIKB8IENB TkNFTCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCg IKAgoCB8PGJyPgogoCCgIKAgoHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCCgIKAgoCCgIKAg oCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxi cj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCZsdDstLS1kaWFsb2cxLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCg IKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCg IKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwmbHQ7PT09PT09YXVkaW89PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0mZ3Q7fDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAg oHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAg oCCgIKAgoCCgIHw8YnI+ClRoZSBQQyB0aGVuIGFkZHMgVmlkZW8gdG8gdGhlIGV4aXN0aW5nIGF1 ZGlvIGNhbGwuPGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCg IKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCBJTlZJVEUgd2l0 aCBKb2luIFtWaWRlb10goCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxi cj4KIKAgoCCgIKB8LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fCCgIKAgoCCgIKAgoCCgIKAgoCCg IHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgMTAwIKAgoCCgIKAgoCCgIKAg oCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAg oCCgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLXwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCg IKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCByZS1J TlZJVEUgW0EvVl0goCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCg IKAgoCCgIKAgoCCgIKAgoCB8LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fCCgIKAgoCCgIKAgoCCg IKAgoCCgIHw8YnI+CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8IHJlLUlOVklURSBbQS9WXSCgIKAgfDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCg IKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8 PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fCAyMDAgT0sgW0EvVl0goCCgIKAgoHw8YnI+CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCg IHwgMjAwIE9LIFtBL1ZdIKAgoCCgIKB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfDxicj4KIKAg oCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLXwgoCCg IKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgMjAwIE9LIFtWaWRlb10goCCgIKB8IKAg oCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCZs dDstLS0tLS0tLS0tLS0tLS0tLS0tLXwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCg IKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAg oCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwmbHQ7LS0tLS0t ZGlhbG9nMi0tLS0tLSZndDt8Jmx0Oy0tLWRpYWxvZzEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tJmd0O3w8YnI+CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCg IKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8IKAgoCCgIKAg oCCgIKAgoCCgIKAgfCZsdDs9PT09PT1hdWRpbz09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PSZndDt8PGJyPgogoCCgIKAgoHwmbHQ7PT09PT09PT09PT09PT09PT09PT09PT09PT09PXZpZGVv PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Jmd0O3w8YnI+CiCgIKAgoCCgfCCgIKAgoCCg IKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCg IHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgo8YnI+Cjxicj4KPGJyPgpUaGUgc2NlbmFyaW8g Y29udGludWVzIGFmdGVyIHRoZSAoKikgYWJvdmU8YnI+CkxldCYjMzk7cyBhc3N1bWUgdGhhdCBB bGljZSB1c2VkIGhlciBwaG9uZSB0byBhbnN3ZXIgdGhlIGluY29taW5nIGNhbGwuPGJyPgpUaGUg cGhvbmUgYW5zd2VycyB0aGUgYXVkaW8gY2FsbDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAg oCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgog oCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IDIwMCBPSyBbQXVkaW9dIKAgoCCgfCCgIKAg oCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwtLS0t LS0tLS0tLS0tLS0tLS0tLSZndDt8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8 IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgMjAwIE9LIFtBdWRp b10goCCgIKB8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCg IKAgoCCgIKAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+CiCgIKAgoCCgfCBDQU5DRUwg oCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fDxicj4KIKAgoCCgIKB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLXwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCg IKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCg IKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwmbHQ7LS0tZGlhbG9nMS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAg oHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8Jmx0Oz09PT09PWF1ZGlvPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Jmd0O3w8YnI+CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCg IKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8IKAg oCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCg IKAgoCB8PGJyPgpUaGUgcGhvbmUgdGhlbiBpbnN0cnVjdHMgdGhlIFBDIHRvIGluaXRpYXRlIGEg dmlkZW8gY2FsbCB0byBqb2luIHRoZTxicj4KPC9ibG9ja3F1b3RlPgpleGlzdGluZyBjYWxsPGJy Pgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhl eDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KIKAgoCCgIKB8 IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgSU5WT0tFIEFjdGlvbjogdXJuOmludm9rZTpjYWxsOmpv aW47bWVkaWE9dmlkZW87ZGlhbG9nPWRpYWxvZzE8YnI+CiCgIKAgoCCgfCZsdDstLS0tLS0tLS0t LS0tLS0tLS0tLXwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxi cj4KIKAgoCCgIKB8IDIwMCBPSyCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwg oCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZn dDt8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAg oCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAg oCCgIKAgoCCgIKAgfDxicj4KVGhlIFBDIHRoZW4gYWRkcyBWaWRlbyB0byB0aGUgZXhpc3Rpbmcg YXVkaW8gY2FsbC48YnI+CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCg IKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8IElOVklURSB3 aXRoIEpvaW4gW1ZpZGVvXSCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8 PGJyPgogoCCgIKAgoHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8IKAgoCCgIKAgoCCgIKAgoCCg IKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCAxMDAgoCCgIKAgoCCgIKAg oCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAg oCCgIKB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCg IKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IHJl LUlOVklURSBbQS9WXSCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCCg IKAgoCCgIKAgoCCgIKAgoCCgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8IKAgoCCgIKAgoCCg IKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAg oCCgIKAgoCCgIHwgcmUtSU5WSVRFIFtBL1ZdIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCg IKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0 O3w8YnI+CiCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAg oCB8IDIwMCBPSyBbQS9WXSCgIKAgoCCgfDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCg IKAgfCAyMDAgT0sgW0EvVl0goCCgIKAgoHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18PGJyPgog oCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfCCg IKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCAyMDAgT0sgW1ZpZGVvXSCgIKAgoHwg oCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKB8 Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCg IKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAg oCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgfCZsdDstLS0t LS1kaWFsb2cyLS0tLS0tJmd0O3wmbHQ7LS0tZGlhbG9nMS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0mZ3Q7fDxicj4KIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCg IKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoHwgoCCgIKAg oCCgIKAgoCCgIKAgoCB8Jmx0Oz09PT09PWF1ZGlvPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Jmd0O3w8YnI+CiCgIKAgoCCgfCZsdDs9PT09PT09PT09PT09PT09PT09PT09PT09PT09dmlk ZW89PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0mZ3Q7fDxicj4KIKAgoCCgIKB8IKAgoCCg IKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAg oCB8PGJyPgo8YnI+Cjxicj4KPGJyPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4Kc3BsaWNlcyBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0 bzpzcGxpY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3BsaWNlc0BpZXRmLm9yZzwvYT48 YnI+CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3BsaWNl cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3BsaWNlczwvYT48YnI+Cjxicj4KPC9ibG9ja3F1b3RlPgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4Kc3BsaWNlcyBtYWlsaW5nIGxpc3Q8YnI+Cjxh IGhyZWY9Im1haWx0bzpzcGxpY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3BsaWNlc0Bp ZXRmLm9yZzwvYT48YnI+CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3BsaWNlcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3BsaWNlczwvYT48YnI+CjwvYmxvY2txdW90ZT4KPGJyPgo8L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPgo8YnI+CjwvYmxvY2txdW90ZT4KPGJyPgo8L2Jsb2NrcXVvdGU+Cl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgpzcGxpY2Vz IG1haWxpbmcgbGlzdDxicj4KPGEgaHJlZj0ibWFpbHRvOnNwbGljZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zcGxpY2VzQGlldGYub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGxpY2VzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGxpY2VzPC9hPjxicj4KPC9kaXY+PC9k aXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4K --0015174780bc90785a04a404e914-- From pkyzivat@cisco.com Tue May 24 06:11:21 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EE4E06BA for ; Tue, 24 May 2011 06:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.254 X-Spam-Level: X-Spam-Status: No, score=-110.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt0zAPrUDdDr for ; Tue, 24 May 2011 06:11:16 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFDCE06A8 for ; Tue, 24 May 2011 06:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=28202; q=dns/txt; s=iport; t=1306242676; x=1307452276; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=u6uzD9eqIWVpR2mlhZ7cGlvN7yUmmXIhp3V+culEnuo=; b=NaIHsOhRsAyRR0as5J1uI15PhxVhdqode28AOZ/T86xnjOW2ctlVIJpL mcbmHN2ilOlQJeUI6ZEg+9nmcGOhL1H4b15kz5qeYo8EYQJ5+XhyvocU9 734NaKE4kbZ/3dV/fy96EV+oCfHN+tQk3Qz1YhjzITQw166CPQdhtSqpu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhABAA2u202tJXG8/2dsb2JhbACXZY5Ed6s0nXyGGwSQH4Q0imk X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="363162279" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 24 May 2011 13:11:15 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4ODBEba026037; Tue, 24 May 2011 13:11:15 GMT Message-ID: <4DDBAE72.2020003@cisco.com> Date: Tue, 24 May 2011 09:11:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Peter Musgrave References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> <4DD97B5D.7040404@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE75@DC-US1MBEX4.global.avaya.com> <4DD9CE66.8010204@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FB9A1@DC-US1MBEX4.global.avaya.com> <4DDA5C19.5040405@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "splices@ietf.org" Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:11:21 -0000 Peter, IMO the "action mechanism" will be controversial regardless of how it is encoded. And it will have largely the same impact on implementations. (It is a significant extension of the scope of SIP.) I don't think that trying to "hide" it will make things better. And as best I understand it doesn't fit the semantics of PUBLISH. (Publish is intimately tied to the state model of an event package. Maybe if the event package is carefully designed you could make a case for this. But I'm dubious.) I think the kind of use cases that Rifaat is posing are good as a starting point. But after some of that I think one of the next steps must be carefully defining the scope of this new action mechanism. And I expect that to be difficult. Right now it seems to be a pot into which you can put *anything*. I think we need to get to the point where it is clear what sorts of things are valid actions, and which are not. I expect this will involve defining an extended environment for a UA, of things it needs to manipulate. (Stuff like speakers, microphones, displays, buttons, multiple dialogs, ...) We might get a head start by exploring what CTI features are defined in other protocols. Thanks, Paul On 5/24/2011 8:41 AM, Peter Musgrave wrote: > I agree with Paul that: > 1) This works ok. > 2) INVOKE is more mechanism than a new header. [A method is a bigger > deal than a header] > > I'd also observe in a "real politik" sense that the potential energy > barrier to geting a new SIP method in place will likely be significant. > I would expect it would have to be a dispatch-ed WG all on it's own. > People will decide to either use it to solve world hunger - or decide > that it is the root of all evil. > > Under "out there" ideas - would it be possible to put the Action header > in a PUBLISH? Would this allow the same signalling semantics as INVOKE > without the need for a new method? > > Peter Musgrave > > On Mon, May 23, 2011 at 9:07 AM, Paul Kyzivat > wrote: > > > > On 5/23/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > I do not see how this proposal is "less mechanism" than the > original proposal, but I tend to agree with you that this might > be "a matter of taste". > > > The devil is in the details here, and we don't have enough details. > So its all in the set of assumptions one is making. > > In the end we probably aren't going to standardize services - just > mechanisms for creating services. But perhaps we will have an > "examples" doc that shows how the mechanisms might be used to create > a range of interesting services such as these. If so, I would think > we would need to work through each one in detail, carefully defining > all the assumptions about the environment. > > And that is really what it takes to decide on each particular > "action", because those seem to be rather specialized. At the moment > I don't have a vision of a clear and obvious set of actions that > enable all the interesting services. Its more a matter of crafting > an action to support one or a few services. I wish it was more clear > cut than that. Maybe it will become so with more study. > > Thanks, > Paul > > > Regards, > Rifaat > > > > ________________________________________ > From: Paul Kyzivat [pkyzivat@cisco.com ] > Sent: Sunday, May 22, 2011 11:03 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org > Subject: Re: [splices] Answering an A/V Call Using Two Separate > Devices proposal > > On 5/22/2011 8:49 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > You are then proposing the following: > > > Alice used her *phone* to answer the incoming call > | | | > | > | | 200 OK [Audio] | > | > | |-------------------->| > | > | | | 200 OK > [Audio] | > | | > |-------------------->| > | CANCEL | | > | > |<------------------------------------------| > | > | | | > | > | > |<---dialog1------------------------------->| > | > |<======audio==============================>| > | | | > | > | INVITE Alert-Info and [Video] | > | > |<--------------------| | > | > > What happens here? > Will the user be required to take an action on the PC to > accept the INVITE? > Or you are expecting the PC to provide an answer without > user intervention? > > > Could be handled various ways. > > The alert-info could suggest auto-answer. (The PC *honoring* such a > request might be conditional on who it comes. But even if not > honored > for auto-answer it might still alert *differently*.) If it wasn't > auto-answered, and returned 180, it could be followed up with an > INVOKE > to force the answer. > > Thanks, > Paul > > | 200 OK [Video] | | > | > |<--------------------| | > | > | | re-INVITE [A/V] | > | > | |-------------------->| > | > | | | > re-INVITE [A/V] | > | | > |-------------------->| > | | | 200 OK > [A/V] | > | | 200 OK [A/V] > |<--------------------| > | |<--------------------| > | > | ACK | | > | > |<--------------------| | > | > | | | > | > > |<------dialog2------>|<---dialog1------------------------------->| > | | | > | > | > |<======audio==============================>| > > |<============================video==============================>| > | | | > | > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > ] > Sent: Sunday, May 22, 2011 5:09 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org > Subject: Re: [splices] Answering an A/V Call Using Two > Separate Devices > proposal > > > > On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Because a new INVITE will probably cause the PC to > present the user with a > > UI component and wait for the users input. > > Well, I suppose you would want the PC to indicate what > is going on in > the UI in *some* way. But probably not exactly the same > as getting a new > call. > > That could be handled via appropriate Alert-Info. To > some extent this is > a matter of taste. I am inclined to prefer an economy of > mechanism, and > I think the alert-info feels like less mechanism than > the particular > INVOKE mechanism used in this scenario. (The invoke > mechanism used here > requires the phone to assume that the PC is aware of the > dialog, and > able to associate it with the appropriate contact > address for doing the > invite.) > > Thanks, > Paul > > Regards, > Rifaat > > > -----Original Message----- > From: splices-bounces@ietf.org > > [mailto:splices-bounces@ietf.org > ] On Behalf > > Of > > Paul Kyzivat > Sent: Saturday, May 21, 2011 11:15 PM > To: splices@ietf.org > Subject: Re: [splices] Answering an A/V Call > Using Two Separate Devices > proposal > > I guess all of that can work. But for the last > part, if the phone knows > enough to send the invoke to the pc, why can't > it just send an INVITE to > the pc? > > Thanks, > Paul > > On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat > (Rifaat) wrote: > > Hi, > > We are still working on a new version of the > INVOKE document that removes > > the implicit subscription. > > > Meanwhile I would like to continue the > discussion of the various possible > > uses cases. > > The following is a proposal for Answering an > A/V Call Using Two Separate > > Devices. > > > Regards, > Rifaat > > > > Alice Alice > Proxy Bob > PC Desk Phone > | | > | | > | | > | | > Both Alice's devices subscribe to the reg > event package, which allows each > > device to > > discover the capabilities of the other > device based on the feature tags > > provided by each device. > > The Desk Phone knows that the PC supports > Video, while the PC knows that > > the > > Desk Phone only supports audio. > > | | > | | > | | SUBSCRIBE > reg | | > | > |-------------------->| | > | | 200 OK > | | > | > |<--------------------| | > | | > | | > | SUBSCRIBE reg | > | | > > |------------------------------------------>| | > | 200 OK | > | | > > |<------------------------------------------| | > | | > | | > | | > | | > The two devices also subscribe to the dialog > of each other. > | | > | | > | | > | | > | SUBSCRIBE dialog | > | | > |-------------------->| > | | > | 200 OK | > | | > |<--------------------| > | | > | | > | | > | SUBSCRIBE dialog | > | | > |<--------------------| > | | > | 200 OK | > | | > |-------------------->| > | | > | | > | | > | | > | | > The scenario starts with an A/V call from > Bob to Alice > | | > | | > | | > | INVITE Alice [A/V] | > | | > |<--------------------| > | | INVITE Alice > [A/V] | | > | > |<--------------------| | > | INVITE Alice [A/V] | > | | > > |<------------------------------------------| | > | | > | | > > > (*) > > > Let's assume that Alice used her PC to > answer the incoming call > The PC instructs the phone to answer the > audio call > | | > | | > | INVOKE Action: > > urn:invoke:call:answer;media=audio;transducer=speaker|headset > > |-------------------->| > | | > | 200 OK | > | | > |<--------------------| > | | > | | > | | > | | 200 OK > [Audio] | | > | > |-------------------->| | > | | > | 200 OK [Audio] | > | | > |-------------------->| > | CANCEL | > | | > > |<------------------------------------------| | > | | > | | > | > |<---dialog1------------------------------->| > | | > | | > | > |<======audio==============================>| > | | > | | > | | > | | > The PC then adds Video to the existing audio > call. > | | > | | > | INVITE with Join [Video] > | | > |-------------------->| > | | > | 100 | > | | > |<--------------------| > | | > | | re-INVITE > [A/V] | | > | > |-------------------->| | > | | > | re-INVITE [A/V] | > | | > |-------------------->| > | | > | 200 OK [A/V] | > | | 200 OK [A/V] > |<--------------------| > | > |<--------------------| | > | 200 OK [Video] | > | | > |<--------------------| > | | > | | > | | > > |<------dialog2------>|<---dialog1------------------------------->| > | | > | | > | > |<======audio==============================>| > > |<============================video==============================>| > | | > | | > | | > | | > > > > The scenario continues after the (*) above > Let's assume that Alice used her phone to > answer the incoming call. > The phone answers the audio call > | | > | | > | | 200 OK > [Audio] | | > | > |-------------------->| | > | | > | 200 OK [Audio] | > | | > |-------------------->| > | CANCEL | > | | > > |<------------------------------------------| | > | | > | | > | > |<---dialog1------------------------------->| > | | > | | > | > |<======audio==============================>| > | | > | | > | | > | | > The phone then instructs the PC to initiate > a video call to join the > > existing call > > | | > | | > | INVOKE Action: > urn:invoke:call:join;media=video;dialog=dialog1 > |<--------------------| > | | > | 200 OK | > | | > |-------------------->| > | | > | | > | | > The PC then adds Video to the existing audio > call. > | | > | | > | INVITE with Join [Video] > | | > |-------------------->| > | | > | 100 | > | | > |<--------------------| > | | > | | re-INVITE > [A/V] | | > | > |-------------------->| | > | | > | re-INVITE [A/V] | > | | > |-------------------->| > | | > | 200 OK [A/V] | > | | 200 OK [A/V] > |<--------------------| > | > |<--------------------| | > | 200 OK [Video] | > | | > |<--------------------| > | | > | | > | | > > |<------dialog2------>|<---dialog1------------------------------->| > | | > | | > | > |<======audio==============================>| > > |<============================video==============================>| > | | > | | > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > From musgravepj@gmail.com Tue May 24 07:22:33 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3888CE06AF for ; Tue, 24 May 2011 07:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tu--ONmZVcJ for ; Tue, 24 May 2011 07:22:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDD5E06BA for ; Tue, 24 May 2011 07:22:29 -0700 (PDT) Received: by fxm15 with SMTP id 15so5281836fxm.31 for ; Tue, 24 May 2011 07:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GLqhvHMP1m2KLfMRb+j+JgmY9x/Re8bw4fw6/lZ/7OY=; b=F0C3phOuEY4rDmwPphf7xeJ2U2/cgIKjqmcIPwuV5HnqU8Fn1gxfH3+MTfg9rKC9AL yKNSrhG3gIQx6gg9LuQS/BAjx/tZJwfO2CXrRjSa5gxS34ievjb8kxCLGgbTtdg7V8TW jp7JMggT0KD2cjoOXTmyXFq1gTmy8X127Euvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=E64r5lprWX9/6JwPvio0fhTGZA/i5LvlcKmZcROOaR3k+7lkOcjqE5umfYFUcoWcre 9z52onnLrDC2bfRA/5e6739i8WLX0U9z05dTfdYNwhLwYvBFUma3fUw1RMykgL/6D762 zaMckqyvS0qmzYXMgZ4QTCaZMrt+8/hVozNjE= MIME-Version: 1.0 Received: by 10.223.36.89 with SMTP id s25mr984714fad.9.1306246948699; Tue, 24 May 2011 07:22:28 -0700 (PDT) Received: by 10.223.116.209 with HTTP; Tue, 24 May 2011 07:22:28 -0700 (PDT) In-Reply-To: <4DDBAE72.2020003@cisco.com> References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> <4DD97B5D.7040404@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE75@DC-US1MBEX4.global.avaya.com> <4DD9CE66.8010204@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FB9A1@DC-US1MBEX4.global.avaya.com> <4DDA5C19.5040405@cisco.com> <4DDBAE72.2020003@cisco.com> Date: Tue, 24 May 2011 10:22:28 -0400 Message-ID: From: Peter Musgrave To: Paul Kyzivat Content-Type: multipart/alternative; boundary=00151747b3625dbdfd04a4065198 Cc: "splices@ietf.org" Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 14:22:33 -0000 --00151747b3625dbdfd04a4065198 Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, I agree the mechanism is fundamentally controversial and the best way to face this is to define the scope very carefully and narrowly. Was the use of CSTA-3 ever discussed? I had a passing acquaintance with this a couple of years ago and some of what splices needs might come from there. Even if not directly relevant it does provide one perspective on the kinds of control primitives which come into play. (I used http://www.ecma-international.org/activities/Communications/TG11/CSTAoverview.pdfto remind myself of some of what it encompassed). While CSTA-3 looks good to me "on paper" - I lack real implementation experience with it - so I would be interested to hear if anyone has input on this. Peter On Tue, May 24, 2011 at 9:11 AM, Paul Kyzivat wrote: > Peter, > > IMO the "action mechanism" will be controversial regardless of how it is > encoded. And it will have largely the same impact on implementations. > (It is a significant extension of the scope of SIP.) > > I don't think that trying to "hide" it will make things better. And as best > I understand it doesn't fit the semantics of PUBLISH. (Publish is intimately > tied to the state model of an event package. Maybe if the event package is > carefully designed you could make a case for this. But I'm dubious.) > > I think the kind of use cases that Rifaat is posing are good as a starting > point. But after some of that I think one of the next steps must be > carefully defining the scope of this new action mechanism. And I expect that > to be difficult. Right now it seems to be a pot into which you can put > *anything*. I think we need to get to the point where it is clear what sorts > of things are valid actions, and which are not. I expect this will involve > defining an extended environment for a UA, of things it needs to manipulate. > (Stuff like speakers, microphones, displays, buttons, multiple dialogs, ...) > We might get a head start by exploring what CTI features are defined in > other protocols. > > Thanks, > Paul > > > On 5/24/2011 8:41 AM, Peter Musgrave wrote: > >> I agree with Paul that: >> 1) This works ok. >> 2) INVOKE is more mechanism than a new header. [A method is a bigger >> deal than a header] >> >> I'd also observe in a "real politik" sense that the potential energy >> barrier to geting a new SIP method in place will likely be significant. >> I would expect it would have to be a dispatch-ed WG all on it's own. >> People will decide to either use it to solve world hunger - or decide >> that it is the root of all evil. >> >> Under "out there" ideas - would it be possible to put the Action header >> in a PUBLISH? Would this allow the same signalling semantics as INVOKE >> without the need for a new method? >> >> Peter Musgrave >> >> On Mon, May 23, 2011 at 9:07 AM, Paul Kyzivat > > wrote: >> >> >> >> On 5/23/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> >> I do not see how this proposal is "less mechanism" than the >> original proposal, but I tend to agree with you that this might >> be "a matter of taste". >> >> >> The devil is in the details here, and we don't have enough details. >> So its all in the set of assumptions one is making. >> >> In the end we probably aren't going to standardize services - just >> mechanisms for creating services. But perhaps we will have an >> "examples" doc that shows how the mechanisms might be used to create >> a range of interesting services such as these. If so, I would think >> we would need to work through each one in detail, carefully defining >> all the assumptions about the environment. >> >> And that is really what it takes to decide on each particular >> "action", because those seem to be rather specialized. At the moment >> I don't have a vision of a clear and obvious set of actions that >> enable all the interesting services. Its more a matter of crafting >> an action to support one or a few services. I wish it was more clear >> cut than that. Maybe it will become so with more study. >> >> Thanks, >> Paul >> >> >> Regards, >> Rifaat >> >> >> >> ________________________________________ >> From: Paul Kyzivat [pkyzivat@cisco.com > >] >> >> Sent: Sunday, May 22, 2011 11:03 PM >> To: Shekh-Yusef, Rifaat (Rifaat) >> Cc: splices@ietf.org >> >> Subject: Re: [splices] Answering an A/V Call Using Two Separate >> Devices proposal >> >> On 5/22/2011 8:49 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> >> >> You are then proposing the following: >> >> >> Alice used her *phone* to answer the incoming call >> | | | >> | >> | | 200 OK [Audio] | >> | >> | |-------------------->| >> | >> | | | 200 OK >> [Audio] | >> | | >> |-------------------->| >> | CANCEL | | >> | >> |<------------------------------------------| >> | >> | | | >> | >> | >> |<---dialog1------------------------------->| >> | >> |<======audio==============================>| >> | | | >> | >> | INVITE Alert-Info and [Video] | >> | >> |<--------------------| | >> | >> >> What happens here? >> Will the user be required to take an action on the PC to >> accept the INVITE? >> Or you are expecting the PC to provide an answer without >> user intervention? >> >> >> Could be handled various ways. >> >> The alert-info could suggest auto-answer. (The PC *honoring* such a >> request might be conditional on who it comes. But even if not >> honored >> for auto-answer it might still alert *differently*.) If it wasn't >> auto-answered, and returned 180, it could be followed up with an >> INVOKE >> to force the answer. >> >> Thanks, >> Paul >> >> | 200 OK [Video] | | >> | >> |<--------------------| | >> | >> | | re-INVITE [A/V] | >> | >> | |-------------------->| >> | >> | | | >> re-INVITE [A/V] | >> | | >> |-------------------->| >> | | | 200 OK >> [A/V] | >> | | 200 OK [A/V] >> |<--------------------| >> | |<--------------------| >> | >> | ACK | | >> | >> |<--------------------| | >> | >> | | | >> | >> >> >> |<------dialog2------>|<---dialog1------------------------------->| >> | | | >> | >> | >> |<======audio==============================>| >> >> >> |<============================video==============================>| >> | | | >> | >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com >> ] >> Sent: Sunday, May 22, 2011 5:09 PM >> To: Shekh-Yusef, Rifaat (Rifaat) >> Cc: splices@ietf.org >> Subject: Re: [splices] Answering an A/V Call Using Two >> Separate Devices >> proposal >> >> >> >> On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> >> Because a new INVITE will probably cause the PC to >> present the user with a >> >> UI component and wait for the users input. >> >> Well, I suppose you would want the PC to indicate what >> is going on in >> the UI in *some* way. But probably not exactly the same >> as getting a new >> call. >> >> That could be handled via appropriate Alert-Info. To >> some extent this is >> a matter of taste. I am inclined to prefer an economy of >> mechanism, and >> I think the alert-info feels like less mechanism than >> the particular >> INVOKE mechanism used in this scenario. (The invoke >> mechanism used here >> requires the phone to assume that the PC is aware of the >> dialog, and >> able to associate it with the appropriate contact >> address for doing the >> invite.) >> >> Thanks, >> Paul >> >> Regards, >> Rifaat >> >> >> -----Original Message----- >> From: splices-bounces@ietf.org >> >> [mailto:splices-bounces@ietf.org >> ] On Behalf >> >> Of >> >> Paul Kyzivat >> Sent: Saturday, May 21, 2011 11:15 PM >> To: splices@ietf.org >> >> Subject: Re: [splices] Answering an A/V Call >> Using Two Separate Devices >> proposal >> >> I guess all of that can work. But for the last >> part, if the phone knows >> enough to send the invoke to the pc, why can't >> it just send an INVITE to >> the pc? >> >> Thanks, >> Paul >> >> On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat >> (Rifaat) wrote: >> >> Hi, >> >> We are still working on a new version of the >> INVOKE document that removes >> >> the implicit subscription. >> >> >> Meanwhile I would like to continue the >> discussion of the various possible >> >> uses cases. >> >> The following is a proposal for Answering an >> A/V Call Using Two Separate >> >> Devices. >> >> >> Regards, >> Rifaat >> >> >> >> Alice Alice >> Proxy Bob >> PC Desk Phone >> | | >> | | >> | | >> | | >> Both Alice's devices subscribe to the reg >> event package, which allows each >> >> device to >> >> discover the capabilities of the other >> device based on the feature tags >> >> provided by each device. >> >> The Desk Phone knows that the PC supports >> Video, while the PC knows that >> >> the >> >> Desk Phone only supports audio. >> >> | | >> | | >> | | SUBSCRIBE >> reg | | >> | >> |-------------------->| | >> | | 200 OK >> | | >> | >> |<--------------------| | >> | | >> | | >> | SUBSCRIBE reg | >> | | >> >> |------------------------------------------>| >> | >> | 200 OK | >> | | >> >> |<------------------------------------------| >> | >> | | >> | | >> | | >> | | >> The two devices also subscribe to the dialog >> of each other. >> | | >> | | >> | | >> | | >> | SUBSCRIBE dialog | >> | | >> |-------------------->| >> | | >> | 200 OK | >> | | >> |<--------------------| >> | | >> | | >> | | >> | SUBSCRIBE dialog | >> | | >> |<--------------------| >> | | >> | 200 OK | >> | | >> |-------------------->| >> | | >> | | >> | | >> | | >> | | >> The scenario starts with an A/V call from >> Bob to Alice >> | | >> | | >> | | >> | INVITE Alice [A/V] | >> | | >> |<--------------------| >> | | INVITE Alice >> [A/V] | | >> | >> |<--------------------| | >> | INVITE Alice [A/V] | >> | | >> >> |<------------------------------------------| >> | >> | | >> | | >> >> >> (*) >> >> >> Let's assume that Alice used her PC to >> answer the incoming call >> The PC instructs the phone to answer the >> audio call >> | | >> | | >> | INVOKE Action: >> >> >> urn:invoke:call:answer;media=audio;transducer=speaker|headset >> >> |-------------------->| >> | | >> | 200 OK | >> | | >> |<--------------------| >> | | >> | | >> | | >> | | 200 OK >> [Audio] | | >> | >> |-------------------->| | >> | | >> | 200 OK [Audio] | >> | | >> |-------------------->| >> | CANCEL | >> | | >> >> |<------------------------------------------| >> | >> | | >> | | >> | >> |<---dialog1------------------------------->| >> | | >> | | >> | >> |<======audio==============================>| >> | | >> | | >> | | >> | | >> The PC then adds Video to the existing audio >> call. >> | | >> | | >> | INVITE with Join [Video] >> | | >> |-------------------->| >> | | >> | 100 | >> | | >> |<--------------------| >> | | >> | | re-INVITE >> [A/V] | | >> | >> |-------------------->| | >> | | >> | re-INVITE [A/V] | >> | | >> |-------------------->| >> | | >> | 200 OK [A/V] | >> | | 200 OK [A/V] >> |<--------------------| >> | >> |<--------------------| | >> | 200 OK [Video] | >> | | >> |<--------------------| >> | | >> | | >> | | >> >> >> |<------dialog2------>|<---dialog1------------------------------->| >> | | >> | | >> | >> |<======audio==============================>| >> >> >> |<============================video==============================>| >> | | >> | | >> | | >> | | >> >> >> >> The scenario continues after the (*) above >> Let's assume that Alice used her phone to >> answer the incoming call. >> The phone answers the audio call >> | | >> | | >> | | 200 OK >> [Audio] | | >> | >> |-------------------->| | >> | | >> | 200 OK [Audio] | >> | | >> |-------------------->| >> | CANCEL | >> | | >> >> |<------------------------------------------| >> | >> | | >> | | >> | >> |<---dialog1------------------------------->| >> | | >> | | >> | >> |<======audio==============================>| >> | | >> | | >> | | >> | | >> The phone then instructs the PC to initiate >> a video call to join the >> >> existing call >> >> | | >> | | >> | INVOKE Action: >> urn:invoke:call:join;media=video;dialog=dialog1 >> |<--------------------| >> | | >> | 200 OK | >> | | >> |-------------------->| >> | | >> | | >> | | >> The PC then adds Video to the existing audio >> call. >> | | >> | | >> | INVITE with Join [Video] >> | | >> |-------------------->| >> | | >> | 100 | >> | | >> |<--------------------| >> | | >> | | re-INVITE >> [A/V] | | >> | >> |-------------------->| | >> | | >> | re-INVITE [A/V] | >> | | >> |-------------------->| >> | | >> | 200 OK [A/V] | >> | | 200 OK [A/V] >> |<--------------------| >> | >> |<--------------------| | >> | 200 OK [Video] | >> | | >> |<--------------------| >> | | >> | | >> | | >> >> >> |<------dialog2------>|<---dialog1------------------------------->| >> | | >> | | >> | >> |<======audio==============================>| >> >> >> |<============================video==============================>| >> | | >> | | >> >> >> >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> >> https://www.ietf.org/mailman/listinfo/splices >> >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> >> https://www.ietf.org/mailman/listinfo/splices >> >> >> >> >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> >> https://www.ietf.org/mailman/listinfo/splices >> >> >> --00151747b3625dbdfd04a4065198 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SGkgUGF1bCygPGRpdj48YnI+PC9kaXY+PGRpdj5JIGFncmVlIHRoZSBtZWNoYW5pc20gaXMgZnVu ZGFtZW50YWxseSBjb250cm92ZXJzaWFsIGFuZCB0aGUgYmVzdCB3YXkgdG8gZmFjZSB0aGlzIGlz IHRvIGRlZmluZSB0aGUgc2NvcGUgdmVyeSBjYXJlZnVsbHkgYW5kIG5hcnJvd2x5LqA8L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PldhcyB0aGUgdXNlIG9mIENTVEEtMyBldmVyIGRpc2N1c3NlZD8g SSBoYWQgYSBwYXNzaW5noGFjcXVhaW50YW5jZaB3aXRoIHRoaXMgYSBjb3VwbGUgb2YgeWVhcnMg YWdvIGFuZCBzb21lIG9mIHdoYXQgc3BsaWNlcyBuZWVkcyBtaWdodCBjb21lIGZyb20gdGhlcmUu IEV2ZW4gaWYgbm90IGRpcmVjdGx5IHJlbGV2YW50IGl0IGRvZXMgcHJvdmlkZSBvbmUgcGVyc3Bl Y3RpdmUgb24gdGhlIGtpbmRzIG9mIGNvbnRyb2wgcHJpbWl0aXZlcyB3aGljaCBjb21lIGludG8g cGxheS4gKEkgdXNlZKA8YSBocmVmPSJodHRwOi8vd3d3LmVjbWEtaW50ZXJuYXRpb25hbC5vcmcv YWN0aXZpdGllcy9Db21tdW5pY2F0aW9ucy9URzExL0NTVEFvdmVydmlldy5wZGYiPmh0dHA6Ly93 d3cuZWNtYS1pbnRlcm5hdGlvbmFsLm9yZy9hY3Rpdml0aWVzL0NvbW11bmljYXRpb25zL1RHMTEv Q1NUQW92ZXJ2aWV3LnBkZjwvYT4gdG8gcmVtaW5kIG15c2VsZiBvZiBzb21lIG9mIHdoYXQgaXQg ZW5jb21wYXNzZWQpLiBXaGlsZSBDU1RBLTMgbG9va3MgZ29vZCB0byBtZSAmcXVvdDtvbiBwYXBl ciZxdW90OyAtIEkgbGFjayByZWFsIGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2Ugd2l0aCBpdCAt IHNvIEkgd291bGQgYmUgaW50ZXJlc3RlZCB0byBoZWFyIGlmIGFueW9uZSBoYXMgaW5wdXQgb24g dGhpcy6gPC9kaXY+CjxkaXY+PGJyPjwvZGl2PjxkaXY+UGV0ZXI8YnI+PGJyPjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiBUdWUsIE1heSAyNCwgMjAxMSBhdCA5OjExIEFNLCBQYXVsIEt5eml2 YXQgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAY2lzY28uY29t Ij5wa3l6aXZhdEBjaXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXg7Ij4KUGV0ZXIsPGJyPgo8YnI+CklNTyB0 aGUgJnF1b3Q7YWN0aW9uIG1lY2hhbmlzbSZxdW90OyB3aWxsIGJlIGNvbnRyb3ZlcnNpYWwgcmVn YXJkbGVzcyBvZiBob3cgaXQgaXMgZW5jb2RlZC4gQW5kIGl0IHdpbGwgaGF2ZSBsYXJnZWx5IHRo ZSBzYW1lIGltcGFjdCBvbiBpbXBsZW1lbnRhdGlvbnMuPGJyPgooSXQgaXMgYSBzaWduaWZpY2Fu dCBleHRlbnNpb24gb2YgdGhlIHNjb3BlIG9mIFNJUC4pPGJyPgo8YnI+CkkgZG9uJiMzOTt0IHRo aW5rIHRoYXQgdHJ5aW5nIHRvICZxdW90O2hpZGUmcXVvdDsgaXQgd2lsbCBtYWtlIHRoaW5ncyBi ZXR0ZXIuIEFuZCBhcyBiZXN0IEkgdW5kZXJzdGFuZCBpdCBkb2VzbiYjMzk7dCBmaXQgdGhlIHNl bWFudGljcyBvZiBQVUJMSVNILiAoUHVibGlzaCBpcyBpbnRpbWF0ZWx5IHRpZWQgdG8gdGhlIHN0 YXRlIG1vZGVsIG9mIGFuIGV2ZW50IHBhY2thZ2UuIE1heWJlIGlmIHRoZSBldmVudCBwYWNrYWdl IGlzIGNhcmVmdWxseSBkZXNpZ25lZCB5b3UgY291bGQgbWFrZSBhIGNhc2UgZm9yIHRoaXMuIEJ1 dCBJJiMzOTttIGR1YmlvdXMuKTxicj4KCjxicj4KSSB0aGluayB0aGUga2luZCBvZiB1c2UgY2Fz ZXMgdGhhdCBSaWZhYXQgaXMgcG9zaW5nIGFyZSBnb29kIGFzIGEgc3RhcnRpbmcgcG9pbnQuIEJ1 dCBhZnRlciBzb21lIG9mIHRoYXQgSSB0aGluayBvbmUgb2YgdGhlIG5leHQgc3RlcHMgbXVzdCBi ZSBjYXJlZnVsbHkgZGVmaW5pbmcgdGhlIHNjb3BlIG9mIHRoaXMgbmV3IGFjdGlvbiBtZWNoYW5p c20uIEFuZCBJIGV4cGVjdCB0aGF0IHRvIGJlIGRpZmZpY3VsdC4gUmlnaHQgbm93IGl0IHNlZW1z IHRvIGJlIGEgcG90IGludG8gd2hpY2ggeW91IGNhbiBwdXQgKmFueXRoaW5nKi4gSSB0aGluayB3 ZSBuZWVkIHRvIGdldCB0byB0aGUgcG9pbnQgd2hlcmUgaXQgaXMgY2xlYXIgd2hhdCBzb3J0cyBv ZiB0aGluZ3MgYXJlIHZhbGlkIGFjdGlvbnMsIGFuZCB3aGljaCBhcmUgbm90LiBJIGV4cGVjdCB0 aGlzIHdpbGwgaW52b2x2ZSBkZWZpbmluZyBhbiBleHRlbmRlZCBlbnZpcm9ubWVudCBmb3IgYSBV QSwgb2YgdGhpbmdzIGl0IG5lZWRzIHRvIG1hbmlwdWxhdGUuIChTdHVmZiBsaWtlIHNwZWFrZXJz LCBtaWNyb3Bob25lcywgZGlzcGxheXMsIGJ1dHRvbnMsIG11bHRpcGxlIGRpYWxvZ3MsIC4uLikg V2UgbWlnaHQgZ2V0IGEgaGVhZCBzdGFydCBieSBleHBsb3Jpbmcgd2hhdCBDVEkgZmVhdHVyZXMg YXJlIGRlZmluZWQgaW4gb3RoZXIgcHJvdG9jb2xzLjxicj4KCjxicj4KIKAgoCCgIKBUaGFua3Ms PGJyPgogoCCgIKAgoFBhdWw8ZGl2IGNsYXNzPSJpbSI+PGJyPgo8YnI+Ck9uIDUvMjQvMjAxMSA4 OjQxIEFNLCBQZXRlciBNdXNncmF2ZSB3cm90ZTo8YnI+CjwvZGl2PjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAj Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgY2xhc3M9ImltIj4KSSBhZ3JlZSB3aXRo IFBhdWwgdGhhdDo8YnI+CjEpIFRoaXMgd29ya3Mgb2suPGJyPgoyKSBJTlZPS0UgaXMgbW9yZSBt ZWNoYW5pc20gdGhhbiBhIG5ldyBoZWFkZXIuIFtBIG1ldGhvZCBpcyBhIGJpZ2dlcjxicj4KZGVh bCB0aGFuIGEgaGVhZGVyXTxicj4KPGJyPgpJJiMzOTtkIGFsc28gb2JzZXJ2ZSBpbiBhICZxdW90 O3JlYWwgcG9saXRpayZxdW90OyBzZW5zZSB0aGF0IHRoZSBwb3RlbnRpYWwgZW5lcmd5PGJyPgpi YXJyaWVyIHRvIGdldGluZyBhIG5ldyBTSVAgbWV0aG9kIGluIHBsYWNlIHdpbGwgbGlrZWx5IGJl IHNpZ25pZmljYW50Ljxicj4KSSB3b3VsZCBleHBlY3QgaXQgd291bGQgaGF2ZSB0byBiZSBhIGRp c3BhdGNoLWVkIFdHIGFsbCBvbiBpdCYjMzk7cyBvd24uPGJyPgpQZW9wbGUgd2lsbCBkZWNpZGUg dG8gZWl0aGVyIHVzZSBpdCB0byBzb2x2ZSB3b3JsZCBodW5nZXIgLSBvciBkZWNpZGU8YnI+CnRo YXQgaXQgaXMgdGhlIHJvb3Qgb2YgYWxsIGV2aWwuPGJyPgo8YnI+ClVuZGVyICZxdW90O291dCB0 aGVyZSZxdW90OyBpZGVhcyAtIHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHB1dCB0aGUgQWN0aW9u IGhlYWRlcjxicj4KaW4gYSBQVUJMSVNIPyBXb3VsZCB0aGlzIGFsbG93IHRoZSBzYW1lIHNpZ25h bGxpbmcgc2VtYW50aWNzIGFzIElOVk9LRTxicj4Kd2l0aG91dCB0aGUgbmVlZCBmb3IgYSBuZXcg bWV0aG9kPzxicj4KPGJyPgpQZXRlciBNdXNncmF2ZTxicj4KPGJyPgpPbiBNb24sIE1heSAyMywg MjAxMSBhdCA5OjA3IEFNLCBQYXVsIEt5eml2YXQgJmx0OzxhIGhyZWY9Im1haWx0bzpwa3l6aXZh dEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5wa3l6aXZhdEBjaXNjby5jb208L2E+PGJyPjwv ZGl2PjxkaXYgY2xhc3M9ImltIj4KJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cGt5eml2YXRA Y2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cGt5eml2YXRAY2lzY28uY29tPC9hPiZndDsmZ3Q7 IHdyb3RlOjxicj4KPGJyPgo8YnI+Cjxicj4KIKAgoE9uIDUvMjMvMjAxMSA4OjU2IEFNLCBTaGVr aC1ZdXNlZiwgUmlmYWF0IChSaWZhYXQpIHdyb3RlOjxicj4KPGJyPgogoCCgIKAgoEkgZG8gbm90 IHNlZSBob3cgdGhpcyBwcm9wb3NhbCBpcyAmcXVvdDtsZXNzIG1lY2hhbmlzbSZxdW90OyB0aGFu IHRoZTxicj4KIKAgoCCgIKBvcmlnaW5hbCBwcm9wb3NhbCwgYnV0IEkgdGVuZCB0byBhZ3JlZSB3 aXRoIHlvdSB0aGF0IHRoaXMgbWlnaHQ8YnI+CiCgIKAgoCCgYmUgJnF1b3Q7YSBtYXR0ZXIgb2Yg dGFzdGUmcXVvdDsuPGJyPgo8YnI+Cjxicj4KIKAgoFRoZSBkZXZpbCBpcyBpbiB0aGUgZGV0YWls cyBoZXJlLCBhbmQgd2UgZG9uJiMzOTt0IGhhdmUgZW5vdWdoIGRldGFpbHMuPGJyPgogoCCgU28g aXRzIGFsbCBpbiB0aGUgc2V0IG9mIGFzc3VtcHRpb25zIG9uZSBpcyBtYWtpbmcuPGJyPgo8YnI+ CiCgIKBJbiB0aGUgZW5kIHdlIHByb2JhYmx5IGFyZW4mIzM5O3QgZ29pbmcgdG8gc3RhbmRhcmRp emUgc2VydmljZXMgLSBqdXN0PGJyPgogoCCgbWVjaGFuaXNtcyBmb3IgY3JlYXRpbmcgc2Vydmlj ZXMuIEJ1dCBwZXJoYXBzIHdlIHdpbGwgaGF2ZSBhbjxicj4KIKAgoCZxdW90O2V4YW1wbGVzJnF1 b3Q7IGRvYyB0aGF0IHNob3dzIGhvdyB0aGUgbWVjaGFuaXNtcyBtaWdodCBiZSB1c2VkIHRvIGNy ZWF0ZTxicj4KIKAgoGEgcmFuZ2Ugb2YgaW50ZXJlc3Rpbmcgc2VydmljZXMgc3VjaCBhcyB0aGVz ZS4gSWYgc28sIEkgd291bGQgdGhpbms8YnI+CiCgIKB3ZSB3b3VsZCBuZWVkIHRvIHdvcmsgdGhy b3VnaCBlYWNoIG9uZSBpbiBkZXRhaWwsIGNhcmVmdWxseSBkZWZpbmluZzxicj4KIKAgoGFsbCB0 aGUgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIGVudmlyb25tZW50Ljxicj4KPGJyPgogoCCgQW5kIHRo YXQgaXMgcmVhbGx5IHdoYXQgaXQgdGFrZXMgdG8gZGVjaWRlIG9uIGVhY2ggcGFydGljdWxhcjxi cj4KIKAgoCZxdW90O2FjdGlvbiZxdW90OywgYmVjYXVzZSB0aG9zZSBzZWVtIHRvIGJlIHJhdGhl ciBzcGVjaWFsaXplZC4gQXQgdGhlIG1vbWVudDxicj4KIKAgoEkgZG9uJiMzOTt0IGhhdmUgYSB2 aXNpb24gb2YgYSBjbGVhciBhbmQgb2J2aW91cyBzZXQgb2YgYWN0aW9ucyB0aGF0PGJyPgogoCCg ZW5hYmxlIGFsbCB0aGUgaW50ZXJlc3Rpbmcgc2VydmljZXMuIEl0cyBtb3JlIGEgbWF0dGVyIG9m IGNyYWZ0aW5nPGJyPgogoCCgYW4gYWN0aW9uIHRvIHN1cHBvcnQgb25lIG9yIGEgZmV3IHNlcnZp Y2VzLiBJIHdpc2ggaXQgd2FzIG1vcmUgY2xlYXI8YnI+CiCgIKBjdXQgdGhhbiB0aGF0LiBNYXli ZSBpdCB3aWxsIGJlY29tZSBzbyB3aXRoIG1vcmUgc3R1ZHkuPGJyPgo8YnI+CiCgIKAgoCCgIKAg oFRoYW5rcyw8YnI+CiCgIKAgoCCgIKAgoFBhdWw8YnI+Cjxicj4KPGJyPgogoCCgIKAgoFJlZ2Fy ZHMsPGJyPgogoCCgIKAgoCCgUmlmYWF0PGJyPgo8YnI+Cjxicj4KPGJyPgogoCCgIKAgoF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+PC9kaXY+CiCgIKAgoCCgRnJv bTogUGF1bCBLeXppdmF0IFs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAY2lzY28uY29tIiB0YXJn ZXQ9Il9ibGFuayI+cGt5eml2YXRAY2lzY28uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpwa3l6aXZhdEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5wa3l6aXZhdEBjaXNjby5j b208L2E+Jmd0O108ZGl2IGNsYXNzPSJpbSI+PGJyPgogoCCgIKAgoFNlbnQ6IFN1bmRheSwgTWF5 IDIyLCAyMDExIDExOjAzIFBNPGJyPgogoCCgIKAgoFRvOiBTaGVraC1ZdXNlZiwgUmlmYWF0IChS aWZhYXQpPGJyPjwvZGl2PgogoCCgIKAgoENjOiA8YSBocmVmPSJtYWlsdG86c3BsaWNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwbGljZXNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnNwbGljZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcGxpY2VzQGll dGYub3JnPC9hPiZndDs8ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPjxicj4KIKAgoCCg IKBTdWJqZWN0OiBSZTogW3NwbGljZXNdIEFuc3dlcmluZyBhbiBBL1YgQ2FsbCBVc2luZyBUd28g U2VwYXJhdGU8YnI+CiCgIKAgoCCgRGV2aWNlcyBwcm9wb3NhbDxicj4KPGJyPgogoCCgIKAgoE9u IDUvMjIvMjAxMSA4OjQ5IFBNLCBTaGVraC1ZdXNlZiwgUmlmYWF0IChSaWZhYXQpIHdyb3RlOjxi cj4KPGJyPgo8YnI+CiCgIKAgoCCgIKAgoFlvdSBhcmUgdGhlbiBwcm9wb3NpbmcgdGhlIGZvbGxv d2luZzo8YnI+Cjxicj4KPGJyPgogoCCgIKAgoCCgIKBBbGljZSB1c2VkIGhlciAqcGhvbmUqIHRv IGFuc3dlciB0aGUgaW5jb21pbmcgY2FsbDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCg IKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwg MjAwIE9LIFtBdWRpb10goCCgIKB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4K IKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwtLS0tLS0tLS0tLS0tLS0t LS0tLSZndDt8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCg IKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IDIwMCBP Szxicj4KIKAgoCCgIKAgoCCgW0F1ZGlvXSCgIKAgoHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoHwg oCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKB8LS0tLS0tLS0tLS0tLS0tLS0t LS0mZ3Q7fDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgfCBDQU5DRUwgoCCgIKAgoCCgIKAgoHwgoCCg IKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAg oCCgIKAgoCCgIKAgoCCgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS18PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAg oCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgfDxicj4KIKAgoCCg IKAgoCCgfCZsdDstLS1kaWFsb2cxLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8 PGJyPgogoCCgIKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCgIKB8Jmx0Oz09PT09PWF1ZGlv PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Jmd0O3w8YnI+CiCgIKAgoCCgIKAgoCCgIKAg oHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoHwgSU5WSVRFIEFsZXJ0 LUluZm8gYW5kIFtWaWRlb10goCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18IKAg oCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+Cjxi cj4KIKAgoCCgIKAgoCCgV2hhdCBoYXBwZW5zIGhlcmU/PGJyPgogoCCgIKAgoCCgIKBXaWxsIHRo ZSB1c2VyIGJlIHJlcXVpcmVkIHRvIHRha2UgYW4gYWN0aW9uIG9uIHRoZSBQQyB0bzxicj4KIKAg oCCgIKAgoCCgYWNjZXB0IHRoZSBJTlZJVEU/PGJyPgogoCCgIKAgoCCgIKBPciB5b3UgYXJlIGV4 cGVjdGluZyB0aGUgUEMgdG8gcHJvdmlkZSBhbiBhbnN3ZXIgd2l0aG91dDxicj4KIKAgoCCgIKAg oCCgdXNlciBpbnRlcnZlbnRpb24/PGJyPgo8YnI+Cjxicj4KIKAgoCCgIKBDb3VsZCCgYmUgaGFu ZGxlZCB2YXJpb3VzIHdheXMuPGJyPgo8YnI+CiCgIKAgoCCgVGhlIGFsZXJ0LWluZm8gY291bGQg c3VnZ2VzdCBhdXRvLWFuc3dlci4gKFRoZSBQQyAqaG9ub3JpbmcqIHN1Y2ggYTxicj4KIKAgoCCg IKByZXF1ZXN0IG1pZ2h0IGJlIGNvbmRpdGlvbmFsIG9uIHdobyBpdCBjb21lcy4gQnV0IGV2ZW4g aWYgbm90PGJyPgogoCCgIKAgoGhvbm9yZWQ8YnI+CiCgIKAgoCCgZm9yIGF1dG8tYW5zd2VyIGl0 IG1pZ2h0IHN0aWxsIGFsZXJ0ICpkaWZmZXJlbnRseSouKSBJZiBpdCB3YXNuJiMzOTt0PGJyPgog oCCgIKAgoGF1dG8tYW5zd2VyZWQsIGFuZCByZXR1cm5lZCAxODAsIGl0IGNvdWxkIGJlIGZvbGxv d2VkIHVwIHdpdGggYW48YnI+CiCgIKAgoCCgSU5WT0tFPGJyPgogoCCgIKAgoHRvIGZvcmNlIHRo ZSBhbnN3ZXIuPGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgVGhhbmtzLDxicj4KIKAgoCCgIKAg oCCgIKAgoCBQYXVsPGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoHwgMjAwIE9LIFtWaWRlb10g oCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18IKAgoCCg IKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAg oCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IHJlLUlOVklURSBbQS9WXSCgIKAg fDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoHwg oCCgIKAgoCCgIKAgoCCgIKAgoCB8LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4KIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgcmUtSU5WSVRF IFtBL1ZdIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fDxicj4KIKAgoCCgIKAgoCCgfC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+CiCgIKAgoCCg IKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCAy MDAgT0s8YnI+CiCgIKAgoCCgIKAgoFtBL1ZdIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCgIKAgoCCg IKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCAyMDAgT0sgW0EvVl08YnI+CiCgIKAgoCCgIKAgoCCg fCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLXw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAg oCCgIKAgoCCgIKAgoCB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfDxicj4KIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoHwgQUNLIKAgoCCgIKAgoCCgIKAg oCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8 YnI+CiCgIKAgoCCgIKAgoCCgIKAgoHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18IKAgoCCgIKAg oCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCg IKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxi cj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKB8Jmx0 Oy0tLS0tLWRpYWxvZzItLS0tLS0mZ3Q7fCZsdDstLS1kaWFsb2cxLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSZndDt8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAg oCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCgIKB8Jmx0Oz09PT09PWF1 ZGlvPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Jmd0O3w8YnI+Cjxicj4KIKAgoCCgIKAg oCCgIKB8Jmx0Oz09PT09PT09PT09PT09PT09PT09PT09PT09PT12aWRlbz09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PSZndDt8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCg IKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCB8PGJyPgo8YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAgoC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPgogoCCgIKAgoCCgIKAgoCCgRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnBreXppdmF0QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBreXppdmF0 QGNpc2NvLmNvbTwvYT48YnI+CiCgIKAgoCCgIKAgoCCgIKAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpwa3l6aXZhdEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5wa3l6aXZhdEBjaXNjby5j b208L2E+Jmd0O108YnI+CiCgIKAgoCCgIKAgoCCgIKBTZW50OiBTdW5kYXksIE1heSAyMiwgMjAx MSA1OjA5IFBNPGJyPgogoCCgIKAgoCCgIKAgoCCgVG86IFNoZWtoLVl1c2VmLCBSaWZhYXQgKFJp ZmFhdCk8YnI+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjwvZGl2PjxkaXYgY2xhc3M9Img1Ij4KIKAg oCCgIKAgoCCgIKAgoENjOiA8YSBocmVmPSJtYWlsdG86c3BsaWNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNwbGljZXNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OnNwbGljZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcGxpY2VzQGlldGYub3JnPC9hPiZn dDs8YnI+CiCgIKAgoCCgIKAgoCCgIKBTdWJqZWN0OiBSZTogW3NwbGljZXNdIEFuc3dlcmluZyBh biBBL1YgQ2FsbCBVc2luZyBUd288YnI+CiCgIKAgoCCgIKAgoCCgIKBTZXBhcmF0ZSBEZXZpY2Vz PGJyPgogoCCgIKAgoCCgIKAgoCCgcHJvcG9zYWw8YnI+Cjxicj4KPGJyPgo8YnI+CiCgIKAgoCCg IKAgoCCgIKBPbiA1LzIyLzIwMTEgMjo0MCBQTSwgU2hla2gtWXVzZWYsIFJpZmFhdCAoUmlmYWF0 KSB3cm90ZTo8YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKBCZWNhdXNlIGEgbmV3IElOVklU RSB3aWxsIHByb2JhYmx5IGNhdXNlIHRoZSBQQyB0bzxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKBw cmVzZW50IHRoZSB1c2VyIHdpdGggYTxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCgVUkgY29tcG9u ZW50IGFuZCB3YWl0IGZvciB0aGUgdXNlcnMgaW5wdXQuPGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCg IKBXZWxsLCBJIHN1cHBvc2UgeW91IHdvdWxkIHdhbnQgdGhlIFBDIHRvIGluZGljYXRlIHdoYXQ8 YnI+CiCgIKAgoCCgIKAgoCCgIKBpcyBnb2luZyBvbiBpbjxicj4KIKAgoCCgIKAgoCCgIKAgoHRo ZSBVSSBpbiAqc29tZSogd2F5LiBCdXQgcHJvYmFibHkgbm90IGV4YWN0bHkgdGhlIHNhbWU8YnI+ CiCgIKAgoCCgIKAgoCCgIKBhcyBnZXR0aW5nIGEgbmV3PGJyPgogoCCgIKAgoCCgIKAgoCCgY2Fs bC48YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAgoFRoYXQgY291bGQgYmUgaGFuZGxlZCB2aWEgYXBw cm9wcmlhdGUgQWxlcnQtSW5mby4gVG88YnI+CiCgIKAgoCCgIKAgoCCgIKBzb21lIGV4dGVudCB0 aGlzIGlzPGJyPgogoCCgIKAgoCCgIKAgoCCgYSBtYXR0ZXIgb2YgdGFzdGUuIEkgYW0gaW5jbGlu ZWQgdG8gcHJlZmVyIGFuIGVjb25vbXkgb2Y8YnI+CiCgIKAgoCCgIKAgoCCgIKBtZWNoYW5pc20s IGFuZDxicj4KIKAgoCCgIKAgoCCgIKAgoEkgdGhpbmsgdGhlIGFsZXJ0LWluZm8gZmVlbHMgbGlr ZSBsZXNzIG1lY2hhbmlzbSB0aGFuPGJyPgogoCCgIKAgoCCgIKAgoCCgdGhlIHBhcnRpY3VsYXI8 YnI+CiCgIKAgoCCgIKAgoCCgIKBJTlZPS0UgbWVjaGFuaXNtIHVzZWQgaW4gdGhpcyBzY2VuYXJp by4gKFRoZSBpbnZva2U8YnI+CiCgIKAgoCCgIKAgoCCgIKBtZWNoYW5pc20gdXNlZCBoZXJlPGJy PgogoCCgIKAgoCCgIKAgoCCgcmVxdWlyZXMgdGhlIHBob25lIHRvIGFzc3VtZSB0aGF0IHRoZSBQ QyBpcyBhd2FyZSBvZiB0aGU8YnI+CiCgIKAgoCCgIKAgoCCgIKBkaWFsb2csIGFuZDxicj4KIKAg oCCgIKAgoCCgIKAgoGFibGUgdG8gYXNzb2NpYXRlIGl0IHdpdGggdGhlIGFwcHJvcHJpYXRlIGNv bnRhY3Q8YnI+CiCgIKAgoCCgIKAgoCCgIKBhZGRyZXNzIGZvciBkb2luZyB0aGU8YnI+CiCgIKAg oCCgIKAgoCCgIKBpbnZpdGUuKTxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBUaGFu a3MsPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBQYXVsPGJyPgo8YnI+CiCgIKAgoCCgIKAg oCCgIKAgoCCgUmVnYXJkcyw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoFJpZmFhdDxicj4K PGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBGcm9tOiA8YSBocmVmPSJtYWlsdG86c3Bs aWNlcy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3BsaWNlcy1ib3VuY2VzQGll dGYub3JnPC9hPjxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86c3BsaWNlcy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3BsaWNl cy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwbGljZXMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnNwbGljZXMtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+CiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwbGljZXMtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnNwbGljZXMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7XSBPbiBC ZWhhbGY8YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAgoE9mPGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoFBhdWwgS3l6aXZhdDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgU2VudDog U2F0dXJkYXksIE1heSAyMSwgMjAxMSAxMToxNSBQTTxicj48L2Rpdj48L2Rpdj4KIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgVG86IDxhIGhyZWY9Im1haWx0bzpzcGxpY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c3BsaWNlc0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86c3BsaWNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwbGljZXNAaWV0Zi5vcmc8L2E+ Jmd0OzxkaXY+PGRpdj48L2Rpdj48ZGl2IGNsYXNzPSJoNSI+PGJyPgoKIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgU3ViamVjdDogUmU6IFtzcGxpY2VzXSBBbnN3ZXJpbmcgYW4gQS9WIENhbGw8YnI+ CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoFVzaW5nIFR3byBTZXBhcmF0ZSBEZXZpY2VzPGJyPgog oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBwcm9wb3NhbDxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKBJIGd1ZXNzIGFsbCBvZiB0aGF0IGNhbiB3b3JrLiBCdXQgZm9yIHRoZSBsYXN0PGJy PgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBwYXJ0LCBpZiB0aGUgcGhvbmUga25vd3M8YnI+CiCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoGVub3VnaCB0byBzZW5kIHRoZSBpbnZva2UgdG8gdGhlIHBj LCB3aHkgY2FuJiMzOTt0PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBpdCBqdXN0IHNlbmQg YW4gSU5WSVRFIHRvPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB0aGUgcGM/PGJyPgo8YnI+ CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgVGhhbmtzLDxicj4KIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCBQYXVsPGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoE9uIDUv MjEvMjAxMSA4OjU2IEFNLCBTaGVraC1ZdXNlZiwgUmlmYWF0PGJyPgogoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAoUmlmYWF0KSB3cm90ZTo8YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoEhpLDxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgV2UgYXJlIHN0aWxs IHdvcmtpbmcgb24gYSBuZXcgdmVyc2lvbiBvZiB0aGU8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKBJTlZPS0UgZG9jdW1lbnQgdGhhdCByZW1vdmVzPGJyPgo8YnI+CiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoHRoZSBpbXBsaWNpdCBzdWJzY3JpcHRpb24uPGJyPgo8YnI+Cjxicj4KIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoE1lYW53aGlsZSBJIHdvdWxkIGxpa2UgdG8gY29udGlu dWUgdGhlPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgZGlzY3Vzc2lvbiBvZiB0aGUg dmFyaW91cyBwb3NzaWJsZTxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB1c2VzIGNh c2VzLjxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgVGhlIGZvbGxvd2luZyBp cyBhIHByb3Bvc2FsIGZvciBBbnN3ZXJpbmcgYW48YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKBBL1YgQ2FsbCBVc2luZyBUd28gU2VwYXJhdGU8YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgRGV2aWNlcy48YnI+Cjxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgUmVnYXJkcyw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIFJpZmFhdDxi cj4KPGJyPgo8YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBBbGlj ZSCgIKAgoCCgIKAgoCCgIKAgQWxpY2U8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKBQcm94eSCgIKAgoCCgIKAgoCCgIKAgoEJvYjxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgUEMgoCCgIKAgoCCgIKAgoCCgIERlc2sgUGhvbmU8YnI+CiCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgog oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCg IHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAg oCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBCb3RoIEFs aWNlJiMzOTtzIGRldmljZXMgc3Vic2NyaWJlIHRvIHRoZSByZWc8YnI+CiCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKBldmVudCBwYWNrYWdlLCB3aGljaCBhbGxvd3MgZWFjaDxicj4KPGJyPgog oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBkZXZpY2UgdG88YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoGRpc2NvdmVyIHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIG90aGVyPGJyPgog oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgZGV2aWNlIGJhc2VkIG9uIHRoZSBmZWF0dXJlIHRh Z3M8YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgcHJvdmlkZWQgYnkgZWFjaCBkZXZp Y2UuPGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBUaGUgRGVzayBQaG9uZSBr bm93cyB0aGF0IHRoZSBQQyBzdXBwb3J0czxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oFZpZGVvLCB3aGlsZSB0aGUgUEMga25vd3MgdGhhdDxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCg dGhlPGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoERlc2sgUGhvbmUgb25seSBzdXBw b3J0cyBhdWRpby48YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgU1VCU0NSSUJFPGJyPgogoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgcmVnIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8 PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgfC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgoCCgIKAgoCCgIKAg oCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCg IKAgoCCgIKAgoCCgIKAgfCAyMDAgT0s8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCZsdDstLS0t LS0tLS0tLS0tLS0tLS0tLXwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJy PgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IFNVQlNDUklCRSByZWcgoCCg IKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCg IKAgoCCgIKAgoCB8PGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fCCgIKAgoCCgIKAgoCCg IKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgMjAwIE9L IKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18IKAg oCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoFRoZSB0d28gZGV2aWNlcyBhbHNvIHN1YnNjcmliZSB0 byB0aGUgZGlhbG9nPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgb2YgZWFjaCBvdGhl ci48YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAg oCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoHwgU1VCU0NSSUJFIGRpYWxvZyCgIKB8PGJyPgogoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8 PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCg IKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgMjAwIE9L IKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8 YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgU1VCU0NSSUJFIGRpYWxv ZyCgIKB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCg IKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwm bHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoHwgMjAwIE9LIKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8 PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCg IKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAg oCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKBUaGUgc2NlbmFyaW8gc3RhcnRzIHdpdGggYW4gQS9WIGNhbGwgZnJvbTxi cj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoEJvYiB0byBBbGljZTxicj4KIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCg IKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IElOVklU RSBBbGljZSBbQS9WXSCgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgSU5WSVRFIEFsaWNlPGJy PgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgW0EvVl0goHwgoCCgIKAgoCCgIKAgoCCgIKAg oCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLXwgoCCgIKAgoCCg IKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IElO VklURSBBbGljZSBbQS9WXSCgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t fCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+Cjxicj4KPGJyPgogoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgKCopPGJyPgo8YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoExldCYjMzk7cyBhc3N1bWUgdGhhdCBBbGljZSB1c2VkIGhlciBQQyB0bzxi cj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoGFuc3dlciB0aGUgaW5jb21pbmcgY2FsbDxi cj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoFRoZSBQQyBpbnN0cnVjdHMgdGhlIHBob25l IHRvIGFuc3dlciB0aGU8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBhdWRpbyBjYWxs PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAg oCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAg oCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8 IElOVk9LRSBBY3Rpb246PGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHVybjppbnZv a2U6Y2FsbDphbnN3ZXI7bWVkaWE9YXVkaW87dHJhbnNkdWNlcj1zcGVha2VyfGhlYWRzZXQ8YnI+ Cjxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfC0tLS0tLS0tLS0tLS0t LS0tLS0tJmd0O3w8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAg oCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgfCAyMDAgT0sgoCCgIKAgoCCgIKAgoHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLXw8YnI+CiCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4K IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCg IHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCg IKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAg oCCgIKAgoCCgIKAgoCCgIHwgMjAwIE9LPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg W0F1ZGlvXSCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfC0t LS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4K IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgMjAwIE9LIFtBdWRpb10goCCg IKB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCg IKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwtLS0t LS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKB8IENBTkNFTCCgIKAgoCCgIKAgoCCgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgo8YnI+CiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKB8Jmx0Oy0tLWRpYWxvZzEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0 O3w8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAg oCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8Jmx0Oz09PT09PWF1ZGlvPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Jmd0O3w8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgog oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCg IHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBUaGUgUEMgdGhlbiBhZGRzIFZpZGVv IHRvIHRoZSBleGlzdGluZyBhdWRpbzxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoGNh bGwuPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCg IKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCg IKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKB8IElOVklURSB3aXRoIEpvaW4gW1ZpZGVvXTxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPgogoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+ CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgMTAwIKAgoCCgIKAgoCCgIKAg oCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAg oCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwmbHQ7 LS0tLS0tLS0tLS0tLS0tLS0tLS18PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IHJlLUlOVklURTxicj4KIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoFtBL1ZdIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxi cj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfDxicj4KIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8IKAgoCCgIKAgoCCgIKAg oCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCg IKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8 IHJlLUlOVklURSBbQS9WXSCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCB8LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4KIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IDIwMCBPSyBbQS9WXSCgIKAgoCCgfDxi cj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAg oCCgIHwgMjAwIE9LIFtBL1ZdPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwmbHQ7LS0tLS0t LS0tLS0tLS0tLS0tLS18IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgfCAyMDAgT0sgW1ZpZGVvXSCgIKAgoHw8YnI+CiCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4K IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCZsdDstLS0tLS0tLS0tLS0tLS0t LS0tLXw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAg oCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCg IKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKB8Jmx0Oy0tLS0tLWRpYWxvZzItLS0tLS0mZ3Q7fCZsdDstLS1kaWFsb2cxLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgfCZsdDs9PT09PT1hdWRpbz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSZn dDt8PGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwmbHQ7PT09PT09PT09 PT09PT09PT09PT09PT09PT09PXZpZGVvPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Jmd0 O3w8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAg oCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+Cjxicj4KPGJyPgo8YnI+CiCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBUaGUgc2NlbmFyaW8gY29udGludWVzIGFmdGVyIHRoZSAo KikgYWJvdmU8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBMZXQmIzM5O3MgYXNzdW1l IHRoYXQgQWxpY2UgdXNlZCBoZXIgcGhvbmUgdG88YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKBhbnN3ZXIgdGhlIGluY29taW5nIGNhbGwuPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgVGhlIHBob25lIGFuc3dlcnMgdGhlIGF1ZGlvIGNhbGw8YnI+CiCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+ CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAg oCB8IDIwMCBPSzxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoFtBdWRpb10goCCgIKB8 IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwtLS0tLS0tLS0tLS0tLS0t LS0tLSZndDt8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IDIwMCBPSyBbQXVkaW9dIKAgoCCgfDxicj4KIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+ CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8LS0tLS0tLS0tLS0tLS0tLS0t LS0mZ3Q7fDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCBDQU5DRUwg oCCgIKAgoCCgIKAgoHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8 IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgoCCg IKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCZsdDst LS1kaWFsb2cxLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPgogoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4K IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAg oCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgfCZsdDs9PT09PT1hdWRpbz09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PSZndDt8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8 IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgVGhlIHBob25lIHRoZW4gaW5zdHJ1Y3RzIHRoZSBQQyB0byBp bml0aWF0ZTxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoGEgdmlkZW8gY2FsbCB0byBq b2luIHRoZTxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBleGlzdGluZyBjYWxsPGJy Pgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAg oCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAg oCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oHwgSU5WT0tFIEFjdGlvbjo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB1cm46aW52 b2tlOmNhbGw6am9pbjttZWRpYT12aWRlbztkaWFsb2c9ZGlhbG9nMTxicj4KIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLXw8YnI+CiCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCAyMDAgT0sgoCCgIKAg oCCgIKAgoHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCg IKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg fC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoFRoZSBQQyB0aGVuIGFkZHMgVmlkZW8gdG8gdGhlIGV4 aXN0aW5nIGF1ZGlvPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgY2FsbC48YnI+CiCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8 PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCg IKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgSU5WSVRF IHdpdGggSm9pbiBbVmlkZW9dPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgfC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+CiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCAxMDAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAgoCCgIKAg fDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCZsdDstLS0tLS0tLS0t LS0tLS0tLS0tLXw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAg oCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgcmUtSU5WSVRFPGJyPgogoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgW0EvVl0goCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgfC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJy PgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCg IKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgcmUtSU5WSVRF IFtBL1ZdIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAg oCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgMjAwIE9LIFtBL1ZdIKAgoCCgIKB8PGJyPgogoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCgIKAgoCCgIKAgfCAyMDAg T0sgW0EvVl08YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwmbHQ7LS0t LS0tLS0tLS0tLS0tLS0tLS18PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCZsdDstLS0tLS0tLS0tLS0tLS0t LS0tLXwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgIKB8IDIwMCBPSyBbVmlkZW9dIKAgoCCgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfDxicj4K IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgIKAgoCCgIKAgoCCgIKAg oCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoCCgIKAgoCCg IKAgoCCgIKAgfDxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCg IKAgoCCgIKAgoCCgIKAgoCB8PGJyPgo8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oHwmbHQ7LS0tLS0tZGlhbG9nMi0tLS0tLSZndDt8Jmx0Oy0tLWRpYWxvZzEtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoHwgoCCgIKAgoCCgIKAgoCCgIKAgoCB8PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8YnI+CiCgIKAgoCCgIKAgoCCg IKAgoCCgIKAgoCCgIKAgoCCgIKAgoHw8YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8 Jmx0Oz09PT09PWF1ZGlvPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Jmd0O3w8YnI+Cjxi cj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCZsdDs9PT09PT09PT09PT09PT09PT09 PT09PT09PT09dmlkZW89PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0mZ3Q7fDxicj4KIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAgoCCgIKAgoCCgIKAgoCCgIHw8 YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoCCgIKAgoCCgIKAg oCCgIKAgfDxicj4KPGJyPgo8YnI+Cjxicj4KIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgogoCCgIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgc3BsaWNlcyBtYWlsaW5nIGxpc3Q8YnI+PC9kaXY+PC9kaXY+ CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKA8YSBocmVmPSJtYWlsdG86c3BsaWNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwbGljZXNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnNwbGljZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcGxpY2VzQGll dGYub3JnPC9hPiZndDs8ZGl2IGNsYXNzPSJpbSI+PGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCg IKAgoCCgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGxp Y2VzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcGxpY2VzPC9hPjxicj4KPGJyPgogoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KIKAgoCCgIKAgoCCgIKAg oCCgIKAgoCCgc3BsaWNlcyBtYWlsaW5nIGxpc3Q8YnI+PC9kaXY+CiCgIKAgoCCgIKAgoCCgIKAg oCCgIKAgoDxhIGhyZWY9Im1haWx0bzpzcGxpY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ c3BsaWNlc0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c3BsaWNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwbGljZXNAaWV0Zi5vcmc8L2E+Jmd0OzxkaXYgY2xh c3M9ImltIj48YnI+CiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3BsaWNlcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3BsaWNlczwvYT48YnI+Cjxicj4KPGJy Pgo8YnI+Cjxicj4KIKAgoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPgogoCCgc3BsaWNlcyBtYWlsaW5nIGxpc3Q8YnI+PC9kaXY+CiCgIKA8YSBocmVm PSJtYWlsdG86c3BsaWNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwbGljZXNAaWV0Zi5v cmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwbGljZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zcGxpY2VzQGlldGYub3JnPC9hPiZndDs8ZGl2IGNsYXNzPSJpbSI+PGJyPgog oCCgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGxpY2Vz IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z cGxpY2VzPC9hPjxicj4KPGJyPgo8YnI+CjwvZGl2PjwvYmxvY2txdW90ZT4KPC9ibG9ja3F1b3Rl PjwvZGl2Pjxicj48L2Rpdj4K --00151747b3625dbdfd04a4065198-- From rifatyu@avaya.com Wed May 25 05:33:06 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB8DE0657 for ; Wed, 25 May 2011 05:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BXH+Xd0zrnB for ; Wed, 25 May 2011 05:33:04 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2A572E0655 for ; Wed, 25 May 2011 05:33:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIBAHr23E2HCzI1/2dsb2JhbACCZpR/g0GLBHiqMwKbQoYcBJUChASGSw X-IronPort-AV: E=Sophos;i="4.65,266,1304308800"; d="scan'208,217";a="281690483" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 May 2011 08:33:03 -0400 X-IronPort-AV: E=Sophos;i="4.65,266,1304308800"; d="scan'208,217";a="656016614" Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 May 2011 08:33:03 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 25 May 2011 08:33:02 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Peter Musgrave , Paul Kyzivat Date: Wed, 25 May 2011 08:32:31 -0400 Thread-Topic: [splices] Answering an A/V Call Using Two Separate Devices proposal Thread-Index: AcwaD/fTLCXe2IroSlmJAUEw6xMrKQAx2fkQ Message-ID: <6369CB70BFD88942B9705AC1E639A33822CCCB8E50@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> <4DD97B5D.7040404@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE75@DC-US1MBEX4.global.avaya.com> <4DD9CE66.8010204@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FB9A1@DC-US1MBEX4.global.avaya.com> <4DDA5C19.5040405@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822CCCB8E50DCUS1MBEX4glo_" MIME-Version: 1.0 Cc: "splices@ietf.org" Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:33:06 -0000 --_000_6369CB70BFD88942B9705AC1E639A33822CCCB8E50DCUS1MBEX4glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, >2) INVOKE is more mechanism than a new header. [A method is a bigger deal = than a header] Did you really think that I do not understand that defining a method is a b= igger deal than defining a header? :) My comment was about the specifics of the call flow and has nothing to do w= ith defining a method or a header. Regards, Rifaat From: Peter Musgrave [mailto:musgravepj@gmail.com] Sent: Tuesday, May 24, 2011 8:42 AM To: Paul Kyzivat Cc: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices pro= posal I agree with Paul that: 1) This works ok. 2) INVOKE is more mechanism than a new header. [A method is a bigger deal t= han a header] I'd also observe in a "real politik" sense that the potential energy barrie= r to geting a new SIP method in place will likely be significant. I would e= xpect it would have to be a dispatch-ed WG all on it's own. People will dec= ide to either use it to solve world hunger - or decide that it is the root = of all evil. Under "out there" ideas - would it be possible to put the Action header in = a PUBLISH? Would this allow the same signalling semantics as INVOKE without= the need for a new method? Peter Musgrave On Mon, May 23, 2011 at 9:07 AM, Paul Kyzivat > wrote: On 5/23/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: I do not see how this proposal is "less mechanism" than the original propos= al, but I tend to agree with you that this might be "a matter of taste". The devil is in the details here, and we don't have enough details. So its all in the set of assumptions one is making. In the end we probably aren't going to standardize services - just mechanis= ms for creating services. But perhaps we will have an "examples" doc that s= hows how the mechanisms might be used to create a range of interesting serv= ices such as these. If so, I would think we would need to work through each= one in detail, carefully defining all the assumptions about the environmen= t. And that is really what it takes to decide on each particular "action", bec= ause those seem to be rather specialized. At the moment I don't have a visi= on of a clear and obvious set of actions that enable all the interesting se= rvices. Its more a matter of crafting an action to support one or a few ser= vices. I wish it was more clear cut than that. Maybe it will become so with= more study. Thanks, Paul Regards, Rifaat ________________________________________ From: Paul Kyzivat [pkyzivat@cisco.com] Sent: Sunday, May 22, 2011 11:03 PM To: Shekh-Yusef, Rifaat (Rifaat) Cc: splices@ietf.org Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices pro= posal On 5/22/2011 8:49 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: You are then proposing the following: Alice used her *phone* to answer the incoming call | | | | | | 200 OK [Audio] | | | |-------------------->| | | | | 200 OK [Audio] | | | |-------------------->| | CANCEL | | | |<------------------------------------------| | | | | | | |<---dialog1------------------------------->| | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | INVITE Alert-Info and [Video] | | |<--------------------| | | What happens here? Will the user be required to take an action on the PC to accept the INVITE? Or you are expecting the PC to provide an answer without user intervention? Could be handled various ways. The alert-info could suggest auto-answer. (The PC *honoring* such a request might be conditional on who it comes. But even if not honored for auto-answer it might still alert *differently*.) If it wasn't auto-answered, and returned 180, it could be followed up with an INVOKE to force the answer. Thanks, Paul | 200 OK [Video] | | | |<--------------------| | | | | re-INVITE [A/V] | | | |-------------------->| | | | | re-INVITE [A/V] | | | |-------------------->| | | | 200 OK [A/V] | | | 200 OK [A/V] |<--------------------| | |<--------------------| | | ACK | | | |<--------------------| | | | | | | |<------dialog2------>|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Sunday, May 22, 2011 5:09 PM To: Shekh-Yusef, Rifaat (Rifaat) Cc: splices@ietf.org Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: Because a new INVITE will probably cause the PC to present the user with a UI component and wait for the users input. Well, I suppose you would want the PC to indicate what is going on in the UI in *some* way. But probably not exactly the same as getting a new call. That could be handled via appropriate Alert-Info. To some extent this is a matter of taste. I am inclined to prefer an economy of mechanism, and I think the alert-info feels like less mechanism than the particular INVOKE mechanism used in this scenario. (The invoke mechanism used here requires the phone to assume that the PC is aware of the dialog, and able to associate it with the appropriate contact address for doing the invite.) Thanks, Paul Regards, Rifaat -----Original Message----- From: splices-bounces@ietf.org [mailto:spl= ices-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Saturday, May 21, 2011 11:15 PM To: splices@ietf.org Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal I guess all of that can work. But for the last part, if the phone knows enough to send the invoke to the pc, why can't it just send an INVITE to the pc? Thanks, Paul On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: Hi, We are still working on a new version of the INVOKE document that removes the implicit subscription. Meanwhile I would like to continue the discussion of the various possible uses cases. The following is a proposal for Answering an A/V Call Using Two Separate Devices. Regards, Rifaat Alice Alice Proxy Bob PC Desk Phone | | | | | | | | Both Alice's devices subscribe to the reg event package, which allows each device to discover the capabilities of the other device based on the feature tags provided by each device. The Desk Phone knows that the PC supports Video, while the PC knows that the Desk Phone only supports audio. | | | | | | SUBSCRIBE reg | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | SUBSCRIBE reg | | | |------------------------------------------>| | | 200 OK | | | |<------------------------------------------| | | | | | | | | | The two devices also subscribe to the dialog of each other. | | | | | | | | | SUBSCRIBE dialog | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | | SUBSCRIBE dialog | | | |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | | | | | The scenario starts with an A/V call from Bob to Alice | | | | | | | INVITE Alice [A/V] | | | |<--------------------| | | INVITE Alice [A/V] | | | |<--------------------| | | INVITE Alice [A/V] | | | |<------------------------------------------| | | | | | (*) Let's assume that Alice used her PC to answer the incoming call The PC instructs the phone to answer the audio call | | | | | INVOKE Action: urn:invoke:call:answer;media=3Daudio;transducer=3Dspeaker|headset |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | | | 200 OK [Audio] | | | |-------------------->| | | | | 200 OK [Audio] | | | |-------------------->| | CANCEL | | | |<------------------------------------------| | | | | | | |<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | | | | The PC then adds Video to the existing audio call. | | | | | INVITE with Join [Video] | | |-------------------->| | | | 100 | | | |<--------------------| | | | | re-INVITE [A/V] | | | |-------------------->| | | | | re-INVITE [A/V] | | | |-------------------->| | | | 200 OK [A/V] | | | 200 OK [A/V] |<--------------------| | |<--------------------| | | 200 OK [Video] | | | |<--------------------| | | | | | | |<------dialog2------>|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | | | | The scenario continues after the (*) above Let's assume that Alice used her phone to answer the incoming call. The phone answers the audio call | | | | | | 200 OK [Audio] | | | |-------------------->| | | | | 200 OK [Audio] | | | |-------------------->| | CANCEL | | | |<------------------------------------------| | | | | | | |<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | | | | The phone then instructs the PC to initiate a video call to join the existing call | | | | | INVOKE Action: urn:invoke:call:join;media=3Dvideo;dialog=3Ddialog1 |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | The PC then adds Video to the existing audio call. | | | | | INVITE with Join [Video] | | |-------------------->| | | | 100 | | | |<--------------------| | | | | re-INVITE [A/V] | | | |-------------------->| | | | | re-INVITE [A/V] | | | |-------------------->| | | | 200 OK [A/V] | | | 200 OK [A/V] |<--------------------| | |<--------------------| | | 200 OK [Video] | | | |<--------------------| | | | | | | |<------dialog2------>|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | _______________________________________________ splices mailing list splices@ietf.org https://www.ietf.org/mailman/listinfo/splices _______________________________________________ splices mailing list splices@ietf.org https://www.ietf.org/mailman/listinfo/splices _______________________________________________ splices mailing list splices@ietf.org https://www.ietf.org/mailman/listinfo/splices --_000_6369CB70BFD88942B9705AC1E639A33822CCCB8E50DCUS1MBEX4glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,=

 <= /p>

>2) INVOKE is more mechanism than = a new header. [A method is a bigger deal than a header]

Did you really think that I do not understand that d= efining a method is a bigger deal than defining a header? J<= o:p>

My comment was about the s= pecifics of the call flow and has nothing to do with defining a method or a= header.

 =

Regards,

Rifaat

 

 

From: Peter Musgrave [= mailto:musgravepj@gmail.com]
Sent: Tuesday, May 24, 2011 8:42 AM=
To: Paul Kyzivat
Cc: Shekh-Yusef, Rifaat (Rifaat); spl= ices@ietf.org
Subject: Re: [splices] Answering an A/V Call Using = Two Separate Devices proposal

 

I agree with Paul that:<= o:p>

1) This works ok. <= /p>

2) INVOKE is more mechanism than a new h= eader. [A method is a bigger deal than a header]

<= p class=3DMsoNormal> 

I'= d also observe in a "real politik" sense that the potential energ= y barrier to geting a new SIP method in place will likely be significant. I= would expect it would have to be a dispatch-ed WG all on it's own. People = will decide to either use it to solve world hunger - or decide that it is t= he root of all evil.

&nb= sp;

Under "out there" id= eas - would it be possible to put the Action header in a PUBLISH? Would thi= s allow the same signalling semantics as INVOKE without the need for a new = method?

 

=

Peter Musgra= ve

On Mon, May 23, 2011 at 9:07 AM,= Paul Kyzivat <pkyzivat@cisco.com<= /a>> wrote:

The devil is in the details here, and we do= n't have enough details.
So its all in the set of assumptions one is mak= ing.

In the end we probably aren't going to standardize services - j= ust mechanisms for creating services. But perhaps we will have an "exa= mples" doc that shows how the mechanisms might be used to create a ran= ge of interesting services such as these. If so, I would think we would nee= d to work through each one in detail, carefully defining all the assumption= s about the environment.

And that is really what it takes to decide = on each particular "action", because those seem to be rather spec= ialized. At the moment I don't have a vision of a clear and obvious set of = actions that enable all the interesting services. Its more a matter of craf= ting an action to support one or a few services. I wish it was more clear c= ut than that. Maybe it will become so with more study.

   =    Thanks,
     =  Paul

 

Regards,
 Rifaat


=
________________________________________
From: Paul Kyzivat [pkyzivat@cisco.com]Sent: Sunday, May 22, 2011 11:03 PM
To: Shekh-Yusef, Rifaat (Rifaat)Cc: splices@ietf.org=
Subject: Re: [splices] Answering an A/V Call Using Two Separate Dev= ices proposal

On 5/22/2011 8:49 PM, Shekh-Yusef, Rifaat (Rifaat) wro= te:


You are then proposing the follo= wing:


Alice used her *phone* to answer the incoming call
&nbs= p;    |                 &= nbsp;   |                 &nbs= p;   |                   =   |
     |            =         | 200 OK [Audio]      |   =                   |
  =    |                 &nbs= p;   |-------------------->|           &nb= sp;         |
     |     &n= bsp;               |      = ;               | 200 OK [Audio]   =    |
     |           =           |           &nb= sp;         |-------------------->|
   =  | CANCEL              |   &n= bsp;                 |    = ;                 |
   = ;  |<------------------------------------------|     &nbs= p;               |
    &nbs= p;|                     |=                     | &n= bsp;                   |
&n= bsp;    |                =     |<---dialog1------------------------------->|
 = ;    |                 &n= bsp;   |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
  &n= bsp;  |                  =   |                   &n= bsp; |                    = ; |
     | INVITE Alert-Info and [Video]     &n= bsp;       |              = ;       |
     |<--------------------| =                     | &nb= sp;                   |
What happens here?
Will the user be required to take an action on the P= C to accept the INVITE?
Or you are expecting the PC to provide an answer= without user intervention?


Could  be handled various ways.

The aler= t-info could suggest auto-answer. (The PC *honoring* such a
request migh= t be conditional on who it comes. But even if not honored
for auto-answe= r it might still alert *differently*.) If it wasn't
auto-answered, and r= eturned 180, it could be followed up with an INVOKE
to force the answer.=

        Thanks,
        = Paul

&nbs= p;    | 200 OK [Video]      |      =               |       &n= bsp;             |
     |&l= t;--------------------|               &n= bsp;     |                = ;     |
     |         &nbs= p;           | re-INVITE [A/V]     | &nb= sp;                   |
&nb= sp;    |                 =     |-------------------->|          =           |
     |    = ;                 |     &= nbsp;               | re-INVITE [A/V] &n= bsp;   |
     |           &= nbsp;         |           &nbs= p;         |-------------------->|
    =  |                   &nbs= p; |                     = | 200 OK [A/V]        |
     |  =                   | 200 OK [A= /V]        |<--------------------|
    =  |                   &nbs= p; |<--------------------|             &nb= sp;       |
     | ACK      = ;           |           &= nbsp;         |           &nbs= p;         |
     |<--------------= ------|                   &nbs= p; |                     = |
     |              =       |               &n= bsp;     |                = ;     |
     |<------dialog2------>|<-= --dialog1------------------------------->|
     | &nbs= p;                   |   =                   |   &nb= sp;                 |
  &nb= sp;  |                   =   |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
    &= nbsp;|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
     | &n= bsp;                   |  = ;                   |   &= nbsp;                 |

-----Original Message-----
From: Paul Ky= zivat [mailto:pkyzi= vat@cisco.com]
Sent: Sunday, May 22, 2011 5:09 PM
To: Shekh-Yusef= , Rifaat (Rifaat)
Cc: splices@ietf.org
Subject: Re: [splices] Answering an A/V Call Us= ing Two Separate Devices
proposal



On 5/22/2011 2:40 PM, S= hekh-Yusef, Rifaat (Rifaat) wrote:

Becau= se a new INVITE will probably cause the PC to present the user with a<= /o:p>

UI component a= nd wait for the users input.

Well, I suppose you would want the PC t= o indicate what is going on in
the UI in *some* way. But probably not ex= actly the same as getting a new
call.

That could be handled via a= ppropriate Alert-Info. To some extent this is
a matter of taste. I am in= clined to prefer an economy of mechanism, and
I think the alert-info fee= ls like less mechanism than the particular
INVOKE mechanism used in this= scenario. (The invoke mechanism used here
requires the phone to assume = that the PC is aware of the dialog, and
able to associate it with the ap= propriate contact address for doing the
invite.)

    &n= bsp;  Thanks,
       Paul

Regards,
   Rifaa= t

-----Original Message-----
= From: splices= -bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf

Of

Paul Kyzivat
Sent: Saturday, May 21, 201= 1 11:15 PM
To: spl= ices@ietf.org
Subject: Re: [splices] Answering an A/V Call Using Two= Separate Devices
proposal

I guess all of that can work. But for = the last part, if the phone knows
enough to send the invoke to the pc, w= hy can't it just send an INVITE to
the pc?

    Thanks,<= br>    Paul

On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rif= aat) wrote:

Hi,

We are still work= ing on a new version of the INVOKE document that removes

the implicit subscription.


Meanwhile I would like to continue the discussion of the various po= ssible

uses cases.

The following is a proposal for Answering an A/V Call Using T= wo Separate

Devices.


Regards,
    Rifaat



  =     Alice                = Alice                Proxy   =                Bob
   =    PC                 De= sk Phone
       |          =           |           &n= bsp;         |            = ;         |
       |   &nbs= p;                 |     =                 |     &nb= sp;               |
Both Alice's devi= ces subscribe to the reg event package, which allows each

device to

discover the= capabilities of the other device based on the feature tags

<= p class=3DMsoNormal>provided by each device.

The Desk Phone knows that the PC supports Video, while the PC knows th= at

the

Desk Pho= ne only supports audio.

    &n= bsp;  |                  =   |                   &n= bsp; |                    = ; |
       |           &nbs= p;         | SUBSCRIBE reg       |  = ;                   |
 = ;      |               &n= bsp;     |-------------------->|         &= nbsp;           |
       | =                     | 200= OK              |       =               |
      =  |                   &nbs= p; |<--------------------|             &nb= sp;       |
       |     &n= bsp;               |      = ;               |       &= nbsp;             |
      &= nbsp;| SUBSCRIBE reg       |         &nb= sp;           |          =           |
       |------= ------------------------------------>|          = ;           |
       | 200 = OK              |       &= nbsp;             |       &nbs= p;             |
      &nbs= p;|<------------------------------------------|       &nb= sp;             |
      &nb= sp;|                     = |                     | &= nbsp;                   |
&= nbsp;      |              = ;       |               &= nbsp;     |               &nbs= p;     |
The two devices also subscribe to the dialog of each = other.
       |           &= nbsp;         |           &nbs= p;         |             =         |
       |    =                 |     &n= bsp;               |      = ;               |
     = ;  | SUBSCRIBE dialog    |          = ;           |           &= nbsp;         |
       |--------= ------------>|                 &= nbsp;   |                 &nbs= p;   |
       | 200 OK       &nb= sp;      |               =       |               &nb= sp;     |
       |<--------------------= |                     | &= nbsp;                   |
&= nbsp;      |              = ;       |               &= nbsp;     |               &nbs= p;     |
       | SUBSCRIBE dialog   =  |                   &nbs= p; |                     = |
       |<--------------------|     &n= bsp;               |      = ;               |
     = ;  | 200 OK              |   &= nbsp;                 |   &nbs= p;                 |
  &nbs= p;    |-------------------->|         &nbs= p;           |           =           |
       |  =                   |   &n= bsp;                 |    = ;                 |
   = ;    |                 &n= bsp;   |                  = ;   |                   &= nbsp; |
The scenario starts with an A/V call from Bob to Alice
 =      |               &nb= sp;     |                =     |                 &n= bsp;   |
       |         &= nbsp;           |         &nbs= p;           | INVITE Alice [A/V]  |
 = ;      |               &n= bsp;     |                = ;     |<--------------------|
       | =                     | INV= ITE Alice [A/V]  |               &n= bsp;     |
       |       &= nbsp;             |<--------------------| =                     |
=        | INVITE Alice [A/V]  |      = ;               |       &= nbsp;             |
      &= nbsp;|<------------------------------------------|       =               |
      =  |                   &nbs= p; |                     = |                     |

(*)


Let's assume that Alice used her PC to answer the = incoming call
The PC instructs the phone to answer the audio call
&nb= sp;      |               =       |               &nb= sp;     |                =     |
       | INVOKE Action:<= /p>

urn:invoke:call:answer;media=3Daudio;transducer=3Ds= peaker|headset

      &nbs= p;|-------------------->|             &nbs= p;       |               =       |
       | 200 OK    =          |           &nb= sp;         |            =         |
       |<---------= -----------|                  =   |                   &n= bsp; |
       |           &= nbsp;         |           &nbs= p;         |             =         |
       |    =                 | 200 OK [Audio] &= nbsp;    |                = ;     |
       |       &nbs= p;             |-------------------->| &nb= sp;                   |
&nb= sp;      |               =       |               &nb= sp;     | 200 OK [Audio]      |
    &= nbsp;  |                  = ;   |                   &= nbsp; |-------------------->|
       | CANCEL &nb= sp;            |         =             |         &nb= sp;           |
       |<= ;------------------------------------------|         &n= bsp;           |
       | &= nbsp;                   | &nbs= p;                   |   =                   |
  =      |               &nbs= p;     |<---dialog1------------------------------->|
&nb= sp;      |               =       |               &nb= sp;     |                =     |
       |        = ;             |<=3D=3D=3D=3D=3D=3Daudio=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>|
       |       &nbs= p;             |         =             |         &nb= sp;           |
       | &n= bsp;                   |  = ;                   |   &= nbsp;                 |
The PC t= hen adds Video to the existing audio call.
       | =                     | &nb= sp;                   |  =                   |
 =      | INVITE with Join [Video]        =          |           &nb= sp;         |
       |----------= ---------->|                 &nb= sp;   |                  =   |
       | 100         &= nbsp;       |             &nbs= p;       |               =       |
       |<-----------------= ---|                     = |                     |       |             &n= bsp;       | re-INVITE [A/V]     |     &= nbsp;               |
    &= nbsp;  |                  = ;   |-------------------->|           &nbs= p;         |
       |   &nb= sp;                 |    =                 | re-INVITE [A/V] =     |
       |        =             |         &n= bsp;           |-------------------->|
 = ;      |               &n= bsp;     |                = ;     | 200 OK [A/V]        |
   = ;    |                 &n= bsp;   | 200 OK [A/V]        |<----------------= ----|
       |           &n= bsp;         |<--------------------|     &= nbsp;               |
    &= nbsp;  | 200 OK [Video]      |       &nb= sp;             |        =             |
       = |<--------------------|              =       |               &n= bsp;     |
       |       &= nbsp;             |       &nbs= p;             |         =             |
       |= <------dialog2------>|<---dialog1-------------------------------&g= t;|
       |           &nbs= p;         |             =         |             &nb= sp;       |
       |     &n= bsp;               |<=3D=3D=3D=3D=3D= =3Daudio=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D>|
       |<=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= video=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D>|
       |     &n= bsp;               |      = ;               |       &= nbsp;             |
      &= nbsp;|                    = ; |                     |=                     |


The scenario continues after the (*) above
Let's assume tha= t Alice used her phone to answer the incoming call.
The phone answers th= e audio call
       |         &n= bsp;           |          = ;           |           &= nbsp;         |
       |   =                   | 200 OK [Au= dio]      |              =       |
       |      = ;               |-------------------->= ;|                     |<= br>       |             &= nbsp;       |             &nbs= p;       | 200 OK [Audio]      |
  &n= bsp;    |                =     |                 &n= bsp;   |-------------------->|
       | CANC= EL              |       &= nbsp;             |       &nbs= p;             |
      &nbs= p;|<------------------------------------------|       &nb= sp;             |
      &nb= sp;|                     = |                     | &= nbsp;                   |
&= nbsp;      |              = ;       |<---dialog1------------------------------->|<= br>       |             &= nbsp;       |             &nbs= p;       |               =       |
       |      =               |<=3D=3D=3D=3D=3D=3Dau= dio=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D>|
       |      = ;               |       &= nbsp;             |       &nbs= p;             |
      &nbs= p;|                     |=                     | &n= bsp;                   |
Th= e phone then instructs the PC to initiate a video call to join the

existing call

       |     =                 |     &nb= sp;               |      =               |
     =  | INVOKE Action: urn:invoke:call:join;media=3Dvideo;dialog=3Ddialog1=
       |<--------------------|     &nb= sp;               |      =               |
     =  | 200 OK              |   &n= bsp;                 |    = ;                 |
   = ;    |-------------------->|          = ;           |           &= nbsp;         |
       |   =                   |   &nb= sp;                 |    =                 |
The PC then a= dds Video to the existing audio call.
       |  = ;                   |   &= nbsp;                 |   &nbs= p;                 |
  &nbs= p;    | INVITE with Join [Video]         &nbs= p;        |             &= nbsp;       |
       |---------------= ----->|                   &= nbsp; |                   &nbs= p; |
       | 100          =       |               &n= bsp;     |                = ;     |
       |<--------------------| =                     | &nb= sp;                   |
&nb= sp;      |               =       | re-INVITE [A/V]     |      =               |
     =  |                   &nb= sp; |-------------------->|             &n= bsp;       |
       |     &= nbsp;               |     &nbs= p;               | re-INVITE [A/V]  = ;   |
       |         &nbs= p;           |           =           |-------------------->|
  &nb= sp;    |                 =     |                 &nb= sp;   | 200 OK [A/V]        |
    &nb= sp;  |                   =   | 200 OK [A/V]        |<--------------------|=
       |             =         |<--------------------|      =               |
     =  | 200 OK [Video]      |         &= nbsp;           |         &nbs= p;           |
       |<= --------------------|               &nbs= p;     |                 =     |
       |        =             |         &n= bsp;           |          = ;           |
       |<-= -----dialog2------>|<---dialog1------------------------------->|       |             &n= bsp;       |              = ;       |               &= nbsp;     |
       |       =               |<=3D=3D=3D=3D=3D=3Daud= io=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D>|
       |<=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dvideo= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>|
       |       &= nbsp;             |       &nbs= p;             |         =             |



________________= _______________________________
splices mailing list
splices@ietf.org
https://www.= ietf.org/mailman/listinfo/splices

__= _____________________________________________
splices mailing list
splices@ietf.orghttps://www.ietf.org/mailman/listinfo/splices

 

&nb= sp;

 

_______________________________________________
splices ma= iling list
splices= @ietf.org
https://www.ietf.org/mailman/listinfo/splices

 

= --_000_6369CB70BFD88942B9705AC1E639A33822CCCB8E50DCUS1MBEX4glo_-- From spromano@unina.it Wed May 25 08:22:14 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02005130052 for ; Wed, 25 May 2011 08:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.099 X-Spam-Level: X-Spam-Status: No, score=-100.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwOAF7TUotpz for ; Wed, 25 May 2011 08:22:12 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id D7696130035 for ; Wed, 25 May 2011 08:22:10 -0700 (PDT) Received: from [10.211.87.5] ([143.225.6.33]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id p4PFLxsM009152 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 May 2011 17:22:00 +0200 Message-ID: <4DDD1E91.8050002@unina.it> Date: Wed, 25 May 2011 17:21:53 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <6369CB70BFD88942B9705AC1E639A33822CC01E548@DC-US1MBEX4.global.avaya.com> <4DD87FBF.5010504@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE3E@DC-US1MBEX4.global.avaya.com> <4DD97B5D.7040404@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FCE75@DC-US1MBEX4.global.avaya.com> <4DD9CE66.8010204@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CC7FB9A1@DC-US1MBEX4.global.avaya.com> <4DDA5C19.5040405@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CCCB8E50@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CCCB8E50@DC-US1MBEX4.global.avaya.com> Content-Type: multipart/alternative; boundary="------------020303070300010504000909" Cc: "splices@ietf.org" Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:22:14 -0000 This is a multi-part message in MIME format. --------------020303070300010504000909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I *personally* agree with Rifaat. Let's first discuss the overall approach of the call flow and then decide on the best venue where to carry out such work. This said, and based on the discussion we are having on the list, I bend towards considering INVOKE as a straightforward "mechanism" which I would be glad to see supported. Simon Il 25/05/2011 14:32, Shekh-Yusef, Rifaat (Rifaat) ha scritto: > > Hi Peter, > > >2) INVOKE is more mechanism than a new header. [A method is a bigger > deal than a header] > > Did you really think that I do not understand that defining a method > is a bigger deal than defining a header? J > > My comment was about the specifics of the call flow and has nothing to > do with defining a method or a header. > > Regards, > > Rifaat > > *From:*Peter Musgrave [mailto:musgravepj@gmail.com] > *Sent:* Tuesday, May 24, 2011 8:42 AM > *To:* Paul Kyzivat > *Cc:* Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > *Subject:* Re: [splices] Answering an A/V Call Using Two Separate > Devices proposal > > I agree with Paul that: > > 1) This works ok. > > 2) INVOKE is more mechanism than a new header. [A method is a bigger > deal than a header] > > I'd also observe in a "real politik" sense that the potential energy > barrier to geting a new SIP method in place will likely be > significant. I would expect it would have to be a dispatch-ed WG all > on it's own. People will decide to either use it to solve world hunger > - or decide that it is the root of all evil. > > Under "out there" ideas - would it be possible to put the Action > header in a PUBLISH? Would this allow the same signalling semantics as > INVOKE without the need for a new method? > > Peter Musgrave > > On Mon, May 23, 2011 at 9:07 AM, Paul Kyzivat > wrote: > > > > On 5/23/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > I do not see how this proposal is "less mechanism" than the original > proposal, but I tend to agree with you that this might be "a matter of > taste". > > The devil is in the details here, and we don't have enough details. > So its all in the set of assumptions one is making. > > In the end we probably aren't going to standardize services - just > mechanisms for creating services. But perhaps we will have an > "examples" doc that shows how the mechanisms might be used to create a > range of interesting services such as these. If so, I would think we > would need to work through each one in detail, carefully defining all > the assumptions about the environment. > > And that is really what it takes to decide on each particular > "action", because those seem to be rather specialized. At the moment I > don't have a vision of a clear and obvious set of actions that enable > all the interesting services. Its more a matter of crafting an action > to support one or a few services. I wish it was more clear cut than > that. Maybe it will become so with more study. > > Thanks, > Paul > > Regards, > Rifaat > > > > ________________________________________ > From: Paul Kyzivat [pkyzivat@cisco.com ] > Sent: Sunday, May 22, 2011 11:03 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org > Subject: Re: [splices] Answering an A/V Call Using Two Separate > Devices proposal > > On 5/22/2011 8:49 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > You are then proposing the following: > > > Alice used her *phone* to answer the incoming call > | | | > | > | | 200 OK [Audio] | > | > | |-------------------->| > | > | | | 200 OK [Audio] > | > | | > |-------------------->| > | CANCEL | | > | > |<------------------------------------------| > | > | | | > | > | > |<---dialog1------------------------------->| > | > |<======audio==============================>| > | | | > | > | INVITE Alert-Info and [Video] | > | > |<--------------------| | > | > > What happens here? > Will the user be required to take an action on the PC to accept > the INVITE? > Or you are expecting the PC to provide an answer without user > intervention? > > > Could be handled various ways. > > The alert-info could suggest auto-answer. (The PC *honoring* such a > request might be conditional on who it comes. But even if not honored > for auto-answer it might still alert *differently*.) If it wasn't > auto-answered, and returned 180, it could be followed up with an > INVOKE > to force the answer. > > Thanks, > Paul > > | 200 OK [Video] | | > | > |<--------------------| | > | > | | re-INVITE [A/V] | > | > | |-------------------->| > | > | | | re-INVITE [A/V] > | > | | > |-------------------->| > | | | 200 OK [A/V] > | > | | 200 OK [A/V] > |<--------------------| > | |<--------------------| > | > | ACK | | > | > |<--------------------| | > | > | | | > | > > |<------dialog2------>|<---dialog1------------------------------->| > | | | > | > | > |<======audio==============================>| > > |<============================video==============================>| > | | | > | > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > ] > Sent: Sunday, May 22, 2011 5:09 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: splices@ietf.org > Subject: Re: [splices] Answering an A/V Call Using Two Separate > Devices > proposal > > > > On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Because a new INVITE will probably cause the PC to present the > user with a > > UI component and wait for the users input. > > Well, I suppose you would want the PC to indicate what is going on in > the UI in *some* way. But probably not exactly the same as getting > a new > call. > > That could be handled via appropriate Alert-Info. To some extent > this is > a matter of taste. I am inclined to prefer an economy of > mechanism, and > I think the alert-info feels like less mechanism than the particular > INVOKE mechanism used in this scenario. (The invoke mechanism used > here > requires the phone to assume that the PC is aware of the dialog, and > able to associate it with the appropriate contact address for > doing the > invite.) > > Thanks, > Paul > > Regards, > Rifaat > > -----Original Message----- > From: splices-bounces@ietf.org > [mailto:splices-bounces@ietf.org > ] On Behalf > > Of > > Paul Kyzivat > Sent: Saturday, May 21, 2011 11:15 PM > To: splices@ietf.org > Subject: Re: [splices] Answering an A/V Call Using Two > Separate Devices > proposal > > I guess all of that can work. But for the last part, if the > phone knows > enough to send the invoke to the pc, why can't it just send an > INVITE to > the pc? > > Thanks, > Paul > > On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi, > > We are still working on a new version of the INVOKE document > that removes > > the implicit subscription. > > > Meanwhile I would like to continue the discussion of the > various possible > > uses cases. > > The following is a proposal for Answering an A/V Call Using > Two Separate > > Devices. > > > Regards, > Rifaat > > > > Alice Alice Proxy > Bob > PC Desk Phone > | | | > | > | | | > | > Both Alice's devices subscribe to the reg event package, which > allows each > > device to > > discover the capabilities of the other device based on the > feature tags > > provided by each device. > > The Desk Phone knows that the PC supports Video, while the PC > knows that > > the > > Desk Phone only supports audio. > > | | | > | > | | SUBSCRIBE reg | > | > | |-------------------->| > | > | | 200 OK | > | > | |<--------------------| > | > | | | > | > | SUBSCRIBE reg | | > | > |------------------------------------------>| > | > | 200 OK | | > | > |<------------------------------------------| > | > | | | > | > | | | > | > The two devices also subscribe to the dialog of each other. > | | | > | > | | | > | > | SUBSCRIBE dialog | | > | > |-------------------->| | > | > | 200 OK | | > | > |<--------------------| | > | > | | | > | > | SUBSCRIBE dialog | | > | > |<--------------------| | > | > | 200 OK | | > | > |-------------------->| | > | > | | | > | > | | | > | > The scenario starts with an A/V call from Bob to Alice > | | | > | > | | | INVITE > Alice [A/V] | > | | > |<--------------------| > | | INVITE Alice [A/V] | > | > | |<--------------------| > | > | INVITE Alice [A/V] | | > | > |<------------------------------------------| > | > | | | > | > > > (*) > > > Let's assume that Alice used her PC to answer the incoming call > The PC instructs the phone to answer the audio call > | | | > | > | INVOKE Action: > > urn:invoke:call:answer;media=audio;transducer=speaker|headset > > |-------------------->| | > | > | 200 OK | | > | > |<--------------------| | > | > | | | > | > | | 200 OK [Audio] | > | > | |-------------------->| > | > | | | 200 OK > [Audio] | > | | > |-------------------->| > | CANCEL | | > | > |<------------------------------------------| > | > | | | > | > | > |<---dialog1------------------------------->| > | | | > | > | > |<======audio==============================>| > | | | > | > | | | > | > The PC then adds Video to the existing audio call. > | | | > | > | INVITE with Join [Video] | > | > |-------------------->| | > | > | 100 | | > | > |<--------------------| | > | > | | re-INVITE [A/V] | > | > | |-------------------->| > | > | | | re-INVITE > [A/V] | > | | > |-------------------->| > | | | 200 OK > [A/V] | > | | 200 OK [A/V] > |<--------------------| > | |<--------------------| > | > | 200 OK [Video] | | > | > |<--------------------| | > | > | | | > | > > |<------dialog2------>|<---dialog1------------------------------->| > | | | > | > | > |<======audio==============================>| > > |<============================video==============================>| > | | | > | > | | | > | > > > > The scenario continues after the (*) above > Let's assume that Alice used her phone to answer the incoming > call. > The phone answers the audio call > | | | > | > | | 200 OK [Audio] | > | > | |-------------------->| > | > | | | 200 OK > [Audio] | > | | > |-------------------->| > | CANCEL | | > | > |<------------------------------------------| > | > | | | > | > | > |<---dialog1------------------------------->| > | | | > | > | > |<======audio==============================>| > | | | > | > | | | > | > The phone then instructs the PC to initiate a video call to > join the > > existing call > > | | | > | > | INVOKE Action: > urn:invoke:call:join;media=video;dialog=dialog1 > |<--------------------| | > | > | 200 OK | | > | > |-------------------->| | > | > | | | > | > The PC then adds Video to the existing audio call. > | | | > | > | INVITE with Join [Video] | > | > |-------------------->| | > | > | 100 | | > | > |<--------------------| | > | > | | re-INVITE [A/V] | > | > | |-------------------->| > | > | | | re-INVITE > [A/V] | > | | > |-------------------->| > | | | 200 OK > [A/V] | > | | 200 OK [A/V] > |<--------------------| > | |<--------------------| > | > | 200 OK [Video] | | > | > |<--------------------| | > | > | | | > | > > |<------dialog2------>|<---dialog1------------------------------->| > | | | > | > | > |<======audio==============================>| > > |<============================video==============================>| > | | | > | > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --------------020303070300010504000909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I *personally* agree with Rifaat. Let's first discuss the overall approach of the call flow and then decide on the best venue where to carry out such work.
This said, and based on the discussion we are having on the list, I bend towards considering INVOKE as a straightforward "mechanism" which I would be glad to see supported.

Simon


Il 25/05/2011 14:32, Shekh-Yusef, Rifaat (Rifaat) ha scritto:

Hi Peter,

 

>2) INVOKE is more mechanism than a new header. [A method is a bigger deal than a header]

Did you really think that I do not understand that defining a method is a bigger deal than defining a header? J

My comment was about the specifics of the call flow and has nothing to do with defining a method or a header.

 

Regards,

Rifaat

 

 

From: Peter Musgrave [mailto:musgravepj@gmail.com]
Sent: Tuesday, May 24, 2011 8:42 AM
To: Paul Kyzivat
Cc: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org
Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal

 

I agree with Paul that:

1) This works ok. 

2) INVOKE is more mechanism than a new header. [A method is a bigger deal than a header]

 

I'd also observe in a "real politik" sense that the potential energy barrier to geting a new SIP method in place will likely be significant. I would expect it would have to be a dispatch-ed WG all on it's own. People will decide to either use it to solve world hunger - or decide that it is the root of all evil.

 

Under "out there" ideas - would it be possible to put the Action header in a PUBLISH? Would this allow the same signalling semantics as INVOKE without the need for a new method?

 

Peter Musgrave

On Mon, May 23, 2011 at 9:07 AM, Paul Kyzivat <pkyzivat@cisco.com> wrote:



On 5/23/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:

I do not see how this proposal is "less mechanism" than the original proposal, but I tend to agree with you that this might be "a matter of taste".

 

The devil is in the details here, and we don't have enough details.
So its all in the set of assumptions one is making.

In the end we probably aren't going to standardize services - just mechanisms for creating services. But perhaps we will have an "examples" doc that shows how the mechanisms might be used to create a range of interesting services such as these. If so, I would think we would need to work through each one in detail, carefully defining all the assumptions about the environment.

And that is really what it takes to decide on each particular "action", because those seem to be rather specialized. At the moment I don't have a vision of a clear and obvious set of actions that enable all the interesting services. Its more a matter of crafting an action to support one or a few services. I wish it was more clear cut than that. Maybe it will become so with more study.

       Thanks,
       Paul

 

Regards,
 Rifaat



________________________________________
From: Paul Kyzivat [pkyzivat@cisco.com]
Sent: Sunday, May 22, 2011 11:03 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: splices@ietf.org
Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal

On 5/22/2011 8:49 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:


You are then proposing the following:


Alice used her *phone* to answer the incoming call
     |                     |                     |                     |
     |                     | 200 OK [Audio]      |                     |
     |                     |-------------------->|                     |
     |                     |                     | 200 OK [Audio]      |
     |                     |                     |-------------------->|
     | CANCEL              |                     |                     |
     |<------------------------------------------|                     |
     |                     |                     |                     |
     |                     |<---dialog1------------------------------->|
     |                     |<======audio==============================>|
     |                     |                     |                     |
     | INVITE Alert-Info and [Video]             |                     |
     |<--------------------|                     |                     |

What happens here?
Will the user be required to take an action on the PC to accept the INVITE?
Or you are expecting the PC to provide an answer without user intervention?


Could  be handled various ways.

The alert-info could suggest auto-answer. (The PC *honoring* such a
request might be conditional on who it comes. But even if not honored
for auto-answer it might still alert *differently*.) If it wasn't
auto-answered, and returned 180, it could be followed up with an INVOKE
to force the answer.

        Thanks,
        Paul

     | 200 OK [Video]      |                     |                     |
     |<--------------------|                     |                     |
     |                     | re-INVITE [A/V]     |                     |
     |                     |-------------------->|                     |
     |                     |                     | re-INVITE [A/V]     |
     |                     |                     |-------------------->|
     |                     |                     | 200 OK [A/V]        |
     |                     | 200 OK [A/V]        |<--------------------|
     |                     |<--------------------|                     |
     | ACK                 |                     |                     |
     |<--------------------|                     |                     |
     |                     |                     |                     |
     |<------dialog2------>|<---dialog1------------------------------->|
     |                     |                     |                     |
     |                     |<======audio==============================>|
     |<============================video==============================>|
     |                     |                     |                     |

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Sunday, May 22, 2011 5:09 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: splices@ietf.org
Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices
proposal



On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:

Because a new INVITE will probably cause the PC to present the user with a

UI component and wait for the users input.

Well, I suppose you would want the PC to indicate what is going on in
the UI in *some* way. But probably not exactly the same as getting a new
call.

That could be handled via appropriate Alert-Info. To some extent this is
a matter of taste. I am inclined to prefer an economy of mechanism, and
I think the alert-info feels like less mechanism than the particular
INVOKE mechanism used in this scenario. (The invoke mechanism used here
requires the phone to assume that the PC is aware of the dialog, and
able to associate it with the appropriate contact address for doing the
invite.)

       Thanks,
       Paul

Regards,
   Rifaat

-----Original Message-----
From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf

Of

Paul Kyzivat
Sent: Saturday, May 21, 2011 11:15 PM
To: splices@ietf.org
Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices
proposal

I guess all of that can work. But for the last part, if the phone knows
enough to send the invoke to the pc, why can't it just send an INVITE to
the pc?

    Thanks,
    Paul

On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:

Hi,

We are still working on a new version of the INVOKE document that removes

the implicit subscription.


Meanwhile I would like to continue the discussion of the various possible

uses cases.

The following is a proposal for Answering an A/V Call Using Two Separate

Devices.


Regards,
    Rifaat



      Alice                 Alice                Proxy                  Bob
       PC                 Desk Phone
       |                     |                     |                     |
       |                     |                     |                     |
Both Alice's devices subscribe to the reg event package, which allows each

device to

discover the capabilities of the other device based on the feature tags

provided by each device.

The Desk Phone knows that the PC supports Video, while the PC knows that

the

Desk Phone only supports audio.

       |                     |                     |                     |
       |                     | SUBSCRIBE reg       |                     |
       |                     |-------------------->|                     |
       |                     | 200 OK              |                     |
       |                     |<--------------------|                     |
       |                     |                     |                     |
       | SUBSCRIBE reg       |                     |                     |
       |------------------------------------------>|                     |
       | 200 OK              |                     |                     |
       |<------------------------------------------|                     |
       |                     |                     |                     |
       |                     |                     |                     |
The two devices also subscribe to the dialog of each other.
       |                     |                     |                     |
       |                     |                     |                     |
       | SUBSCRIBE dialog    |                     |                     |
       |-------------------->|                     |                     |
       | 200 OK              |                     |                     |
       |<--------------------|                     |                     |
       |                     |                     |                     |
       | SUBSCRIBE dialog    |                     |                     |
       |<--------------------|                     |                     |
       | 200 OK              |                     |                     |
       |-------------------->|                     |                     |
       |                     |                     |                     |
       |                     |                     |                     |
The scenario starts with an A/V call from Bob to Alice
       |                     |                     |                     |
       |                     |                     | INVITE Alice [A/V]  |
       |                     |                     |<--------------------|
       |                     | INVITE Alice [A/V]  |                     |
       |                     |<--------------------|                     |
       | INVITE Alice [A/V]  |                     |                     |
       |<------------------------------------------|                     |
       |                     |                     |                     |


(*)


Let's assume that Alice used her PC to answer the incoming call
The PC instructs the phone to answer the audio call
       |                     |                     |                     |
       | INVOKE Action:

urn:invoke:call:answer;media=audio;transducer=speaker|headset

       |-------------------->|                     |                     |
       | 200 OK              |                     |                     |
       |<--------------------|                     |                     |
       |                     |                     |                     |
       |                     | 200 OK [Audio]      |                     |
       |                     |-------------------->|                     |
       |                     |                     | 200 OK [Audio]      |
       |                     |                     |-------------------->|
       | CANCEL              |                     |                     |
       |<------------------------------------------|                     |
       |                     |                     |                     |
       |                     |<---dialog1------------------------------->|
       |                     |                     |                     |
       |                     |<======audio==============================>|
       |                     |                     |                     |
       |                     |                     |                     |
The PC then adds Video to the existing audio call.
       |                     |                     |                     |
       | INVITE with Join [Video]                  |                     |
       |-------------------->|                     |                     |
       | 100                 |                     |                     |
       |<--------------------|                     |                     |
       |                     | re-INVITE [A/V]     |                     |
       |                     |-------------------->|                     |
       |                     |                     | re-INVITE [A/V]     |
       |                     |                     |-------------------->|
       |                     |                     | 200 OK [A/V]        |
       |                     | 200 OK [A/V]        |<--------------------|
       |                     |<--------------------|                     |
       | 200 OK [Video]      |                     |                     |
       |<--------------------|                     |                     |
       |                     |                     |                     |
       |<------dialog2------>|<---dialog1------------------------------->|
       |                     |                     |                     |
       |                     |<======audio==============================>|
       |<============================video==============================>|
       |                     |                     |                     |
       |                     |                     |                     |



The scenario continues after the (*) above
Let's assume that Alice used her phone to answer the incoming call.
The phone answers the audio call
       |                     |                     |                     |
       |                     | 200 OK [Audio]      |                     |
       |                     |-------------------->|                     |
       |                     |                     | 200 OK [Audio]      |
       |                     |                     |-------------------->|
       | CANCEL              |                     |                     |
       |<------------------------------------------|                     |
       |                     |                     |                     |
       |                     |<---dialog1------------------------------->|
       |                     |                     |                     |
       |                     |<======audio==============================>|
       |                     |                     |                     |
       |                     |                     |                     |
The phone then instructs the PC to initiate a video call to join the

existing call

       |                     |                     |                     |
       | INVOKE Action: urn:invoke:call:join;media=video;dialog=dialog1
       |<--------------------|                     |                     |
       | 200 OK              |                     |                     |
       |-------------------->|                     |                     |
       |                     |                     |                     |
The PC then adds Video to the existing audio call.
       |                     |                     |                     |
       | INVITE with Join [Video]                  |                     |
       |-------------------->|                     |                     |
       | 100                 |                     |                     |
       |<--------------------|                     |                     |
       |                     | re-INVITE [A/V]     |                     |
       |                     |-------------------->|                     |
       |                     |                     | re-INVITE [A/V]     |
       |                     |                     |-------------------->|
       |                     |                     | 200 OK [A/V]        |
       |                     | 200 OK [A/V]        |<--------------------|
       |                     |<--------------------|                     |
       | 200 OK [Video]      |                     |                     |
       |<--------------------|                     |                     |
       |                     |                     |                     |
       |<------dialog2------>|<---dialog1------------------------------->|
       |                     |                     |                     |
       |                     |<======audio==============================>|
       |<============================video==============================>|
       |                     |                     |                     |



_______________________________________________
splices mailing list
splices@ietf.org
https://www.ietf.org/mailman/listinfo/splices

_______________________________________________
splices mailing list
splices@ietf.org
https://www.ietf.org/mailman/listinfo/splices

 

 

 

_______________________________________________
splices mailing list
splices@ietf.org
https://www.ietf.org/mailman/listinfo/splices

 


_______________________________________________
splices mailing list
splices@ietf.org
https://www.ietf.org/mailman/listinfo/splices


-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
--------------020303070300010504000909-- From rifatyu@avaya.com Thu May 26 17:20:15 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34562E07AD for ; Thu, 26 May 2011 17:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6JeKBdKoLlS for ; Thu, 26 May 2011 17:20:14 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 57B63E07AA for ; Thu, 26 May 2011 17:20:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAOTt3k2HCzI1/2dsb2JhbABUpjVwCKZQg1oCmyKGHASVD4pW X-IronPort-AV: E=Sophos;i="4.65,277,1304308800"; d="scan'208";a="190344362" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 26 May 2011 20:20:05 -0400 X-IronPort-AV: E=Sophos;i="4.65,277,1304308800"; d="scan'208";a="656719948" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 May 2011 20:20:05 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 26 May 2011 20:20:04 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "splices@ietf.org" Date: Thu, 26 May 2011 20:20:02 -0400 Thread-Topic: [splices] Initiate an A/V Call Using Two Separate Devices proposal Thread-Index: AcwcA9ICWlHJ0iFSQrC3DgLgYMzGCQ== Message-ID: <6369CB70BFD88942B9705AC1E639A33822CCE270ED@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [splices] Initiate an A/V Call Using Two Separate Devices proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 00:20:15 -0000 Hi, The following is a proposal for Initiating an A/V Call Using Two Separate D= evices Regards, Rifaat Alice Alice Proxy Bob PC Desk Phone =20 | | | | | | | | Both Alice's devices subscribe to the reg event package, which allows each = device to=20 discover the capabilities of the other device based on the feature tags pro= vided by each device. The Desk Phone knows that the PC supports Video, while the PC knows that th= e Desk Phone only supports audio. | | | | | | SUBSCRIBE reg | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | SUBSCRIBE reg | | | |------------------------------------------>| | | 200 OK | | | |<------------------------------------------| | | | | | | | | | The two devices also subscribe to the dialog of each other. | | | | | | | | | SUBSCRIBE dialog | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | | SUBSCRIBE dialog | | | |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | | | | | Alice wants to use her PC to initiate an A/V call to Bob. The PC instructs the phone to initiate a *video* call to Bob. The phone kno= ws it cannot handle video, but it know that the PC can. The phone then sends a slow start INVITE to th= e PC to get the video offer, and then sends an INVITE with A/V offer to Bob | | | | | | | | | INVOKE Action: urn:invoke:call:initiate;media=3Dvideo;target=3Dbob@wh= atever |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | | INVITE [] | | | |<--------------------| | | | 200 OK [Video] | | | |-------------------->| | | | | INVITE [A/V] | | | |-------------------->| | | | | INVITE [A/V] | | | |-------------------->| | | | 180 | | | 180 |<--------------------| | |<--------------------| | | | | 200 OK [A/V] | | | 200 OK [A/V] |<--------------------| | |<--------------------| | | ACK [Video] | | | |<--------------------| | | | | ACK | | | |-------------------->| | | | | ACK | | | |-------------------->| | | | | |<----dialog2-------->|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | Alice wants to use her phone to initiate an A/V call to Bob. The phone knows it cannot handle video, but it know that the PC can.=20 The phone sends an INVOKE request to instruct the PC to initiate a vidoe ca= ll.=20 Because the Action does not have a target parameter, this indicates to the = PC to send the INVITE to the phone. | | | | | INVOKE Action: urn:invoke:call:initiate;media=3Dvideo |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | | INVITE [Video] | | | |-------------------->| | | | 100 | | | |<--------------------| | | | | INVITE [A/V] | | | |-------------------->| | | | | INVITE [A/V] | | | |-------------------->| | | | 180 | | | 180 |<--------------------| | |<--------------------| | | 180 | | | |<--------------------| | 200 OK [A/V] | | | 200 OK [A/V] |<--------------------| | |<--------------------| | | ACK [Video] | | | |<--------------------| | | | | ACK | | | |-------------------->| | | | | ACK | | | |-------------------->| | | | | |<----dialog2-------->|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3Dvideo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | From rifatyu@avaya.com Thu May 26 17:37:05 2011 Return-Path: X-Original-To: splices@ietfa.amsl.com Delivered-To: splices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FCEE0739 for ; Thu, 26 May 2011 17:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.286 X-Spam-Level: X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELEej717Lt10 for ; Thu, 26 May 2011 17:37:05 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 86A8FE0697 for ; Thu, 26 May 2011 17:37:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAM/x3k3GmAcF/2dsb2JhbABUpjVwCKZhg1oCmyCGHASVD4pW X-IronPort-AV: E=Sophos;i="4.65,277,1304308800"; d="scan'208";a="248411907" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 May 2011 20:37:02 -0400 X-IronPort-AV: E=Sophos;i="4.65,277,1304308800"; d="scan'208";a="626657771" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 May 2011 20:37:02 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 26 May 2011 20:37:01 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "splices@ietf.org" Date: Thu, 26 May 2011 20:37:00 -0400 Thread-Topic: [splices] Using Two Separate Devices to Start a Conversation proposal Thread-Index: AcwcBjEKPHRsQSI9R9CEF7Om5nHptA== Message-ID: <6369CB70BFD88942B9705AC1E639A33822CCE270F5@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [splices] Using Two Separate Devices to Start a Conversation proposal X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 00:37:05 -0000 Hi, The following proposal is to cover the first use case in the disaggregated = media draft. Regards, Rifaat Alice Alice Proxy Bob PC Desk Phone =20 | | | | | | | | Both Alice's devices subscribe to the reg event package, which allows each = device to=20 discover the capabilities of the other device based on the feature tags pro= vided by each device. The Desk Phone knows that the PC supports Video, while the PC knows that th= e Desk Phone only supports audio. | | | | | | SUBSCRIBE reg | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | SUBSCRIBE reg | | | |------------------------------------------>| | | 200 OK | | | |<------------------------------------------| | | | | | | | | | The two devices also subscribe to the dialog of each other. | | | | | | | | | SUBSCRIBE dialog | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | | | | | SUBSCRIBE dialog | | | |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | | | | | Alice wants to initiate a call to Bob, but wants to use her Desk Phone to r= eceive the audio from Bob and use her PC to send audio to Bob. The PC instructs the Desk Phone to initiate a call to Bob in a receive only= mode. | | | | | INVOKE Action: urn:invoke:call:initiate;media=3Daudio;direction=3Drec= vonly;target=3Dbob@whatever |-------------------->| | | | OK | | | |<--------------------| | | | | INVITE [recvonly] | | | |-------------------->| | | | | INVITE [recvonly] | | | |-------------------->| | | | 180 | | | 180 |<--------------------| | |<--------------------| | | | | 200 OK | | | 200 OK |<--------------------| | |<--------------------| | | | | | As soon as Bob answers the call, a NOTIFY is sent to Alice's PC (dialog eve= nt package) | | | | | NOTIFY | | | |<--------------------| | | | OK | | | |-------------------->| | | | | | | PC sends a new INVITE with Join with a sendonly SDP offer | | | | | INVITE Join [sendonly] | | |-------------------->| | | | 100 Trying | | | |<--------------------| | | | | | | | | re-INVITE [sendrecv]| | | |-------------------->| | | | | re-INVITE [sendrecv]| | | |-------------------->| | | | 200 OK | | | 200 OK |<--------------------| | |<--------------------| | | 200 OK | | | |<--------------------| | | | | | | | | | | |<----dialog2-------->|<---dialog1------------------------------->| | | | | | |<=3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3Daudio=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | | | |