From ietf@meetecho.com Tue Apr 5 09:37:34 2011 Return-Path: X-Original-To: splices@core3.amsl.com Delivered-To: splices@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E7F3A6965 for ; Tue, 5 Apr 2011 09:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWqjWCD-8KgI for ; Tue, 5 Apr 2011 09:37:33 -0700 (PDT) Received: from smtpw1.aruba.it (smtpa1.aruba.it [62.149.128.210]) by core3.amsl.com (Postfix) with SMTP id 552093A6960 for ; Tue, 5 Apr 2011 09:37:33 -0700 (PDT) Received: (qmail 17304 invoked by uid 89); 5 Apr 2011 16:39:15 -0000 Received: from unknown (HELO aruba.it) (62.149.158.91) by smtpw1.ad.aruba.it with SMTP; 5 Apr 2011 16:39:15 -0000 Date: Tue, 5 Apr 2011 18:39:15 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1302021555.2A.321993.42.32005.52.42.007.397988745" From: "ietf@meetecho.com" To: splices@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 143.225.229.199 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N Subject: [splices] SPLICES recording available -- update X-BeenThere: splices@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 16:37:34 -0000 --_=__=_XaM3_.1302021555.2A.321993.42.32005.52.42.007.397988745 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,the full recording (synchronized video, audio, slides and jabber= room) of the SPLICES session at IETF80 is available at the following URL= :http://ietf.conf.meetecho.comYou can either choose to watch it online (t= wo different approaches are available) or download and replay it whenever= you want.In case of problems with the playout, just drop an e-mail to ie= tf-support@meetecho.com.For the chair(s): please feel free to put the lin= k to the recording in the minutes, if you think this might be useful.Chee= rs,the Meetecho Team --_=__=_XaM3_.1302021555.2A.321993.42.32005.52.42.007.397988745 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A
=0A
Dear all,

the full recording (synchronized v= ideo, audio, slides and jabber room) of the SPLICES session at IETF80 is = available at the following URL:
http://ietf.conf.meetecho.com

Y= ou can either choose to watch it online (two different approaches are ava= ilable) or download and replay it whenever you want.

In case of pr= oblems with the playout, just drop an e-mail to ietf-support@meetecho.com= .

For the chair(s): please feel free to put the link to the record= ing in the minutes, if you think this might be useful.

Cheers,
= the Meetecho Team
=0A
=0A --_=__=_XaM3_.1302021555.2A.321993.42.32005.52.42.007.397988745-- From gonzalo.camarillo@ericsson.com Tue Apr 12 05:47:34 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0F7A7E07C7 for ; Tue, 12 Apr 2011 05:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnpBojBCf8EV for ; Tue, 12 Apr 2011 05:47:33 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id 41741E07BD for ; Tue, 12 Apr 2011 05:47:30 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-fa-4da449e1c130 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 97.B3.09202.1E944AD4; Tue, 12 Apr 2011 14:47:29 +0200 (CEST) Received: from [131.160.126.135] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Tue, 12 Apr 2011 14:47:29 +0200 Message-ID: <4DA449E0.3030904@ericsson.com> Date: Tue, 12 Apr 2011 15:47:28 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: splices@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [splices] Way forward for the WG 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, 12 Apr 2011 12:47:34 -0000 Hi, in the SPLICES session in Prague, there was consensus in the room not to work on scenarios that require updated UAs on both ends. That is, the new SPLICES functionality would need to be available as long as one end supported the new mechanisms. Such consensus needs to be confirmed on the list. Simon Pietro will take care of that. It is obvious that this WG is running very low on energy. The little energy I have seen came from people interested in scenarios where both ends supported the new mechanisms to be developed. People against updating both ends have been mostly opposing work on those mechanisms, as opposed to driving new work. So, I am concerned that when this decision is confirmed, there will not be any energy left in this WG. At this point, I would like to ask whether people are willing to allocate some of their cycles to work on the problems described in the charter of this WG or if I should simply shut down the WG for lack of energy. In short, I want SPLICES to be either an active WG or not to be a WG at all. I do not want it to be in a kind of limbo where nothing happens and nobody cares. Thanks, Gonzalo From gao.yang2@zte.com.cn Tue Apr 12 06:13:54 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 61192E075D for ; Tue, 12 Apr 2011 06:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.146 X-Spam-Level: X-Spam-Status: No, score=-96.146 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwyauE-R5kK3 for ; Tue, 12 Apr 2011 06:13:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfc.amsl.com (Postfix) with ESMTP id CA4F2E0709 for ; Tue, 12 Apr 2011 06:13:51 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 125201917726163; Tue, 12 Apr 2011 21:13:03 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 69889.3170586594; Tue, 12 Apr 2011 21:02:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3CDDbF4022281; Tue, 12 Apr 2011 21:13:37 +0800 (GMT-8) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4DA449E0.3030904@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-KeepSent: 7A353BA5:02D23D19-48257870:00471375; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 12 Apr 2011 21:10:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-12 21:13:39, Serialize complete at 2011-04-12 21:13:39 Content-Type: multipart/alternative; boundary="=_alternative 0048BF0848257870_=" X-MAIL: mse02.zte.com.cn p3CDDbF4022281 Cc: splices@ietf.org Subject: Re: [splices] Way forward for the WG 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, 12 Apr 2011 13:13:54 -0000 This is a multipart message in MIME format. --=_alternative 0048BF0848257870_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR29uemFsbywNCg0KV2UoWlRFKSBjYXJlIGFib3V0IHRoaXMgdG9waWMuIEJlY2F1c2Ugb2Yg aGF2aW5nIG5vIHRpbWUgZm9yIHRoZSBtZWV0aW5nIA0KaW4gUHJhZ3VlLCBJIGRpZCBub3Qgam9p biB0aGUgZmFjZSB0byBmYWNlIG1lZXRpbmcuIEkgY2FuIGpvaW4gdGhlIA0KZGlzY3Vzc2lvbiBv biB0aGUgbWFpbGxpc3QsIGFuZCBhc2sgb3RoZXIgWlRFIGd1eXMgZm9yIHRoZSBmYWNlIHRvIGZh Y2UgDQptZWV0aW5nIGZvciB0aGUgbmV4dCB0aW1lLg0KDQpUaGVuLCBiYWNrIHRvIHRoZSBjaGFy dGVyIGl0c2VsZiwgSSB0aGluayB0aGlzIHRvcGljIGlzIHF1aXRlIG1lYW5pbmdmdWwuIA0KQW5k IHRoZXJlJ3Mgc29tZSBvcGVyYXRvcnMgY29udGFjdCB1cyB0byB0YWxrIGFib3V0IHRoZSByZXF1 aXJlbWVudCBvZiANCnNoYXJpbmcgc3RyZWFtcyBiZXR3ZWVuIFVFcyBpbiBJTVMuIA0KDQpMYXN0 IG9uZSwgSSB0aGluayB0aGlzIHRvcGlzIGlzIG92ZXJsYXBwZWQgd2l0aCBJVVQgdG9waWMgaW4g M0dQUC4gSG93IHRvIA0KaGFuZGxlIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhlIHR3byB0b3BpY3Mg aW4gSU1TIGRlcGxveW1lbnQgaXMgDQppbnRlcmVzdGluZy4NCg0KVGhhbmtzLA0KDQpHYW8NCg0K DQoNCg0KR29uemFsbyBDYW1hcmlsbG8gPEdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbT4g DQq3orz+yMs6ICBzcGxpY2VzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDQtMTIgMjA6NDcNCg0K ytW8/sjLDQpzcGxpY2VzQGlldGYub3JnDQqzrcvNDQoNCtb3zOINCltzcGxpY2VzXSBXYXkgZm9y d2FyZCBmb3IgdGhlIFdHDQoNCg0KDQoNCg0KDQpIaSwNCg0KaW4gdGhlIFNQTElDRVMgc2Vzc2lv biBpbiBQcmFndWUsIHRoZXJlIHdhcyBjb25zZW5zdXMgaW4gdGhlIHJvb20gbm90IHRvDQp3b3Jr IG9uIHNjZW5hcmlvcyB0aGF0IHJlcXVpcmUgdXBkYXRlZCBVQXMgb24gYm90aCBlbmRzLiBUaGF0 IGlzLCB0aGUNCm5ldyBTUExJQ0VTIGZ1bmN0aW9uYWxpdHkgd291bGQgbmVlZCB0byBiZSBhdmFp bGFibGUgYXMgbG9uZyBhcyBvbmUgZW5kDQpzdXBwb3J0ZWQgdGhlIG5ldyBtZWNoYW5pc21zLiBT dWNoIGNvbnNlbnN1cyBuZWVkcyB0byBiZSBjb25maXJtZWQgb24NCnRoZSBsaXN0LiBTaW1vbiBQ aWV0cm8gd2lsbCB0YWtlIGNhcmUgb2YgdGhhdC4NCg0KSXQgaXMgb2J2aW91cyB0aGF0IHRoaXMg V0cgaXMgcnVubmluZyB2ZXJ5IGxvdyBvbiBlbmVyZ3kuIFRoZSBsaXR0bGUNCmVuZXJneSBJIGhh dmUgc2VlbiBjYW1lIGZyb20gcGVvcGxlIGludGVyZXN0ZWQgaW4gc2NlbmFyaW9zIHdoZXJlIGJv dGgNCmVuZHMgc3VwcG9ydGVkIHRoZSBuZXcgbWVjaGFuaXNtcyB0byBiZSBkZXZlbG9wZWQuIFBl b3BsZSBhZ2FpbnN0DQp1cGRhdGluZyBib3RoIGVuZHMgaGF2ZSBiZWVuIG1vc3RseSBvcHBvc2lu ZyB3b3JrIG9uIHRob3NlIG1lY2hhbmlzbXMsDQphcyBvcHBvc2VkIHRvIGRyaXZpbmcgbmV3IHdv cmsuDQoNClNvLCBJIGFtIGNvbmNlcm5lZCB0aGF0IHdoZW4gdGhpcyBkZWNpc2lvbiBpcyBjb25m aXJtZWQsIHRoZXJlIHdpbGwgbm90DQpiZSBhbnkgZW5lcmd5IGxlZnQgaW4gdGhpcyBXRy4NCg0K QXQgdGhpcyBwb2ludCwgSSB3b3VsZCBsaWtlIHRvIGFzayB3aGV0aGVyIHBlb3BsZSBhcmUgd2ls bGluZyB0bw0KYWxsb2NhdGUgc29tZSBvZiB0aGVpciBjeWNsZXMgdG8gd29yayBvbiB0aGUgcHJv YmxlbXMgZGVzY3JpYmVkIGluIHRoZQ0KY2hhcnRlciBvZiB0aGlzIFdHIG9yIGlmIEkgc2hvdWxk IHNpbXBseSBzaHV0IGRvd24gdGhlIFdHIGZvciBsYWNrIG9mDQplbmVyZ3kuDQoNCkluIHNob3J0 LCBJIHdhbnQgU1BMSUNFUyB0byBiZSBlaXRoZXIgYW4gYWN0aXZlIFdHIG9yIG5vdCB0byBiZSBh IFdHIGF0DQphbGwuIEkgZG8gbm90IHdhbnQgaXQgdG8gYmUgaW4gYSBraW5kIG9mIGxpbWJvIHdo ZXJlIG5vdGhpbmcgaGFwcGVucyBhbmQNCm5vYm9keSBjYXJlcy4NCg0KVGhhbmtzLA0KDQpHb256 YWxvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpz cGxpY2VzIG1haWxpbmcgbGlzdA0Kc3BsaWNlc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcGxpY2VzDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlz IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwg Y29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJl IG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBk aXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRo aXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRp YWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVz c2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRo ZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2 aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0048BF0848257870_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdvbnphbG8sPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZShaVEUpIGNhcmUgYWJv dXQgdGhpcyB0b3BpYy4gQmVjYXVzZQ0Kb2YgaGF2aW5nIG5vIHRpbWUgZm9yIHRoZSBtZWV0aW5n IGluIDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPlByYWd1ZTwvZm9udD48L3R0Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4sDQpJIGRpZCBub3Qgam9pbiB0aGUgZmFjZSB0byBmYWNlIG1l ZXRpbmcuIEkgY2FuIGpvaW4gdGhlIGRpc2N1c3Npb24gb24gdGhlDQptYWlsbGlzdCwgYW5kIGFz ayBvdGhlciBaVEUgZ3V5cyBmb3IgdGhlIGZhY2UgdG8gZmFjZSBtZWV0aW5nIGZvciB0aGUgbmV4 dA0KdGltZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlRoZW4sIGJhY2sgdG8gdGhlIGNoYXJ0ZXIgaXRzZWxmLCBJDQp0aGluayB0aGlzIHRvcGljIGlz IHF1aXRlIG1lYW5pbmdmdWwuIEFuZCB0aGVyZSdzIHNvbWUgb3BlcmF0b3JzIGNvbnRhY3QNCnVz IHRvIHRhbGsgYWJvdXQgdGhlIHJlcXVpcmVtZW50IG9mIHNoYXJpbmcgc3RyZWFtcyBiZXR3ZWVu IFVFcyBpbiBJTVMuDQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkxhc3Qgb25lLCBJIHRoaW5rIHRoaXMgdG9waXMgaXMgb3ZlcmxhcHBlZA0Kd2l0aCBJ VVQgdG9waWMgaW4gM0dQUC4gSG93IHRvIGhhbmRsZSB0aGUgcmVsYXRpb25zaGlwIG9mIHRoZSB0 d28gdG9waWNzDQppbiBJTVMgZGVwbG95bWVudCBpcyBpbnRlcmVzdGluZy48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Hb256YWxvIENhbWFy aWxsbyAmbHQ7R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tJmd0OzwvYj4NCjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtzcGxpY2Vz LWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+MjAxMS0wNC0xMiAyMDo0NzwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5zcGxpY2VzQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bc3BsaWNlc10gV2F5IGZvcndh cmQgZm9yIHRoZSBXRzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+SGksPGJyPg0KPGJyPg0KaW4gdGhlIFNQTElDRVMgc2Vzc2lvbiBpbiBQ cmFndWUsIHRoZXJlIHdhcyBjb25zZW5zdXMgaW4gdGhlIHJvb20gbm90IHRvPGJyPg0Kd29yayBv biBzY2VuYXJpb3MgdGhhdCByZXF1aXJlIHVwZGF0ZWQgVUFzIG9uIGJvdGggZW5kcy4gVGhhdCBp cywgdGhlPGJyPg0KbmV3IFNQTElDRVMgZnVuY3Rpb25hbGl0eSB3b3VsZCBuZWVkIHRvIGJlIGF2 YWlsYWJsZSBhcyBsb25nIGFzIG9uZSBlbmQ8YnI+DQpzdXBwb3J0ZWQgdGhlIG5ldyBtZWNoYW5p c21zLiBTdWNoIGNvbnNlbnN1cyBuZWVkcyB0byBiZSBjb25maXJtZWQgb248YnI+DQp0aGUgbGlz dC4gU2ltb24gUGlldHJvIHdpbGwgdGFrZSBjYXJlIG9mIHRoYXQuPGJyPg0KPGJyPg0KSXQgaXMg b2J2aW91cyB0aGF0IHRoaXMgV0cgaXMgcnVubmluZyB2ZXJ5IGxvdyBvbiBlbmVyZ3kuIFRoZSBs aXR0bGU8YnI+DQplbmVyZ3kgSSBoYXZlIHNlZW4gY2FtZSBmcm9tIHBlb3BsZSBpbnRlcmVzdGVk IGluIHNjZW5hcmlvcyB3aGVyZSBib3RoPGJyPg0KZW5kcyBzdXBwb3J0ZWQgdGhlIG5ldyBtZWNo YW5pc21zIHRvIGJlIGRldmVsb3BlZC4gUGVvcGxlIGFnYWluc3Q8YnI+DQp1cGRhdGluZyBib3Ro IGVuZHMgaGF2ZSBiZWVuIG1vc3RseSBvcHBvc2luZyB3b3JrIG9uIHRob3NlIG1lY2hhbmlzbXMs PGJyPg0KYXMgb3Bwb3NlZCB0byBkcml2aW5nIG5ldyB3b3JrLjxicj4NCjxicj4NClNvLCBJIGFt IGNvbmNlcm5lZCB0aGF0IHdoZW4gdGhpcyBkZWNpc2lvbiBpcyBjb25maXJtZWQsIHRoZXJlIHdp bGwgbm90PGJyPg0KYmUgYW55IGVuZXJneSBsZWZ0IGluIHRoaXMgV0cuPGJyPg0KPGJyPg0KQXQg dGhpcyBwb2ludCwgSSB3b3VsZCBsaWtlIHRvIGFzayB3aGV0aGVyIHBlb3BsZSBhcmUgd2lsbGlu ZyB0bzxicj4NCmFsbG9jYXRlIHNvbWUgb2YgdGhlaXIgY3ljbGVzIHRvIHdvcmsgb24gdGhlIHBy b2JsZW1zIGRlc2NyaWJlZCBpbiB0aGU8YnI+DQpjaGFydGVyIG9mIHRoaXMgV0cgb3IgaWYgSSBz aG91bGQgc2ltcGx5IHNodXQgZG93biB0aGUgV0cgZm9yIGxhY2sgb2Y8YnI+DQplbmVyZ3kuPGJy Pg0KPGJyPg0KSW4gc2hvcnQsIEkgd2FudCBTUExJQ0VTIHRvIGJlIGVpdGhlciBhbiBhY3RpdmUg V0cgb3Igbm90IHRvIGJlIGEgV0cgYXQ8YnI+DQphbGwuIEkgZG8gbm90IHdhbnQgaXQgdG8gYmUg aW4gYSBraW5kIG9mIGxpbWJvIHdoZXJlIG5vdGhpbmcgaGFwcGVucyBhbmQ8YnI+DQpub2JvZHkg Y2FyZXMuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NCkdvbnphbG88YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNwbGlj ZXMgbWFpbGluZyBsaXN0PGJyPg0Kc3BsaWNlc0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3BsaWNlczxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0K PGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNw O05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlz Jm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4m bmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGln YXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJl Jm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZu YnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3Rv Jm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7Zmls ZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZp ZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJz cDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVz c2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZu YnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNw O3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7 QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNz YWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtz Y2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZu YnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0048BF0848257870_=-- From pkyzivat@cisco.com Tue Apr 12 17:24:44 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 786A5E06B8 for ; Tue, 12 Apr 2011 17:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.466 X-Spam-Level: X-Spam-Status: No, score=-110.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TumygJH+9RzK for ; Tue, 12 Apr 2011 17:24:43 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 80513E0681 for ; Tue, 12 Apr 2011 17:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1883; q=dns/txt; s=iport; t=1302654283; x=1303863883; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=fkafJJC4teRsDT2kUPNsVzuzYCyXC00bugtwyaUKfAQ=; b=FDRLhRh+4HS79I9BG5rbPlJaQPtmKNcGb9+GkaD5pIMIrH+hg8JcZVLV kY9sfBH2V0bUJs4k7C1QbOdEvjGqK44eCjH1fZmxNbydKGT2mp82pPkA/ p6MDJBeRuXNcnz0ckFMRKFwMQ6zhi95Xy+wEfGKJf5WFlEAdz+RqRrFuq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4HAMHspE2tJXG+/2dsb2JhbACYXI0pd6donQ6FbgSNY4Nv X-IronPort-AV: E=Sophos;i="4.64,200,1301875200"; d="scan'208";a="294993609" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 13 Apr 2011 00:24:42 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3D0OgCe016959 for ; Wed, 13 Apr 2011 00:24:42 GMT Message-ID: <4DA4ED4A.5040000@cisco.com> Date: Tue, 12 Apr 2011 20:24:42 -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: splices@ietf.org References: <4DA449E0.3030904@ericsson.com> In-Reply-To: <4DA449E0.3030904@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [splices] Way forward for the WG 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, 13 Apr 2011 00:24:44 -0000 Gonzalo, I am *interested* in this work. (I was working on something similar when I first got involved with sip 10 years ago.) And while I have been opposed to new mechanisms for coordination between the two ends, I do see need for mechanisms to further coordinate the federated pieces at the end where federation is occurring - such as getting a subsidiary device to answer the call from a sibling device. (I just don't see that as an alternative to a sip dialog for establishing a media session.) However I *don't* have cycles to allocate to this work now, beyond general review and comment. Thanks, Paul On 4/12/2011 8:47 AM, Gonzalo Camarillo wrote: > Hi, > > in the SPLICES session in Prague, there was consensus in the room not to > work on scenarios that require updated UAs on both ends. That is, the > new SPLICES functionality would need to be available as long as one end > supported the new mechanisms. Such consensus needs to be confirmed on > the list. Simon Pietro will take care of that. > > It is obvious that this WG is running very low on energy. The little > energy I have seen came from people interested in scenarios where both > ends supported the new mechanisms to be developed. People against > updating both ends have been mostly opposing work on those mechanisms, > as opposed to driving new work. > > So, I am concerned that when this decision is confirmed, there will not > be any energy left in this WG. > > At this point, I would like to ask whether people are willing to > allocate some of their cycles to work on the problems described in the > charter of this WG or if I should simply shut down the WG for lack of > energy. > > In short, I want SPLICES to be either an active WG or not to be a WG at > all. I do not want it to be in a kind of limbo where nothing happens and > nobody cares. From spromano@unina.it Thu Apr 14 14:11:27 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 74F08E082A for ; Thu, 14 Apr 2011 14:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.719 X-Spam-Level: X-Spam-Status: No, score=-100.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpjKeFldDR3v for ; Thu, 14 Apr 2011 14:11:25 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfc.amsl.com (Postfix) with ESMTP id 24F1BE0823 for ; Thu, 14 Apr 2011 14:11:21 -0700 (PDT) Received: from [192.168.1.102] ([151.77.221.4]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id p3ELBHpO023374 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 14 Apr 2011 23:11:19 +0200 Message-ID: <4DA762EF.60007@unina.it> Date: Thu, 14 Apr 2011 23:11:11 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: splices@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Subject: [splices] SPLICES IETF-80 meeting minutes and start of ML discussion 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, 14 Apr 2011 21:11:27 -0000 Dear all, I went again through the SPLICES session recording in order to derive a "faithful" summary of the things we discussed. You'll find SPLICES minutes at the following URL: http://www.ietf.org/proceedings/80/minutes/splices.txt I encourage all of you to go and have a look at them in order to: 1. notify me in case you find something which needs revision/re-interpretation; 2. check once more the main lines of discussion we had in Prague. As decided at the end of the meeting, I am herein also asking you to formally express your opinion on the main topic we tackled at the meeting and which I am copying below: "Do people believe that all the burden of this service should be on the side implementing the service itself?" I remind you that the sense of the room at last IETF was clearly in favor of this solution, which means that we CANNOT touch the far end of the session when designing the SPLICES solution. This said, I warmly invite all of the people who participated in the SPLICES session and who fruitfully contributed to the discussion to dedicate some of their cycles to SPLICES. I personally keep on thinking that we might do some good work here. Finally, I encourage the authors of the documents we have been discussing so far to raise their voice and explicitly declare: (i) their willingness to proceed with the work they proposed; (ii) the main path forward they currently envisage in order to let the documents we discussed progress. Let's try and come out of this limbo! Cheers, Simon -- _\\|//_ ( 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 pkyzivat@cisco.com Thu Apr 14 14:57:08 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C30DBE0791 for ; Thu, 14 Apr 2011 14:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eBMmI39tvq8 for ; Thu, 14 Apr 2011 14:57:07 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfc.amsl.com (Postfix) with ESMTP id A1040E0715 for ; Thu, 14 Apr 2011 14:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1832; q=dns/txt; s=iport; t=1302818227; x=1304027827; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Qt4kdBeXqtFmOvZVPKC3Yg9HtgFqmW6VVQsP9eagpWg=; b=FmU1ftBlXmMIvzuyFNL6YyxooqttvYFN4dvxkAGlH+ue4gkasaCDO12U BMFyJ/tg7MIQxcFBk2GrswPiZ8mWuEqpYzoPNPWp+iQZVLb4dzJ9tLLE3 N4uH95302PQGn2hSuIQk0xdQjYTESFrTRLynbBVXYkX24tUcNowiHoUGd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMHAJJsp02tJXHB/2dsb2JhbACYPI0/d4hvniqdBYVuBI1vg3M X-IronPort-AV: E=Sophos;i="4.64,213,1301875200"; d="scan'208";a="282965148" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 14 Apr 2011 21:57:06 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p3ELv6sU009671 for ; Thu, 14 Apr 2011 21:57:06 GMT Message-ID: <4DA76DB2.8020600@cisco.com> Date: Thu, 14 Apr 2011 17:57:06 -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: splices@ietf.org References: <4DA762EF.60007@unina.it> In-Reply-To: <4DA762EF.60007@unina.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [splices] SPLICES IETF-80 meeting minutes and start of ML discussion 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, 14 Apr 2011 21:57:08 -0000 On 4/14/2011 5:11 PM, Simon Pietro Romano wrote: > Dear all, > > I went again through the SPLICES session recording in order to derive a > "faithful" summary of the things we discussed. You'll find SPLICES > minutes at the following URL: > http://www.ietf.org/proceedings/80/minutes/splices.txt Wow! You have a promising future as a secretary taking dictation! > I encourage all of you to go and have a look at them in order to: > 1. notify me in case you find something which needs > revision/re-interpretation; > 2. check once more the main lines of discussion we had in Prague. Yup, its consistent with what I remember. > As decided at the end of the meeting, I am herein also asking you to > formally express your opinion on the main topic we tackled at the > meeting and which I am copying below: > > "Do people believe that all the burden of this service should be on the > side implementing the service itself?" I think my position is clear: YES > I remind you that the sense of the room at last IETF was clearly in > favor of this solution, which means that we CANNOT touch the far end of > the session when designing the SPLICES solution. > > This said, I warmly invite all of the people who participated in the > SPLICES session and who fruitfully contributed to the discussion to > dedicate some of their cycles to SPLICES. I personally keep on thinking > that we might do some good work here. > Finally, I encourage the authors of the documents we have been > discussing so far to raise their voice and explicitly declare: (i) their > willingness to proceed with the work they proposed; (ii) the main path > forward they currently envisage in order to let the documents we > discussed progress. > > Let's try and come out of this limbo! > > Cheers, > > Simon > > From salvatore.loreto@ericsson.com Fri Apr 15 11:02:39 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6758FE08C5 for ; Fri, 15 Apr 2011 11:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qD3UiuilJzFO for ; Fri, 15 Apr 2011 11:02:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id 05E50E08BF for ; Fri, 15 Apr 2011 11:02:28 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-17-4da88834ab62 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EE.36.09202.43888AD4; Fri, 15 Apr 2011 20:02:28 +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; Fri, 15 Apr 2011 20:02:27 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B5A9C23F6 for ; Fri, 15 Apr 2011 21:02:27 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7C3EA50AC7 for ; Fri, 15 Apr 2011 21:02:27 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F20A24F6A7 for ; Fri, 15 Apr 2011 21:02:26 +0300 (EEST) Message-ID: <4DA88832.2090202@ericsson.com> Date: Fri, 15 Apr 2011 20:02:26 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: splices@ietf.org References: <4DA762EF.60007@unina.it> In-Reply-To: <4DA762EF.60007@unina.it> Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [splices] SPLICES IETF-80 meeting minutes and start of ML discussion 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, 15 Apr 2011 18:02:39 -0000 On 4/14/11 11:11 PM, Simon Pietro Romano wrote: > Dear all, > > I went again through the SPLICES session recording in order to derive a > "faithful" summary of the things we discussed. You'll find SPLICES > minutes at the following URL: > http://www.ietf.org/proceedings/80/minutes/splices.txt > > I encourage all of you to go and have a look at them in order to: > 1. notify me in case you find something which needs > revision/re-interpretation; > 2. check once more the main lines of discussion we had in Prague. > > As decided at the end of the meeting, I am herein also asking you to > formally express your opinion on the main topic we tackled at the > meeting and which I am copying below: > > "Do people believe that all the burden of this service should be on the > side implementing the service itself?" No, I am interested in scenarios where both ends may be impacted by the implementation of the new mechanism to be developed; of course in the case an impact is required, I do think the design should consider a fall back for the case the other peer does not implement it (e.g. a legacy UA) > I remind you that the sense of the room at last IETF was clearly in > favor of this solution, which means that we CANNOT touch the far end of > the session when designing the SPLICES solution. yes, that was the sense of the room, but any decision made at a face-to-face meeting must also gain consensus on the WG mailing list. > This said, I warmly invite all of the people who participated in the > SPLICES session and who fruitfully contributed to the discussion to > dedicate some of their cycles to SPLICES. I personally keep on thinking > that we might do some good work here. > Finally, I encourage the authors of the documents we have been > discussing so far to raise their voice and explicitly declare: (i) their > willingness to proceed with the work they proposed; (ii) the main path > forward they currently envisage in order to let the documents we > discussed progress. work of a loosely-coupled coordination scenario, where no single device needs to remain in the session for its entire duration and no single device needs to act as master... is still something that I personally find interesting to be investigated cheers /Sal -- Salvatore Loreto www.sloreto.com > Let's try and come out of this limbo! > > Cheers, > > Simon > > From rifatyu@avaya.com Fri Apr 15 12:18:20 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1F4C9E0925 for ; Fri, 15 Apr 2011 12:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cen-d2lRzcMR for ; Fri, 15 Apr 2011 12:18:19 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfc.amsl.com (Postfix) with ESMTP id 1EDF8E08D2 for ; Fri, 15 Apr 2011 12:18:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU2HCzI1/2dsb2JhbACYKo47dKR5ApkWAoVfBJAM X-IronPort-AV: E=Sophos;i="4.64,220,1301889600"; d="scan'208";a="275040715" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Apr 2011 15:18:17 -0400 X-IronPort-AV: E=Sophos;i="4.64,220,1301889600"; d="scan'208";a="639586142" 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; 15 Apr 2011 15:18: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; Fri, 15 Apr 2011 15:18:17 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Simon Pietro Romano , "splices@ietf.org" Date: Fri, 15 Apr 2011 15:18:11 -0400 Thread-Topic: [splices] SPLICES IETF-80 meeting minutes and start of ML discussion Thread-Index: Acv66IZh9GNu2GP+SjaweUjPq82QLQAkvyug Message-ID: <6369CB70BFD88942B9705AC1E639A33822CACD0161@DC-US1MBEX4.global.avaya.com> References: <4DA762EF.60007@unina.it> In-Reply-To: <4DA762EF.60007@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 Subject: Re: [splices] SPLICES IETF-80 meeting minutes and start of ML discussion 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, 15 Apr 2011 19:18:20 -0000 The SIP Action Referral team is committed to this work and planning on keep= pushing it forward. We are planning on creating a new document with a new SIP method, which see= ms to be the preferred choice for the SPLICES WG members that expressed the= ir opinion on this issue. I am personally interested in the core work of the SPLICES WG and will try = to contribute to that work too. Regards, Rifaat > -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Simon Pietro Romano > Sent: Thursday, April 14, 2011 5:11 PM > To: splices@ietf.org > Subject: [splices] SPLICES IETF-80 meeting minutes and start of ML discus= sion >=20 > Dear all, >=20 > I went again through the SPLICES session recording in order to derive a > "faithful" summary of the things we discussed. You'll find SPLICES > minutes at the following URL: > http://www.ietf.org/proceedings/80/minutes/splices.txt >=20 > I encourage all of you to go and have a look at them in order to: > 1. notify me in case you find something which needs > revision/re-interpretation; > 2. check once more the main lines of discussion we had in Prague. >=20 > As decided at the end of the meeting, I am herein also asking you to > formally express your opinion on the main topic we tackled at the > meeting and which I am copying below: >=20 > "Do people believe that all the burden of this service should be on the > side implementing the service itself?" >=20 > I remind you that the sense of the room at last IETF was clearly in > favor of this solution, which means that we CANNOT touch the far end of > the session when designing the SPLICES solution. >=20 > This said, I warmly invite all of the people who participated in the > SPLICES session and who fruitfully contributed to the discussion to > dedicate some of their cycles to SPLICES. I personally keep on thinking > that we might do some good work here. > Finally, I encourage the authors of the documents we have been > discussing so far to raise their voice and explicitly declare: (i) their > willingness to proceed with the work they proposed; (ii) the main path > forward they currently envisage in order to let the documents we > discussed progress. >=20 > Let's try and come out of this limbo! >=20 > Cheers, >=20 > Simon >=20 >=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 >=20 > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From pkyzivat@cisco.com Fri Apr 15 17:23:21 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 702A9E0680 for ; Fri, 15 Apr 2011 17:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.436 X-Spam-Level: X-Spam-Status: No, score=-110.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vinN9MbkAORl for ; Fri, 15 Apr 2011 17:23:20 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id B7C22E066C for ; Fri, 15 Apr 2011 17:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1040; q=dns/txt; s=iport; t=1302913400; x=1304123000; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Aj8DWpQ0Q04+DceuTNCbyI9SZiIoUtmbMs1rODLsJYQ=; b=Fl+oafJ19jrgnefNerX7g33ukoiN1hO/9EAlvBC/WWxpTju9oWCJOv53 0loLG5s3EJ2r/egXlQgkb2Nbi4bMmh8uVdVE53E7d0I7LwHIH4cQH9yt0 zH4Hnj8u3kKvuNNyO3tA+fLeYo90PVL85OdTaHKtG5wCPg0ZOSnYqV7DG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIIAE7gqE2rRDoG/2dsb2JhbACYTY1Ad6dVnRWFbgSNeoN0 X-IronPort-AV: E=Sophos;i="4.64,222,1301875200"; d="scan'208";a="295660650" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 16 Apr 2011 00:23:20 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3G0NJkV022407 for ; Sat, 16 Apr 2011 00:23:20 GMT Message-ID: <4DA8E177.7070908@cisco.com> Date: Fri, 15 Apr 2011 20:23:19 -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: splices@ietf.org References: <4DA762EF.60007@unina.it> <4DA88832.2090202@ericsson.com> In-Reply-To: <4DA88832.2090202@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [splices] SPLICES IETF-80 meeting minutes and start of ML discussion 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, 16 Apr 2011 00:23:21 -0000 Sal, On 4/15/2011 2:02 PM, Salvatore Loreto wrote: ... > I am interested in scenarios where both ends may be impacted by the > implementation > of the new mechanism to be developed; > of course in the case an impact is required, I do think the design > should consider a fall back for the case the other > peer does not implement it (e.g. a legacy UA) ... > work of a loosely-coupled coordination scenario, > where no single device needs to remain in the session for its entire > duration > and no single device needs to act as master... > is still something that I personally find interesting to be investigated I still don't *get* it. Can you lay out a scenario/use case/example of what you have in mind? - describe to moving parts - what interactions they have to make the case work - what capabilities each has/expects of others - if parts of the coordination depend on special behavior of *people* rather than automata, explain that too. Nothing complicated - just very high level. Thanks, Paul From rifatyu@avaya.com Fri Apr 22 09:03:20 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 43347E07A1 for ; Fri, 22 Apr 2011 09:03:20 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N591ZADg0H9y for ; Fri, 22 Apr 2011 09:03:19 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfc.amsl.com (Postfix) with ESMTP id 4F944E0768 for ; Fri, 22 Apr 2011 09:03:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU3GmAcF/2dsb2JhbACmZXSkeQKZFoVhBJAM X-IronPort-AV: E=Sophos;i="4.64,254,1301889600"; d="scan'208";a="276144503" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Apr 2011 12:03:18 -0400 X-IronPort-AV: E=Sophos;i="4.64,254,1301889600"; d="scan'208";a="611969560" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Apr 2011 12:02:58 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 22 Apr 2011 12:02:57 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "splices@ietf.org" Date: Fri, 22 Apr 2011 12:02:56 -0400 Thread-Topic: Answering a Call Using Two Separate Devices proposal Thread-Index: AcwBBr5eBSB77KQiR06UQA3Gynn7EA== Message-ID: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@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 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: Fri, 22 Apr 2011 16:03:20 -0000 Hi, I would like to discuss the following proposal for addressing the scenario = of answering a call using two separate devices: Alice Alice Proxy Bob PC Desk Phone =20 | | | | | | | | Both Alice's devices subscribe to the reg event package, which allows each= =20 device to discover the capabilities of the other device based on the=20 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 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 answer the call =20 | | | | | REFER Refer-To: urn:sip-action:call:answer | |-------------------->| | | | 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=20 to the existing audio call | | | | | | | INVITE Alice [A/V] | | | |<--------------------| | | INVITE 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. | | | | | INVITE [Video] | | | |<--------------------| | | | 180 | | | |-------------------->| | | | | | | The user can either answer the video call using his PC, or his Desk Phone. If the user chose to answer the incoming video call using his Desk Phone, the following REFER will be sent to 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 uses her PC and attempt to initiate a new video call. Because the=20 PC is aware that another device is logged in using the same AOR, it will try to find if there is any existing dialog on the other device by=20 subscribing to the dialog event package | | | | | SUBSCRIBE dialog | | | |-------------------->| | | | 200 OK | | | |<--------------------| | | | NOTIFY | | | |<--------------------| | | | OK | | | |-------------------->| | | | | | | The PC discovers 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 attach the new video call to the existing audio call or not. In this=20 case Alice chose to attach the new video call to the existing audio call | | | | | | | | | INVITE [Video] | | | | Target-Dialog: dialog1 | | |-------------------->| | | | 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>| | | | | | | | | | | | | Regards, Rifaat From pkyzivat@cisco.com Fri Apr 22 10:26:44 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5C4E4E07DE for ; Fri, 22 Apr 2011 10:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.443 X-Spam-Level: X-Spam-Status: No, score=-110.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjG6YcoFxlNt for ; Fri, 22 Apr 2011 10:26:43 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id F2C10E07CB for ; Fri, 22 Apr 2011 10:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=12449; q=dns/txt; s=iport; t=1303493203; x=1304702803; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=+MPcWi93xG4BlAxcO//TTSdJP7hFUBipkRg64QBbjlQ=; b=MVag8xQS7obWd1xqqkwPpR8dT01drvwEus40DkTdB6AqzANShi1YspqQ XHny1n/halMnbOyR4YJ3agbv4nv1v/wJ1jesOJLAe6sj9hGuvCVnnScMu u18SJzx6FfUvTiYKrfUgQTnQ3O/t5RITiNXUufEHlc8FyVyqmLOa6IATj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMa5sU2rRDoH/2dsb2JhbAClXXeIcKAJnE2FdgSOLYQH X-IronPort-AV: E=Sophos;i="4.64,254,1301875200"; d="scan'208";a="300142514" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2011 17:26:42 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3MHQfjl009563 for ; Fri, 22 Apr 2011 17:26:42 GMT Message-ID: <4DB1BA51.4080307@cisco.com> Date: Fri, 22 Apr 2011 13:26:41 -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: splices@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@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: Fri, 22 Apr 2011 17:26:44 -0000 On 4/22/2011 12:02 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Hi, > > I would like to discuss the following proposal for addressing the scenario of answering a call using two separate devices: > > > 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 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 answer the call You mean Alice used her PC to instruct her phone to answer the call. For the point you are making, it would be equally fine if she had simply picked up the phone. How do you assume the phone is rendering the audio when instructed to answer this way. Sending/receiving from the handset isn't very useful when its on the cradle. Do you assume speaker phone, or that Alice has a headset connected to the phone? (If the latter, why not simply connect the headset to the PC?) > | | | | > | REFER Refer-To: urn:sip-action:call:answer | > |-------------------->| | | > | 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 > | | | | > | | | INVITE Alice [A/V] | > | | |<--------------------| > | | INVITE 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. Seems reasonable. > | | | | > | INVITE [Video] | | | > |<--------------------| | | > | 180 | | | > |-------------------->| | | > | | | | > The user can either answer the video call using his PC, or his Desk Phone. > If the user chose to answer the incoming video call using his Desk Phone, > the following REFER will be sent to the PC: I don't fully understand what you have in mind here. Somehow Alice must become aware that video has been offered and she must do something to accept it. From the diagram I gather that you expect some sort of alert on the PC, so answering it from the PC makes sense. For Alice to answer from the phone there must be some way to do so. Presumably there would have to be some UI on the phone providing a means to "accept video". Most likely that means there will be some sort of alerting on the phone too. (But maybe not *ringing*.) > | | | | > | 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==============================>| > | | | | > | | | | Otherwise the above all makes sense. > 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 uses her PC and attempt to initiate a new video call. Because the > PC is aware that another device is logged in using the same AOR, it will > try to find if there is any existing dialog on the other device by > subscribing to the dialog event package This doesn't quite make sense to me - at least the wording. The PC has a fairly rich UI, and it could *already* know about the call in progress. And certainly Alice knows she wants to add video to an existing call rather than make a new call. So I would expect the interaction between Alice and her PC to first be one of discovering the existing call that *could* be joined, and then requesting to join. (Alternatively Alice might decide she doesn't want to join that call - that she wants to make an independent call from the PC to somebody else.) > | | | | > | SUBSCRIBE dialog | | | > |-------------------->| | | > | 200 OK | | | > |<--------------------| | | > | NOTIFY | | | > |<--------------------| | | > | OK | | | > |-------------------->| | | > | | | | > The PC discovers 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 > attach the new video call to the existing audio call or not. In this > case Alice chose to attach the new video call to the existing audio call > | | | | > | | | | > | INVITE [Video] | | | > | Target-Dialog: dialog1 | | > |-------------------->| | | I would tweak this - the invite should use Join. > | 100 | | | > |<--------------------| | | > | | re-INVITE [A/V] | | > | |-------------------->| | > | | | re-INVITE [A/V] | > | | |-------------------->| > | | | 200 OK [A/V] | > | | 200 OK [A/V] |<--------------------| > | |<--------------------| | > | 200 OK [Video] | | | > |<--------------------| | | > | | | | > | | | | > |<----dialog2-------->|<---dialog1------------------------------->| > | | | | > | |<======audio==============================>| > |<============================video==============================>| > | | | | > | | | | > | | | | Otherwise this sounds right on to me. Its an example of what I have been talking about all along. You've described it well. Thanks, Paul From rifatyu@avaya.com Fri Apr 22 12:09:21 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 18AD6E076D for ; Fri, 22 Apr 2011 12:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHtdRBKru+tc for ; Fri, 22 Apr 2011 12:09:19 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfc.amsl.com (Postfix) with ESMTP id 4E71EE076F for ; Fri, 22 Apr 2011 12:09:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU2HCzI1/2dsb2JhbACYKo47dKR5ApkWhWEEkAw X-IronPort-AV: E=Sophos;i="4.64,255,1301889600"; d="scan'208";a="243008231" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Apr 2011 15:09:09 -0400 X-IronPort-AV: E=Sophos;i="4.64,255,1301889600"; d="scan'208";a="642263107" 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 Apr 2011 15:09:08 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 22 Apr 2011 15:09:08 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat , "splices@ietf.org" Date: Fri, 22 Apr 2011 15:09:06 -0400 Thread-Topic: [splices] Answering a Call Using Two Separate Devices proposal Thread-Index: AcwBEnax3sge/7f4RCuIRU1p6cKrvgACtATA Message-ID: <6369CB70BFD88942B9705AC1E639A33822CAF4465A@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> <4DB1BA51.4080307@cisco.com> In-Reply-To: <4DB1BA51.4080307@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: Fri, 22 Apr 2011 19:09:21 -0000 > -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Paul Kyzivat > Sent: Friday, April 22, 2011 1:27 PM > To: splices@ietf.org > Subject: Re: [splices] Answering a Call Using Two Separate Devices propos= al >=20 >=20 >=20 > On 4/22/2011 12:02 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi, > > > > I would like to discuss the following proposal for addressing the scena= rio > of answering a call using two separate devices: > > > > > > 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 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 answer the call >=20 > You mean Alice used her PC to instruct her phone to answer the call. > For the point you are making, it would be equally fine if she had simply > picked up the phone. >=20 Yes. > How do you assume the phone is rendering the audio when instructed to > answer this way. Sending/receiving from the handset isn't very useful > when its on the cradle. Do you assume speaker phone, or that Alice has a > headset connected to the phone? (If the latter, why not simply connect > the headset to the PC?) >=20 My initial thought was to use the speaker phone, but you raise a good point= here. Maybe we need to add a parameter to the URN to indicate which transducer to= use, e.g REFER Refer-To: urn:sip-action:call:answer;transducer=3Dspeaker|headset Alice answered the call on her Desk Phone because she knows it has a better= audio quality. Why do you want to connect the headset to the PC? > > | | | = | > > | REFER Refer-To: urn:sip-action:call:answer = | > > |-------------------->| | = | > > | 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 > > | | | = | > > | | | INVITE Alice [A/V] = | > > | | |<--------------------= | > > | | INVITE 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. >=20 > Seems reasonable. >=20 > > | | | = | > > | INVITE [Video] | | = | > > |<--------------------| | = | > > | 180 | | = | > > |-------------------->| | = | > > | | | = | > > The user can either answer the video call using his PC, or his Desk Pho= ne. > > If the user chose to answer the incoming video call using his Desk Phon= e, > > the following REFER will be sent to the PC: >=20 > I don't fully understand what you have in mind here. > Somehow Alice must become aware that video has been offered and she must > do something to accept it. From the diagram I gather that you expect > some sort of alert on the PC, so answering it from the PC makes sense. >=20 > For Alice to answer from the phone there must be some way to do so. > Presumably there would have to be some UI on the phone providing a means > to "accept video". Most likely that means there will be some sort of > alerting on the phone too. (But maybe not *ringing*.) >=20 Yes, that is exactly what I had in mind. > > | | | = | > > | 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 > Otherwise the above all makes sense. >=20 > > 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 uses her PC and attempt to initiate a new video call. Because the > > PC is aware that another device is logged in using the same AOR, it wil= l > > try to find if there is any existing dialog on the other device by > > subscribing to the dialog event package >=20 > This doesn't quite make sense to me - at least the wording. > The PC has a fairly rich UI, and it could *already* know about the call > in progress. And certainly Alice knows she wants to add video to an > existing call rather than make a new call. So I would expect the > interaction between Alice and her PC to first be one of discovering the > existing call that *could* be joined, and then requesting to join. > (Alternatively Alice might decide she doesn't want to join that call - > that she wants to make an independent call from the PC to somebody else.) >=20 Remember that this scenario starts after the (*) above, which means that=20 the PC is not aware of the existing call between the Desk Phone and Bob.=20 Of course Alice is aware of that call and expects the PC to discover=20 that when Alice clicks on her PC and opens the UI that allows here to initi= ate=20 a video call. > > | | | = | > > | SUBSCRIBE dialog | | = | > > |-------------------->| | = | > > | 200 OK | | = | > > |<--------------------| | = | > > | NOTIFY | | = | > > |<--------------------| | = | > > | OK | | = | > > |-------------------->| | = | > > | | | = | > > The PC discovers that there is an existing dialog between the Desk Phon= e > > and Bob and present this to Alice for her to choose if she wants to > > attach the new video call to the existing audio call or not. In this > > case Alice chose to attach the new video call to the existing audio cal= l > > | | | = | > > | | | = | > > | INVITE [Video] | | = | > > | Target-Dialog: dialog1 | = | > > |-------------------->| | = | >=20 > I would tweak this - the invite should use Join. >=20 Yeah, good point. > > | 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 > Otherwise this sounds right on to me. >=20 > Its an example of what I have been talking about all along. You've > described it well. >=20 Ok, great! > Thanks, > Paul > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From peter.musgrave@magorcorp.com Fri Apr 22 14:00:18 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 60CE0E0679 for ; Fri, 22 Apr 2011 14:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3SEW+ww3ae1 for ; Fri, 22 Apr 2011 14:00:17 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfc.amsl.com (Postfix) with ESMTP id CDD2FE0663 for ; Fri, 22 Apr 2011 14:00:17 -0700 (PDT) Received: by gyf3 with SMTP id 3so287260gyf.31 for ; Fri, 22 Apr 2011 14:00:17 -0700 (PDT) Received: by 10.236.88.235 with SMTP id a71mr1414745yhf.287.1303506017377; Fri, 22 Apr 2011 14:00:17 -0700 (PDT) Received: from [192.168.1.106] ([204.237.32.134]) by mx.google.com with ESMTPS id v62sm1378966yhm.36.2011.04.22.14.00.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2011 14:00:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CAF4465A@DC-US1MBEX4.global.avaya.com> Date: Fri, 22 Apr 2011 17:00:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> <4DB1BA51.4080307@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CAF4465A@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: Fri, 22 Apr 2011 21:00:18 -0000 Hi Rifaat, Overall I think this works.=20 1) Use of INVITE from phone to PC to signal addition of video: The current mechanism (with an new INVITE to the PC from the phone) = seems likely to me to cause the call to ring on the PC - and I think = having a call that is already in progress ring a second device as a = means of signalling the availability of video will not be the ideal user = experience (or perhaps when the device sees an INVITE with video and no = audio it knows not to alert the user in the usual way?) One alternative would be: When the accept on the PC results in the: | REFER Refer-To: urn:sip-action:call:answer =20 | message from the PC to the phone does it make sense for the PC to = subscribe to the dialog-state of the call at this point? (In fact would = it hurt to have the coupled devices always subscribed to each other's = dialog state?) Then when a reINVITE with video is offered the PC will receive a = notification and it can offer the user a choice to accept the call there = - with some pop-up and beep (or whatever). If the user accepts then it = could send a REFER to the phone to make it offer video to the PC. (I = first thought of using an INVITE with JOIN from PC to phone - but then = the video offer comes from the PC and forces the phone to build a video = answer based on the PCs offer - which seems a bad idea).=20 2) As an aside, how does lipsync on sending and playout get handled in = this configuration?=20 Regards,=20 Peter Musgrave From rifatyu@avaya.com Fri Apr 22 15:42:49 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 78BF6E068E for ; Fri, 22 Apr 2011 15:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.313 X-Spam-Level: X-Spam-Status: No, score=-3.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzWRdY5UWqpV for ; Fri, 22 Apr 2011 15:42:48 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfc.amsl.com (Postfix) with ESMTP id 9BC17E0685 for ; Fri, 22 Apr 2011 15:42:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU3GmAcF/2dsb2JhbACYKo47dKR5ApkWgncBgmkEkAw X-IronPort-AV: E=Sophos;i="4.64,256,1301889600"; d="scan'208";a="243027781" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Apr 2011 18:42:46 -0400 X-IronPort-AV: E=Sophos;i="4.64,256,1301889600"; d="scan'208";a="612067708" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Apr 2011 18:42: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; Fri, 22 Apr 2011 18:42:34 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Peter Musgrave Date: Fri, 22 Apr 2011 18:42:33 -0400 Thread-Topic: [splices] Answering a Call Using Two Separate Devices proposal Thread-Index: AcwBME4GCQSgXC5LRoqPbpSUjcT6WQAClgUw Message-ID: <6369CB70BFD88942B9705AC1E639A33822CAF44765@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> <4DB1BA51.4080307@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CAF4465A@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: Fri, 22 Apr 2011 22:42:49 -0000 > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: Friday, April 22, 2011 5:00 PM > 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 > Overall I think this works. >=20 > 1) Use of INVITE from phone to PC to signal addition of video: >=20 > The current mechanism (with an new INVITE to the PC from the phone) seems > likely to me to cause the call to ring on the PC - and I think having a c= all > that is already in progress ring a second device as a means of signalling= the > availability of video will not be the ideal user experience=20 > I personally think it is a reasonable user experience, but I can go either = way on this. Do other people have an opinion on this? (or perhaps when > the device sees an INVITE with video and no audio it knows not to alert t= he > user in the usual way?) >=20 This might be one way to address that. > One alternative would be: >=20 > When the accept on the PC results in the: > | REFER Refer-To: urn:sip-action:call:answer > | > message from the PC to the phone does it make sense for the PC to subscri= be to > the dialog-state of the call at this point? (In fact would it hurt to hav= e the > coupled devices always subscribed to each other's dialog state?) >=20 I just wanted to optimize the use of these subscriptions and avoid any unne= cessary ones until it is really needed. But in general, it seems like a reasonable approach to me. Anybody else has some thoughts on this?=20 > Then when a reINVITE with video is offered the PC will receive a notifica= tion > and it can offer the user a choice to accept the call there - with some p= op-up > and beep (or whatever). If the user accepts then it could send a REFER to= the > phone to make it offer video to the PC. (I first thought of using an INVI= TE > with JOIN from PC to phone - but then the video offer comes from the PC a= nd > forces the phone to build a video answer based on the PCs offer - which s= eems > a bad idea). >=20 It complicates matters a little bit, but it would work. > 2) As an aside, how does lipsync on sending and playout get handled in th= is > configuration? >=20 I have some thoughts around this, but not enough to be able to put a propos= al on the table. If you or anybody else has some thoughts on this, I would appreciate it if = you can share it with us. > Regards, >=20 > Peter Musgrave >=20 From peter.musgrave@magorcorp.com Fri Apr 22 16:17:43 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D5A50E079D for ; Fri, 22 Apr 2011 16:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crqS0oHB9A-z for ; Fri, 22 Apr 2011 16:17:43 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfc.amsl.com (Postfix) with ESMTP id 57A0CE06AD for ; Fri, 22 Apr 2011 16:17:43 -0700 (PDT) Received: by yxk30 with SMTP id 30so309094yxk.31 for ; Fri, 22 Apr 2011 16:17:43 -0700 (PDT) Received: by 10.90.23.19 with SMTP id 19mr1619181agw.108.1303514262743; Fri, 22 Apr 2011 16:17:42 -0700 (PDT) Received: from [192.168.1.106] ([204.237.32.134]) by mx.google.com with ESMTPS id x34sm3200904ana.36.2011.04.22.16.17.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2011 16:17:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CAF44765@DC-US1MBEX4.global.avaya.com> Date: Fri, 22 Apr 2011 19:17:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <888156C5-4209-43A7-9ACE-A5A89287F066@magorcorp.com> References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> <4DB1BA51.4080307@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CAF4465A@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CAF44765@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: Fri, 22 Apr 2011 23:17:44 -0000 Hi, On 2011-04-22, at 6:42 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> Then when a reINVITE with video is offered the PC will receive a = notification >> and it can offer the user a choice to accept the call there - with = some pop-up >> and beep (or whatever). If the user accepts then it could send a = REFER to the >> phone to make it offer video to the PC. (I first thought of using an = INVITE >> with JOIN from PC to phone - but then the video offer comes from the = PC and >> forces the phone to build a video answer based on the PCs offer - = which seems >> a bad idea). >>=20 > It complicates matters a little bit, but it would work. I agree it's inelegant.=20 How about an INVITE from the PC to the phone with delayed offer (i.e. no = SDP in INVITE) and a JOIN? Peter Musgrave= From pkyzivat@cisco.com Fri Apr 22 16:44:06 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DFCBCE065F for ; Fri, 22 Apr 2011 16:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.448 X-Spam-Level: X-Spam-Status: No, score=-110.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p90zHxHeQw5g for ; Fri, 22 Apr 2011 16:44:06 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id EA95EE00BE for ; Fri, 22 Apr 2011 16:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2816; q=dns/txt; s=iport; t=1303515846; x=1304725446; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LJ0H8YNmsqSzyUzLxsbT9WI0Rat1reFZsVWH98XYtRw=; b=A7KirYX/OgmifmH3wK+9zd3PditTuByMtvv7p6yOvvs28l70fkEDn4lN Fcz6Y4PxD4boC4+1Gb6n4Mo/BsEnKw1Im192l5yg91R1DcSuk/2R/Bzc8 ox2v/RK9LqV2i4hI4bIViyw1PAdfYb128Rem0zXbfl2EBDm31mqvoKfvf g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKURsk2tJXG9/2dsb2JhbAClaHeIcJ9knEmFdgSOLYQH X-IronPort-AV: E=Sophos;i="4.64,256,1301875200"; d="scan'208";a="300324397" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2011 23:44:05 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3MNi4HV022120; Fri, 22 Apr 2011 23:44:04 GMT Message-ID: <4DB212C4.9070403@cisco.com> Date: Fri, 22 Apr 2011 19:44:04 -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: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> <4DB1BA51.4080307@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CAF4465A@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CAF4465A@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: Fri, 22 Apr 2011 23:44:07 -0000 On 4/22/2011 3:09 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> How do you assume the phone is rendering the audio when instructed to >> answer this way. Sending/receiving from the handset isn't very useful >> when its on the cradle. Do you assume speaker phone, or that Alice has a >> headset connected to the phone? (If the latter, why not simply connect >> the headset to the PC?) >> > My initial thought was to use the speaker phone, but you raise a good point here. > Maybe we need to add a parameter to the URN to indicate which transducer to use, e.g > REFER Refer-To: urn:sip-action:call:answer;transducer=speaker|headset That is a whole can of worms. But its perhaps one that needs to be opened. > Alice answered the call on her Desk Phone because she knows it has a better audio quality. > Why do you want to connect the headset to the PC? I thought the quality difference, if any, would be due to the transducers. So the phone could be better than the speakers on the PC. But if you are talking about a headset, then does it matter which its connected to? But this is irrelevant to the discussion. >>> Alice uses her PC and attempt to initiate a new video call. Because the >>> PC is aware that another device is logged in using the same AOR, it will >>> try to find if there is any existing dialog on the other device by >>> subscribing to the dialog event package >> >> This doesn't quite make sense to me - at least the wording. >> The PC has a fairly rich UI, and it could *already* know about the call >> in progress. And certainly Alice knows she wants to add video to an >> existing call rather than make a new call. So I would expect the >> interaction between Alice and her PC to first be one of discovering the >> existing call that *could* be joined, and then requesting to join. >> (Alternatively Alice might decide she doesn't want to join that call - >> that she wants to make an independent call from the PC to somebody else.) >> > Remember that this scenario starts after the (*) above, which means that > the PC is not aware of the existing call between the Desk Phone and Bob. > Of course Alice is aware of that call and expects the PC to discover > that when Alice clicks on her PC and opens the UI that allows here to initiate > a video call. I said it *could* know about the call. Specifically, it could monitor the dialog package all the time. Or it might just do so after it has received an invite and then been canceled before answering - noting the phone got the call. Its all hypothetical of course - its part of the application design for the PC. But I do think its useful to explore the use cases and find some that are really compelling. So poking into the details might be relevant. Thanks, Paul From pkyzivat@cisco.com Fri Apr 22 17:07:47 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 60B92E06A0 for ; Fri, 22 Apr 2011 17:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.454 X-Spam-Level: X-Spam-Status: No, score=-110.454 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaO5+UJjBLOe for ; Fri, 22 Apr 2011 17:07:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 4E230E067D for ; Fri, 22 Apr 2011 17:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3674; q=dns/txt; s=iport; t=1303517266; x=1304726866; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=o7D8AZTGLN8/PK+MeZs+6WFDO3OFCcH94fLj2bC7dPo=; b=W9j9nJlme6FpyF1Fy5ApQ+YZz469IpQPpmdf8+hXBB1ud1pYksdcEgC6 05AsuL2Pz+vKs9CQvjk0Lx9cj64mwTzI1lNiXNRK2JAtzS5Tkuioyxaav iUYaYfXZ+mhnWJRUahGfQo7t9i9LGexWGUGlYmn+UtwBrzC0k8GuOwNfw Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4BAEkXsk2tJXG+/2dsb2JhbACXXY4Ld4hwn2ecRYJ4AYJ9BI4thAc X-IronPort-AV: E=Sophos;i="4.64,256,1301875200"; d="scan'208";a="300333067" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 23 Apr 2011 00:07:45 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3N07iqG000958; Sat, 23 Apr 2011 00:07:44 GMT Message-ID: <4DB21850.4000509@cisco.com> Date: Fri, 22 Apr 2011 20:07:44 -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: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> <4DB1BA51.4080307@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CAF4465A@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CAF44765@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CAF44765@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: Sat, 23 Apr 2011 00:07:47 -0000 On 4/22/2011 6:42 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > >> -----Original Message----- >> From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] >> Sent: Friday, April 22, 2011 5:00 PM >> To: Shekh-Yusef, Rifaat (Rifaat) >> Cc: Paul Kyzivat; splices@ietf.org >> Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal >> >> Hi Rifaat, >> >> Overall I think this works. >> >> 1) Use of INVITE from phone to PC to signal addition of video: >> >> The current mechanism (with an new INVITE to the PC from the phone) seems >> likely to me to cause the call to ring on the PC - and I think having a call >> that is already in progress ring a second device as a means of signalling the >> availability of video will not be the ideal user experience >> > I personally think it is a reasonable user experience, but I can go either way on this. > Do other people have an opinion on this? IMO when the offer to escalate to video is received, the user will typically need *some* kind indication and control. Absent some predefined policy, it seems reasonable to "alert", though its probably not reasonable to alert via a loud jangly noise. :-) The Alert-Info urn mechanism is designed to support this sort of thing. And I think that is preferable to the PC trying to "figure out" what it should do. Policy can bypass this in various ways: - accept video by default, but in recvonly mode until the user does something overt to initiate sending video - accept video by default, but send some canned image rather than live video of the user. >> When the accept on the PC results in the: >> | REFER Refer-To: urn:sip-action:call:answer >> | >> message from the PC to the phone does it make sense for the PC to subscribe to >> the dialog-state of the call at this point? (In fact would it hurt to have the >> coupled devices always subscribed to each other's dialog state?) >> > I just wanted to optimize the use of these subscriptions and avoid any unnecessary ones until it is really needed. > But in general, it seems like a reasonable approach to me. > Anybody else has some thoughts on this? I think this can vary. Some might not want their PC doing stuff like this all the time. But if you permit it, you can get a nicer user experience. >> Then when a reINVITE with video is offered the PC will receive a notification >> and it can offer the user a choice to accept the call there - with some pop-up >> and beep (or whatever). If the user accepts then it could send a REFER to the >> phone to make it offer video to the PC. IIUC, you are then back to trying to do session establishment with sub/not - bad idea. Perhaps it could REFER the phone to get it to send an invite to the PC, but that gets complicated. >> (I first thought of using an INVITE >> with JOIN from PC to phone - but then the video offer comes from the PC and >> forces the phone to build a video answer based on the PCs offer - which seems >> a bad idea). Not evident why that is so bad. Or the PC could send an offerless invite to the phone, and the capabilities in the contact would let the phone know to offer video. > It complicates matters a little bit, but it would work. >> 2) As an aside, how does lipsync on sending and playout get handled in this >> configuration? >> > I have some thoughts around this, but not enough to be able to put a proposal on the table. > If you or anybody else has some thoughts on this, I would appreciate it if you can share it with us. That could be difficult. Not a subject I know about. Thanks, Paul From peter.musgrave@magorcorp.com Fri Apr 22 18:28:01 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 05215E0670 for ; Fri, 22 Apr 2011 18:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+rG+d9jFLt4 for ; Fri, 22 Apr 2011 18:28:00 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfc.amsl.com (Postfix) with ESMTP id 73B38E066B for ; Fri, 22 Apr 2011 18:28:00 -0700 (PDT) Received: by gxk19 with SMTP id 19so326386gxk.31 for ; Fri, 22 Apr 2011 18:28:00 -0700 (PDT) Received: by 10.150.169.3 with SMTP id r3mr1799896ybe.331.1303522080011; Fri, 22 Apr 2011 18:28:00 -0700 (PDT) Received: from [192.168.1.109] ([204.237.32.134]) by mx.google.com with ESMTPS id p33sm2701942ybk.17.2011.04.22.18.27.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2011 18:27:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CAF44765@DC-US1MBEX4.global.avaya.com> Date: Fri, 22 Apr 2011 19:17:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <888156C5-4209-43A7-9ACE-A5A89287F066@magorcorp.com> References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> <4DB1BA51.4080307@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CAF4465A@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CAF44765@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: Sat, 23 Apr 2011 01:28:01 -0000 Hi, On 2011-04-22, at 6:42 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> Then when a reINVITE with video is offered the PC will receive a = notification >> and it can offer the user a choice to accept the call there - with = some pop-up >> and beep (or whatever). If the user accepts then it could send a = REFER to the >> phone to make it offer video to the PC. (I first thought of using an = INVITE >> with JOIN from PC to phone - but then the video offer comes from the = PC and >> forces the phone to build a video answer based on the PCs offer - = which seems >> a bad idea). >>=20 > It complicates matters a little bit, but it would work. I agree it's inelegant.=20 How about an INVITE from the PC to the phone with delayed offer (i.e. no = SDP in INVITE) and a JOIN? Peter Musgrave= From peter.musgrave@magorcorp.com Sat Apr 23 04:17:21 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 93755E066C for ; Sat, 23 Apr 2011 04:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0ewSL35h4ex for ; Sat, 23 Apr 2011 04:17:21 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 08ACFE0660 for ; Sat, 23 Apr 2011 04:17:20 -0700 (PDT) Received: by iwn39 with SMTP id 39so1217958iwn.31 for ; Sat, 23 Apr 2011 04:17:20 -0700 (PDT) Received: by 10.43.60.200 with SMTP id wt8mr2188825icb.358.1303557440663; Sat, 23 Apr 2011 04:17:20 -0700 (PDT) Received: from [192.168.1.109] ([204.237.32.134]) by mx.google.com with ESMTPS id 13sm1455044ibo.25.2011.04.23.04.17.17 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Apr 2011 04:17:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <4DB21850.4000509@cisco.com> Date: Sat, 23 Apr 2011 07:17:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50D5201E-A013-4EF5-AA6C-CA7D007B5BFF@magorcorp.com> References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> <4DB1BA51.4080307@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CAF4465A@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CAF44765@DC-US1MBEX4.global.avaya.com> <4DB21850.4000509@cisco.com> To: Paul Kyzivat 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: Sat, 23 Apr 2011 11:17:21 -0000 On 2011-04-22, at 8:07 PM, Paul Kyzivat wrote: >>>=20 >>> When the accept on the PC results in the: >>> | REFER Refer-To: urn:sip-action:call:answer >>> | >>> message from the PC to the phone does it make sense for the PC to = subscribe to >>> the dialog-state of the call at this point? (In fact would it hurt = to have the >>> coupled devices always subscribed to each other's dialog state?) >>>=20 >> I just wanted to optimize the use of these subscriptions and avoid = any unnecessary ones until it is really needed. >> But in general, it seems like a reasonable approach to me. >> Anybody else has some thoughts on this? >=20 > I think this can vary. > Some might not want their PC doing stuff like this all the time. > But if you permit it, you can get a nicer user experience. In the absence of this subscription ISTM the phone cannot know the PC is = present (or that the call application is running). In this case would it = send the INVITE to the PC and then use the lack of a TRYING to conclude = that video should be rejected ? I agree with your point that putting SUB/NOT in the session = establishment path when adding video is not a good idea. Peter= From gao.yang2@zte.com.cn Sun Apr 24 21:27:01 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33098E0689 for ; Sun, 24 Apr 2011 21:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.59 X-Spam-Level: X-Spam-Status: No, score=-96.59 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2icp43H61V-l for ; Sun, 24 Apr 2011 21:26:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfc.amsl.com (Postfix) with ESMTP id 03AF7E00BE for ; Sun, 24 Apr 2011 21:26:56 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 125201917726163; Mon, 25 Apr 2011 12:25:36 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 35180.3679098894; Mon, 25 Apr 2011 12:15:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3P4Qjug012126; Mon, 25 Apr 2011 12:26:45 +0800 (GMT-8) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> To: "Shekh-Yusef, Rifaat (Rifaat)" MIME-Version: 1.0 X-KeepSent: 72946BD9:9432A2C6-4825787D:001619F0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 25 Apr 2011 12:26:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-25 12:26:45, Serialize complete at 2011-04-25 12:26:45 Content-Type: multipart/alternative; boundary="=_alternative 001882DD4825787D_=" X-MAIL: mse01.zte.com.cn p3P4Qjug012126 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, 25 Apr 2011 04:27:01 -0000 This is a multipart message in MIME format. --=_alternative 001882DD4825787D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBiYXNlIG9mIHRoZSBoYW5kbGluZyBvbmUgc2Vzc2lvbiBiZXR3ZWVuIHR3byBz ZXBhcmF0ZSBkZXZpY2VzIGlzIHRvIA0KY29vcmRpbmF0ZSB0aGUgdHdvIHNlcGFyYXRlIGRldmlj ZXMuIA0KDQpDb21wYXJpbmcgd2l0aCB0aGUgM3BjYywgcmVmZXIgYWN0aW9uKGRyYWZ0LXl1c2Vm LWRpc3BhdGNoLWFjdGlvbi1yZWYtMDApIA0KaXMgYSBuZXcgd2F5LiBBbmQgSSB0aGluayBpdCBp cyBpbnRlcmVzdGluZy4NCg0KQnV0IGNvbnNpZGVyaW5nIEFsaWNlIGNhbiBoYW5kbGUgdGhlIHR3 byBkZXZpY2VzIGF0IHRoZSBzYW1lIHRpbWUsIEkgdGhpbmsgDQpBbGljZSBjYW4gYW5zd2VyIHRo ZSBjYWxsIHVzaW5nIFBDIHdpdGhvdXQgdGhlIHJlZmVyLWFjdGlvbiBpbmRpY2F0aW9uIGJ5IA0K dGhlIGRlc2sgcGhvbmUuDQoNClRoZW4sIGR1cmluZyB0aGUgYWRkaW5nIHZpZGVvIHN0cmVhbSBz dGFnZSwgQWxpY2UncyBkZXNrIHBob25lIHNlbmQgDQpJTlZJVEUod2l0aCB2aWRlbykgdG8gQWxp Y2UncyBQQy4gSSB0aGluayBBbGljZSBQQyBjYW4gYWNjZXB0IHRoZSBJTlZJVEUgDQpyZXF1ZXN0 IGJ5IEFsaWNlJ3MgbWFudWFsIGFjdGlvbiwgd2hpbGUgbm90IGJ5IHRoZSByZWZlci1hY3Rpb24g DQppbmRpY2F0aW9uLiANCg0KT25lIGRpc2N1c3Npb24gaGVyZTogdGhlIElOVklURSBzZW50IGJ5 IEFsaWNlJ3MgZGVzayBwaG9uZSB3b3VsZCBtYWtlIHRoZSANClNEUCBmcm9tIEJvYidzIFJlLUlO VklURS4gVGhpcyBpcyBzb21ldGhpbmcgbGlrZSAzcGNjLCBhIHNpbXBsZSBkZXNrIHBob25lIA0K Y2FuIG5vdCBoYXZlIHN1Y2ggZmVhdHVyZS4gU28sIHdoZW4gdGhlIHNlc3Npb24gaGFzIGJlZW4g YW5jaG9yZWQgb24gc29tZSANCnRyYWRpdGlvbmFsIFNJUCBkZXNrIHBob25lLCBBUygzcGNjKSBz ZWFtcyBNVVNUIGJlIG5lZWQuDQoNClRoYW5rcywNCg0KR2FvDQoNCg0Kc3BsaWNlcy1ib3VuY2Vz QGlldGYub3JnINC009ogMjAxMS0wNC0yMyAwMDowMjo1NjoNCg0KPiBIaSwNCj4gDQo+IEkgd291 bGQgbGlrZSB0byBkaXNjdXNzIHRoZSBmb2xsb3dpbmcgcHJvcG9zYWwgZm9yIGFkZHJlc3Npbmcg dGhlIA0KPiBzY2VuYXJpbyBvZiBhbnN3ZXJpbmcgYSBjYWxsIHVzaW5nIHR3byBzZXBhcmF0ZSBk ZXZpY2VzOg0KPiANCj4gDQo+ICAgIEFsaWNlICAgICAgICAgICAgICAgICBBbGljZSAgICAgICAg ICAgICAgICBQcm94eSAgICAgICAgICAgICAgICAgIEJvYg0KPiAgICAgUEMgICAgICAgICAgICAg ICAgIERlc2sgUGhvbmUgDQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+IEJv dGggQWxpY2UncyBkZXZpY2VzIHN1YnNjcmliZSB0byB0aGUgcmVnIGV2ZW50IHBhY2thZ2UsIHdo aWNoIGFsbG93cyANCmVhY2ggDQo+IGRldmljZSB0byBkaXNjb3ZlciB0aGUgY2FwYWJpbGl0aWVz IG9mIHRoZSBvdGhlciBkZXZpY2UgYmFzZWQgb24gdGhlIA0KPiBmZWF0dXJlIHRhZ3MgcHJvdmlk ZWQgYnkgZWFjaCBkZXZpY2UuDQo+IFRoZSBEZXNrIFBob25lIGtub3dzIHRoYXQgdGhlIFBDIHN1 cHBvcnRzIFZpZGVvLCB3aGlsZSB0aGUgUEMga25vd3MgdGhhdA0KPiB0aGUgRGVzayBQaG9uZSBv bmx5IHN1cHBvcnRzIGF1ZGlvLg0KPiAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfCAgICAgICAgICAg ICAgICAgICAgIHwgU1VCU0NSSUJFIHJlZyAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0K PiAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAg ICAgICAgICAgICAgICAgfA0KPiAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgMjAwIE9LICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfCAgICAgICAgICAgICAg ICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgfA0KPiAg ICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgfA0KPiAgICAgfCBTVUJTQ1JJQkUgcmVnICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAg fCAyMDAgT0sgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfA0KPiAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS18ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfCAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfCAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgfA0KPiBUaGUgc2NlbmFyaW8gc3RhcnRzIHdpdGggYW4gYXVkaW8gY2FsbCBmcm9tIEJv YiB0byBBbGljZQ0KPiAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfCAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICB8IElOVklURSBBbGljZSBbQXVkaW9dfA0KPiAgICAgfCAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0t LS0tLS0tfA0KPiAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgSU5WSVRFIEFsaWNlIFtBdWRp b118ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfCAgICAgICAgICAgICAgICAgICAgIHw8 LS0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfCBJTlZJ VEUgQWxpY2UgW0F1ZGlvXXwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgfA0KPiAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18 ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KPiBMZXQncyBhc3N1bWUg dGhhdCBBbGljZSB1c2VkIGhlciBQQyB0byBhbnN3ZXIgdGhlIGNhbGwgDQo+ICAgICB8ICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICB8DQo+ICAgICB8IFJFRkVSIFJlZmVyLVRvOiB1cm46c2lwLWFjdGlvbjpjYWxsOmFuc3dlciAg ICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8IDIwMCBPSyAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8 DQo+ICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfCAyMDAgT0sgW0F1ZGlvXSAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAg ICAgICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgIHwgMjAwIE9LIFtBdWRpb10gICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+ICAg ICB8IENBTkNFTCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICB8DQo+ICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLXwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8 ICAgICAgICAgICAgICAgICAgICAgfDwtLS1kaWFsb2cxLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLT58DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAg fDw9PT09PT1hdWRpbz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT58DQo+ICAgICB8ICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICB8DQo+IA0KPiAoKikNCj4gDQo+ICAgICB8ICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8 DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+IFRoZSBmb2xsb3dpbmcgaXMg YSByZS1JTlZJVEUgZnJvbSB0aGUgcmVtb3RlIHBhcnR5IChCb2IpIHRvIGFkZCB2aWRlbyANCj4g dG8gdGhlIGV4aXN0aW5nIGF1ZGlvIGNhbGwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCBJTlZJVEUgQWxpY2UgW0Ev Vl0gIHwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg fDwtLS0tLS0tLS0tLS0tLS0tLS0tLXwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8IElO VklURSBBbGljZSBbQS9WXSAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgICAgICAg ICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgICAgICAg IHwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8IDEwMCBUcnlpbmcgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8LS0tLS0t LS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAxMDAgVHJ5aW5nICAgICAgICAgIHwN Cj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfC0tLS0t LS0tLS0tLS0tLS0tLS0tPnwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gVGhlIERlc2sgUGhvbmUgY2Fu bm90IGhhbmRsZSB2aWRlbywgYnV0IGl0IGtub3dzIHRoYXQgdGhlIFBDIGNhbiBoYW5kbGUNCj4g dmlkZW8sIHNvIHRoZSBEZXNrIFBob25lIGluaXRpYXRlcyBhIG5ldyB2aWRlbyBJTlZJVEUgdG8g dGhlIFBDLg0KPiAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfCBJTlZJVEUgW1ZpZGVvXSAgICAgIHwg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfDwtLS0t LS0tLS0tLS0tLS0tLS0tLXwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgfA0KPiAgICAgfCAxODAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgfCAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg fA0KPiBUaGUgdXNlciBjYW4gZWl0aGVyIGFuc3dlciB0aGUgdmlkZW8gY2FsbCB1c2luZyBoaXMg UEMsIG9yIGhpcyBEZXNrIA0KUGhvbmUuDQo+IElmIHRoZSB1c2VyIGNob3NlIHRvIGFuc3dlciB0 aGUgaW5jb21pbmcgdmlkZW8gY2FsbCB1c2luZyBoaXMgRGVzayANClBob25lLA0KPiB0aGUgZm9s bG93aW5nIFJFRkVSIHdpbGwgYmUgc2VudCB0byB0aGUgUEM6DQo+ICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ ICAgICB8IFJFRkVSIFJlZmVyLVRvOiB1cm46c2lwLWFjdGlvbjpjYWxsOmFuc3dlciAgICAgICAg ICAgICAgICAgICAgICB8DQo+ICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8IDIwMCBPSyAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAg ICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8IDIwMCBPSyBbVmlkZW9dICAg ICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8 LS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAg fCAyMDAgT0sgW0EvVl0gICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8ICAg ICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICAg ICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg IHwgMjAwIE9LIFtBL1ZdICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+ICAgICB8ICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICB8DQo+ICAgICB8PC0tLS1kaWFsb2cyLS0tLS0tLS0+fDwtLS1kaWFsb2cxLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAg ICAgICAgICAgICAgfDw9PT09PT1hdWRpbz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT58 DQo+ICAgICB8PD09PT09PT09PT09PT09PT09PT09PT09PT09PT12aWRlbz09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT58DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQo+ IA0KPiANCj4gDQo+IE5vdyBsZXQncyBhc3N1bWUgdGhhdCBBbGljZSBpcyB0aGUgc2lkZSB0aGF0 IHdhbnRzIHRvIGFkZCB2aWRlbyB0byB0aGUgDQo+IGV4aXN0aW5nIGF1ZGlvIGNhbGwuIFRoZSBz Y2VuYXJpbyBjb250aW51ZXMgYWZ0ZXIgdGhlICgqKSBhYm92ZS4NCj4gDQo+IEFsaWNlIHVzZXMg aGVyIFBDIGFuZCBhdHRlbXB0IHRvIGluaXRpYXRlIGEgbmV3IHZpZGVvIGNhbGwuIEJlY2F1c2Ug dGhlIA0KPiBQQyBpcyBhd2FyZSB0aGF0IGFub3RoZXIgZGV2aWNlIGlzIGxvZ2dlZCBpbiB1c2lu ZyB0aGUgc2FtZSBBT1IsIGl0IHdpbGwNCj4gdHJ5IHRvIGZpbmQgaWYgdGhlcmUgaXMgYW55IGV4 aXN0aW5nIGRpYWxvZyBvbiB0aGUgb3RoZXIgZGV2aWNlIGJ5IA0KPiBzdWJzY3JpYmluZyB0byB0 aGUgZGlhbG9nIGV2ZW50IHBhY2thZ2UNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgU1VCU0NS SUJFIGRpYWxvZyAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg IHwNCj4gICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgMjAwIE9LICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHw8LS0tLS0tLS0t LS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwN Cj4gICAgIHwgTk9USUZZICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgIHwNCj4gICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgT0sgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4g ICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgIHwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gVGhlIFBDIGRpc2NvdmVycyB0aGF0 IHRoZXJlIGlzIGFuIGV4aXN0aW5nIGRpYWxvZyBiZXR3ZWVuIHRoZSBEZXNrIFBob25lIA0KDQo+ IGFuZCBCb2IgYW5kIHByZXNlbnQgdGhpcyB0byBBbGljZSBmb3IgaGVyIHRvIGNob29zZSBpZiBz aGUgd2FudHMgdG8gDQo+IGF0dGFjaCB0aGUgbmV3IHZpZGVvIGNhbGwgdG8gdGhlIGV4aXN0aW5n IGF1ZGlvIGNhbGwgb3Igbm90LiBJbiB0aGlzIA0KPiBjYXNlIEFsaWNlIGNob3NlIHRvIGF0dGFj aCB0aGUgbmV3IHZpZGVvIGNhbGwgdG8gdGhlIGV4aXN0aW5nIGF1ZGlvIGNhbGwNCj4gICAgIHwg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgIHwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgSU5WSVRFIFtWaWRlb10gICAgICB8 ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgICAg ICAgIFRhcmdldC1EaWFsb2c6IGRpYWxvZzEgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgIHwNCj4gICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgMTAwICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHw8LS0tLS0t LS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg IHwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8IHJlLUlOVklURSBbQS9WXSAgICAgfCAg ICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8LS0tLS0t LS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCByZS1JTlZJVEUgW0EvVl0gICAgIHwN Cj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfC0tLS0t LS0tLS0tLS0tLS0tLS0tPnwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgfCAyMDAgT0sgW0EvVl0gICAgICAgIHwNCj4gICAgIHwgICAgICAgICAgICAg ICAgICAgICB8IDIwMCBPSyBbQS9WXSAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLXwNCj4g ICAgIHwgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAg ICAgICAgICAgICAgIHwNCj4gICAgIHwgMjAwIE9LIFtWaWRlb10gICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHw8LS0tLS0tLS0tLS0tLS0t LS0tLS18ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAg IHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgIHwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHw8LS0tLWRpYWxvZzItLS0tLS0t LT58PC0tLWRpYWxvZzEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCj4gICAgIHwg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgIHwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8PD09PT09PWF1ZGlvPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PnwNCj4gICAgIHw8PT09PT09PT09PT09PT09PT09PT09 PT09PT09PXZpZGVvPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PnwNCj4gICAgIHwgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgIHwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCj4gDQo+IA0KPiBSZWdh cmRzLA0KPiAgUmlmYWF0DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBzcGxpY2VzIG1haWxpbmcgbGlzdA0KPiBzcGxpY2VzQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3BsaWNlcw0KPiANCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS4NCg== --=_alternative 001882DD4825787D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIGJhc2Ugb2YgdGhlIGhhbmRsaW5n IG9uZSBzZXNzaW9uDQpiZXR3ZWVuIHR3byA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5zZXBhcmF0 ZSBkZXZpY2VzPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPg0KaXMg dG8gY29vcmRpbmF0ZSB0aGUgdHdvIDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPnNlcGFyYXRlIGRl dmljZXM8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Lg0KPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Db21wYXJpbmcgd2l0 aCB0aGUgM3BjYywgcmVmZXIgYWN0aW9uKGRyYWZ0LXl1c2VmLWRpc3BhdGNoLWFjdGlvbi1yZWYt MDApDQppcyBhIG5ldyB3YXkuIEFuZCBJIHRoaW5rIGl0IGlzIGludGVyZXN0aW5nLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QnV0IGNvbnNpZGVyaW5n IEFsaWNlIGNhbiBoYW5kbGUgdGhlDQp0d28gPC9mb250Pjx0dD48Zm9udCBzaXplPTI+ZGV2aWNl czwvZm9udD48L3R0Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4NCmF0IHRoZSBzYW1l IHRpbWUsIEkgdGhpbmsgQWxpY2UgY2FuIGFuc3dlciB0aGUgY2FsbCB1c2luZyBQQyB3aXRob3V0 IHRoZQ0KcmVmZXItYWN0aW9uIGluZGljYXRpb24gYnkgdGhlIGRlc2sgcGhvbmUuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGVuLCBkdXJpbmcgdGhl IGFkZGluZyB2aWRlbyBzdHJlYW0NCnN0YWdlLCBBbGljZSdzIGRlc2sgcGhvbmUgc2VuZCBJTlZJ VEUod2l0aCB2aWRlbykgdG8gQWxpY2UncyBQQy4gSSB0aGluaw0KQWxpY2UgUEMgY2FuIGFjY2Vw dCB0aGUgSU5WSVRFIHJlcXVlc3QgYnkgQWxpY2UncyBtYW51YWwgYWN0aW9uLCB3aGlsZQ0Kbm90 IGJ5IHRoZSByZWZlci1hY3Rpb24gaW5kaWNhdGlvbi4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5PbmUgZGlzY3Vzc2lvbiBoZXJlOiB0aGUgSU5WSVRF IHNlbnQNCmJ5IEFsaWNlJ3MgZGVzayBwaG9uZSB3b3VsZCBtYWtlIHRoZSBTRFAgZnJvbSBCb2In cyBSZS1JTlZJVEUuIFRoaXMgaXMNCnNvbWV0aGluZyBsaWtlIDNwY2MsIGEgc2ltcGxlIGRlc2sg cGhvbmUgY2FuIG5vdCBoYXZlIHN1Y2ggZmVhdHVyZS4gU28sDQp3aGVuIHRoZSBzZXNzaW9uIGhh cyBiZWVuIGFuY2hvcmVkIG9uIHNvbWUgdHJhZGl0aW9uYWwgU0lQIGRlc2sgcGhvbmUsDQpBUygz cGNjKSBzZWFtcyBNVVNUIGJlIG5lZWQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj5zcGxpY2VzLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDExLTA0LTIzIDAwOjAyOjU2Ojxi cj4NCjxicj4NCiZndDsgSGksPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgd291bGQgbGlrZSB0byBk aXNjdXNzIHRoZSBmb2xsb3dpbmcgcHJvcG9zYWwgZm9yIGFkZHJlc3NpbmcgdGhlDQo8YnI+DQom Z3Q7IHNjZW5hcmlvIG9mIGFuc3dlcmluZyBhIGNhbGwgdXNpbmcgdHdvIHNlcGFyYXRlIGRldmlj ZXM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0FsaWNlICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEFs aWNlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtQcm94eQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtCb2I8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgUEMgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgRGVzayBQaG9uZSAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfDxicj4N CiZndDsgQm90aCBBbGljZSdzIGRldmljZXMgc3Vic2NyaWJlIHRvIHRoZSByZWcgZXZlbnQgcGFj a2FnZSwgd2hpY2ggYWxsb3dzDQplYWNoIDxicj4NCiZndDsgZGV2aWNlIHRvIGRpc2NvdmVyIHRo ZSBjYXBhYmlsaXRpZXMgb2YgdGhlIG90aGVyIGRldmljZSBiYXNlZCBvbiB0aGUNCjxicj4NCiZn dDsgZmVhdHVyZSB0YWdzIHByb3ZpZGVkIGJ5IGVhY2ggZGV2aWNlLjxicj4NCiZndDsgVGhlIERl c2sgUGhvbmUga25vd3MgdGhhdCB0aGUgUEMgc3VwcG9ydHMgVmlkZW8sIHdoaWxlIHRoZSBQQyBr bm93cw0KdGhhdDxicj4NCiZndDsgdGhlIERlc2sgUGhvbmUgb25seSBzdXBwb3J0cyBhdWRpby48 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg fCBTVUJTQ1JJQkUgcmVnICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8LS0tLS0tLS0tLS0tLS0tLS0t LS0mZ3Q7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7IHwgMjAwIE9LICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3wNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8IFNVQlNDUklCRSByZWcgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0mZ3Q7fCAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAyMDAgT0sg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fA0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHwNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwmbHQ7LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyBUaGUgc2NlbmFyaW8g c3RhcnRzIHdpdGggYW4gYXVkaW8gY2FsbCBmcm9tIEJvYiB0byBBbGljZTxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgfCBJTlZJVEUgQWxpY2UgW0F1ZGlvXXw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfDxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCBJTlZJVEUgQWxpY2UgW0F1ZGlv XXwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgfCBJTlZJVEUgQWxpY2UgW0F1ZGlvXXwgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 IHw8YnI+DQomZ3Q7IExldCdzIGFzc3VtZSB0aGF0IEFsaWNlIHVzZWQgaGVyIFBDIHRvIGFuc3dl ciB0aGUgY2FsbCAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgfCBSRUZFUiBSZWZlci1UbzogdXJuOnNpcC1hY3Rpb246Y2FsbDphbnN3ZXIgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0t LS0tLS0tLSZndDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgfCAyMDAgT0sgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgfCAyMDAgT0sgW0F1ZGlvXSAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8LS0t LS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8IDIwMCBPSyBbQXVkaW9dICZu YnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IHwgQ0FOQ0VMICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3wNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLXwgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7IHwmbHQ7LS0tZGlhbG9nMS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0mZ3Q7fDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyB8Jmx0Oz09PT09PWF1ZGlvPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Jmd0O3w8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IDxicj4NCiZndDsgKCopPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7IFRoZSBmb2xsb3dpbmcg aXMgYSByZS1JTlZJVEUgZnJvbSB0aGUgcmVtb3RlIHBhcnR5IChCb2IpIHRvIGFkZCB2aWRlbw0K PGJyPg0KJmd0OyB0byB0aGUgZXhpc3RpbmcgYXVkaW8gY2FsbDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCBJ TlZJVEUgQWxpY2UgW0EvVl0gJm5ic3A7fDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8IElOVklURSBBbGljZSBbQS9WXSAm bmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLXwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8IDEwMCBUcnlpbmcgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyB8IDEwMCBUcnlpbmcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8 LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyBUaGUg RGVzayBQaG9uZSBjYW5ub3QgaGFuZGxlIHZpZGVvLCBidXQgaXQga25vd3MgdGhhdCB0aGUgUEMg Y2FuIGhhbmRsZTxicj4NCiZndDsgdmlkZW8sIHNvIHRoZSBEZXNrIFBob25lIGluaXRpYXRlcyBh IG5ldyB2aWRlbyBJTlZJVEUgdG8gdGhlIFBDLjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IHwgSU5WSVRFIFtWaWRlb10gJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCZsdDst LS0tLS0tLS0tLS0tLS0tLS0tLXwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyB8IDE4MCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgfCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyBU aGUgdXNlciBjYW4gZWl0aGVyIGFuc3dlciB0aGUgdmlkZW8gY2FsbCB1c2luZyBoaXMgUEMsIG9y IGhpcyBEZXNrDQpQaG9uZS48YnI+DQomZ3Q7IElmIHRoZSB1c2VyIGNob3NlIHRvIGFuc3dlciB0 aGUgaW5jb21pbmcgdmlkZW8gY2FsbCB1c2luZyBoaXMgRGVzaw0KUGhvbmUsPGJyPg0KJmd0OyB0 aGUgZm9sbG93aW5nIFJFRkVSIHdpbGwgYmUgc2VudCB0byB0aGUgUEM6PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCBSRUZFUiBSZWZlci1UbzogdXJuOnNpcC1hY3Rp b246Y2FsbDphbnN3ZXIgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAyMDAgT0sgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyB8IDIwMCBPSyBbVmlkZW9dICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwt LS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg fCAyMDAgT0sgW0EvVl0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0t LS0tLS0tLSZndDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgMjAwIE9LIFtBL1ZdICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3w8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyB8LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8 PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwmbHQ7LS0tLWRpYWxvZzItLS0tLS0tLSZndDt8Jmx0 Oy0tLWRpYWxvZzEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCZsdDs9PT09 PT1hdWRpbz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSZndDt8PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7IHwmbHQ7PT09PT09PT09PT09PT09PT09PT09PT09PT09PXZpZGVvPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Jmd0O3w8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IDxicj4NCiZndDsgTm93IGxldCdzIGFzc3VtZSB0aGF0IEFsaWNlIGlzIHRoZSBzaWRl IHRoYXQgd2FudHMgdG8gYWRkIHZpZGVvIHRvDQp0aGUgPGJyPg0KJmd0OyBleGlzdGluZyBhdWRp byBjYWxsLiBUaGUgc2NlbmFyaW8gY29udGludWVzIGFmdGVyIHRoZSAoKikgYWJvdmUuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEFsaWNlIHVzZXMgaGVyIFBDIGFuZCBhdHRlbXB0IHRvIGluaXRpYXRl IGEgbmV3IHZpZGVvIGNhbGwuIEJlY2F1c2UNCnRoZSA8YnI+DQomZ3Q7IFBDIGlzIGF3YXJlIHRo YXQgYW5vdGhlciBkZXZpY2UgaXMgbG9nZ2VkIGluIHVzaW5nIHRoZSBzYW1lIEFPUiwgaXQNCndp bGw8YnI+DQomZ3Q7IHRyeSB0byBmaW5kIGlmIHRoZXJlIGlzIGFueSBleGlzdGluZyBkaWFsb2cg b24gdGhlIG90aGVyIGRldmljZSBieQ0KPGJyPg0KJmd0OyBzdWJzY3JpYmluZyB0byB0aGUgZGlh bG9nIGV2ZW50IHBhY2thZ2U8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyB8IFNVQlNDUklCRSBkaWFsb2cgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8LS0tLS0tLS0tLS0tLS0tLS0tLS0m Z3Q7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7IHwgMjAwIE9LICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3wNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgTk9USUZZICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0t fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 IHwgT0sgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgVGhlIFBDIGRpc2NvdmVy cyB0aGF0IHRoZXJlIGlzIGFuIGV4aXN0aW5nIGRpYWxvZyBiZXR3ZWVuIHRoZSBEZXNrDQpQaG9u ZSA8YnI+DQomZ3Q7IGFuZCBCb2IgYW5kIHByZXNlbnQgdGhpcyB0byBBbGljZSBmb3IgaGVyIHRv IGNob29zZSBpZiBzaGUgd2FudHMgdG8NCjxicj4NCiZndDsgYXR0YWNoIHRoZSBuZXcgdmlkZW8g Y2FsbCB0byB0aGUgZXhpc3RpbmcgYXVkaW8gY2FsbCBvciBub3QuIEluIHRoaXMNCjxicj4NCiZn dDsgY2FzZSBBbGljZSBjaG9zZSB0byBhdHRhY2ggdGhlIG5ldyB2aWRlbyBjYWxsIHRvIHRoZSBl eGlzdGluZyBhdWRpbw0KY2FsbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHw8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCBJTlZJVEUgW1ZpZGVvXSAmbmJzcDsgJm5ic3A7ICZuYnNw O3wgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RhcmdldC1EaWFsb2c6IGRpYWxvZzENCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAxMDAg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgcmUtSU5WSVRFIFtB L1ZdICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7IHwgcmUtSU5WSVRFIFtBL1ZdICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0t LSZndDt8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgfCAyMDAgT0sgW0EvVl0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAyMDAgT0sgW0EvVl0gJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLXw8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8IDIwMCBPSyBbVmlkZW9dICZu YnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwmbHQ7LS0tLWRpYWxvZzItLS0tLS0tLSZndDt8Jmx0Oy0t LWRpYWxvZzEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgfDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCZsdDs9PT09PT1h dWRpbz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSZndDt8PGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IHwmbHQ7PT09PT09PT09PT09PT09PT09PT09PT09PT09PXZpZGVvPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Jmd0O3w8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8 PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRz LDxicj4NCiZndDsgJm5ic3A7UmlmYWF0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzcGxpY2VzIG1h aWxpbmcgbGlzdDxicj4NCiZndDsgc3BsaWNlc0BpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGxpY2VzPGJyPg0KJmd0OyA8YnI+DQo8L2Zv bnQ+PC90dD4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkm bmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJz cDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0 eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7 VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRp YWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtv YmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNw O2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0 aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJz cDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNw O2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtj b25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZu YnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29y Jm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2Fk ZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3Ro aXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkm bmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZu YnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7 bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5i c3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7 YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 001882DD4825787D_=-- From pkyzivat@cisco.com Mon Apr 25 05:44:15 2011 Return-Path: X-Original-To: splices@ietfc.amsl.com Delivered-To: splices@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B1A5DE06CF for ; Mon, 25 Apr 2011 05:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.933 X-Spam-Level: X-Spam-Status: No, score=-108.933 tagged_above=-999 required=5 tests=[AWL=-1.384, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNcK5+uwDEnh for ; Mon, 25 Apr 2011 05:44:14 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 3C02CE06B8 for ; Mon, 25 Apr 2011 05:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=8855; q=dns/txt; s=iport; t=1303735454; x=1304945054; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=3P8ER9etkKZkJA/VkVIA1AD6nM5Ni6GM4PiT2VY9jG0=; b=jErrSVysOEPRxb1zje8SqiGbY8mX89TRZSqyDHUR0ebkFp5eIiBotPxh wceZlB1HnaCDk/SxiRbr61MXoUsReIatDjWG3065uFmEBWMuj79F53xfi dM77qqQf/SrUJQykcML4+HLdC67b+xq9hbvhYQURaQ3EGT/8Shg/hJXT6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHRrtU2tJV2a/2dsb2JhbACET6Bld4hwnB+LWgiQIwKBI4NQgQEEhVSIYYQI X-IronPort-AV: E=Sophos;i="4.64,265,1301875200"; d="scan'208";a="301350390" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-3.cisco.com with ESMTP; 25 Apr 2011 12:44:13 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3PCiC1D029088 for ; Mon, 25 Apr 2011 12:44:12 GMT Message-ID: <4DB56C9C.1080004@cisco.com> Date: Mon, 25 Apr 2011 08:44:12 -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: splices@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit 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, 25 Apr 2011 12:44:15 -0000 On 4/25/2011 12:26 AM, gao.yang2@zte.com.cn wrote: > > Hi, > > The base of the handling one session between two separate devicesis to > coordinate the two separate devices. > > Comparing with the 3pcc, refer > action(draft-yusef-dispatch-action-ref-00) is a new way. And I think it > is interesting. > > But considering Alice can handle the two devicesat the same time, I > think Alice can answer the call using PC without the refer-action > indication by the desk phone. I'm not sure what you mean here. In the original scenario, I think "Alice answers the call using the PC" means that Alice interacts with the PC in order to cause the desk phone to answer. Without using something like refer-action, the PC could only answer the call itself, thus putting audio on the PC rather than the phone. That's fine if its what Alice wants, but its a different scenario. > Then, during the adding video stream stage, Alice's desk phone send > INVITE(with video) to Alice's PC. I think Alice PC can accept the INVITE > request by Alice's manual action, while not by the refer-action indication. Yes, that is certainly possible. What is tricky is what appears on the UI of the PC in this circumstance. Some possibilities: - appears as a "normal" (new) video call from Alice - appears as a "normal" (new) video call from Bob - appears as something special - a request for video support from the desk phone. To get this to be anything but the first of the above will require *something* we don't currently have. > One discussion here: the INVITE sent by Alice's desk phone would make > the SDP from Bob's Re-INVITE. This is something like 3pcc, Yes. > a simple desk > phone can not have such feature. So, when the session has been anchored > on some traditional SIP desk phone, AS(3pcc) seams MUST be need. *something* with the intelligence to coordinate multiple devices, and with an awareness of what devices are available to be coordinated, must be present. Anybody who wants such a capability will need to arrange to have a suitable device available. It could be a UA owned by the user (e.g. a PC with sufficient software, or a smart phone), or it could be a service residing at or near the user's registrar. In this respect it isn't much different from an answering machine. Thanks, Paul > Thanks, > > Gao > > > splices-bounces@ietf.org дÓÚ 2011-04-23 00:02:56: > > > Hi, > > > > I would like to discuss the following proposal for addressing the > > scenario of answering a call using two separate devices: > > > > > > 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 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 answer the call > > | | | | > > | REFER Refer-To: urn:sip-action:call:answer | > > |-------------------->| | | > > | 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 > > | | | | > > | | | INVITE Alice [A/V] | > > | | |<--------------------| > > | | INVITE 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. > > | | | | > > | INVITE [Video] | | | > > |<--------------------| | | > > | 180 | | | > > |-------------------->| | | > > | | | | > > The user can either answer the video call using his PC, or his Desk > Phone. > > If the user chose to answer the incoming video call using his Desk Phone, > > the following REFER will be sent to 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 uses her PC and attempt to initiate a new video call. Because the > > PC is aware that another device is logged in using the same AOR, it will > > try to find if there is any existing dialog on the other device by > > subscribing to the dialog event package > > | | | | > > | SUBSCRIBE dialog | | | > > |-------------------->| | | > > | 200 OK | | | > > |<--------------------| | | > > | NOTIFY | | | > > |<--------------------| | | > > | OK | | | > > |-------------------->| | | > > | | | | > > The PC discovers 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 > > attach the new video call to the existing audio call or not. In this > > case Alice chose to attach the new video call to the existing audio call > > | | | | > > | | | | > > | INVITE [Video] | | | > > | Target-Dialog: dialog1 | | > > |-------------------->| | | > > | 100 | | | > > |<--------------------| | | > > | | re-INVITE [A/V] | | > > | |-------------------->| | > > | | | re-INVITE [A/V] | > > | | |-------------------->| > > | | | 200 OK [A/V] | > > | | 200 OK [A/V] |<--------------------| > > | |<--------------------| | > > | 200 OK [Video] | | | > > |<--------------------| | | > > | | | | > > | | | | > > |<----dialog2-------->|<---dialog1------------------------------->| > > | | | | > > | |<======audio==============================>| > > |<============================video==============================>| > > | | | | > > | | | | > > | | | | > > > > > > Regards, > > Rifaat > > > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > > > > -------------------------------------------------------- > 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. > > > > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices From john.elwell@siemens-enterprise.com Wed Apr 27 05:09: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 A439AE0727 for ; Wed, 27 Apr 2011 05:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.784 X-Spam-Level: X-Spam-Status: No, score=-104.784 tagged_above=-999 required=5 tests=[AWL=1.815, 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 0hOj26J72b0M for ; Wed, 27 Apr 2011 05:09:37 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 6176AE06EF for ; Wed, 27 Apr 2011 05:09:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1303906169!11758588!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 22913 invoked from network); 27 Apr 2011 12:09:29 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-15.tower-174.messagelabs.com with SMTP; 27 Apr 2011 12:09:29 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 3AE0623F03DB; Wed, 27 Apr 2011 14:09:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 27 Apr 2011 14:09:29 +0200 From: "Elwell, John" To: "Shekh-Yusef, Rifaat (Rifaat)" , "splices@ietf.org" Date: Wed, 27 Apr 2011 14:09:28 +0200 Thread-Topic: Answering a Call Using Two Separate Devices proposal Thread-Index: AcwBBr5eBSB77KQiR06UQA3Gynn7EADtu8/g Message-ID: References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@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: 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: Wed, 27 Apr 2011 12:09:41 -0000 Rifaat, This involves sending SIP requests (REFER, INVITE, SUBSCRIBE) directly betw= een Alice's two devices. What about NAT and firewall issues, if the two dev= ices are not in the same network area? For example, phone on 3G, PC on WiFi= ? Don't the requests need to go via a proxy? John=20 > -----Original Message----- > From: splices-bounces@ietf.org=20 > [mailto:splices-bounces@ietf.org] On Behalf Of Shekh-Yusef,=20 > Rifaat (Rifaat) > Sent: 22 April 2011 17:03 > To: splices@ietf.org > Subject: [splices] Answering a Call Using Two Separate=20 > Devices proposal >=20 > Hi, >=20 > I would like to discuss the following proposal for addressing=20 > the scenario of answering a call using two separate devices: >=20 >=20 > Alice Alice Proxy =20 > Bob > PC Desk Phone =20 > =20 > | | | =20 > | > | | | =20 > | > Both Alice's devices subscribe to the reg event package,=20 > which allows each=20 > device to discover the capabilities of the other device based on the=20 > feature tags provided by each device. > The Desk Phone knows that the PC supports Video, while the PC=20 > knows that > the Desk Phone only supports audio. > | | | =20 > | > | | SUBSCRIBE reg | =20 > | > | |-------------------->| =20 > | > | | 200 OK | =20 > | > | |<--------------------| =20 > | > | | | =20 > | > | SUBSCRIBE reg | | =20 > | > |------------------------------------------>| =20 > | > | 200 OK | | =20 > | > |<------------------------------------------| =20 > | > | | | =20 > | > | | | =20 > | > The scenario starts with an audio call from Bob to Alice > | | | =20 > | > | | | INVITE=20 > Alice [Audio]| > | | =20 > |<--------------------| > | | INVITE Alice [Audio]| =20 > | > | |<--------------------| =20 > | > | INVITE Alice [Audio]| | =20 > | > |<------------------------------------------| =20 > | > | | | =20 > | > Let's assume that Alice used her PC to answer the call =20 > | | | =20 > | > | REFER Refer-To: urn:sip-action:call:answer =20 > | > |-------------------->| | =20 > | > | 200 OK | | =20 > | > |<--------------------| | =20 > | > | | | =20 > | > | | 200 OK [Audio] | =20 > | > | |-------------------->| =20 > | > | | | 200 OK=20 > [Audio] | > | | =20 > |-------------------->| > | CANCEL | | =20 > | > |<------------------------------------------| =20 > | > | | | =20 > | > | =20 > |<---dialog1------------------------------->| > | | | =20 > | > | =20 > |<=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 > | > =20 > (*) >=20 > | | | =20 > | > | | | =20 > | > | | | =20 > | > The following is a re-INVITE from the remote party (Bob) to add video=20 > to the existing audio call > | | | =20 > | > | | | INVITE=20 > Alice [A/V] | > | | =20 > |<--------------------| > | | INVITE Alice [A/V] | =20 > | > | |<--------------------| =20 > | > | | 100 Trying | =20 > | > | |-------------------->| =20 > | > | | | 100 Trying =20 > | > | | =20 > |-------------------->| > | | | =20 > | > The Desk Phone cannot handle video, but it knows that the PC=20 > can handle > video, so the Desk Phone initiates a new video INVITE to the PC. > | | | =20 > | > | INVITE [Video] | | =20 > | > |<--------------------| | =20 > | > | 180 | | =20 > | > |-------------------->| | =20 > | > | | | =20 > | > The user can either answer the video call using his PC, or=20 > his Desk Phone. > If the user chose to answer the incoming video call using his=20 > Desk Phone, > the following REFER will be sent to the PC: > | | | =20 > | > | REFER Refer-To: urn:sip-action:call:answer =20 > | > |<--------------------| | =20 > | > | 200 OK | | =20 > | > |-------------------->| | =20 > | > | | | =20 > | > | 200 OK [Video] | | =20 > | > |-------------------->| | =20 > | > | | | =20 > | > | | 200 OK [A/V] | =20 > | > | |-------------------->| =20 > | > | | | 200 OK=20 > [A/V] | > | | =20 > |-------------------->| > | | | =20 > | > =20 > |<----dialog2-------->|<---dialog1------------------------------->| > | | | =20 > | > | =20 > |<=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 > |<=3D=3D=3D=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 >=20 > =20 > Now let's assume that Alice is the side that wants to add=20 > video to the=20 > existing audio call. The scenario continues after the (*) above. >=20 > Alice uses her PC and attempt to initiate a new video call.=20 > Because the=20 > PC is aware that another device is logged in using the same=20 > AOR, it will > try to find if there is any existing dialog on the other device by=20 > subscribing to the dialog event package > | | | =20 > | > | SUBSCRIBE dialog | | =20 > | > |-------------------->| | =20 > | > | 200 OK | | =20 > | > |<--------------------| | =20 > | > | NOTIFY | | =20 > | > |<--------------------| | =20 > | > | OK | | =20 > | > |-------------------->| | =20 > | > | | | =20 > | > The PC discovers that there is an existing dialog between the=20 > Desk Phone=20 > and Bob and present this to Alice for her to choose if she wants to=20 > attach the new video call to the existing audio call or not. In this=20 > case Alice chose to attach the new video call to the existing=20 > audio call > | | | =20 > | > | | | =20 > | > | INVITE [Video] | | =20 > | > | Target-Dialog: dialog1 | =20 > | > |-------------------->| | =20 > | > | 100 | | =20 > | > |<--------------------| | =20 > | > | | re-INVITE [A/V] | =20 > | > | |-------------------->| =20 > | > | | | re-INVITE=20 > [A/V] | > | | =20 > |-------------------->| > | | | 200 OK=20 > [A/V] | > | | 200 OK [A/V] =20 > |<--------------------| > | |<--------------------| =20 > | > | 200 OK [Video] | | =20 > | > |<--------------------| | =20 > | > | | | =20 > | > | | | =20 > | > =20 > |<----dialog2-------->|<---dialog1------------------------------->| > | | | =20 > | > | =20 > |<=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 > |<=3D=3D=3D=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 > | >=20 >=20 > Regards, > Rifaat >=20 > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices > = From rifatyu@avaya.com Wed Apr 27 08:49: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 18502E0831 for ; Wed, 27 Apr 2011 08:49:43 -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, J_CHICKENPOX_64=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 GUgK0WWce0wl for ; Wed, 27 Apr 2011 08:49:42 -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 9A445E0839 for ; Wed, 27 Apr 2011 08:49:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBAN05uE2HCzI1/2dsb2JhbACXf41td6k0Apo+hXYEkn+KGg X-IronPort-AV: E=Sophos;i="4.64,274,1301889600"; d="scan'208";a="243631941" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Apr 2011 11:49:37 -0400 X-IronPort-AV: E=Sophos;i="4.64,274,1301889600"; d="scan'208";a="643944122" Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Apr 2011 11:49:36 -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, 27 Apr 2011 11:49:36 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat , "splices@ietf.org" Date: Wed, 27 Apr 2011 11:49:34 -0400 Thread-Topic: [splices] Answering a Call Using Two Separate Devices proposal Thread-Index: AcwDRn/GbooctIxRQ+OggswrBOb+BgBINPyg Message-ID: <6369CB70BFD88942B9705AC1E639A33822CB26E13D@DC-US1MBEX4.global.avaya.com> References: <4DB56C9C.1080004@cisco.com> In-Reply-To: <4DB56C9C.1080004@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: Wed, 27 Apr 2011 15:49:43 -0000 > -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behal= f Of > Paul Kyzivat > Sent: Monday, April 25, 2011 8:44 AM > To: splices@ietf.org > Subject: Re: [splices] Answering a Call Using Two Separate Devices propos= al >=20 >=20 > On 4/25/2011 12:26 AM, gao.yang2@zte.com.cn wrote: > > > > > > Then, during the adding video stream stage, Alice's desk phone send > > INVITE(with video) to Alice's PC. I think Alice PC can accept the INVIT= E > > request by Alice's manual action, while not by the refer-action indicat= ion. >=20 > Yes, that is certainly possible. > What is tricky is what appears on the UI of the PC in this circumstance. > Some possibilities: > - appears as a "normal" (new) video call from Alice > - appears as a "normal" (new) video call from Bob > - appears as something special - a request for video support > from the desk phone. >=20 > To get this to be anything but the first of the above will require > *something* we don't currently have. >=20 I think that we should try to achieve the second option of the 3 options yo= u listed above. How about if the PC subscribes to the Desk Phone dialog event package with = include-session-description, combined with Peter's idea of slow start INVIT= E with Join from the PC, as follows: | SUBSCRIBE Event: dialog;include-session-description | |-------------------->| | | | 200 | | | |<--------------------| | | | NOTIFY [100 Trying] | | | |<--------------------| | | | OK | | | |-------------------->| | | (*) | | | | | | | | | | | | The following is a re-INVITE from the remote party (Bob) to add video=20 to the existing audio call | | | | | | | INVITE Alice [A/V] | | | |<--------------------| | | INVITE Alice [A/V] | | | |<--------------------| | | | 100 Trying | | | |-------------------->| | | | | 100 Trying | | | |-------------------->| | | | | | | | | The PC gets a notification of the new incoming call and the fact that it=20 is video call. | NOTIFY dialog-info with session description | |<--------------------| | | | 200 OK | | | |-------------------->| | | | | | | The PC prompts the user and waits for his response. When the user=20 accepts the request, the PC initiates a slow start INVITE to the Desk=20 Phone as follows: | | | | | INVITE Join dialog1 | | | |-------------------->| | | | 200 [Video] | | | |<--------------------| | | | ACK [Video] | | | |-------------------->| | | | | 200 OK [A/V] | | | |-------------------->| | | | | 200 OK [A/V] | | | |-------------------->| | | | | Regards, Rifaat From rifatyu@avaya.com Wed Apr 27 08:57: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 B7113E070B for ; Wed, 27 Apr 2011 08:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 D1FFOjP1Sfv4 for ; Wed, 27 Apr 2011 08:57:03 -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 38D7CE06CE for ; Wed, 27 Apr 2011 08:57:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBAC88uE2HCzI1/2dsb2JhbACXf41td6khAppBAoV0BJJ/iho X-IronPort-AV: E=Sophos;i="4.64,274,1301889600"; d="scan'208";a="243633464" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Apr 2011 11:57:00 -0400 X-IronPort-AV: E=Sophos;i="4.64,274,1301889600"; d="scan'208";a="643947124" 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; 27 Apr 2011 11:57:00 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 27 Apr 2011 11:56:59 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "Elwell, John" , "splices@ietf.org" Date: Wed, 27 Apr 2011 11:56:59 -0400 Thread-Topic: Answering a Call Using Two Separate Devices proposal Thread-Index: AcwBBr5eBSB77KQiR06UQA3Gynn7EADtu8/gAA1JVDA= Message-ID: <6369CB70BFD88942B9705AC1E639A33822CB26E165@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@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 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: Wed, 27 Apr 2011 15:57:03 -0000 Hi John, I was not trying to suggest that all these requests will go directly betwee= n the devices without going through a proxy. I just did not see the need to explicitly show that because it does not add= anything to the scenario and to simplify the call flow. Regards, Rifaat =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, April 27, 2011 8:09 AM > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > Subject: RE: Answering a Call Using Two Separate Devices proposal >=20 > Rifaat, >=20 > This involves sending SIP requests (REFER, INVITE, SUBSCRIBE) directly be= tween > Alice's two devices. What about NAT and firewall issues, if the two devic= es > are not in the same network area? For example, phone on 3G, PC on WiFi? D= on't > the requests need to go via a proxy? >=20 > John >=20 > > -----Original Message----- > > From: splices-bounces@ietf.org > > [mailto:splices-bounces@ietf.org] On Behalf Of Shekh-Yusef, > > Rifaat (Rifaat) > > Sent: 22 April 2011 17:03 > > To: splices@ietf.org > > Subject: [splices] Answering a Call Using Two Separate > > Devices proposal > > > > Hi, > > > > I would like to discuss the following proposal for addressing > > the scenario of answering a call using two separate devices: > > > > > > 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 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 answer the call > > | | | > > | > > | REFER Refer-To: urn:sip-action:call:answer > > | > > |-------------------->| | > > | > > | 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 > > | | | > > | > > | | | INVITE > > Alice [A/V] | > > | | > > |<--------------------| > > | | INVITE 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. > > | | | > > | > > | INVITE [Video] | | > > | > > |<--------------------| | > > | > > | 180 | | > > | > > |-------------------->| | > > | > > | | | > > | > > The user can either answer the video call using his PC, or > > his Desk Phone. > > If the user chose to answer the incoming video call using his > > Desk Phone, > > the following REFER will be sent to 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 uses her PC and attempt to initiate a new video call. > > Because the > > PC is aware that another device is logged in using the same > > AOR, it will > > try to find if there is any existing dialog on the other device by > > subscribing to the dialog event package > > | | | > > | > > | SUBSCRIBE dialog | | > > | > > |-------------------->| | > > | > > | 200 OK | | > > | > > |<--------------------| | > > | > > | NOTIFY | | > > | > > |<--------------------| | > > | > > | OK | | > > | > > |-------------------->| | > > | > > | | | > > | > > The PC discovers 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 > > attach the new video call to the existing audio call or not. In this > > case Alice chose to attach the new video call to the existing > > audio call > > | | | > > | > > | | | > > | > > | INVITE [Video] | | > > | > > | Target-Dialog: dialog1 | > > | > > |-------------------->| | > > | > > | 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>| > > | | | > > | > > | | | > > | > > | | | > > | > > > > > > Regards, > > Rifaat > > > > _______________________________________________ > > splices mailing list > > splices@ietf.org > > https://www.ietf.org/mailman/listinfo/splices > > From pkyzivat@cisco.com Wed Apr 27 10:34: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 19553E07DA for ; Wed, 27 Apr 2011 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.191 X-Spam-Level: X-Spam-Status: No, score=-110.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_64=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 9F7QTEC8TLkh for ; Wed, 27 Apr 2011 10:34:42 -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 D56E1E07D6 for ; Wed, 27 Apr 2011 10:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=5521; q=dns/txt; s=iport; t=1303925681; x=1305135281; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MVlUmwfnedshFKdhdeqZqnVS8unaI17FwtxxGaiiHXs=; b=E6O0gFNA368hRVpUcN3I6C+cqfB+rfscWGJmfyFgjBZTaSgjL11QyKQz bZ1XOsRXqddmfBFzLUSoiwMjLC/K5NpItdL0qT/Pb1gCKfUH3aKJBgMtf GH0rm1RBThqB5xBIuufTsVgK1bjuOBSFglblKMkAAP/tP3v3AuIg1ubu3 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBADZTuE2tJV2d/2dsb2JhbACXf41td4hwnXWceIV2BI5RhBKKNg X-IronPort-AV: E=Sophos;i="4.64,275,1301875200"; d="scan'208";a="231598058" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2011 17:34:41 +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 p3RHYelP009650; Wed, 27 Apr 2011 17:34:40 GMT Message-ID: <4DB853B0.5060506@cisco.com> Date: Wed, 27 Apr 2011 13:34:40 -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> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CB26E13D@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: Wed, 27 Apr 2011 17:34:43 -0000 inline On 4/27/2011 11:49 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > >> -----Original Message----- >> From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Monday, April 25, 2011 8:44 AM >> To: splices@ietf.org >> Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal >> >> >> On 4/25/2011 12:26 AM, gao.yang2@zte.com.cn wrote: >>> >>> >>> Then, during the adding video stream stage, Alice's desk phone send >>> INVITE(with video) to Alice's PC. I think Alice PC can accept the INVITE >>> request by Alice's manual action, while not by the refer-action indication. >> >> Yes, that is certainly possible. >> What is tricky is what appears on the UI of the PC in this circumstance. >> Some possibilities: >> - appears as a "normal" (new) video call from Alice >> - appears as a "normal" (new) video call from Bob >> - appears as something special - a request for video support >> from the desk phone. >> >> To get this to be anything but the first of the above will require >> *something* we don't currently have. >> > I think that we should try to achieve the second option of the 3 options you listed above. Well, the 2nd is "better" than the first, but the third is better than the second. So if it can be achieved, all the better. > How about if the PC subscribes to the Desk Phone dialog event package with include-session-description, combined with Peter's idea of slow start INVITE with Join from the PC, as follows: > > | SUBSCRIBE Event: dialog;include-session-description | > |-------------------->| | | > | 200 | | | > |<--------------------| | | > | NOTIFY [100 Trying] | | | > |<--------------------| | | > | OK | | | > |-------------------->| | | > > (*) > | | | | > | | | | > | | | | > The following is a re-INVITE from the remote party (Bob) to add video > to the existing audio call > | | | | > | | | INVITE Alice [A/V] | > | | |<--------------------| > | | INVITE Alice [A/V] | | > | |<--------------------| | > | | 100 Trying | | > | |-------------------->| | > | | | 100 Trying | > | | |-------------------->| > | | | | > | | | | > The PC gets a notification of the new incoming call and the fact that it > is video call. > | NOTIFY dialog-info with session description | > |<--------------------| | | > | 200 OK | | | > |-------------------->| | | > | | | | > The PC prompts the user and waits for his response. When the user > accepts the request, the PC initiates a slow start INVITE to the Desk > Phone as follows: > | | | | > | INVITE Join dialog1 | | | > |-------------------->| | | > | 200 [Video] | | | > |<--------------------| | | > | ACK [Video] | | | > |-------------------->| | | Its a leap of faith here to assume that the phone will realize what it is expected to do when there is no offer in the invite. Clearly it has to offer *something*. So *maybe* when the invite has Join it will know it should offer something related to the current call. But at the least it has the option of offering either just video, or audio plus video. And in some sense it is a policy decision which it should do. I think we need to find a way to eliminate the leaps of faith, and replace with some plausible procedures coupled with some reasonable policy knobs. Thanks, Paul > | | 200 OK [A/V] | | > | |-------------------->| | > | | | 200 OK [A/V] | > | | |-------------------->| > | | | | > > > Regards, > Rifaat > > > From salvatore.loreto@ericsson.com Wed Apr 27 11:45:27 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 85AEBE077F for ; Wed, 27 Apr 2011 11:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvhfHZzDqUlL for ; Wed, 27 Apr 2011 11:45:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 52B0CE0769 for ; Wed, 27 Apr 2011 11:45:26 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-c3-4db86445bb8f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 80.26.28525.54468BD4; Wed, 27 Apr 2011 20:45:25 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 27 Apr 2011 20:45:25 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C114724D8 for ; Wed, 27 Apr 2011 21:45:24 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8A82E50CE2 for ; Wed, 27 Apr 2011 21:45:24 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0CDF250CE1 for ; Wed, 27 Apr 2011 21:45:23 +0300 (EEST) Message-ID: <4DB86443.8040008@ericsson.com> Date: Wed, 27 Apr 2011 20:45:23 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: splices@ietf.org References: <4DA762EF.60007@unina.it> <4DA88832.2090202@ericsson.com> <4DA8E177.7070908@cisco.com> In-Reply-To: <4DA8E177.7070908@cisco.com> 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] SPLICES IETF-80 meeting minutes and start of ML discussion 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, 27 Apr 2011 18:45:27 -0000 On 4/16/11 2:23 AM, Paul Kyzivat wrote: > Sal, > > On 4/15/2011 2:02 PM, Salvatore Loreto wrote: > ... >> I am interested in scenarios where both ends may be impacted by the >> implementation >> of the new mechanism to be developed; >> of course in the case an impact is required, I do think the design >> should consider a fall back for the case the other >> peer does not implement it (e.g. a legacy UA) > ... >> work of a loosely-coupled coordination scenario, >> where no single device needs to remain in the session for its entire >> duration >> and no single device needs to act as master... >> is still something that I personally find interesting to be investigated > I still don't *get* it. > > Can you lay out a scenario/use case/example of what you have in mind? > - describe to moving parts > - what interactions they have to make the case work > - what capabilities each has/expects of others > - if parts of the coordination depend on special behavior of > *people* rather than automata, explain that too. > > Nothing complicated - just very high level. what I have in mind is a scenario where a user can make or answer a Call Using Two or more separate devices; the devices can happen to be in the same network or in different area networks, however I don't want any of the devices to be a single point of failure for the call: that means that any device, involved in the side of the call (the one is using different devices to handle the call), can go out of coverage, can restart etc.etc. without having any impact on the call as such. cheers /Sal -- Salvatore Loreto www.sloreto.com From pkyzivat@cisco.com Wed Apr 27 15:43:36 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 958E0E07AE for ; Wed, 27 Apr 2011 15:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.176 X-Spam-Level: X-Spam-Status: No, score=-110.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_33=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 psN99pYQVotZ for ; Wed, 27 Apr 2011 15:43:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id C207BE07A9 for ; Wed, 27 Apr 2011 15:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2682; q=dns/txt; s=iport; t=1303944215; x=1305153815; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=9ym827+Y5wrAKa4m0oSP0zj+GNsI0/djyZ0pqevaFvE=; b=PX8RwGOv2Mae1wqJ547HXyqSTweC8mN18/OdmiNcWlYl8/PUdjaKuQer mXprjoPabb9alIWzCajwE4791g+UKuCwR3DbumAlx/g/lrds4eVTiv7YY anR5j1k9VBDFvZlu44mE0vcND2PKqt8XgY0GE4SiGXfXEsHZD2+GhtYXE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkHAOSauE2tJXG9/2dsb2JhbACYUY0ud6d8nHiFdgSOUYQSijY X-IronPort-AV: E=Sophos;i="4.64,276,1301875200"; d="scan'208";a="437726962" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2011 22:43:35 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RMhYQs011357 for ; Wed, 27 Apr 2011 22:43:35 GMT Message-ID: <4DB89C16.6080001@cisco.com> Date: Wed, 27 Apr 2011 18:43:34 -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: splices@ietf.org References: <4DA762EF.60007@unina.it> <4DA88832.2090202@ericsson.com> <4DA8E177.7070908@cisco.com> <4DB86443.8040008@ericsson.com> In-Reply-To: <4DB86443.8040008@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [splices] SPLICES IETF-80 meeting minutes and start of ML discussion 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, 27 Apr 2011 22:43:36 -0000 inline On 4/27/2011 2:45 PM, Salvatore Loreto wrote: > On 4/16/11 2:23 AM, Paul Kyzivat wrote: >> Sal, >> >> On 4/15/2011 2:02 PM, Salvatore Loreto wrote: >> ... >>> I am interested in scenarios where both ends may be impacted by the >>> implementation >>> of the new mechanism to be developed; >>> of course in the case an impact is required, I do think the design >>> should consider a fall back for the case the other >>> peer does not implement it (e.g. a legacy UA) >> ... >>> work of a loosely-coupled coordination scenario, >>> where no single device needs to remain in the session for its entire >>> duration >>> and no single device needs to act as master... >>> is still something that I personally find interesting to be investigated >> I still don't *get* it. >> >> Can you lay out a scenario/use case/example of what you have in mind? >> - describe to moving parts >> - what interactions they have to make the case work >> - what capabilities each has/expects of others >> - if parts of the coordination depend on special behavior of >> *people* rather than automata, explain that too. >> >> Nothing complicated - just very high level. > > what I have in mind is a scenario where > a user can make or answer a Call Using Two or more separate devices; > the devices can happen to be in the same network or in different area > networks, > however I don't want any of the devices to be a single point of failure > for the call: > that means that any device, involved in the side of the call > (the one is using different devices to handle the call), can go out of > coverage, can restart etc.etc. > without having any impact on the call as such. Well, maybe a little more detail that that :-) The above seems to be of the "and then magic happens" school. I presume you have in mind that the *other* party manages two separate dialogs and coordinates them. But who has the intelligence to establish the multi-device call? - know that more than two devices should be used - know how to reach the additional device - know enough about the existing call to splice it in Thanks, Paul P.S. I think a variant of the 3pcc approach we are discussing in another thread could potentially be used in your scenario too, if the main point is to manage where the failure point is. For instance, if Alice and Bob are talking, and Alice wants to add in a local display device, it could send a REFER to the display device, asking it to send and INVITE/Join to Bob. This is not so straightforward - there are many details to work out. But I find it no less plausible than any other yet-to-be-devised scheme. From john.elwell@siemens-enterprise.com Thu Apr 28 00:34: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 535DDE064A for ; Thu, 28 Apr 2011 00:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.943 X-Spam-Level: X-Spam-Status: No, score=-104.943 tagged_above=-999 required=5 tests=[AWL=1.656, 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 xNdj1oTztBFZ for ; Thu, 28 Apr 2011 00:34:08 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id CA907E062A for ; Thu, 28 Apr 2011 00:34:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1303976031!42058654!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 28119 invoked from network); 28 Apr 2011 07:33:51 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-21.messagelabs.com with SMTP; 28 Apr 2011 07:33:51 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 797C21EB83D3; Thu, 28 Apr 2011 09:34:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 28 Apr 2011 09:34:06 +0200 From: "Elwell, John" To: "Shekh-Yusef, Rifaat (Rifaat)" , "splices@ietf.org" Date: Thu, 28 Apr 2011 09:34:05 +0200 Thread-Topic: Answering a Call Using Two Separate Devices proposal Thread-Index: AcwBBr5eBSB77KQiR06UQA3Gynn7EADtu8/gAA1JVDAAIO+8YA== Message-ID: References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> <6369CB70BFD88942B9705AC1E639A33822CB26E165@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CB26E165@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: 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: Thu, 28 Apr 2011 07:34:09 -0000 Rifaat, OK, that's fine. Presumably a GRUU would be used to address the specific de= vice. John=20 > -----Original Message----- > From: Shekh-Yusef, Rifaat (Rifaat) [mailto:rifatyu@avaya.com]=20 > Sent: 27 April 2011 16:57 > To: Elwell, John; splices@ietf.org > Subject: RE: Answering a Call Using Two Separate Devices proposal >=20 > Hi John, >=20 > I was not trying to suggest that all these requests will go=20 > directly between the devices without going through a proxy. > I just did not see the need to explicitly show that because=20 > it does not add anything to the scenario and to simplify the=20 > call flow. >=20 > Regards, > Rifaat >=20 > =20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, April 27, 2011 8:09 AM > > To: Shekh-Yusef, Rifaat (Rifaat); splices@ietf.org > > Subject: RE: Answering a Call Using Two Separate Devices proposal > >=20 > > Rifaat, > >=20 > > This involves sending SIP requests (REFER, INVITE,=20 > SUBSCRIBE) directly between > > Alice's two devices. What about NAT and firewall issues, if=20 > the two devices > > are not in the same network area? For example, phone on 3G,=20 > PC on WiFi? Don't > > the requests need to go via a proxy? > >=20 > > John > >=20 > > > -----Original Message----- > > > From: splices-bounces@ietf.org > > > [mailto:splices-bounces@ietf.org] On Behalf Of Shekh-Yusef, > > > Rifaat (Rifaat) > > > Sent: 22 April 2011 17:03 > > > To: splices@ietf.org > > > Subject: [splices] Answering a Call Using Two Separate > > > Devices proposal > > > > > > Hi, > > > > > > I would like to discuss the following proposal for addressing > > > the scenario of answering a call using two separate devices: > > > > > > > > > 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=20 > 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 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 answer the call > > > | | | > > > | > > > | REFER Refer-To: urn:sip-action:call:answer > > > | > > > |-------------------->| | > > > | > > > | 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)=20 > to add video > > > to the existing audio call > > > | | | > > > | > > > | | | INVITE > > > Alice [A/V] | > > > | | > > > |<--------------------| > > > | | INVITE 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. > > > | | | > > > | > > > | INVITE [Video] | | > > > | > > > |<--------------------| | > > > | > > > | 180 | | > > > | > > > |-------------------->| | > > > | > > > | | | > > > | > > > The user can either answer the video call using his PC, or > > > his Desk Phone. > > > If the user chose to answer the incoming video call using his > > > Desk Phone, > > > the following REFER will be sent to the PC: > > > | | | > > > | > > > | REFER Refer-To: urn:sip-action:call:answer > > > | > > > |<--------------------| | > > > | > > > | 200 OK | | > > > | > > > |-------------------->| | > > > | > > > | | | > > > | > > > | 200 OK [Video] | | > > > | > > > |-------------------->| | > > > | > > > | | | > > > | > > > | | 200 OK [A/V] | > > > | > > > | |-------------------->| > > > | > > > | | | 200 OK > > > [A/V] | > > > | | > > > |-------------------->| > > > | | | > > > | > > > > > >=20 > |<----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>| > > > > > >=20 > |<=3D=3D=3D=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 uses her PC and attempt to initiate a new video call. > > > Because the > > > PC is aware that another device is logged in using the same > > > AOR, it will > > > try to find if there is any existing dialog on the other device by > > > subscribing to the dialog event package > > > | | | > > > | > > > | SUBSCRIBE dialog | | > > > | > > > |-------------------->| | > > > | > > > | 200 OK | | > > > | > > > |<--------------------| | > > > | > > > | NOTIFY | | > > > | > > > |<--------------------| | > > > | > > > | OK | | > > > | > > > |-------------------->| | > > > | > > > | | | > > > | > > > The PC discovers that there is an existing dialog between the > > > Desk Phone > > > and Bob and present this to Alice for her to choose if=20 > she wants to > > > attach the new video call to the existing audio call or=20 > not. In this > > > case Alice chose to attach the new video call to the existing > > > audio call > > > | | | > > > | > > > | | | > > > | > > > | INVITE [Video] | | > > > | > > > | Target-Dialog: dialog1 | > > > | > > > |-------------------->| | > > > | > > > | 100 | | > > > | > > > |<--------------------| | > > > | > > > | | re-INVITE [A/V] | > > > | > > > | |-------------------->| > > > | > > > | | | re-INVITE > > > [A/V] | > > > | | > > > |-------------------->| > > > | | | 200 OK > > > [A/V] | > > > | | 200 OK [A/V] > > > |<--------------------| > > > | |<--------------------| > > > | > > > | 200 OK [Video] | | > > > | > > > |<--------------------| | > > > | > > > | | | > > > | > > > | | | > > > | > > > > > >=20 > |<----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>| > > > > > >=20 > |<=3D=3D=3D=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>| > > > | | | > > > | > > > | | | > > > | > > > | | | > > > | > > > > > > > > > Regards, > > > Rifaat > > > > > > _______________________________________________ > > > splices mailing list > > > splices@ietf.org > > > https://www.ietf.org/mailman/listinfo/splices > > > > =