From gregert@teigre.com Sat Aug 1 21:29:54 2009 From: Greger Viken Teigre To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [tracker] Task closed: Core dump on CentOS5 Date: Sat, 01 Aug 2009 21:29:55 +0200 Message-ID: In-Reply-To: <20090731124152.7115.970851561.swift@sip-router.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1105035490==" --===============1105035490== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cheers. Verified to work. g-) On Fri, 31 Jul 2009 14:41:52 +0200, sip-router wrote: > THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. > > The following task is now closed: > > FS#11 - Core dump on CentOS5 > User who did this - Daniel-Constantin Mierla (miconda) > > Reason for closing: Fixed > Additional comments about closing: Thanks, fixed in GIT b1336a. > > More information can be found at the following URL: > https://sip-router.org/tracker/index.php?do=details&task_id=11 > > You are receiving this message because you have requested it from the > Flyspray bugtracking system. If you did not expect this message or > don't want to receive mails in future, you can change your notification > settings at the URL shown above. > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --===============1105035490==-- From admin@sip-router.org Sun Aug 2 05:20:53 2009 From: sip-router To: sr-dev@lists.kamailio.org Subject: [sr-dev] [tracker] Task opened: gaqmyuyx Date: Sun, 02 Aug 2009 05:20:53 +0200 Message-ID: <20090802032053.23121.206476525.swift@sip-router.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0207487419==" --===============0207487419== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below.=20 User who did this - Anonymous user ()=20 Attached to Project - sip-router Summary - gaqmyuyx Task Type - Feature Request Category - blacklist Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - NetBSD Severity - Medium Priority - Normal Reported Version - 2.99 Due in Version - Undecided Due Date - Undecided Details - [URL=3Dhttp://tnoqerfl.com]cadzfbbd[/URL] bbslghty http://kpixcka= w.com fhmrmtta voytambj kwizbgzp=20 More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=3Ddetails&task_id=3D13 You are receiving this message because you have requested it from the Flyspra= y bugtracking system. If you did not expect this message or don't want to re= ceive mails in future, you can change your notification settings at the URL s= hown above. --===============0207487419==-- From admin@sip-router.org Sun Aug 2 05:20:54 2009 From: sip-router To: sr-dev@lists.kamailio.org Subject: [sr-dev] [tracker] Assignee added: gaqmyuyx Date: Sun, 02 Aug 2009 05:20:52 +0200 Message-ID: <20090802032052.23121.1259310985.swift@sip-router.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2039489334==" --===============2039489334== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#13 - gaqmyuyx User who did this - Anonymous user () http://sip-router.org/tracker/index.php?do=3Ddetails&task_id=3D13 You are receiving this message because you have requested it from the Flyspra= y bugtracking system. If you did not expect this message or don't want to re= ceive mails in future, you can change your notification settings at the URL s= hown above. --===============2039489334==-- From miconda@gmail.com Mon Aug 3 14:07:48 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] dokuwiki, bug tracker and git Date: Mon, 03 Aug 2009 14:07:14 +0200 Message-ID: <4A76D2F2.6000304@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1896128404==" --===============1896128404== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, I installed two plugins for dokuwiki and flyspray bug tracker to reference easier the git repository and bugs. For FlySpray, when you describe or comment a bug you can reference to a git commit by using: GIT#hash - hash must be at list the first six characters of git commit hash value Unfortunately FlySpray accepts only plain text in the "Close Task" description, so the git reference does not work there, yet. In dokuwiki same syntax can be used. In addition, you can add references to FlySpray items via: FlySpray#itemid - itemid is the integer id of FlySpray tracked item I tried to collect all these plus other options for DW syntax in a wiki page: http://sip-router.org/wiki/tutorials/contribute-to-dokuwiki Feel free to add more details there. Cheers, Daniel -- Daniel-Constantin Mierla * SIP Router Bootcamp * Kamailio (OpenSER) and Asterisk Training * Berlin, Germany, Sep 1-4, 2009 * http://www.asipto.com/index.php/sip-router-bootcamp/ --===============1896128404==-- From miconda@gmail.com Mon Aug 3 15:18:18 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] QjSimple 0.6.3 - sip phone for linux, macosx and windows Date: Mon, 03 Aug 2009 15:17:43 +0200 Message-ID: <4A76E377.1000607@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1207210710==" --===============1207210710== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thanks to Klaus Darilion, QjSimple 0.6.3 works on most of desktop OS: Linux(es), Windows and Mac OS X. It is a very handy application, especially for developers, but not olny, with simple UI and debugger window. A perfect replacement (for my very old good Linux testing tool) KPhone since QjSimple has SIMPLE presence support, tls ... more at: http://www.ipcom.at/index.php?id=560/ Cheers, Daniel -- Daniel-Constantin Mierla * SIP Router Bootcamp * Kamailio (OpenSER) and Asterisk Training * Berlin, Germany, Sep 1-4, 2009 * http://www.asipto.com/index.php/sip-router-bootcamp/ --===============1207210710==-- From ibc@aliax.net Mon Aug 3 15:42:02 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] QjSimple 0.6.3 - sip phone for linux, macosx and windows Date: Mon, 03 Aug 2009 15:41:30 +0200 Message-ID: In-Reply-To: <4A76E377.1000607@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1803346884==" --===============1803346884== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 2009/8/3 Daniel-Constantin Mierla : > Thanks to Klaus Darilion, QjSimple 0.6.3 works on most of desktop OS: > Linux(es), Windows and Mac OS X. > > It is a very handy application, especially for developers, but not olny, > with simple UI and debugger window. A perfect replacement (for my very old > good Linux testing tool) KPhone Hi Daniel, can I ask why you were using the old Kphone and not Twinkle which implements much more features (and really well)? :) > since QjSimple has SIMPLE presence support, > tls ... more at: > http://www.ipcom.at/index.php?id=560/ Great. -- Iñaki Baz Castillo --===============1803346884==-- From jan@ryngle.com Mon Aug 3 15:51:06 2009 From: Jan Janak To: sr-dev@lists.kamailio.org Subject: [sr-dev] openims git import Date: Mon, 03 Aug 2009 15:50:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0850830197==" --===============0850830197== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, The git import of the SVN tree of OpenIMSCore is now available in the sip-router repository. You can clone openimscore using: git clone git://git.sip-router.org/openimscore or git clone http://git.sip-router.org/openimscore or you can browse it with gitweb at http://git.sip-router.org. The repository is read-only and it is synchronized with the SVN repository at berlios every 15 minutes. Dragos, please take a look and let me know if there is anything missing. Jan. --===============0850830197==-- From miconda@gmail.com Mon Aug 3 15:53:39 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] QjSimple 0.6.3 - sip phone for linux, macosx and windows Date: Mon, 03 Aug 2009 15:53:03 +0200 Message-ID: <4A76EBBF.800@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2033492805==" --===============2033492805== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Inaki, On 03.08.2009 15:41 Uhr, Iñaki Baz Castillo wrote: > 2009/8/3 Daniel-Constantin Mierla : > >> Thanks to Klaus Darilion, QjSimple 0.6.3 works on most of desktop OS: >> Linux(es), Windows and Mac OS X. >> >> It is a very handy application, especially for developers, but not olny, >> with simple UI and debugger window. A perfect replacement (for my very old >> good Linux testing tool) KPhone >> > > Hi Daniel, can I ask why you were using the old Kphone and not Twinkle > which implements much more features (and really well)? :) > KP because of very handy interface and options for register/unregister, a.s.o. When starting it from terminal, it prints the debug and sip traffic... It was also easier to compile it when the packages were not available. Twinkle is pretty complex to compile due to dependencies. Otherwise is nice piece of software, I do use it, just didn't prove to be handy for me when testing. I was starting playing with QjSimple because of portability, compiling it on darwin os was very simple. Cheers, Daniel >> since QjSimple has SIMPLE presence support, >> tls ... more at: >> http://www.ipcom.at/index.php?id=560/ >> > > Great. > > > -- Daniel-Constantin Mierla * SIP Router Bootcamp * Kamailio (OpenSER) and Asterisk Training * Berlin, Germany, Sep 1-4, 2009 * http://www.asipto.com/index.php/sip-router-bootcamp/ --===============2033492805==-- From miconda@gmail.com Mon Aug 3 15:57:08 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: presence_xml: define _DARWIN_C_SOURCE 1 Date: Mon, 03 Aug 2009 15:57:07 +0200 Message-ID: <20090803135707.4BDD4EF8070@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0883932357==" --===============0883932357== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: cabd988384344a485377b817da4dc49ab0151a91 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3Dcabd988384344a485377b817da4dc49ab0151a91 Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Mon Aug 3 15:54:54 2009 +0200 presence_xml: define _DARWIN_C_SOURCE 1 - compile the module on darwin, workaround for strptime --- modules_k/presence_xml/pidf.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/modules_k/presence_xml/pidf.c b/modules_k/presence_xml/pidf.c index 36eb2a5..95b0a47 100644 --- a/modules_k/presence_xml/pidf.c +++ b/modules_k/presence_xml/pidf.c @@ -41,6 +41,7 @@ #define _BSD_SOURCE 1 /* needed on linux to "fix" the effect of the above define on features.h/unistd.h syscall() */ + #define _DARWIN_C_SOURCE 1 #else #define _XOPEN_SOURCE_EXTENDED 1 /* solaris */ #endif --===============0883932357==-- From ibc@aliax.net Mon Aug 3 20:51:57 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] QjSimple 0.6.3 - sip phone for linux, macosx and windows Date: Mon, 03 Aug 2009 20:51:53 +0200 Message-ID: <200908032051.53862.ibc@aliax.net> In-Reply-To: <4A76EBBF.800@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0724101248==" --===============0724101248== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit El Lunes, 3 de Agosto de 2009, Daniel-Constantin Mierla escribió: > KP because of very handy interface and options for register/unregister, > a.s.o. With Twinkle you have a menu with "Register, Unregister, Register all and Unregister all" :) > When starting it from terminal, it prints the debug and sip > traffic... Set the maximun log level in Twinkle and check $HOME/.twinkle/twinkle.log. :) -- Iñaki Baz Castillo --===============0724101248==-- From miconda@gmail.com Mon Aug 3 21:32:31 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] QjSimple 0.6.3 - sip phone for linux, macosx and windows Date: Mon, 03 Aug 2009 21:31:57 +0200 Message-ID: <4A773B2D.7010204@gmail.com> In-Reply-To: <200908032051.53862.ibc@aliax.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0463989585==" --===============0463989585== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 03.08.2009 20:51 Uhr, Iñaki Baz Castillo wrote: > El Lunes, 3 de Agosto de 2009, Daniel-Constantin Mierla escribió: > > >> KP because of very handy interface and options for register/unregister, >> a.s.o. >> > > With Twinkle you have a menu with "Register, Unregister, Register all and > Unregister all" :) > yes, but no toggle button :-) which is one click less. >> When starting it from terminal, it prints the debug and sip >> traffic... >> > > Set the maximun log level in Twinkle and check $HOME/.twinkle/twinkle.log. > Still does not beat kphone UI in simplicity ... I might be old fashion, simple (not ietf) is the best. Cheers, Daniel -- Daniel-Constantin Mierla * SIP Router Bootcamp * Kamailio (OpenSER) and Asterisk Training * Berlin, Germany, Sep 1-4, 2009 * http://www.asipto.com/index.php/sip-router-bootcamp/ --===============0463989585==-- From ibc@aliax.net Mon Aug 3 21:52:30 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] QjSimple 0.6.3 - sip phone for linux, macosx and windows Date: Mon, 03 Aug 2009 21:51:54 +0200 Message-ID: <200908032151.54558.ibc@aliax.net> In-Reply-To: <4A773B2D.7010204@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0178414690==" --===============0178414690== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit El Lunes, 3 de Agosto de 2009, Daniel-Constantin Mierla escribió: > Still does not beat kphone UI in simplicity ... I might be old fashion, > simple (not ietf) is the best. Does Kphone allow having 20 simultaneous and different SIP account loaded containing each one 20 buddies (presence subscription)? XDDD -- Iñaki Baz Castillo --===============0178414690==-- From klaus.mailinglists@pernau.at Mon Aug 3 22:03:27 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] QjSimple 0.6.3 - sip phone for linux, macosx and windows Date: Mon, 03 Aug 2009 22:02:58 +0200 Message-ID: <4A774272.7080603@pernau.at> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0992805703==" --===============0992805703== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Iñaki Baz Castillo wrote: > 2009/8/3 Daniel-Constantin Mierla : >> Thanks to Klaus Darilion, QjSimple 0.6.3 works on most of desktop OS: >> Linux(es), Windows and Mac OS X. >> >> It is a very handy application, especially for developers, but not olny, >> with simple UI and debugger window. A perfect replacement (for my very old >> good Linux testing tool) KPhone > > Hi Daniel, can I ask why you were using the old Kphone and not Twinkle > which implements much more features (and really well)? :) Yes. Twinkle is very powerful and has some nice features (e.g. zrtp, fetch registrations, ...) - I like it. Unfortunately it only runs under Linux, not Windows. Further, AFAIK it does not support TLS and IPv6. regards klaus --===============0992805703==-- From miconda@gmail.com Tue Aug 4 16:59:30 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:tmp/core_events: topoh: new module for hiding topology details Date: Tue, 04 Aug 2009 16:59:29 +0200 Message-ID: <20090804145929.AADF8EF8064@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1940525688==" --===============1940525688== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: tmp/core_events Commit: b16b129457bb7f1198fab78bea367e5c19ea8ca7 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3Db16b129457bb7f1198fab78bea367e5c19ea8ca7 Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Tue Aug 4 16:53:44 2009 +0200 topoh: new module for hiding topology details - transparent for script writer and processing type (stateless, stateful) - it is not affected by server restart - can handle cloud deployments by using same secret key --- modules/topoh/Makefile | 15 + modules/topoh/README | 186 ++++++++ modules/topoh/doc/Makefile | 4 + modules/topoh/doc/topoh.xml | 37 ++ modules/topoh/doc/topoh_admin.xml | 198 ++++++++ modules/topoh/th_mask.c | 175 +++++++ modules/topoh/th_mask.h | 30 ++ modules/topoh/th_msg.c | 913 +++++++++++++++++++++++++++++++++++= ++ modules/topoh/th_msg.h | 45 ++ modules/topoh/topoh_mod.c | 332 ++++++++++++++ 10 files changed, 1935 insertions(+), 0 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommitdi= ff;h=3Db16b129457bb7f1198fab78bea367e5c19ea8ca7 --===============1940525688==-- From miconda@gmail.com Tue Aug 4 16:59:30 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:tmp/core_events: core: new sr events system Date: Tue, 04 Aug 2009 16:59:29 +0200 Message-ID: <20090804145929.B80AFEF8074@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1370085022==" --===============1370085022== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: tmp/core_events Commit: 85acffe10f182c5d0cfb382f33ff5a2d1203524a URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3D85acffe10f182c5d0cfb382f33ff5a2d1203524a Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Tue Aug 4 16:47:10 2009 +0200 core: new sr events system - designed to have small footprint in core - the goal is to execute a event manager function during core processing - event managers can be implemented in modules or elsewhere - two event types added: SREV_NET_DATA_IN and SREV_NET_DATA_OUT (see the other commit) --- events.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++ events.h | 40 +++++++++++++++++++++++++++ 2 files changed, 130 insertions(+), 0 deletions(-) diff --git a/events.c b/events.c new file mode 100644 index 0000000..7ba5e34 --- /dev/null +++ b/events.c @@ -0,0 +1,90 @@ +/** + * $Id$ + * + * Copyright (C) 2009 SIP-Router.org + * + * This file is part of Extensible SIP Router, a free SIP server. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include "dprint.h" +#include "mem/mem.h" +#include "events.h" + +static sr_event_cb_t _sr_events_list; +static int _sr_events_inited =3D 0; + +void sr_event_cb_init(void) +{ + if(_sr_events_inited =3D=3D 0) + { + memset(&_sr_events_list, 0, sizeof(sr_event_cb_t)); + _sr_events_inited =3D 1; + } +} + +int sr_event_register_cb(int type, sr_event_cb_f f) +{ + sr_event_cb_init(); + switch(type) { + case SREV_NET_DATA_IN: + if(_sr_events_list.net_data_in=3D=3D0) + _sr_events_list.net_data_in =3D f; + else return -1; + break; + case SREV_NET_DATA_OUT: + if(_sr_events_list.net_data_out=3D=3D0) + _sr_events_list.net_data_out =3D f; + else return -1; + break; + default: + return -1; + } + return 0; +} + +int sr_event_exec(int type, void *data) +{ + int ret; + str *p; + switch(type) { + case SREV_NET_DATA_IN: + if(_sr_events_list.net_data_in!=3D0) + { + p =3D (str*)data; + LM_DBG("PRE-IN ++++++++++++++++++++++++++++++++\n" + "%.*s\n+++++\n", p->len, p->s); + ret =3D _sr_events_list.net_data_in(data); + LM_DBG("POST-IN ++++++++++++++++++++++++++++++++\n" + "%.*s\n+++++\n", p->len, p->s); + return ret; + } else return 1; + break; + case SREV_NET_DATA_OUT: + if(_sr_events_list.net_data_out!=3D0) + { + p =3D (str*)data; + LM_DBG("PRE-OUT ++++++++++++++++++++\n" + "%.*s\n+++++++++++++++++++\n", p->len, p->s); + ret =3D _sr_events_list.net_data_out(data); + LM_DBG("POST-OUT ++++++++++++++++++++\n" + "%.*s\n+++++++++++++++++++\n", p->len, p->s); + return ret; + } else return 1; + break; + default: + return -1; + } +} + diff --git a/events.h b/events.h new file mode 100644 index 0000000..9fda619 --- /dev/null +++ b/events.h @@ -0,0 +1,40 @@ +/** + * $Id$ + * + * Copyright (C) 2009 SIP-Router.org + * + * This file is part of Extensible SIP Router, a free SIP server. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#ifndef _SR_EVENTS_H_ +#define _SR_EVENTS_H_ + +#include "parser/msg_parser.h" + +#define SREV_NET_DATA_IN 1 +#define SREV_NET_DATA_OUT 2 + +typedef int (*sr_event_cb_f)(void *data); + +typedef struct sr_event_cb { + sr_event_cb_f net_data_in; + sr_event_cb_f net_data_out; +} sr_event_cb_t; + +void sr_event_cb_init(void); +int sr_event_register_cb(int type, sr_event_cb_f f); +int sr_event_exec(int type, void *data); + +#endif --===============1370085022==-- From miconda@gmail.com Tue Aug 4 16:59:30 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:tmp/core_events: core: execute callbacks for NET_DATA_IN and NET_DATA_OUT Date: Tue, 04 Aug 2009 16:59:29 +0200 Message-ID: <20090804145929.8CBF3EF8072@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0848475963==" --===============0848475963== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: tmp/core_events Commit: 88b792e4932b33700f5240be3923c19394c8e4d0 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3D88b792e4932b33700f5240be3923c19394c8e4d0 Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Tue Aug 4 16:43:30 2009 +0200 core: execute callbacks for NET_DATA_IN and NET_DATA_OUT - NET_DATA_IN is executed when a sip message is received. The callback may replace the content of incoming buffer, assuming BUF_SIZE for its size - NET_DATA_OUT is executed when a sip message is sent. The callback may replace the output buffer content with a new pkg location --- forward.h | 18 ++++++++++++++---- receive.c | 6 ++++++ 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/forward.h b/forward.h index 0a5750a..b486694 100644 --- a/forward.h +++ b/forward.h @@ -60,6 +60,7 @@ #endif =20 #include "compiler_opt.h" +#include "events.h" =20 =20 enum ss_mismatch { @@ -114,9 +115,14 @@ int forward_reply( struct sip_msg* msg); * that generated them; use 0 if you don't want this) * buf, len =3D buffer * returns: 0 if ok, -1 on error*/ + static inline int msg_send(struct dest_info* dst, char* buf, int len) { struct dest_info new_dst; + str outb; + outb.s =3D buf; + outb.len =3D len; + sr_event_exec(SREV_NET_DATA_OUT, (void*)&outb); =09 if (likely(dst->proto=3D=3DPROTO_UDP)){ if (unlikely((dst->send_sock=3D=3D0) ||=20 @@ -129,7 +135,7 @@ static inline int msg_send(struct dest_info* dst, char* b= uf, int len) } dst=3D&new_dst; } - if (unlikely(udp_send(dst, buf, len)=3D=3D-1)){ + if (unlikely(udp_send(dst, outb.s, outb.len)=3D=3D-1)){ STATS_TX_DROPS; LOG(L_ERR, "msg_send: ERROR: udp_send failed\n"); goto error; @@ -143,7 +149,7 @@ static inline int msg_send(struct dest_info* dst, char* b= uf, int len) " support is disabled\n"); goto error; }else{ - if (unlikely(tcp_send(dst, 0, buf, len)<0)){ + if (unlikely(tcp_send(dst, 0, outb.s, outb.len)<0)){ STATS_TX_DROPS; LOG(L_ERR, "msg_send: ERROR: tcp_send failed\n"); goto error; @@ -158,7 +164,7 @@ static inline int msg_send(struct dest_info* dst, char* b= uf, int len) " support is disabled\n"); goto error; }else{ - if (unlikely(tcp_send(dst, 0, buf, len)<0)){ + if (unlikely(tcp_send(dst, 0, outb.s, outb.len)<0)){ STATS_TX_DROPS; LOG(L_ERR, "msg_send: ERROR: tcp_send failed\n"); goto error; @@ -184,7 +190,7 @@ static inline int msg_send(struct dest_info* dst, char* b= uf, int len) } dst=3D&new_dst; } - if (unlikely(sctp_msg_send(dst, buf, len)<0)){ + if (unlikely(sctp_msg_send(dst, outb.s, outb.len)<0)){ STATS_TX_DROPS; LOG(L_ERR, "msg_send: ERROR: sctp_msg_send failed\n"); goto error; @@ -196,8 +202,12 @@ static inline int msg_send(struct dest_info* dst, char* = buf, int len) LOG(L_CRIT, "BUG: msg_send: unknown proto %d\n", dst->proto); goto error; } + if(outb.s !=3D buf) + pkg_free(outb.s); return 0; error: + if(outb.s !=3D buf) + pkg_free(outb.s); return -1; } =20 diff --git a/receive.c b/receive.c index 824e693..579a6c2 100644 --- a/receive.c +++ b/receive.c @@ -98,6 +98,12 @@ int receive_msg(char* buf, unsigned int len, struct receiv= e_info* rcv_info) struct timezone tz; unsigned int diff; #endif + str inb; + + inb.s =3D buf; + inb.len =3D len; + sr_event_exec(SREV_NET_DATA_IN, (void*)&inb); + len =3D inb.len; =20 msg=3Dpkg_malloc(sizeof(struct sip_msg)); if (msg=3D=3D0) { --===============0848475963==-- From miconda@gmail.com Tue Aug 4 17:16:22 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] core events famework Date: Tue, 04 Aug 2009 17:15:48 +0200 Message-ID: <4A7850A4.2070100@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0061040439==" --===============0061040439== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, I committed in branch tmp/core_events a simple framework to execute callbacks by core in various cases. So far there are two defined events: for network data in and data out. I used it for implementing a topo-hiding module that is transparent for script writer and cope with stateless/stateful module in the same way. Now, about the new event framework. The core stores a structure with pointers to event manager callbacks. typedef int (*sr_event_cb_f)(void *data); typedef struct sr_event_cb { sr_event_cb_f net_data_in; sr_event_cb_f net_data_out; } sr_event_cb_t; The event manager can be implemented elsewhere, but the execution of call manager and implementation must be very tied. The event manager callback gets only one parameter, which is a void* and is specific per event, thus the implementation must know what is the content. So far, only one listener is needed for network data in/out events, thus the event manager does the processing, but if the event should trigger more functions from different parts of code, then the manager must take of handling them (registration, execution, etc...). You can download the branch and test the topoh module. It will be merged once we discuss and decide whether the new core events framework is the best for now, if something is missing, a.s.o. Feedback is very much appreciated. Cheers, Daniel -- Daniel-Constantin Mierla * SIP Router Bootcamp * Kamailio (OpenSER) and Asterisk Training * Berlin, Germany, Sep 1-4, 2009 * http://www.asipto.com/index.php/sip-router-bootcamp/ --===============0061040439==-- From ramona@rosdev.ro Tue Aug 4 17:47:24 2009 From: Elena-Ramona Modroiu To: sr-dev@lists.kamailio.org Subject: [sr-dev] SF.net SVN: openser:[5908] branches/1.5/modules/rls/subscribe.c Date: Tue, 04 Aug 2009 15:47:21 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1137411412==" --===============1137411412== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Revision: 5908 http://openser.svn.sourceforge.net/openser/?rev=3D5908&view=3Drev Author: anomarme Date: 2009-08-04 15:47:21 +0000 (Tue, 04 Aug 2009) Log Message: ----------- - fixed supported header name Modified Paths: -------------- branches/1.5/modules/rls/subscribe.c This was sent by the SourceForge.net collaborative development platform, the = world's largest Open Source development site. --===============1137411412==-- From ramona@rosdev.ro Wed Aug 5 13:34:38 2009 From: Elena-Ramona Modroiu To: sr-dev@lists.kamailio.org Subject: [sr-dev] SF.net SVN: openser:[5909] branches/1.5/modules/rls Date: Wed, 05 Aug 2009 11:34:36 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0713331742==" --===============0713331742== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Revision: 5909 http://openser.svn.sourceforge.net/openser/?rev=3D5909&view=3Drev Author: anomarme Date: 2009-08-05 11:34:36 +0000 (Wed, 05 Aug 2009) Log Message: ----------- - fix memory leak Modified Paths: -------------- branches/1.5/modules/rls/notify.c branches/1.5/modules/rls/resource_notify.c branches/1.5/modules/rls/subscribe.c This was sent by the SourceForge.net collaborative development platform, the = world's largest Open Source development site. --===============0713331742==-- From ibc@aliax.net Thu Aug 6 01:31:38 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 01:31:04 +0200 Message-ID: <200908060131.04402.ibc@aliax.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0204760086==" --===============0204760086== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, does/will SR implement TEL URI properly? This is: OpenSer/Kamailio doesn'= t=20 support it (just a very basic support). Also, some useful funtions would be: - "is_sip?": returns true if RURI has SIP URI. - "is_sips?": returns true if RURI has SIPS URI. - "is_sip_ips?": returns true if RURI has SIP or SIPS URI. - "is_tel?": returns true if RURI has TEL URI. Regards. --=20 I=C3=B1aki Baz Castillo --===============0204760086==-- From abalashov@evaristesys.com Thu Aug 6 01:59:25 2009 From: Alex Balashov To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Wed, 05 Aug 2009 20:05:21 -0400 Message-ID: <4A7A1E41.5090703@evaristesys.com> In-Reply-To: <200908060131.04402.ibc@aliax.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0651441081==" --===============0651441081== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I=C3=B1aki Baz Castillo wrote: > Hi, does/will SR implement TEL URI properly? This is: OpenSer/Kamailio does= n't=20 > support it (just a very basic support). >=20 > Also, some useful funtions would be: >=20 > - "is_sip?": returns true if RURI has SIP URI. if($ru =3D~ "^sip:") > - "is_sips?": returns true if RURI has SIPS URI. if($ru =3D~ "^sips:") > - "is_sip_ips?": returns true if RURI has SIP or SIPS URI. if($ru =3D~ "^sip([s]*):) > - "is_tel?": returns true if RURI has TEL URI. if($ru =3D~ "^tel:") ? Or are you looking for something more involved than that, i.e.=20 validation of the actual contents of the values and not just the alleged=20 URI scheme? -- Alex --=20 Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775 --===============0651441081==-- From oej@edvina.net Thu Aug 6 08:03:28 2009 From: "Olle E. Johansson" To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 08:02:56 +0200 Message-ID: <64196F9F-8C3C-4E14-BE40-487AD32E5260@edvina.net> In-Reply-To: <200908060131.04402.ibc@aliax.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1022179243==" --===============1022179243== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 6 aug 2009 kl. 01.31 skrev Iñaki Baz Castillo: > Hi, does/will SR implement TEL URI properly? This is: OpenSer/ > Kamailio doesn't > support it (just a very basic support). > > Also, some useful funtions would be: > > - "is_sip?": returns true if RURI has SIP URI. > - "is_sips?": returns true if RURI has SIPS URI. > - "is_sip_ips?": returns true if RURI has SIP or SIPS URI. > - "is_tel?": returns true if RURI has TEL URI. At the same time, we could implement support for other URI's, like XMPP since we have an xmpp gateway. /O --===============1022179243==-- From ibc@aliax.net Thu Aug 6 10:31:57 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 10:31:26 +0200 Message-ID: In-Reply-To: <4A7A1E41.5090703@evaristesys.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1683587054==" --===============1683587054== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 2009/8/6 Alex Balashov : > Iñaki Baz Castillo wrote: > >> Hi, does/will SR implement TEL URI properly? This is: OpenSer/Kamailio >> doesn't support it (just a very basic support). >> >> Also, some useful funtions would be: >> >> - "is_sip?": returns true if RURI has SIP URI. > >  if($ru =~ "^sip:") > >> - "is_sips?": returns true if RURI has SIPS URI. > >  if($ru =~ "^sips:") > >> - "is_sip_ips?": returns true if RURI has SIP or SIPS URI. > >  if($ru =~ "^sip([s]*):) > >> - "is_tel?": returns true if RURI has TEL URI. > >  if($ru =~ "^tel:") > > ? > > Or are you looking for something more involved than that, i.e. validation of > the actual contents of the values and not just the alleged URI scheme? Yes Alex, the above is a hack ;) The current "support" of TEL uri is also a "hack", since after parsing a TEL URI what we have is: - $rU = null - $rd = the TEL number (note: parhaps is the opposite) I'd realy would like to have something as: - $rtU = RURI TEL number - $rtparams = RURI TEL parameters -- Iñaki Baz Castillo --===============1683587054==-- From miconda@gmail.com Thu Aug 6 10:42:39 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 10:42:33 +0200 Message-ID: <4A7A9779.7080303@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1596371231==" --===============1596371231== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, On 06.08.2009 10:31 Uhr, I=C3=B1aki Baz Castillo wrote: > 2009/8/6 Alex Balashov : > =20 >> I=C3=B1aki Baz Castillo wrote: >> >> =20 >>> Hi, does/will SR implement TEL URI properly? This is: OpenSer/Kamailio >>> doesn't support it (just a very basic support). >>> >>> Also, some useful funtions would be: >>> >>> - "is_sip?": returns true if RURI has SIP URI. >>> =20 >> if($ru =3D~ "^sip:") >> >> =20 >>> - "is_sips?": returns true if RURI has SIPS URI. >>> =20 >> if($ru =3D~ "^sips:") >> >> =20 >>> - "is_sip_ips?": returns true if RURI has SIP or SIPS URI. >>> =20 >> if($ru =3D~ "^sip([s]*):) >> >> =20 >>> - "is_tel?": returns true if RURI has TEL URI. >>> =20 >> if($ru =3D~ "^tel:") >> >> ? >> >> Or are you looking for something more involved than that, i.e. validation = of >> the actual contents of the values and not just the alleged URI scheme? >> =20 > > > Yes Alex, the above is a hack ;) > > > The current "support" of TEL uri is also a "hack", since after parsing > a TEL URI what we have is: > - $rU =3D null > - $rd =3D the TEL number > (note: parhaps is the opposite) > > I'd realy would like to have something as: > - $rtU =3D RURI TEL number > - $rtparams =3D RURI TEL parameters > =20 sip-router core has support for tel uri, but there are no PVs associated=20 with. The username should be the tel number and the host is empty. Try=20 and see if all works ok. Cheers, Daniel --=20 Daniel-Constantin Mierla * SIP Router Bootcamp * Kamailio (OpenSER) and Asterisk Training * Berlin, Germany, Sep 1-4, 2009 * http://www.asipto.com/index.php/sip-router-bootcamp/ --===============1596371231==-- From martin.hoffmann@telio.ch Thu Aug 6 10:43:52 2009 From: Martin Hoffmann To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 10:43:31 +0200 Message-ID: <20090806084331.GG28787@mlap.hq.telio.no> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0631057048==" --===============0631057048== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Iñaki Baz Castillo wrote: > > The current "support" of TEL uri is also a "hack", since after parsing > a TEL URI what we have is: > - $rU = null > - $rd = the TEL number > (note: parhaps is the opposite) > > I'd realy would like to have something as: > - $rtU = RURI TEL number > - $rtparams = RURI TEL parameters Call me biased, but I do prefer the select stuff: @ruri.type -> "tel" @ruri.user -> number @ruri.params -> parameters @ruri.params["phone-context"] -> phone-context parameter The only thing I always need to look up is whether it is user or username. One could probably add a sub-select "number" which is only valid if the type is "tel" or if the username part of the URI consists of characters valid in a TEL URI. I know C people like their functions and variables to have cryptical names for hyst[eo]rical reasons, but this is so 20th century. Regards, Martin --===============0631057048==-- From miconda@gmail.com Thu Aug 6 10:49:17 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 10:48:44 +0200 Message-ID: <4A7A98EC.8020101@gmail.com> In-Reply-To: <20090806084331.GG28787@mlap.hq.telio.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1611757171==" --===============1611757171== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 06.08.2009 10:43 Uhr, Martin Hoffmann wrote: > I=C3=B1aki Baz Castillo wrote: > =20 > =20 >> The current "support" of TEL uri is also a "hack", since after parsing >> a TEL URI what we have is: >> - $rU =3D null >> - $rd =3D the TEL number >> (note: parhaps is the opposite) >> >> I'd realy would like to have something as: >> - $rtU =3D RURI TEL number >> - $rtparams =3D RURI TEL parameters >> =20 > > Call me biased, but I do prefer the select stuff: > > @ruri.type -> "tel" > @ruri.user -> number > @ruri.params -> parameters > @ruri.params["phone-context"] -> phone-context parameter > =20 in K there are transformations that can be used as well for other=20 variables that contains URI: $var(x) =3D "sip:daniel(a)xyz.com"; $(var(x){uri.user}) http://www.kamailio.org/dokuwiki/doku.php/transformations:1.5.x#uri_transform= ations Cheers, Daniel > The only thing I always need to look up is whether it is user or > username. One could probably add a sub-select "number" which is only > valid if the type is "tel" or if the username part of the URI consists > of characters valid in a TEL URI. > > I know C people like their functions and variables to have cryptical > names for hyst[eo]rical reasons, but this is so 20th century. > > Regards, > Martin > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > =20 --=20 Daniel-Constantin Mierla * SIP Router Bootcamp * Kamailio (OpenSER) and Asterisk Training * Berlin, Germany, Sep 1-4, 2009 * http://www.asipto.com/index.php/sip-router-bootcamp/ --===============1611757171==-- From ibc@aliax.net Thu Aug 6 10:51:47 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 10:51:16 +0200 Message-ID: In-Reply-To: <20090806084331.GG28787@mlap.hq.telio.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0843836024==" --===============0843836024== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 2009/8/6 Martin Hoffmann : > Call me biased, but I do prefer the select stuff: > >   @ruri.type -> "tel" >   @ruri.user -> number >   @ruri.params -> parameters >   @ruri.params["phone-context"] -> phone-context parameter > > The only thing I always need to look up is whether it is user or > username. One could probably add a sub-select "number" which is only > valid if the type is "tel" or if the username part of the URI consists > of characters valid in a TEL URI. > > I know C people like their functions and variables to have cryptical > names for hyst[eo]rical reasons, but this is so 20th century. I agree 200%. In fact I really would like that each module exports functions (and pseudo-variables) into a namespace, example: if userloc.lockup("location") There are ~ 100 modules right now, each one adding functions and pseudo variables to the config script. When I see "check_to" or "is_gw" it's really annoying to know which is the parent module of those functions. Imagine a newbie inspecting for first time the example config file. -- Iñaki Baz Castillo --===============0843836024==-- From klaus.mailinglists@pernau.at Thu Aug 6 14:25:00 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 14:24:28 +0200 Message-ID: <4A7ACB7C.2030604@pernau.at> In-Reply-To: <64196F9F-8C3C-4E14-BE40-487AD32E5260@edvina.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0216702913==" --===============0216702913== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Olle E. Johansson schrieb: > > 6 aug 2009 kl. 01.31 skrev Iñaki Baz Castillo: > >> Hi, does/will SR implement TEL URI properly? This is: OpenSer/Kamailio >> doesn't >> support it (just a very basic support). >> >> Also, some useful funtions would be: >> >> - "is_sip?": returns true if RURI has SIP URI. >> - "is_sips?": returns true if RURI has SIPS URI. >> - "is_sip_ips?": returns true if RURI has SIP or SIPS URI. >> - "is_tel?": returns true if RURI has TEL URI. > > At the same time, we could implement support for other URI's, like XMPP > since we have an xmpp gateway. Yes, should be generic as RFC 3261 which allows all kind of URIs klaus --===============0216702913==-- From ibc@aliax.net Thu Aug 6 14:42:43 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 14:42:11 +0200 Message-ID: In-Reply-To: <4A7ACB7C.2030604@pernau.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1690347447==" --===============1690347447== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 2009/8/6 Klaus Darilion : >> At the same time, we could implement support for other URI's, like XMPP >> since we have an xmpp gateway. > > Yes, should be generic as RFC 3261 which allows all kind of URIs Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a request, or a mailto URI, even if RFC 3261 says "any URI". AFAIK the only URI's to implement wouuld be: - SIP - SIPS - TEL - URN -- Iñaki Baz Castillo --===============1690347447==-- From jan@ryngle.com Thu Aug 6 15:12:58 2009 From: Jan Janak To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 15:12:26 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1283515432==" --===============1283515432== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Aug 6, 2009 at 2:42 PM, Iñaki Baz Castillo wrote: > 2009/8/6 Klaus Darilion : >>> At the same time, we could implement support for other URI's, like XMPP >>> since we have an xmpp gateway. >> >> Yes, should be generic as RFC 3261 which allows all kind of URIs > > Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a > request, or a mailto URI, even if RFC 3261 says "any URI". Why not? > AFAIK the only URI's to implement wouuld be: > - SIP > - SIPS > - TEL > - URN Why URN yes and HTTP not? Jan. --===============1283515432==-- From ibc@aliax.net Thu Aug 6 15:24:59 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 15:24:28 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1786416758==" --===============1786416758== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 2009/8/6 Jan Janak : > On Thu, Aug 6, 2009 at 2:42 PM, Iñaki Baz Castillo wrote: >> 2009/8/6 Klaus Darilion : >>>> At the same time, we could implement support for other URI's, like XMPP >>>> since we have an xmpp gateway. >>> >>> Yes, should be generic as RFC 3261 which allows all kind of URIs >> >> Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a >> request, or a mailto URI, even if RFC 3261 says "any URI". > > Why not? > >> AFAIK the only URI's to implement wouuld be: >> - SIP >> - SIPS >> - TEL >> - URN > > Why URN yes and HTTP not? According to some exotic RFC, a proxy should handle a URN URI and translate it into a SIP URI (or route the request to a predefined proxy which handles it). But no specification defines how a HTTP URI should be translated into a SIP URI (or other kind of URI). But if SR impements HTTP perfect, then I'll configure a SR as HTTP proxy and load balancer XDD -- Iñaki Baz Castillo --===============1786416758==-- From martin.hoffmann@telio.ch Thu Aug 6 15:34:46 2009 From: Martin Hoffmann To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 15:34:24 +0200 Message-ID: <20090806133424.GM28787@mlap.hq.telio.no> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0559743437==" --===============0559743437== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Iñaki Baz Castillo wrote: > > According to some exotic RFC, a proxy should handle a URN URI and > translate it into a SIP URI (or route the request to a predefined > proxy which handles it). But no specification defines how a HTTP URI > should be translated into a SIP URI (or other kind of URI). Because it isn't specified, it can't be done? One could probably think of some scenarios where a MESSAGE request with a text body and a mailto URI does make sense. Of course you need some pre-configured logic to make the proxy understand what to do with it. If it knows where to send the request to, it can happily do that. No need to have a SIP URI for that purpose. Regards, Martin --===============0559743437==-- From ibc@aliax.net Thu Aug 6 15:48:07 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 15:47:35 +0200 Message-ID: In-Reply-To: <20090806133424.GM28787@mlap.hq.telio.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0277580902==" --===============0277580902== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 2009/8/6 Martin Hoffmann : > Iñaki Baz Castillo wrote: >> >> According to some exotic RFC, a proxy should handle a URN URI and >> translate it into a SIP URI (or route the request to a predefined >> proxy which handles it). But no specification defines how a HTTP URI >> should be translated into a SIP URI (or other kind of URI). > > Because it isn't specified, it can't be done? One could probably think > of some scenarios where a MESSAGE request with a text body and a mailto > URI does make sense. Of course you need some pre-configured logic to > make the proxy understand what to do with it. If it knows where to send > the request to, it can happily do that. No need to have a SIP URI for > that purpose. Ok, but for sure that's not the purpose of a SIP proxy ;) -- Iñaki Baz Castillo --===============0277580902==-- From jan@ryngle.com Thu Aug 6 15:58:19 2009 From: Jan Janak To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 15:57:47 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1887391217==" --===============1887391217== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Aug 6, 2009 at 3:47 PM, Iñaki Baz Castillo wrote: > 2009/8/6 Martin Hoffmann : >> Iñaki Baz Castillo wrote: >>> >>> According to some exotic RFC, a proxy should handle a URN URI and >>> translate it into a SIP URI (or route the request to a predefined >>> proxy which handles it). But no specification defines how a HTTP URI >>> should be translated into a SIP URI (or other kind of URI). >> >> Because it isn't specified, it can't be done? One could probably think >> of some scenarios where a MESSAGE request with a text body and a mailto >> URI does make sense. Of course you need some pre-configured logic to >> make the proxy understand what to do with it. If it knows where to send >> the request to, it can happily do that. No need to have a SIP URI for >> that purpose. > > Ok, but for sure that's not the purpose of a SIP proxy ;) Just to make things a bit more clear, I was asking why not because I assumed that you were referring to some existing internet draft or RFC which says that HTTTP (and possibly other URI types) should not be used in SIP messages. Possibly because they are considered harmful, or something like that (IETF does issue such RFCs from time to time). Not being able to recall any such document, I thought I missed it. If that's not the case then I just mentally add "in my opinion" to the original text to make is sound less definitive. I was not trying to argue that HTTP (or any other URI types) should be explicitly supported by a SIP proxy. Jan. --===============1887391217==-- From klaus.mailinglists@pernau.at Thu Aug 6 17:25:36 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 17:25:04 +0200 Message-ID: <4A7AF5D0.7010003@pernau.at> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0963601358==" --===============0963601358== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Iñaki Baz Castillo schrieb: > 2009/8/6 Klaus Darilion : >>> At the same time, we could implement support for other URI's, like XMPP >>> since we have an xmpp gateway. >> Yes, should be generic as RFC 3261 which allows all kind of URIs > > Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a > request, or a mailto URI, even if RFC 3261 says "any URI". > AFAIK the only URI's to implement wouuld be: > - SIP > - SIPS > - TEL > - URN IMO this is a little bit short-sighted. You never know which knid of new URIs we have in 3 years. It would be great if we do not have to patch sr for every new URI schema - having support for "absolute-URI" would allow to just handle the URI to an external application (exec, http, DB-query, radius ..whatever) and do the routing for the next hop. regaeds Klaus --===============0963601358==-- From oej@edvina.net Thu Aug 6 18:37:14 2009 From: "Olle E. Johansson" To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 18:36:41 +0200 Message-ID: <187C3B36-9F1C-496A-89DD-51A83E33BD82@edvina.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1894420575==" --===============1894420575== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 6 aug 2009 kl. 14.42 skrev Iñaki Baz Castillo: > 2009/8/6 Klaus Darilion : >>> At the same time, we could implement support for other URI's, like >>> XMPP >>> since we have an xmpp gateway. >> >> Yes, should be generic as RFC 3261 which allows all kind of URIs > > Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a > request, or a mailto URI, even if RFC 3261 says "any URI". > AFAIK the only URI's to implement wouuld be: > - SIP > - SIPS > - TEL > - URN > You're forgetting - IM - XMPP - PRES /O --===============1894420575==-- From ibc@aliax.net Thu Aug 6 18:51:32 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 18:51:00 +0200 Message-ID: In-Reply-To: <187C3B36-9F1C-496A-89DD-51A83E33BD82@edvina.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0436032297==" --===============0436032297== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 2009/8/6 Olle E. Johansson : > You're forgetting > > - IM IM: Hyper exotic concept made in IETF which absolutely nobody cares and nobody implements. > - PRES Idem. > - XMPP Why should a SIP proxy manage XMPP URI? -- Iñaki Baz Castillo --===============0436032297==-- From henning.westerholt@1und1.de Thu Aug 6 19:08:33 2009 From: Henning Westerholt To: sr-dev@lists.kamailio.org Subject: [sr-dev] SF.net SVN: openser:[5910] branches Date: Thu, 06 Aug 2009 17:08:30 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2116463567==" --===============2116463567== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Revision: 5910 http://openser.svn.sourceforge.net/openser/?rev=3D5910&view=3Drev Author: henningw Date: 2009-08-06 17:08:30 +0000 (Thu, 06 Aug 2009) Log Message: ----------- - fix error in auth_db documentation for calc_ha1 parameter Modified Paths: -------------- branches/1.3/modules/auth_db/README branches/1.3/modules/auth_db/doc/auth_db_user.sgml branches/1.4/modules/auth_db/README branches/1.4/modules/auth_db/doc/auth_db_admin.xml branches/1.5/modules/auth_db/README branches/1.5/modules/auth_db/doc/auth_db_admin.xml This was sent by the SourceForge.net collaborative development platform, the = world's largest Open Source development site. --===============2116463567==-- From oej@edvina.net Thu Aug 6 19:19:38 2009 From: "Olle E. Johansson" To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 19:19:06 +0200 Message-ID: <33A34D5B-ADE7-4A72-A222-40B15A5382BC@edvina.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1605274831==" --===============1605274831== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 6 aug 2009 kl. 18.51 skrev Iñaki Baz Castillo: > 2009/8/6 Olle E. Johansson : >> You're forgetting >> >> - IM > > IM: Hyper exotic concept made in IETF which absolutely nobody cares > and nobody implements. Well, I spent a few hours with at least one person that implements it at IETF. It's coming. > > >> - PRES > > Idem. I can't say much about that. > > >> - XMPP > > Why should a SIP proxy manage XMPP URI? sip router already has XMPP gateways. In order to send instant messages or set up calls to URI's in the XMPP name space, it's easier to use that than having to mangle it with various strange methods. MESSAGE sip:inaki(a)aliax.net From: xmpp:oej(a)edvina.net To: sip:inaki(a)aliax.net See? /O --===============1605274831==-- From oej@edvina.net Thu Aug 6 19:24:20 2009 From: "Olle E. Johansson" To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 19:23:49 +0200 Message-ID: In-Reply-To: <4A7ACB7C.2030604@pernau.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0114095073==" --===============0114095073== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 6 aug 2009 kl. 14.24 skrev Klaus Darilion: > > > Olle E. Johansson schrieb: >> 6 aug 2009 kl. 01.31 skrev Iñaki Baz Castillo: >>> Hi, does/will SR implement TEL URI properly? This is: OpenSer/ >>> Kamailio doesn't >>> support it (just a very basic support). >>> >>> Also, some useful funtions would be: >>> >>> - "is_sip?": returns true if RURI has SIP URI. >>> - "is_sips?": returns true if RURI has SIPS URI. >>> - "is_sip_ips?": returns true if RURI has SIP or SIPS URI. >>> - "is_tel?": returns true if RURI has TEL URI. >> At the same time, we could implement support for other URI's, like >> XMPP since we have an xmpp gateway. > > Yes, should be generic as RFC 3261 which allows all kind of URIs Yes, exactly. As you say, the only thing we can be sure of is that we have no idea about which URI schemes that will be used in the future. An internal registry of handlers would be a good thing. /O --===============0114095073==-- From oej@edvina.net Thu Aug 6 20:10:11 2009 From: "Olle E. Johansson" To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 20:09:40 +0200 Message-ID: <02EC208D-E26F-4586-ACBC-32E83F8DA85B@edvina.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1336962526==" --===============1336962526== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 6 aug 2009 kl. 15.24 skrev Iñaki Baz Castillo: > 2009/8/6 Jan Janak : >> On Thu, Aug 6, 2009 at 2:42 PM, Iñaki Baz Castillo >> wrote: >>> 2009/8/6 Klaus Darilion : >>>>> At the same time, we could implement support for other URI's, >>>>> like XMPP >>>>> since we have an xmpp gateway. >>>> >>>> Yes, should be generic as RFC 3261 which allows all kind of URIs >>> >>> Well, I can't agree. A SIP proxy shouldn't implement a HTTP URI in a >>> request, or a mailto URI, even if RFC 3261 says "any URI". >> >> Why not? >> >>> AFAIK the only URI's to implement wouuld be: >>> - SIP >>> - SIPS >>> - TEL >>> - URN >> >> Why URN yes and HTTP not? > > > According to some exotic RFC, a proxy should handle a URN URI and > translate it into a SIP URI (or route the request to a predefined > proxy which handles it). But no specification defines how a HTTP URI > should be translated into a SIP URI (or other kind of URI). Why should it be translated??? > > But if SR impements HTTP perfect, then I'll configure a SR as HTTP > proxy and load balancer XDD > No, but there's a lot of stuff now being implemented in HTTP requests in regards to SIP conferencing and SIMPLE. /O --===============1336962526==-- From ibc@aliax.net Thu Aug 6 20:22:54 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 20:22:47 +0200 Message-ID: <200908062022.47371.ibc@aliax.net> In-Reply-To: <02EC208D-E26F-4586-ACBC-32E83F8DA85B@edvina.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1016186994==" --===============1016186994== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribi=C3=B3: > > According to some exotic RFC, a proxy should handle a URN URI and > > translate it into a SIP URI (or route the request to a predefined > > proxy which handles it). But no specification defines how a HTTP URI > > should be translated into a SIP URI (or other kind of URI). > > Why should it be translated??? I don't remember the details right now, but AFAIR a UAC sends a URN request t= o=20 its oubound proxy which routes it to the proxy server handling those kind of = requests. The later proxies translates them into a normal SIP/TEL URI=20 generating a normal call to a PSTN number (the PSTN emergency number accordin= g=20 for the caller based on his location and so on). > > But if SR impements HTTP perfect, then I'll configure a SR as HTTP > > proxy and load balancer XDD > > No, but there's a lot of stuff now being implemented in HTTP requests > in regards to SIP conferencing and SIMPLE. ops, I didn't read about it. --=20 I=C3=B1aki Baz Castillo --===============1016186994==-- From ibc@aliax.net Thu Aug 6 20:25:02 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 20:24:15 +0200 Message-ID: <200908062024.15998.ibc@aliax.net> In-Reply-To: <33A34D5B-ADE7-4A72-A222-40B15A5382BC@edvina.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0402986683==" --===============0402986683== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió: > > Why should a SIP proxy manage XMPP URI? > > sip router already has XMPP gateways. In order to send instant > messages or set up calls to URI's in the XMPP name space, it's easier > to use that than having to mangle it with various strange methods. > > > MESSAGE sip:inaki(a)aliax.net > From: xmpp:oej(a)edvina.net > To: sip:inaki(a)aliax.net > > See? This means that the receipt of the request (my softphone) should also allow XMPP URI to display the From. Since no RFC states it, why should my softphone implement it? -- Iñaki Baz Castillo --===============0402986683==-- From oej@edvina.net Thu Aug 6 20:33:04 2009 From: "Olle E. Johansson" To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 20:32:33 +0200 Message-ID: In-Reply-To: <200908062024.15998.ibc@aliax.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0232027249==" --===============0232027249== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 6 aug 2009 kl. 20.24 skrev Iñaki Baz Castillo: > El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió: >>> Why should a SIP proxy manage XMPP URI? >> >> sip router already has XMPP gateways. In order to send instant >> messages or set up calls to URI's in the XMPP name space, it's easier >> to use that than having to mangle it with various strange methods. >> >> >> MESSAGE sip:inaki(a)aliax.net >> From: xmpp:oej(a)edvina.net >> To: sip:inaki(a)aliax.net >> >> See? > > This means that the receipt of the request (my softphone) should > also allow > XMPP URI to display the From. Since no RFC states it, why should my > softphone > implement it? Because of future work being done right now that will soon result in internet-drafts. SIP - XMPP interoperability... Wait and see. /O --===============0232027249==-- From ibc@aliax.net Thu Aug 6 20:56:16 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 20:55:42 +0200 Message-ID: <200908062055.42694.ibc@aliax.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0379569205==" --===============0379569205== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió: > > This means that the receipt of the request (my softphone) should > > also allow > > XMPP URI to display the From. Since no RFC states it, why should my > > softphone > > implement it? > > Because of future work being done right now that will soon result in > internet-drafts. > SIP - XMPP interoperability... > > Wait and see. I strongly prefer to improve the SIP high presence including XCAP more than interoperating with other protocols. ;) -- Iñaki Baz Castillo --===============0379569205==-- From oej@edvina.net Thu Aug 6 21:31:18 2009 From: "Olle E. Johansson" To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 21:30:45 +0200 Message-ID: In-Reply-To: <200908062055.42694.ibc@aliax.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0654544702==" --===============0654544702== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 6 aug 2009 kl. 20.55 skrev Iñaki Baz Castillo: > El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió: >>> This means that the receipt of the request (my softphone) should >>> also allow >>> XMPP URI to display the From. Since no RFC states it, why should my >>> softphone >>> implement it? >> >> Because of future work being done right now that will soon result in >> internet-drafts. >> SIP - XMPP interoperability... >> >> Wait and see. > > I strongly prefer to improve the SIP high presence including XCAP > more than > interoperating with other protocols. ;) Well interoperability was one of the CPIM requirements from IETF, so you'll be trapped there no matter what ;-) /O --===============0654544702==-- From ibc@aliax.net Thu Aug 6 21:41:26 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Thu, 06 Aug 2009 21:40:49 +0200 Message-ID: <200908062140.49866.ibc@aliax.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1092556997==" --===============1092556997== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribió: > > I strongly prefer to improve the SIP high presence including XCAP > > more than > > interoperating with other protocols. ;) > > Well interoperability was one of the CPIM requirements from IETF, so > you'll be trapped there no matter what ;-) ok, I prefer to fix SIP/SIMPLE interoperability *before* implementing interoperability between SIP and XMPP ;) -- Iñaki Baz Castillo --===============1092556997==-- From klaus.mailinglists@pernau.at Fri Aug 7 13:34:59 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Fri, 07 Aug 2009 13:34:28 +0200 Message-ID: <4A7C1144.6060600@pernau.at> In-Reply-To: <200908062024.15998.ibc@aliax.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1207217511==" --===============1207217511== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I=C3=B1aki Baz Castillo schrieb: > El Jueves, 6 de Agosto de 2009, Olle E. Johansson escribi=C3=B3: >>> Why should a SIP proxy manage XMPP URI? >> sip router already has XMPP gateways. In order to send instant >> messages or set up calls to URI's in the XMPP name space, it's easier >> to use that than having to mangle it with various strange methods. >> >> >> MESSAGE sip:inaki(a)aliax.net >> From: xmpp:oej(a)edvina.net >> To: sip:inaki(a)aliax.net >> >> See? >=20 > This means that the receipt of the request (my softphone) should also allow= =20 > XMPP URI to display the From. Since no RFC states it, why should my softpho= ne=20 > implement it? Because RFC 3261 defines it: From =3D ( "From" / "f" ) HCOLON from-spec from-spec =3D ( name-addr / addr-spec ) *( SEMI from-param ) addr-spec =3D SIP-URI / SIPS-URI / absoluteURI ^^^^^^^^^^^^^^ regards klaus --===============1207217511==-- From jan@iptel.org Fri Aug 7 13:35:59 2009 From: Jan Janak To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: tls: Set internal module name to "tls". Date: Fri, 07 Aug 2009 13:35:58 +0200 Message-ID: <20090807113558.80F22EF8070@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1687156659==" --===============1687156659== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: a2bae03c1760ea5764728e3611ee82161270bedd URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3Da2bae03c1760ea5764728e3611ee82161270bedd Author: Jan Janak Committer: Jan Janak Date: Fri Aug 7 13:35:39 2009 +0200 tls: Set internal module name to "tls". Set module name to "tls", not "tlsops". Reported by M=C3=89SZ=C3=81ROS Mih=C3=A1ly --- modules/tls/tls_mod.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules/tls/tls_mod.c b/modules/tls/tls_mod.c index 7f79ce8..f0499e2 100644 --- a/modules/tls/tls_mod.c +++ b/modules/tls/tls_mod.c @@ -224,7 +224,7 @@ static param_export_t params[] =3D { * Module interface */ struct module_exports exports =3D { - "tlsops",=20 + "tls",=20 DEFAULT_DLFLAGS, /* dlopen flags */ cmds, /* Exported functions */ params, /* Exported parameters */ --===============1687156659==-- From ibc@aliax.net Fri Aug 7 13:36:20 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Fri, 07 Aug 2009 13:35:49 +0200 Message-ID: In-Reply-To: <4A7C1144.6060600@pernau.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0586955972==" --===============0586955972== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 2009/8/7 Klaus Darilion : >>> MESSAGE sip:inaki(a)aliax.net >>> From: xmpp:oej(a)edvina.net >>> To: sip:inaki(a)aliax.net >>> >>> See? >> >> This means that the receipt of the request (my softphone) should also >> allow XMPP URI to display the From. Since no RFC states it, why should my >> softphone implement it? > > Because RFC 3261 defines it: > > From =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D =C2=A0( "From" / "f" ) HCOLON from-spec > from-spec =C2=A0 =3D =C2=A0( name-addr / addr-spec ) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *( SEMI from-param ) > addr-spec =C2=A0 =C2=A0 =C2=A0=3D =C2=A0SIP-URI / SIPS-URI / absoluteURI > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^= ^^^^^^ Yes, I know. However I would like to know how many implementations would accept it and don't reject the request :( --=20 I=C3=B1aki Baz Castillo --===============0586955972==-- From ibc@aliax.net Fri Aug 7 13:42:00 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] About SIP and TEL uri in SR Date: Fri, 07 Aug 2009 13:41:28 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0631032472==" --===============0631032472== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 2009/8/7 I=C3=B1aki Baz Castillo : >>> This means that the receipt of the request (my softphone) should also >>> allow XMPP URI to display the From. Since no RFC states it, why should my >>> softphone implement it? >> >> Because RFC 3261 defines it: >> >> From =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D =C2=A0( "From" / "f" ) HCOLON from-spec >> from-spec =C2=A0 =3D =C2=A0( name-addr / addr-spec ) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *( SEMI from-param ) >> addr-spec =C2=A0 =C2=A0 =C2=A0=3D =C2=A0SIP-URI / SIPS-URI / absoluteURI >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^ > > > Yes, I know. However I would like to know how many implementations > would accept it and don't reject the request :( Also, please suggest me what would be the content of $fu, $fU, $fd in the following cases: a) From: ;tag=3D1234567 b) From: ;tag=3D123123 c) From: ;tag=3D12234234 :) --=20 I=C3=B1aki Baz Castillo --===============0631032472==-- From jan@iptel.org Fri Aug 7 14:20:01 2009 From: Jan Janak To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: auth_identity: Add -lrt and -ldap to the list of libraries Date: Fri, 07 Aug 2009 14:20:01 +0200 Message-ID: <20090807122001.652B3EF8070@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1938102753==" --===============1938102753== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: 20747a3a7ce264b8f6bef5e79d2d49ba107c6259 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3D20747a3a7ce264b8f6bef5e79d2d49ba107c6259 Author: Jan Janak Committer: Jan Janak Date: Fri Aug 7 14:19:36 2009 +0200 auth_identity: Add -lrt and -ldap to the list of libraries Two more libraries are needed when compiling auth_identity module statically, -lrt and -lldap. Reported by M=C3=89SZ=C3=81ROS Mih=C3=A1ly --- modules_s/auth_identity/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules_s/auth_identity/Makefile b/modules_s/auth_identity/Makef= ile index 9828cbe..f4974b0 100644 --- a/modules_s/auth_identity/Makefile +++ b/modules_s/auth_identity/Makefile @@ -13,7 +13,7 @@ LIBS+=3D -L$(LOCALBASE)/lib -L$(LOCALBASE)/ssl/lib -lssl -l= crypto -lcurl # # Static linking, if you'd like to use TLS and AUTH_IDENTITY at the same time # -#LIBS+=3D /usr/lib/libcurl.a /usr/lib/libssl.a /usr/lib/libcrypto.a -lkrb5 -= lidn -lz -lgssapi_krb5 +#LIBS+=3D /usr/lib/libcurl.a /usr/lib/libssl.a /usr/lib/libcrypto.a -lkrb5 -= lidn -lz -lgssapi_krb5 -lrt -lldap =20 DEFS+=3D-DSER_MOD_INTERFACE =20 --===============1938102753==-- From sobomax@sippysoft.com Tue Aug 11 01:24:38 2009 From: Maxim Sobolev To: sr-dev@lists.kamailio.org Subject: [sr-dev] CVS:commitlog: rtpproxy main.c rtpp_command.c rtpp_defines.h rtpp_network.c rtpp_network.h Date: Tue, 11 Aug 2009 01:24:06 +0200 Message-ID: <20090810232406.C39EB187F81@mail.berlios.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1604970978==" --===============1604970978== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable sobomax 2009/08/11 01:24:06 CEST SER CVS Repository Modified files: . main.c rtpp_command.c rtpp_defines.h=20 rtpp_network.c rtpp_network.h=20 Log: Introduce automatic bridging functionality. The way it works is that the RTPproxy expects signalling layer (B2BUA, Sip Proxy etc) to let it know either local IP for media or remote IP for this particular call leg. If the local IP is specified, then it will be used verbatim, otherwise the local address will be determined automatically based on remote IP and result of dummy connect(2)/getsockname(2) calls. Both IPv6 and IPv4 addresses are supported. =20 Internally feature is implemented as an extension to the U/L command. option "l" should be used for local addresses, or option "r" for remote, with IPv6 address enclosed into square brackets. For example: =20 Ul[abcd:efgh:0:1] callid remote_ip remote_port fromtag =20 Lr1.2.3.4 callid remote_ip remote_port fromtag totag =20 Changes to OpenSIPS, Kamalio/SER and Sippy B2BUA are to follow. =20 Sponsored by: Evision GmbH =20 Revision Changes Path 1.92 +8 -8 rtpproxy/main.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/main.c.diff?r1=3D1.91&= r2=3D1.92 1.29 +76 -6 rtpproxy/rtpp_command.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_command.c.diff?r1= =3D1.28&r2=3D1.29 1.27 +7 -1 rtpproxy/rtpp_defines.h http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_defines.h.diff?r1= =3D1.26&r2=3D1.27 1.16 +97 -2 rtpproxy/rtpp_network.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_network.c.diff?r1= =3D1.15&r2=3D1.16 1.21 +8 -2 rtpproxy/rtpp_network.h http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_network.h.diff?r1= =3D1.20&r2=3D1.21 --===============1604970978==-- From henning.westerholt@1und1.de Tue Aug 11 17:22:20 2009 From: Henning Westerholt To: sr-dev@lists.kamailio.org Subject: [sr-dev] SF.net SVN: openser:[5911] branches Date: Tue, 11 Aug 2009 15:22:18 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1985204536==" --===============1985204536== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Revision: 5911 http://openser.svn.sourceforge.net/openser/?rev=3D5911&view=3Drev Author: henningw Date: 2009-08-11 15:22:17 +0000 (Tue, 11 Aug 2009) Log Message: ----------- - fix stupid bug related to the (legacy..) prime_route function Modified Paths: -------------- branches/1.4/modules/carrierroute/carrierroute.c branches/1.5/modules/carrierroute/carrierroute.c This was sent by the SourceForge.net collaborative development platform, the = world's largest Open Source development site. --===============1985204536==-- From misi@niif.hu Wed Aug 12 21:13:48 2009 From: =?utf-8?b?TcOJU1rDgVJPUyBNaWjDoWx5?= To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Devel] [SR-Dev] TLS merge Date: Wed, 12 Aug 2009 21:13:40 +0200 Message-ID: <4A831464.4040704@niif.hu> In-Reply-To: <20090224101201.GA1699@shell> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1976799001==" --===============1976799001== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Andrei et al. > BTW: for anybody trying to use tls with sip-router: the tls module > doesn't yet support the tcp async mode, so if you try to use it make > sure tcp_buf_write=no (there are still some changes at the tcp level > required for tls async and I haven't finished them yet). > > Andrei > > May i ask from You about Your plan "Async TLS" ? Are You, or any of You working on Async TLS currently? Are any plan to continue and finish the implementation this feature? Regards, Misi --===============1976799001==-- From inge@legos.fr Thu Aug 13 13:47:41 2009 From: inge To: sr-dev@lists.kamailio.org Subject: [sr-dev] SER crash : Segmentation fault Date: Thu, 13 Aug 2009 13:47:09 +0200 Message-ID: <1250164029.6784.5.camel@legos01.legos.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1246334802==" --===============1246334802== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi all, My SER process had crashed today with the following logs in /var/log/messages : ser[378]: child process 418 exited by a signal 11 ser[378]: core was generated ser[378]: INFO: terminating due to SIGCHLD ser[421]: INFO: signal 15 received ... Can someone help me to determine what kind of problem is it ? I think I need to use gdb to extract some information from the core dump. How can I use it to extract the uses informations ? Regards, Adrien --===============1246334802==-- From klaus.mailinglists@pernau.at Thu Aug 13 13:54:11 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] SER crash : Segmentation fault Date: Thu, 13 Aug 2009 13:53:40 +0200 Message-ID: <4A83FEC4.2040100@pernau.at> In-Reply-To: <1250164029.6784.5.camel@legos01.legos.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0327081726==" --===============0327081726== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit locate the core file (either in the working dir or /tmp or /) then execute: gdb /usr/local/sbin/ser /path/to/core (gdb) bt regards klaus inge schrieb: > Hi all, > > My SER process had crashed today with the following logs > in /var/log/messages : > > ser[378]: child process 418 exited by a signal 11 > ser[378]: core was generated > ser[378]: INFO: terminating due to SIGCHLD > ser[421]: INFO: signal 15 received > ... > > Can someone help me to determine what kind of problem is it ? I think I > need to use gdb to extract some information from the core dump. How can > I use it to extract the uses informations ? > > Regards, > > Adrien > > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --===============0327081726==-- From inge@legos.fr Thu Aug 13 15:32:31 2009 From: inge To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] SER crash : Segmentation fault Date: Thu, 13 Aug 2009 15:32:00 +0200 Message-ID: <1250170320.6914.1.camel@legos01.legos.fr> In-Reply-To: <4A83FEC4.2040100@pernau.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0649933928==" --===============0649933928== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Klaus, Thanks. I put the output of gdb in attached. I hope someone can decrypt this. Thank you. Regards, Adrien Le jeudi 13 août 2009 à 13:53 +0200, Klaus Darilion a écrit : > locate the core file (either in the working dir or /tmp or /) > then execute: > > gdb /usr/local/sbin/ser /path/to/core > (gdb) bt > > regards > klaus > > inge schrieb: > > Hi all, > > > > My SER process had crashed today with the following logs > > in /var/log/messages : > > > > ser[378]: child process 418 exited by a signal 11 > > ser[378]: core was generated > > ser[378]: INFO: terminating due to SIGCHLD > > ser[421]: INFO: signal 15 received > > ... > > > > Can someone help me to determine what kind of problem is it ? I think I > > need to use gdb to extract some information from the core dump. How can > > I use it to extract the uses informations ? > > > > Regards, > > > > Adrien > > > > > > _______________________________________________ > > sr-dev mailing list > > sr-dev(a)lists.sip-router.org > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --===============0649933928== Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="090813_dump_ser.txt" MIME-Version: 1.0 IzAgIDB4MDBlOTY0ZDMgaW4gbWF0Y2hpbmdfMzI2MSAocF9tc2c9MHg4MTY0N2U4LCB0cmFucz0w eGJmZjc0ZjM4LCBza2lwX21ldGhvZD00Mjk0OTY3Mjk0KSBhdCB0X2xvb2t1cC5jOjIyMgoyMjIg ICAgICAgICAgICAgaWYgKG1lbWNtcChnZXRfdG8oYWNrKS0+dGFnX3ZhbHVlLnMscF9jZWxsLT51 YXMubG9jYWxfdG90YWcucywKKGdkYikgYnQKIzAgIDB4MDBlOTY0ZDMgaW4gbWF0Y2hpbmdfMzI2 MSAocF9tc2c9MHg4MTY0N2U4LCB0cmFucz0weGJmZjc0ZjM4LCBza2lwX21ldGhvZD00Mjk0OTY3 Mjk0KSBhdCB0X2xvb2t1cC5jOjIyMgojMSAgMHgwMGU5NmFmZiBpbiB0X2xvb2t1cF9yZXF1ZXN0 IChwX21zZz0weDgxNjQ3ZTgsIGxlYXZlX25ld19sb2NrZWQ9MSkgYXQgdF9sb29rdXAuYzo0MjEK IzIgIDB4MDBlOTkyYTAgaW4gdF9uZXd0cmFuIChwX21zZz0weDgxNjQ3ZTgpIGF0IHRfbG9va3Vw LmM6MTA4NQojMyAgMHgwMGU5MTE2YSBpbiB0X3JlbGF5X3RvIChwX21zZz0weDgxNjQ3ZTgsIHBy b3h5PTB4MCwgcHJvdG89MCwgcmVwbGljYXRlPTApIGF0IHRfZnVuY3MuYzoyMjQKIzQgIDB4MDBl OWM0MTAgaW4gd190X3JlbGF5IChwX21zZz0weDgxNjQ3ZTgsIF9mb289MHgwLCBfYmFyPTB4MCkg YXQgdG0uYzo4ODkKIzUgIDB4MDgwNGZjODEgaW4gZG9fYWN0aW9uIChhPTB4ODExNzgxOCwgbXNn PTB4ODE2NDdlOCkgYXQgYWN0aW9uLmM6NjEwCiM2ICAweDA4MDUwOTlkIGluIHJ1bl9hY3Rpb25z IChhPTB4ODExNzgxOCwgbXNnPTB4ODE2NDdlOCkgYXQgYWN0aW9uLmM6NzE4CiM3ICAweDA4MDcz ZjA4IGluIGV2YWxfZWxlbSAoZT0weDgxMTc4NDAsIG1zZz0weDgxNjQ3ZTgpIGF0IHJvdXRlLmM6 NjA1CiM4ICAweDA4MDc0MzkyIGluIGV2YWxfZXhwciAoZT0weDgxMTc4NDAsIG1zZz0weDgxNjQ3 ZTgpIGF0IHJvdXRlLmM6NjU0CiM5ICAweDA4MDc0M2NlIGluIGV2YWxfZXhwciAoZT0weDgxMTc4 NjAsIG1zZz0weDgxNjQ3ZTgpIGF0IHJvdXRlLmM6NjcwCiMxMCAweDA4MDRlYzk1IGluIGRvX2Fj dGlvbiAoYT0weDgxMTdiYzgsIG1zZz0weDgxNjQ3ZTgpIGF0IGFjdGlvbi5jOjU4NgojMTEgMHgw ODA1MDk5ZCBpbiBydW5fYWN0aW9ucyAoYT0weDgxMTc2MzAsIG1zZz0weDgxNjQ3ZTgpIGF0IGFj dGlvbi5jOjcxOAojMTIgMHgwODA0ZmZkZiBpbiBkb19hY3Rpb24gKGE9MHg4MTE0ZjcwLCBtc2c9 MHg4MTY0N2U4KSBhdCBhY3Rpb24uYzozNzUKIzEzIDB4MDgwNTA5OWQgaW4gcnVuX2FjdGlvbnMg KGE9MHg4MTE0ZjcwLCBtc2c9MHg4MTY0N2U4KSBhdCBhY3Rpb24uYzo3MTgKIzE0IDB4MDgwNGVj ZDMgaW4gZG9fYWN0aW9uIChhPTB4ODExNGZjMCwgbXNnPTB4ODE2NDdlOCkgYXQgYWN0aW9uLmM6 NjAzCiMxNSAweDA4MDUwOTlkIGluIHJ1bl9hY3Rpb25zIChhPTB4ODExNGZjMCwgbXNnPTB4ODE2 NDdlOCkgYXQgYWN0aW9uLmM6NzE4CiMxNiAweDA4MDRlY2QzIGluIGRvX2FjdGlvbiAoYT0weDgx MTRmZTgsIG1zZz0weDgxNjQ3ZTgpIGF0IGFjdGlvbi5jOjYwMwojMTcgMHgwODA1MDk5ZCBpbiBy dW5fYWN0aW9ucyAoYT0weDgxMTRmZTgsIG1zZz0weDgxNjQ3ZTgpIGF0IGFjdGlvbi5jOjcxOAoj MTggMHgwODA0ZWNkMyBpbiBkb19hY3Rpb24gKGE9MHg4MTE1MDEwLCBtc2c9MHg4MTY0N2U4KSBh dCBhY3Rpb24uYzo2MDMKIzE5IDB4MDgwNTA5OWQgaW4gcnVuX2FjdGlvbnMgKGE9MHg4MTE1MDEw LCBtc2c9MHg4MTY0N2U4KSBhdCBhY3Rpb24uYzo3MTgKIzIwIDB4MDgwNGVjZDMgaW4gZG9fYWN0 aW9uIChhPTB4ODExNTAzOCwgbXNnPTB4ODE2NDdlOCkgYXQgYWN0aW9uLmM6NjAzCiMyMSAweDA4 MDUwOTlkIGluIHJ1bl9hY3Rpb25zIChhPTB4ODExNTAzOCwgbXNnPTB4ODE2NDdlOCkgYXQgYWN0 aW9uLmM6NzE4CiMyMiAweDA4MDRlY2QzIGluIGRvX2FjdGlvbiAoYT0weDgxMTUwNjAsIG1zZz0w eDgxNjQ3ZTgpIGF0IGFjdGlvbi5jOjYwMwojMjMgMHgwODA1MDk5ZCBpbiBydW5fYWN0aW9ucyAo YT0weDgxMGZlODgsIG1zZz0weDgxNjQ3ZTgpIGF0IGFjdGlvbi5jOjcxOAojMjQgMHgwODA2ZDA2 MiBpbiByZWNlaXZlX21zZyAoCiAgICBidWY9MHg4MGQ2MWUwICJBQ0sgc2lwOjAzODk3MTk2NDFA ZG9tYWluLnRsZDo1MDYwIFNJUC8yLjBcclxuTWF4LUZvcndhcmRzOiAxNlxyXG5Db250ZW50LUxl bmd0aDogMFxyXG5WaWE6IFNJUC8yLjAvVURQIDEwLjAuMTQwLjE0Nzo1MDYwO2JyYW5jaD16OWhH NGJLNGYxYjg1NzFjXHJcbkNhbGwtSUQ6IGJmODVjNzZhNWUyMDY2MjU2Njc5ZTM5NDVmNmI0ZTM2 QDEwLjAuMTQwLjE0N1xyXG5GIi4uLiwgbGVuPTU5MiwgcmN2X2luZm89MHhiZmY3NjM0MCkgYXQg cmVjZWl2ZS5jOjE2NQojMjUgMHgwODA4NDNjYyBpbiB1ZHBfcmN2X2xvb3AgKCkgYXQgdWRwX3Nl cnZlci5jOjQ3MgojMjYgMHgwODA1Y2RhZiBpbiBtYWluX2xvb3AgKCkgYXQgbWFpbi5jOjEwNTYK IzI3IDB4MDgwNWU0MGIgaW4gbWFpbiAoYXJnYz0xLCBhcmd2PTB4YmZmNzY1MDQpIGF0IG1haW4u YzoxNTkyCgo= --===============0649933928==-- From henning.westerholt@1und1.de Fri Aug 14 13:57:33 2009 From: Henning Westerholt To: sr-dev@lists.kamailio.org Subject: [sr-dev] SF.net SVN: openser:[5912] branches/1.5/modules/textops/textops.c Date: Fri, 14 Aug 2009 11:57:30 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0233080158==" --===============0233080158== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Revision: 5912 http://openser.svn.sourceforge.net/openser/?rev=3D5912&view=3Drev Author: henningw Date: 2009-08-14 11:57:30 +0000 (Fri, 14 Aug 2009) Log Message: ----------- * port from sr: b3e2889f22db1 * filter_body function now takes multipart/mixed boundary string from Content-Type ;boundary parameter Modified Paths: -------------- branches/1.5/modules/textops/textops.c This was sent by the SourceForge.net collaborative development platform, the = world's largest Open Source development site. --===============0233080158==-- From andrei@iptel.org Fri Aug 14 14:46:19 2009 From: Andrei Pelinescu-Onciul To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] SER crash : Segmentation fault Date: Fri, 14 Aug 2009 14:45:48 +0200 Message-ID: <20090814124548.GS22992@shell.iptel.org> In-Reply-To: <1250170320.6914.1.camel@legos01.legos.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1082423727==" --===============1082423727== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Aug 13, 2009 at 15:32, inge wrote: > Hi Klaus, >=20 > Thanks. >=20 > I put the output of gdb in attached. >=20 > I hope someone can decrypt this. Thank you. If you are using ser 2.1/latest cvs or sip-router then just update to the latest cvs or git. It's a known fixed bug (sip router git 6fcd5e or ser 2.1 commit starting with "rr: fix from header access"). If you are using another version then tell me which one (ser -V)=20 and I'll fix it. Andrei >=20 > Le jeudi 13 ao??t 2009 ?? 13:53 +0200, Klaus Darilion a ??crit : > > locate the core file (either in the working dir or /tmp or /) > > then execute: > >=20 > > gdb /usr/local/sbin/ser /path/to/core > > (gdb) bt > >=20 > > regards > > klaus > >=20 > > inge schrieb: > > > Hi all, > > >=20 > > > My SER process had crashed today with the following logs > > > in /var/log/messages :=20 > > >=20 > > > ser[378]: child process 418 exited by a signal 11 > > > ser[378]: core was generated > > > ser[378]: INFO: terminating due to SIGCHLD > > > ser[421]: INFO: signal 15 received > > > ... > > >=20 > > > Can someone help me to determine what kind of problem is it ? I think I > > > need to use gdb to extract some information from the core dump. How can > > > I use it to extract the uses informations ? > > >=20 > > > Regards, > > >=20 > > > Adrien > > >=20 > > >=20 > > > _______________________________________________ > > > sr-dev mailing list > > > sr-dev(a)lists.sip-router.org > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74f38, ski= p_method=3D4294967294) at t_lookup.c:222 > 222 if (memcmp(get_to(ack)->tag_value.s,p_cell->uas.local_totag= .s, > (gdb) bt > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74f38, ski= p_method=3D4294967294) at t_lookup.c:222 > #1 0x00e96aff in t_lookup_request (p_msg=3D0x81647e8, leave_new_locked=3D1= ) at t_lookup.c:421 > #2 0x00e992a0 in t_newtran (p_msg=3D0x81647e8) at t_lookup.c:1085 > #3 0x00e9116a in t_relay_to (p_msg=3D0x81647e8, proxy=3D0x0, proto=3D0, re= plicate=3D0) at t_funcs.c:224 > #4 0x00e9c410 in w_t_relay (p_msg=3D0x81647e8, _foo=3D0x0, _bar=3D0x0) at = tm.c:889 > #5 0x0804fc81 in do_action (a=3D0x8117818, msg=3D0x81647e8) at action.c:610 > #6 0x0805099d in run_actions (a=3D0x8117818, msg=3D0x81647e8) at action.c:= 718 > #7 0x08073f08 in eval_elem (e=3D0x8117840, msg=3D0x81647e8) at route.c:605 > #8 0x08074392 in eval_expr (e=3D0x8117840, msg=3D0x81647e8) at route.c:654 > #9 0x080743ce in eval_expr (e=3D0x8117860, msg=3D0x81647e8) at route.c:670 > #10 0x0804ec95 in do_action (a=3D0x8117bc8, msg=3D0x81647e8) at action.c:586 > #11 0x0805099d in run_actions (a=3D0x8117630, msg=3D0x81647e8) at action.c:= 718 > #12 0x0804ffdf in do_action (a=3D0x8114f70, msg=3D0x81647e8) at action.c:375 > #13 0x0805099d in run_actions (a=3D0x8114f70, msg=3D0x81647e8) at action.c:= 718 > #14 0x0804ecd3 in do_action (a=3D0x8114fc0, msg=3D0x81647e8) at action.c:603 > #15 0x0805099d in run_actions (a=3D0x8114fc0, msg=3D0x81647e8) at action.c:= 718 > #16 0x0804ecd3 in do_action (a=3D0x8114fe8, msg=3D0x81647e8) at action.c:603 > #17 0x0805099d in run_actions (a=3D0x8114fe8, msg=3D0x81647e8) at action.c:= 718 > #18 0x0804ecd3 in do_action (a=3D0x8115010, msg=3D0x81647e8) at action.c:603 > #19 0x0805099d in run_actions (a=3D0x8115010, msg=3D0x81647e8) at action.c:= 718 > #20 0x0804ecd3 in do_action (a=3D0x8115038, msg=3D0x81647e8) at action.c:603 > #21 0x0805099d in run_actions (a=3D0x8115038, msg=3D0x81647e8) at action.c:= 718 > #22 0x0804ecd3 in do_action (a=3D0x8115060, msg=3D0x81647e8) at action.c:603 > #23 0x0805099d in run_actions (a=3D0x810fe88, msg=3D0x81647e8) at action.c:= 718 > #24 0x0806d062 in receive_msg ( > buf=3D0x80d61e0 "ACK sip:0389719641(a)domain.tld:5060 SIP/2.0\r\nMax-Fo= rwards: 16\r\nContent-Length: 0\r\nVia: SIP/2.0/UDP 10.0.140.147:5060;branch= =3Dz9hG4bK4f1b8571c\r\nCall-ID: bf85c76a5e2066256679e3945f6b4e36(a)10.0.140.1= 47\r\nF"..., len=3D592, rcv_info=3D0xbff76340) at receive.c:165 > #25 0x080843cc in udp_rcv_loop () at udp_server.c:472 > #26 0x0805cdaf in main_loop () at main.c:1056 > #27 0x0805e40b in main (argc=3D1, argv=3D0xbff76504) at main.c:1592 >=20 > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --===============1082423727==-- From andrei@iptel.org Fri Aug 14 14:50:16 2009 From: Andrei Pelinescu-Onciul To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Devel] [SR-Dev] TLS merge Date: Fri, 14 Aug 2009 14:49:45 +0200 Message-ID: <20090814124944.GT22992@shell.iptel.org> In-Reply-To: <4A831464.4040704@niif.hu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1523751426==" --===============1523751426== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Aug 12, 2009 at 21:13, M?SZ?ROS Mih?ly wrote: > Hi Andrei et al. > >BTW: for anybody trying to use tls with sip-router: the tls module > >doesn't yet support the tcp async mode, so if you try to use it make > >sure tcp_buf_write=no (there are still some changes at the tcp level > >required for tls async and I haven't finished them yet). > > > >Andrei > > > > > May i ask from You about Your plan "Async TLS" ? > Are You, or any of You working on Async TLS currently? No, I'm not working on it right now. I'll probably do it later in the autumn (after the September release) if there's enough interest in it and something more important won't come up. I was planning to do it this summer, but lots of merge fixes + holidays kept me from working on it so far. > Are any plan to continue and finish the implementation this feature? > Yes, is just that more urgent things keep comming up :-) Andrei --===============1523751426==-- From inge@legos.fr Fri Aug 14 15:02:16 2009 From: inge To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] SER crash : Segmentation fault Date: Fri, 14 Aug 2009 15:01:42 +0200 Message-ID: <1250254903.8409.2.camel@legos01.legos.fr> In-Reply-To: <20090814124548.GS22992@shell.iptel.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1220673556==" --===============1220673556== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Andrei, Thanks for your reply. I use ser 0.9.5-pre4.=20 I don't really understand the bug you have identify, where can I find a description ? Regards, Adrien Le vendredi 14 ao=C3=BBt 2009 =C3=A0 14:45 +0200, Andrei Pelinescu-Onciul a =C3=A9crit : > On Aug 13, 2009 at 15:32, inge wrote: > > Hi Klaus, > >=20 > > Thanks. > >=20 > > I put the output of gdb in attached. > >=20 > > I hope someone can decrypt this. Thank you. >=20 >=20 > If you are using ser 2.1/latest cvs or sip-router then just update to > the latest cvs or git. It's a known fixed bug (sip router > git 6fcd5e or ser 2.1 commit starting with "rr: fix from header > access"). >=20 > If you are using another version then tell me which one (ser -V)=20 > and I'll fix it. >=20 > Andrei >=20 > >=20 > > Le jeudi 13 ao??t 2009 ?? 13:53 +0200, Klaus Darilion a ??crit : > > > locate the core file (either in the working dir or /tmp or /) > > > then execute: > > >=20 > > > gdb /usr/local/sbin/ser /path/to/core > > > (gdb) bt > > >=20 > > > regards > > > klaus > > >=20 > > > inge schrieb: > > > > Hi all, > > > >=20 > > > > My SER process had crashed today with the following logs > > > > in /var/log/messages :=20 > > > >=20 > > > > ser[378]: child process 418 exited by a signal 11 > > > > ser[378]: core was generated > > > > ser[378]: INFO: terminating due to SIGCHLD > > > > ser[421]: INFO: signal 15 received > > > > ... > > > >=20 > > > > Can someone help me to determine what kind of problem is it ? I think= I > > > > need to use gdb to extract some information from the core dump. How c= an > > > > I use it to extract the uses informations ? > > > >=20 > > > > Regards, > > > >=20 > > > > Adrien > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > sr-dev mailing list > > > > sr-dev(a)lists.sip-router.org > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >=20 > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74f38, s= kip_method=3D4294967294) at t_lookup.c:222 > > 222 if (memcmp(get_to(ack)->tag_value.s,p_cell->uas.local_tot= ag.s, > > (gdb) bt > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74f38, s= kip_method=3D4294967294) at t_lookup.c:222 > > #1 0x00e96aff in t_lookup_request (p_msg=3D0x81647e8, leave_new_locked= =3D1) at t_lookup.c:421 > > #2 0x00e992a0 in t_newtran (p_msg=3D0x81647e8) at t_lookup.c:1085 > > #3 0x00e9116a in t_relay_to (p_msg=3D0x81647e8, proxy=3D0x0, proto=3D0, = replicate=3D0) at t_funcs.c:224 > > #4 0x00e9c410 in w_t_relay (p_msg=3D0x81647e8, _foo=3D0x0, _bar=3D0x0) a= t tm.c:889 > > #5 0x0804fc81 in do_action (a=3D0x8117818, msg=3D0x81647e8) at action.c:= 610 > > #6 0x0805099d in run_actions (a=3D0x8117818, msg=3D0x81647e8) at action.= c:718 > > #7 0x08073f08 in eval_elem (e=3D0x8117840, msg=3D0x81647e8) at route.c:6= 05 > > #8 0x08074392 in eval_expr (e=3D0x8117840, msg=3D0x81647e8) at route.c:6= 54 > > #9 0x080743ce in eval_expr (e=3D0x8117860, msg=3D0x81647e8) at route.c:6= 70 > > #10 0x0804ec95 in do_action (a=3D0x8117bc8, msg=3D0x81647e8) at action.c:= 586 > > #11 0x0805099d in run_actions (a=3D0x8117630, msg=3D0x81647e8) at action.= c:718 > > #12 0x0804ffdf in do_action (a=3D0x8114f70, msg=3D0x81647e8) at action.c:= 375 > > #13 0x0805099d in run_actions (a=3D0x8114f70, msg=3D0x81647e8) at action.= c:718 > > #14 0x0804ecd3 in do_action (a=3D0x8114fc0, msg=3D0x81647e8) at action.c:= 603 > > #15 0x0805099d in run_actions (a=3D0x8114fc0, msg=3D0x81647e8) at action.= c:718 > > #16 0x0804ecd3 in do_action (a=3D0x8114fe8, msg=3D0x81647e8) at action.c:= 603 > > #17 0x0805099d in run_actions (a=3D0x8114fe8, msg=3D0x81647e8) at action.= c:718 > > #18 0x0804ecd3 in do_action (a=3D0x8115010, msg=3D0x81647e8) at action.c:= 603 > > #19 0x0805099d in run_actions (a=3D0x8115010, msg=3D0x81647e8) at action.= c:718 > > #20 0x0804ecd3 in do_action (a=3D0x8115038, msg=3D0x81647e8) at action.c:= 603 > > #21 0x0805099d in run_actions (a=3D0x8115038, msg=3D0x81647e8) at action.= c:718 > > #22 0x0804ecd3 in do_action (a=3D0x8115060, msg=3D0x81647e8) at action.c:= 603 > > #23 0x0805099d in run_actions (a=3D0x810fe88, msg=3D0x81647e8) at action.= c:718 > > #24 0x0806d062 in receive_msg ( > > buf=3D0x80d61e0 "ACK sip:0389719641(a)domain.tld:5060 SIP/2.0\r\nMax-= Forwards: 16\r\nContent-Length: 0\r\nVia: SIP/2.0/UDP 10.0.140.147:5060;branc= h=3Dz9hG4bK4f1b8571c\r\nCall-ID: bf85c76a5e2066256679e3945f6b4e36(a)10.0.140.= 147\r\nF"..., len=3D592, rcv_info=3D0xbff76340) at receive.c:165 > > #25 0x080843cc in udp_rcv_loop () at udp_server.c:472 > > #26 0x0805cdaf in main_loop () at main.c:1056 > > #27 0x0805e40b in main (argc=3D1, argv=3D0xbff76504) at main.c:1592 > >=20 >=20 > > _______________________________________________ > > sr-dev mailing list > > sr-dev(a)lists.sip-router.org > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >=20 --===============1220673556==-- From klaus.mailinglists@pernau.at Fri Aug 14 15:43:30 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] SER crash : Segmentation fault Date: Fri, 14 Aug 2009 15:42:59 +0200 Message-ID: <4A8569E3.2030600@pernau.at> In-Reply-To: <1250254903.8409.2.camel@legos01.legos.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1512230535==" --===============1512230535== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable inge schrieb: > Hi Andrei, >=20 > Thanks for your reply. >=20 > I use ser 0.9.5-pre4.=20 ser 0.9 is very very old. I recommend update to never versions, e.g. - Kamailio 1.5 (stable version of the ser-fork) or - sip-router: development version of ser/Kamailio join regards klaus >=20 > I don't really understand the bug you have identify, where can I find a > description ? >=20 > Regards, >=20 > Adrien >=20 > Le vendredi 14 ao=C3=BBt 2009 =C3=A0 14:45 +0200, Andrei Pelinescu-Onciul a > =C3=A9crit : >> On Aug 13, 2009 at 15:32, inge wrote: >>> Hi Klaus, >>> >>> Thanks. >>> >>> I put the output of gdb in attached. >>> >>> I hope someone can decrypt this. Thank you. >> >> If you are using ser 2.1/latest cvs or sip-router then just update to >> the latest cvs or git. It's a known fixed bug (sip router >> git 6fcd5e or ser 2.1 commit starting with "rr: fix from header >> access"). >> >> If you are using another version then tell me which one (ser -V)=20 >> and I'll fix it. >> >> Andrei >> >>> Le jeudi 13 ao??t 2009 ?? 13:53 +0200, Klaus Darilion a ??crit : >>>> locate the core file (either in the working dir or /tmp or /) >>>> then execute: >>>> >>>> gdb /usr/local/sbin/ser /path/to/core >>>> (gdb) bt >>>> >>>> regards >>>> klaus >>>> >>>> inge schrieb: >>>>> Hi all, >>>>> >>>>> My SER process had crashed today with the following logs >>>>> in /var/log/messages :=20 >>>>> >>>>> ser[378]: child process 418 exited by a signal 11 >>>>> ser[378]: core was generated >>>>> ser[378]: INFO: terminating due to SIGCHLD >>>>> ser[421]: INFO: signal 15 received >>>>> ... >>>>> >>>>> Can someone help me to determine what kind of problem is it ? I think I >>>>> need to use gdb to extract some information from the core dump. How can >>>>> I use it to extract the uses informations ? >>>>> >>>>> Regards, >>>>> >>>>> Adrien >>>>> >>>>> >>>>> _______________________________________________ >>>>> sr-dev mailing list >>>>> sr-dev(a)lists.sip-router.org >>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >>> #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74f38, s= kip_method=3D4294967294) at t_lookup.c:222 >>> 222 if (memcmp(get_to(ack)->tag_value.s,p_cell->uas.local_tot= ag.s, >>> (gdb) bt >>> #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74f38, s= kip_method=3D4294967294) at t_lookup.c:222 >>> #1 0x00e96aff in t_lookup_request (p_msg=3D0x81647e8, leave_new_locked= =3D1) at t_lookup.c:421 >>> #2 0x00e992a0 in t_newtran (p_msg=3D0x81647e8) at t_lookup.c:1085 >>> #3 0x00e9116a in t_relay_to (p_msg=3D0x81647e8, proxy=3D0x0, proto=3D0, = replicate=3D0) at t_funcs.c:224 >>> #4 0x00e9c410 in w_t_relay (p_msg=3D0x81647e8, _foo=3D0x0, _bar=3D0x0) a= t tm.c:889 >>> #5 0x0804fc81 in do_action (a=3D0x8117818, msg=3D0x81647e8) at action.c:= 610 >>> #6 0x0805099d in run_actions (a=3D0x8117818, msg=3D0x81647e8) at action.= c:718 >>> #7 0x08073f08 in eval_elem (e=3D0x8117840, msg=3D0x81647e8) at route.c:6= 05 >>> #8 0x08074392 in eval_expr (e=3D0x8117840, msg=3D0x81647e8) at route.c:6= 54 >>> #9 0x080743ce in eval_expr (e=3D0x8117860, msg=3D0x81647e8) at route.c:6= 70 >>> #10 0x0804ec95 in do_action (a=3D0x8117bc8, msg=3D0x81647e8) at action.c:= 586 >>> #11 0x0805099d in run_actions (a=3D0x8117630, msg=3D0x81647e8) at action.= c:718 >>> #12 0x0804ffdf in do_action (a=3D0x8114f70, msg=3D0x81647e8) at action.c:= 375 >>> #13 0x0805099d in run_actions (a=3D0x8114f70, msg=3D0x81647e8) at action.= c:718 >>> #14 0x0804ecd3 in do_action (a=3D0x8114fc0, msg=3D0x81647e8) at action.c:= 603 >>> #15 0x0805099d in run_actions (a=3D0x8114fc0, msg=3D0x81647e8) at action.= c:718 >>> #16 0x0804ecd3 in do_action (a=3D0x8114fe8, msg=3D0x81647e8) at action.c:= 603 >>> #17 0x0805099d in run_actions (a=3D0x8114fe8, msg=3D0x81647e8) at action.= c:718 >>> #18 0x0804ecd3 in do_action (a=3D0x8115010, msg=3D0x81647e8) at action.c:= 603 >>> #19 0x0805099d in run_actions (a=3D0x8115010, msg=3D0x81647e8) at action.= c:718 >>> #20 0x0804ecd3 in do_action (a=3D0x8115038, msg=3D0x81647e8) at action.c:= 603 >>> #21 0x0805099d in run_actions (a=3D0x8115038, msg=3D0x81647e8) at action.= c:718 >>> #22 0x0804ecd3 in do_action (a=3D0x8115060, msg=3D0x81647e8) at action.c:= 603 >>> #23 0x0805099d in run_actions (a=3D0x810fe88, msg=3D0x81647e8) at action.= c:718 >>> #24 0x0806d062 in receive_msg ( >>> buf=3D0x80d61e0 "ACK sip:0389719641(a)domain.tld:5060 SIP/2.0\r\nMax-= Forwards: 16\r\nContent-Length: 0\r\nVia: SIP/2.0/UDP 10.0.140.147:5060;branc= h=3Dz9hG4bK4f1b8571c\r\nCall-ID: bf85c76a5e2066256679e3945f6b4e36(a)10.0.140.= 147\r\nF"..., len=3D592, rcv_info=3D0xbff76340) at receive.c:165 >>> #25 0x080843cc in udp_rcv_loop () at udp_server.c:472 >>> #26 0x0805cdaf in main_loop () at main.c:1056 >>> #27 0x0805e40b in main (argc=3D1, argv=3D0xbff76504) at main.c:1592 >>> >>> _______________________________________________ >>> sr-dev mailing list >>> sr-dev(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >=20 --===============1512230535==-- From andrei@iptel.org Fri Aug 14 16:34:40 2009 From: Andrei Pelinescu-Onciul To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] SER crash : Segmentation fault Date: Fri, 14 Aug 2009 16:34:09 +0200 Message-ID: <20090814143409.GB7175@shell.iptel.org> In-Reply-To: <1250254903.8409.2.camel@legos01.legos.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1429080944==" --===============1429080944== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Aug 14, 2009 at 15:01, inge wrote: > Hi Andrei, >=20 > Thanks for your reply. >=20 > I use ser 0.9.5-pre4.=20 >=20 > I don't really understand the bug you have identify, where can I find a > description ? Sorry, I was wrong (that bug was in RR and appears only in newer code). Could you run gdb on the core again , type "frame 0" and then send me the=20 output of the following commands: print p_cell print p_msg print p_msg->buf print p_cell->uas.local_totag.len print p_cell->uas.local_totag.s print p_msg->to print p_msg->to->parsed print *((struct to_body*)(p_msg->to->parsed)) print ((struct to_body*)(p_msg->to->parsed))->tag_value.len print ((struct to_body*)(p_msg->to->parsed))->tag_value.s Andrei P.S.: you could try also upgrading to ser 2.0, 2.1 or sip-router. >=20 > Regards, >=20 > Adrien >=20 > Le vendredi 14 ao??t 2009 ?? 14:45 +0200, Andrei Pelinescu-Onciul a > ??crit : > > On Aug 13, 2009 at 15:32, inge wrote: > > > Hi Klaus, > > >=20 > > > Thanks. > > >=20 > > > I put the output of gdb in attached. > > >=20 > > > I hope someone can decrypt this. Thank you. > >=20 > >=20 > > If you are using ser 2.1/latest cvs or sip-router then just update to > > the latest cvs or git. It's a known fixed bug (sip router > > git 6fcd5e or ser 2.1 commit starting with "rr: fix from header > > access"). > >=20 > > If you are using another version then tell me which one (ser -V)=20 > > and I'll fix it. > >=20 > > Andrei > >=20 > > >=20 > > > Le jeudi 13 ao??t 2009 ?? 13:53 +0200, Klaus Darilion a ??crit : > > > > locate the core file (either in the working dir or /tmp or /) > > > > then execute: > > > >=20 > > > > gdb /usr/local/sbin/ser /path/to/core > > > > (gdb) bt > > > >=20 > > > > regards > > > > klaus > > > >=20 > > > > inge schrieb: > > > > > Hi all, > > > > >=20 > > > > > My SER process had crashed today with the following logs > > > > > in /var/log/messages :=20 > > > > >=20 > > > > > ser[378]: child process 418 exited by a signal 11 > > > > > ser[378]: core was generated > > > > > ser[378]: INFO: terminating due to SIGCHLD > > > > > ser[421]: INFO: signal 15 received > > > > > ... > > > > >=20 > > > > > Can someone help me to determine what kind of problem is it ? I thi= nk I > > > > > need to use gdb to extract some information from the core dump. How= can > > > > > I use it to extract the uses informations ? > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Adrien > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > sr-dev mailing list > > > > > sr-dev(a)lists.sip-router.org > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > >=20 > > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74f38,= skip_method=3D4294967294) at t_lookup.c:222 > > > 222 if (memcmp(get_to(ack)->tag_value.s,p_cell->uas.local_t= otag.s, > > > (gdb) bt > > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74f38,= skip_method=3D4294967294) at t_lookup.c:222 > > > #1 0x00e96aff in t_lookup_request (p_msg=3D0x81647e8, leave_new_locked= =3D1) at t_lookup.c:421 > > > #2 0x00e992a0 in t_newtran (p_msg=3D0x81647e8) at t_lookup.c:1085 > > > #3 0x00e9116a in t_relay_to (p_msg=3D0x81647e8, proxy=3D0x0, proto=3D0= , replicate=3D0) at t_funcs.c:224 > > > #4 0x00e9c410 in w_t_relay (p_msg=3D0x81647e8, _foo=3D0x0, _bar=3D0x0)= at tm.c:889 > > > #5 0x0804fc81 in do_action (a=3D0x8117818, msg=3D0x81647e8) at action.= c:610 > > > #6 0x0805099d in run_actions (a=3D0x8117818, msg=3D0x81647e8) at actio= n.c:718 > > > #7 0x08073f08 in eval_elem (e=3D0x8117840, msg=3D0x81647e8) at route.c= :605 > > > #8 0x08074392 in eval_expr (e=3D0x8117840, msg=3D0x81647e8) at route.c= :654 > > > #9 0x080743ce in eval_expr (e=3D0x8117860, msg=3D0x81647e8) at route.c= :670 > > > #10 0x0804ec95 in do_action (a=3D0x8117bc8, msg=3D0x81647e8) at action.= c:586 > > > #11 0x0805099d in run_actions (a=3D0x8117630, msg=3D0x81647e8) at actio= n.c:718 > > > #12 0x0804ffdf in do_action (a=3D0x8114f70, msg=3D0x81647e8) at action.= c:375 > > > #13 0x0805099d in run_actions (a=3D0x8114f70, msg=3D0x81647e8) at actio= n.c:718 > > > #14 0x0804ecd3 in do_action (a=3D0x8114fc0, msg=3D0x81647e8) at action.= c:603 > > > #15 0x0805099d in run_actions (a=3D0x8114fc0, msg=3D0x81647e8) at actio= n.c:718 > > > #16 0x0804ecd3 in do_action (a=3D0x8114fe8, msg=3D0x81647e8) at action.= c:603 > > > #17 0x0805099d in run_actions (a=3D0x8114fe8, msg=3D0x81647e8) at actio= n.c:718 > > > #18 0x0804ecd3 in do_action (a=3D0x8115010, msg=3D0x81647e8) at action.= c:603 > > > #19 0x0805099d in run_actions (a=3D0x8115010, msg=3D0x81647e8) at actio= n.c:718 > > > #20 0x0804ecd3 in do_action (a=3D0x8115038, msg=3D0x81647e8) at action.= c:603 > > > #21 0x0805099d in run_actions (a=3D0x8115038, msg=3D0x81647e8) at actio= n.c:718 > > > #22 0x0804ecd3 in do_action (a=3D0x8115060, msg=3D0x81647e8) at action.= c:603 > > > #23 0x0805099d in run_actions (a=3D0x810fe88, msg=3D0x81647e8) at actio= n.c:718 > > > #24 0x0806d062 in receive_msg ( > > > buf=3D0x80d61e0 "ACK sip:0389719641(a)domain.tld:5060 SIP/2.0\r\nMa= x-Forwards: 16\r\nContent-Length: 0\r\nVia: SIP/2.0/UDP 10.0.140.147:5060;bra= nch=3Dz9hG4bK4f1b8571c\r\nCall-ID: bf85c76a5e2066256679e3945f6b4e36(a)10.0.14= 0.147\r\nF"..., len=3D592, rcv_info=3D0xbff76340) at receive.c:165 > > > #25 0x080843cc in udp_rcv_loop () at udp_server.c:472 > > > #26 0x0805cdaf in main_loop () at main.c:1056 > > > #27 0x0805e40b in main (argc=3D1, argv=3D0xbff76504) at main.c:1592 > > >=20 > >=20 > > > _______________________________________________ > > > sr-dev mailing list > > > sr-dev(a)lists.sip-router.org > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > >=20 --===============1429080944==-- From inge@legos.fr Fri Aug 14 17:03:46 2009 From: inge To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] SER crash : Segmentation fault Date: Fri, 14 Aug 2009 17:03:13 +0200 Message-ID: <1250262193.8409.6.camel@legos01.legos.fr> In-Reply-To: <20090814143409.GB7175@shell.iptel.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2090879299==" --===============2090879299== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Please find the requested information in attached. I'm aware of the need for an update. It's in the list of tasks to be done, however, the priority is to troubleshoot the problem and maybe find a workaround. Regards, Adrien Le vendredi 14 ao=C3=BBt 2009 =C3=A0 16:34 +0200, Andrei Pelinescu-Onciul a =C3=A9crit : > On Aug 14, 2009 at 15:01, inge wrote: > > Hi Andrei, > >=20 > > Thanks for your reply. > >=20 > > I use ser 0.9.5-pre4.=20 > >=20 > > I don't really understand the bug you have identify, where can I find a > > description ? >=20 > Sorry, I was wrong (that bug was in RR and appears only in newer code). >=20 > Could you run gdb on the core again , type "frame 0" and then send me the=20 > output of the following commands: >=20 > print p_cell > print p_msg > print p_msg->buf > print p_cell->uas.local_totag.len > print p_cell->uas.local_totag.s > print p_msg->to > print p_msg->to->parsed > print *((struct to_body*)(p_msg->to->parsed)) > print ((struct to_body*)(p_msg->to->parsed))->tag_value.len > print ((struct to_body*)(p_msg->to->parsed))->tag_value.s >=20 >=20 > Andrei > P.S.: you could try also upgrading to ser 2.0, 2.1 or sip-router. >=20 >=20 > >=20 > > Regards, > >=20 > > Adrien > >=20 > > Le vendredi 14 ao??t 2009 ?? 14:45 +0200, Andrei Pelinescu-Onciul a > > ??crit : > > > On Aug 13, 2009 at 15:32, inge wrote: > > > > Hi Klaus, > > > >=20 > > > > Thanks. > > > >=20 > > > > I put the output of gdb in attached. > > > >=20 > > > > I hope someone can decrypt this. Thank you. > > >=20 > > >=20 > > > If you are using ser 2.1/latest cvs or sip-router then just update to > > > the latest cvs or git. It's a known fixed bug (sip router > > > git 6fcd5e or ser 2.1 commit starting with "rr: fix from header > > > access"). > > >=20 > > > If you are using another version then tell me which one (ser -V)=20 > > > and I'll fix it. > > >=20 > > > Andrei > > >=20 > > > >=20 > > > > Le jeudi 13 ao??t 2009 ?? 13:53 +0200, Klaus Darilion a ??crit : > > > > > locate the core file (either in the working dir or /tmp or /) > > > > > then execute: > > > > >=20 > > > > > gdb /usr/local/sbin/ser /path/to/core > > > > > (gdb) bt > > > > >=20 > > > > > regards > > > > > klaus > > > > >=20 > > > > > inge schrieb: > > > > > > Hi all, > > > > > >=20 > > > > > > My SER process had crashed today with the following logs > > > > > > in /var/log/messages :=20 > > > > > >=20 > > > > > > ser[378]: child process 418 exited by a signal 11 > > > > > > ser[378]: core was generated > > > > > > ser[378]: INFO: terminating due to SIGCHLD > > > > > > ser[421]: INFO: signal 15 received > > > > > > ... > > > > > >=20 > > > > > > Can someone help me to determine what kind of problem is it ? I t= hink I > > > > > > need to use gdb to extract some information from the core dump. H= ow can > > > > > > I use it to extract the uses informations ? > > > > > >=20 > > > > > > Regards, > > > > > >=20 > > > > > > Adrien > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > sr-dev mailing list > > > > > > sr-dev(a)lists.sip-router.org > > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > >=20 > > > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74f3= 8, skip_method=3D4294967294) at t_lookup.c:222 > > > > 222 if (memcmp(get_to(ack)->tag_value.s,p_cell->uas.local= _totag.s, > > > > (gdb) bt > > > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74f3= 8, skip_method=3D4294967294) at t_lookup.c:222 > > > > #1 0x00e96aff in t_lookup_request (p_msg=3D0x81647e8, leave_new_lock= ed=3D1) at t_lookup.c:421 > > > > #2 0x00e992a0 in t_newtran (p_msg=3D0x81647e8) at t_lookup.c:1085 > > > > #3 0x00e9116a in t_relay_to (p_msg=3D0x81647e8, proxy=3D0x0, proto= =3D0, replicate=3D0) at t_funcs.c:224 > > > > #4 0x00e9c410 in w_t_relay (p_msg=3D0x81647e8, _foo=3D0x0, _bar=3D0x= 0) at tm.c:889 > > > > #5 0x0804fc81 in do_action (a=3D0x8117818, msg=3D0x81647e8) at actio= n.c:610 > > > > #6 0x0805099d in run_actions (a=3D0x8117818, msg=3D0x81647e8) at act= ion.c:718 > > > > #7 0x08073f08 in eval_elem (e=3D0x8117840, msg=3D0x81647e8) at route= .c:605 > > > > #8 0x08074392 in eval_expr (e=3D0x8117840, msg=3D0x81647e8) at route= .c:654 > > > > #9 0x080743ce in eval_expr (e=3D0x8117860, msg=3D0x81647e8) at route= .c:670 > > > > #10 0x0804ec95 in do_action (a=3D0x8117bc8, msg=3D0x81647e8) at actio= n.c:586 > > > > #11 0x0805099d in run_actions (a=3D0x8117630, msg=3D0x81647e8) at act= ion.c:718 > > > > #12 0x0804ffdf in do_action (a=3D0x8114f70, msg=3D0x81647e8) at actio= n.c:375 > > > > #13 0x0805099d in run_actions (a=3D0x8114f70, msg=3D0x81647e8) at act= ion.c:718 > > > > #14 0x0804ecd3 in do_action (a=3D0x8114fc0, msg=3D0x81647e8) at actio= n.c:603 > > > > #15 0x0805099d in run_actions (a=3D0x8114fc0, msg=3D0x81647e8) at act= ion.c:718 > > > > #16 0x0804ecd3 in do_action (a=3D0x8114fe8, msg=3D0x81647e8) at actio= n.c:603 > > > > #17 0x0805099d in run_actions (a=3D0x8114fe8, msg=3D0x81647e8) at act= ion.c:718 > > > > #18 0x0804ecd3 in do_action (a=3D0x8115010, msg=3D0x81647e8) at actio= n.c:603 > > > > #19 0x0805099d in run_actions (a=3D0x8115010, msg=3D0x81647e8) at act= ion.c:718 > > > > #20 0x0804ecd3 in do_action (a=3D0x8115038, msg=3D0x81647e8) at actio= n.c:603 > > > > #21 0x0805099d in run_actions (a=3D0x8115038, msg=3D0x81647e8) at act= ion.c:718 > > > > #22 0x0804ecd3 in do_action (a=3D0x8115060, msg=3D0x81647e8) at actio= n.c:603 > > > > #23 0x0805099d in run_actions (a=3D0x810fe88, msg=3D0x81647e8) at act= ion.c:718 > > > > #24 0x0806d062 in receive_msg ( > > > > buf=3D0x80d61e0 "ACK sip:0389719641(a)domain.tld:5060 SIP/2.0\r\n= Max-Forwards: 16\r\nContent-Length: 0\r\nVia: SIP/2.0/UDP 10.0.140.147:5060;b= ranch=3Dz9hG4bK4f1b8571c\r\nCall-ID: bf85c76a5e2066256679e3945f6b4e36(a)10.0.= 140.147\r\nF"..., len=3D592, rcv_info=3D0xbff76340) at receive.c:165 > > > > #25 0x080843cc in udp_rcv_loop () at udp_server.c:472 > > > > #26 0x0805cdaf in main_loop () at main.c:1056 > > > > #27 0x0805e40b in main (argc=3D1, argv=3D0xbff76504) at main.c:1592 > > > >=20 > > >=20 > > > > _______________________________________________ > > > > sr-dev mailing list > > > > sr-dev(a)lists.sip-router.org > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > >=20 --===============2090879299== Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="090814_gdb_ser.txt" MIME-Version: 1.0 IzAgIDB4MDBlOTY0ZDMgaW4gbWF0Y2hpbmdfMzI2MSAocF9tc2c9MHg4MTY0N2U4LCB0cmFucz0w eGJmZjc0ZjM4LCBza2lwX21ldGhvZD00Mjk0OTY3Mjk0KSBhdCB0X2xvb2t1cC5jOjIyMgoyMjIg ICAgICAgICAgICAgaWYgKG1lbWNtcChnZXRfdG8oYWNrKS0+dGFnX3ZhbHVlLnMscF9jZWxsLT51 YXMubG9jYWxfdG90YWcucywKKGdkYikgZnJhbWUgMAojMCAgMHgwMGU5NjRkMyBpbiBtYXRjaGlu Z18zMjYxIChwX21zZz0weDgxNjQ3ZTgsIHRyYW5zPTB4YmZmNzRmMzgsIHNraXBfbWV0aG9kPTQy OTQ5NjcyOTQpIGF0IHRfbG9va3VwLmM6MjIyCjIyMiAgICAgICAgICAgICBpZiAobWVtY21wKGdl dF90byhhY2spLT50YWdfdmFsdWUucyxwX2NlbGwtPnVhcy5sb2NhbF90b3RhZy5zLAooZ2RiKSBw cmludCBwX2NlbGwKJDEgPSAoc3RydWN0IGNlbGwgKikgMHhiNjJiNTU0MAooZ2RiKSBwcmludCBw X21zZwokMiA9IChzdHJ1Y3Qgc2lwX21zZyAqKSAweDgxNjQ3ZTgKKGdkYikgcHJpbnQgcF9tc2ct PmJ1ZgokMyA9IDB4ODBkNjFlMCAiQUNLIHNpcDowMzg5NzE5NjQxQGRvbWFpbi50bGQ6NTA2MCBT SVAvMi4wXHJcbk1heC1Gb3J3YXJkczogMTZcclxuQ29udGVudC1MZW5ndGg6IDBcclxuVmlhOiBT SVAvMi4wL1VEUCAxMC4wLjE0MC4xNDc6NTA2MDticmFuY2g9ejloRzRiSzRmMWI4NTcxY1xyXG5D YWxsLUlEOiBiZjg1Yzc2YTVlMjA2NjI1NjY3OWUzOTQ1ZjZiNGUzNkAxMC4wLjE0MC4xNDdcclxu RiIuLi4KKGdkYikgcHJpbnQgcF9jZWxsLT51YXMubG9jYWxfdG90YWcubGVuCiQ0ID0gMTMKKGdk YikgcHJpbnQgcF9jZWxsLT51YXMubG9jYWxfdG90YWcucwokNSA9IDB4YWUyN2M4NjUgPEFkZHJl c3MgMHhhZTI3Yzg2NSBvdXQgb2YgYm91bmRzPgooZ2RiKSBwcmludCBwX21zZy0+dG8KJDYgPSAo c3RydWN0IGhkcl9maWVsZCAqKSAweDgxNGRkMjAKKGdkYikgcHJpbnQgcF9tc2ctPnRvLT5wYXJz ZWQKJDcgPSAodm9pZCAqKSAweDgxNDllNTgKKGdkYikgcHJpbnQgKigoc3RydWN0IHRvX2JvZHkq KShwX21zZy0+dHAtPnBhcnNlZCkpClRoZXJlIGlzIG5vIG1lbWJlciBuYW1lZCB0cC4KKGdkYikg cHJpbnQgKigoc3RydWN0IHRvX2JvZHkqKShwX21zZy0+dG8tPnBhcnNlZCkpCiQ4ID0ge2Vycm9y ID0gMSwgYm9keSA9IHsKICAgIHMgPSAweDgwZDYyZTcgInNpcDowMzg5NzE5NjQxQGRvbWFpbi50 bGQ6NTA2MDt0YWc9NTNDRDhEODAtMjFCNFxyXG5DU2VxOiAxOTU4NDM0ODAxIEFDS1xyXG5Qcm94 eS1BdXRob3JpemF0aW9uOkRpZ2VzdCByZXNwb25zZT1cImJiNmQxMDU2M2FiZWRjODBjNzEwYmMx NDQ5NTAzYTAwXCIsdXNlcm5hbWU9XCIwMzg5MjQyODk3XCIscmVhbG09XCJkb21haW4udGxkXCIs bm9uY2U9XCI0YTgzZiIuLi4sIGxlbiA9IDMyfSwgdXJpID0gewogICAgcyA9IDB4ODBkNjJlNyAi c2lwOjAzODk3MTk2NDFAZG9tYWluLnRsZDo1MDYwO3RhZz01M0NEOEQ4MC0yMUI0XHJcbkNTZXE6 IDE5NTg0MzQ4MDEgQUNLXHJcblByb3h5LUF1dGhvcml6YXRpb246RGlnZXN0IHJlc3BvbnNlPVwi YmI2ZDEwNTYzYWJlZGM4MGM3MTBiYzE0NDk1MDNhMDBcIix1c2VybmFtZT1cIjAzODkyNDI4OTdc IixyZWFsbT1cImRvbWFpbi50bGRcIixub25jZT1cIjRhODNmIi4uLiwgbGVuID0gMzJ9LCBkaXNw bGF5ID0ge3MgPSAweDAsIGxlbiA9IDB9LCAKICB0YWdfdmFsdWUgPSB7CiAgICBzID0gMHg4MGQ2 MzBjICI1M0NEOEQ4MC0yMUI0XHJcbkNTZXE6IDE5NTg0MzQ4MDEgQUNLXHJcblByb3h5LUF1dGhv cml6YXRpb246RGlnZXN0IHJlc3BvbnNlPVwiYmI2ZDEwNTYzYWJlZGM4MGM3MTBiYzE0NDk1MDNh MDBcIix1c2VybmFtZT1cIjAzODkyNDI4OTdcIixyZWFsbT1cImRvbWFpbi50bGRcIixub25jZT1c IjRhODNmNGEzZDk3YzQ1NjdlYTRhYzZjNmExYmY1N2MzY2ZmODQ2OTZcIiwiLi4uLCBsZW4gPSAx M30sIHBhcmFtX2xzdCA9IDB4ODE1MTRjOCwgCiAgbGFzdF9wYXJhbSA9IDB4ODE1MTRjOH0KKGdk YikgcHJpbnQgKChzdHJ1Y3QgdG9fYm9keSopKHBfbXNnLT50by0+cGFyc2VkKSktPnRhZ192YWx1 ZS5sZW4KJDkgPSAxMwooZ2RiKSBwcmludCAoKHN0cnVjdCB0b19ib2R5KikocF9tc2ctPnRvLT5w YXJzZWQpKS0+dGFnX3ZhbHVlLnMKJDEwID0gMHg4MGQ2MzBjICI1M0NEOEQ4MC0yMUI0XHJcbkNT ZXE6IDE5NTg0MzQ4MDEgQUNLXHJcblByb3h5LUF1dGhvcml6YXRpb246RGlnZXN0IHJlc3BvbnNl PVwiYmI2ZDEwNTYzYWJlZGM4MGM3MTBiYzE0NDk1MDNhMDBcIix1c2VybmFtZT1cIjAzODkyNDI4 OTdcIixyZWFsbT1cImRvbWFpbi50bGRcIixub25jZT1cIjRhODNmNGEzZDk3YzQ1NjdlYTRhYzZj NmExYmY1N2MzY2ZmODQ2OTZcIiwiLi4uCgo= --===============2090879299==-- From gregert@teigre.com Sat Aug 15 17:44:43 2009 From: Greger Viken Teigre To: sr-dev@lists.kamailio.org Subject: [sr-dev] ishexnumber in rtpp_command.c (rtpproxy) Date: Sat, 15 Aug 2009 17:44:39 +0200 Message-ID: <4A86D7E7.2090008@teigre.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2141992513==" --===============2141992513== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On CentOS5 it seems that ishexnumber is available. Is there a reason for why isxdigit cannot be used? g-) --===============2141992513== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+CjxodG1sPgo8aGVhZD4KPC9oZWFkPgo8Ym9keSBiZ2NvbG9yPSIjZmZmZmZmIiB0ZXh0 PSIjMDAwMDAwIj4KPGZvbnQgc2l6ZT0iKzEiPk9uIENlbnRPUzUgaXQgc2VlbXMgdGhhdCBpc2hl eG51bWJlciBpcyBhdmFpbGFibGUuIElzCnRoZXJlIGEgcmVhc29uIGZvciB3aHkgaXN4ZGlnaXQg Y2Fubm90IGJlIHVzZWQ/PGJyPgpnLSk8YnI+CjwvZm9udD4KPC9ib2R5Pgo8L2h0bWw+Cg== --===============2141992513==-- From sobomax@sippysoft.com Sun Aug 16 00:06:25 2009 From: Maxim Sobolev To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] ishexnumber in rtpp_command.c (rtpproxy) Date: Sat, 15 Aug 2009 15:06:07 -0700 Message-ID: <4A87314F.9070505@sippysoft.com> In-Reply-To: <4A86D7E7.2090008@teigre.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1764288076==" --===============1764288076== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Greger Viken Teigre wrote: > On CentOS5 it seems that ishexnumber is available. Is there a reason for > why isxdigit cannot be used? > g-) I will check what we can do about that. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: sales(a)sippysoft.com Skype: SippySoft --===============1764288076==-- From sobomax@sippysoft.com Sun Aug 16 00:08:20 2009 From: Maxim Sobolev To: sr-dev@lists.kamailio.org Subject: [sr-dev] CVS:commitlog: rtpproxy rtpp_command.c Date: Sun, 16 Aug 2009 00:07:46 +0200 Message-ID: <20090815220746.8CDA918D097@mail.berlios.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2021396789==" --===============2021396789== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable sobomax 2009/08/16 00:07:45 CEST SER CVS Repository Modified files: . rtpp_command.c=20 Log: Properly advertize automatic bridging capability. =20 Revision Changes Path 1.30 +2 -1 rtpproxy/rtpp_command.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_command.c.diff?r1= =3D1.29&r2=3D1.30 --===============2021396789==-- From sobomax@sippysoft.com Sun Aug 16 00:20:00 2009 From: Maxim Sobolev To: sr-dev@lists.kamailio.org Subject: [sr-dev] CVS:commitlog: rtpproxy rtpp_network.c Date: Sun, 16 Aug 2009 00:19:29 +0200 Message-ID: <20090815221929.9801F18B6B4@mail.berlios.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0371366521==" --===============0371366521== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable sobomax 2009/08/16 00:19:29 CEST SER CVS Repository Modified files: . rtpp_network.c=20 Log: Use isxdigit(3) instead of ishexnumber(3). The former belongs to C90 standard, while the latter does not. =20 Submitted by: Greger Viken Teigre =20 Revision Changes Path 1.17 +2 -2 rtpproxy/rtpp_network.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_network.c.diff?r1= =3D1.16&r2=3D1.17 --===============0371366521==-- From sobomax@sippysoft.com Sun Aug 16 01:32:41 2009 From: Maxim Sobolev To: sr-dev@lists.kamailio.org Subject: [sr-dev] CVS:commitlog: rtpproxy/debian rtpproxy.init Date: Sun, 16 Aug 2009 01:32:09 +0200 Message-ID: <20090815233209.0AE00E3389@mail.berlios.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1682833656==" --===============1682833656== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable sobomax 2009/08/16 01:32:09 CEST SER CVS Repository Modified files: debian rtpproxy.init=20 Log: Don't use "basename $0", since init.d subsystem starts RTPproxy using symbolic link, whose name K20rtpproxy, S20rtpproxy and so on. =20 Submitted by: Inaki Baz Castillo =20 Revision Changes Path 1.4 +1 -2 rtpproxy/debian/rtpproxy.init http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/debian/rtpproxy.init.d= iff?r1=3D1.3&r2=3D1.4 --===============1682833656==-- From gregert@teigre.com Sun Aug 16 11:55:11 2009 From: Greger Viken Teigre To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] CVS:commitlog: rtpproxy rtpp_network.c Date: Sun, 16 Aug 2009 11:55:05 +0200 Message-ID: <4A87D779.1070801@teigre.com> In-Reply-To: <20090815221929.9801F18B6B4@mail.berlios.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1177155944==" --===============1177155944== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks, Maxim! That was quick :-D g-) Maxim Sobolev wrote: > sobomax 2009/08/16 00:19:29 CEST > > SER CVS Repository > > Modified files: > . rtpp_network.c=20 > Log: > Use isxdigit(3) instead of ishexnumber(3). The former belongs to C90 > standard, while the latter does not. > =20 > Submitted by: Greger Viken Teigre > =20 > Revision Changes Path > 1.17 +2 -2 rtpproxy/rtpp_network.c > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_network.c.diff?= r1=3D1.16&r2=3D1.17 > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > =20 --===============1177155944==-- From inge@legos.fr Mon Aug 17 14:42:35 2009 From: inge To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] SER crash : Segmentation fault Date: Mon, 17 Aug 2009 14:42:03 +0200 Message-ID: <1250512923.29814.3.camel@legos01.legos.fr> In-Reply-To: <1250262193.8409.6.camel@legos01.legos.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0258186885==" --===============0258186885== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Andrei, Hope you are fine. Do you have any update on our crash ? Is there anything we can do to find the segmentation fault cause, maybe as a well-known bug, without bothering you ? Sincerely, Adrien Le vendredi 14 ao=C3=BBt 2009 =C3=A0 17:03 +0200, inge a =C3=A9crit : > Please find the requested information in attached. >=20 > I'm aware of the need for an update. It's in the list of tasks to be > done, however, the priority is to troubleshoot the problem and maybe > find a workaround. >=20 > Regards, >=20 > Adrien >=20 > Le vendredi 14 ao=C3=BBt 2009 =C3=A0 16:34 +0200, Andrei Pelinescu-Onciul a > =C3=A9crit : > > On Aug 14, 2009 at 15:01, inge wrote: > > > Hi Andrei, > > >=20 > > > Thanks for your reply. > > >=20 > > > I use ser 0.9.5-pre4.=20 > > >=20 > > > I don't really understand the bug you have identify, where can I find a > > > description ? > >=20 > > Sorry, I was wrong (that bug was in RR and appears only in newer code). > >=20 > > Could you run gdb on the core again , type "frame 0" and then send me the= =20 > > output of the following commands: > >=20 > > print p_cell > > print p_msg > > print p_msg->buf > > print p_cell->uas.local_totag.len > > print p_cell->uas.local_totag.s > > print p_msg->to > > print p_msg->to->parsed > > print *((struct to_body*)(p_msg->to->parsed)) > > print ((struct to_body*)(p_msg->to->parsed))->tag_value.len > > print ((struct to_body*)(p_msg->to->parsed))->tag_value.s > >=20 > >=20 > > Andrei > > P.S.: you could try also upgrading to ser 2.0, 2.1 or sip-router. > >=20 > >=20 > > >=20 > > > Regards, > > >=20 > > > Adrien > > >=20 > > > Le vendredi 14 ao??t 2009 ?? 14:45 +0200, Andrei Pelinescu-Onciul a > > > ??crit : > > > > On Aug 13, 2009 at 15:32, inge wrote: > > > > > Hi Klaus, > > > > >=20 > > > > > Thanks. > > > > >=20 > > > > > I put the output of gdb in attached. > > > > >=20 > > > > > I hope someone can decrypt this. Thank you. > > > >=20 > > > >=20 > > > > If you are using ser 2.1/latest cvs or sip-router then just update to > > > > the latest cvs or git. It's a known fixed bug (sip router > > > > git 6fcd5e or ser 2.1 commit starting with "rr: fix from header > > > > access"). > > > >=20 > > > > If you are using another version then tell me which one (ser -V)=20 > > > > and I'll fix it. > > > >=20 > > > > Andrei > > > >=20 > > > > >=20 > > > > > Le jeudi 13 ao??t 2009 ?? 13:53 +0200, Klaus Darilion a ??crit : > > > > > > locate the core file (either in the working dir or /tmp or /) > > > > > > then execute: > > > > > >=20 > > > > > > gdb /usr/local/sbin/ser /path/to/core > > > > > > (gdb) bt > > > > > >=20 > > > > > > regards > > > > > > klaus > > > > > >=20 > > > > > > inge schrieb: > > > > > > > Hi all, > > > > > > >=20 > > > > > > > My SER process had crashed today with the following logs > > > > > > > in /var/log/messages :=20 > > > > > > >=20 > > > > > > > ser[378]: child process 418 exited by a signal 11 > > > > > > > ser[378]: core was generated > > > > > > > ser[378]: INFO: terminating due to SIGCHLD > > > > > > > ser[421]: INFO: signal 15 received > > > > > > > ... > > > > > > >=20 > > > > > > > Can someone help me to determine what kind of problem is it ? I= think I > > > > > > > need to use gdb to extract some information from the core dump.= How can > > > > > > > I use it to extract the uses informations ? > > > > > > >=20 > > > > > > > Regards, > > > > > > >=20 > > > > > > > Adrien > > > > > > >=20 > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > sr-dev mailing list > > > > > > > sr-dev(a)lists.sip-router.org > > > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > >=20 > > > > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74= f38, skip_method=3D4294967294) at t_lookup.c:222 > > > > > 222 if (memcmp(get_to(ack)->tag_value.s,p_cell->uas.loc= al_totag.s, > > > > > (gdb) bt > > > > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff74= f38, skip_method=3D4294967294) at t_lookup.c:222 > > > > > #1 0x00e96aff in t_lookup_request (p_msg=3D0x81647e8, leave_new_lo= cked=3D1) at t_lookup.c:421 > > > > > #2 0x00e992a0 in t_newtran (p_msg=3D0x81647e8) at t_lookup.c:1085 > > > > > #3 0x00e9116a in t_relay_to (p_msg=3D0x81647e8, proxy=3D0x0, proto= =3D0, replicate=3D0) at t_funcs.c:224 > > > > > #4 0x00e9c410 in w_t_relay (p_msg=3D0x81647e8, _foo=3D0x0, _bar=3D= 0x0) at tm.c:889 > > > > > #5 0x0804fc81 in do_action (a=3D0x8117818, msg=3D0x81647e8) at act= ion.c:610 > > > > > #6 0x0805099d in run_actions (a=3D0x8117818, msg=3D0x81647e8) at a= ction.c:718 > > > > > #7 0x08073f08 in eval_elem (e=3D0x8117840, msg=3D0x81647e8) at rou= te.c:605 > > > > > #8 0x08074392 in eval_expr (e=3D0x8117840, msg=3D0x81647e8) at rou= te.c:654 > > > > > #9 0x080743ce in eval_expr (e=3D0x8117860, msg=3D0x81647e8) at rou= te.c:670 > > > > > #10 0x0804ec95 in do_action (a=3D0x8117bc8, msg=3D0x81647e8) at act= ion.c:586 > > > > > #11 0x0805099d in run_actions (a=3D0x8117630, msg=3D0x81647e8) at a= ction.c:718 > > > > > #12 0x0804ffdf in do_action (a=3D0x8114f70, msg=3D0x81647e8) at act= ion.c:375 > > > > > #13 0x0805099d in run_actions (a=3D0x8114f70, msg=3D0x81647e8) at a= ction.c:718 > > > > > #14 0x0804ecd3 in do_action (a=3D0x8114fc0, msg=3D0x81647e8) at act= ion.c:603 > > > > > #15 0x0805099d in run_actions (a=3D0x8114fc0, msg=3D0x81647e8) at a= ction.c:718 > > > > > #16 0x0804ecd3 in do_action (a=3D0x8114fe8, msg=3D0x81647e8) at act= ion.c:603 > > > > > #17 0x0805099d in run_actions (a=3D0x8114fe8, msg=3D0x81647e8) at a= ction.c:718 > > > > > #18 0x0804ecd3 in do_action (a=3D0x8115010, msg=3D0x81647e8) at act= ion.c:603 > > > > > #19 0x0805099d in run_actions (a=3D0x8115010, msg=3D0x81647e8) at a= ction.c:718 > > > > > #20 0x0804ecd3 in do_action (a=3D0x8115038, msg=3D0x81647e8) at act= ion.c:603 > > > > > #21 0x0805099d in run_actions (a=3D0x8115038, msg=3D0x81647e8) at a= ction.c:718 > > > > > #22 0x0804ecd3 in do_action (a=3D0x8115060, msg=3D0x81647e8) at act= ion.c:603 > > > > > #23 0x0805099d in run_actions (a=3D0x810fe88, msg=3D0x81647e8) at a= ction.c:718 > > > > > #24 0x0806d062 in receive_msg ( > > > > > buf=3D0x80d61e0 "ACK sip:0389719641(a)domain.tld:5060 SIP/2.0\r= \nMax-Forwards: 16\r\nContent-Length: 0\r\nVia: SIP/2.0/UDP 10.0.140.147:5060= ;branch=3Dz9hG4bK4f1b8571c\r\nCall-ID: bf85c76a5e2066256679e3945f6b4e36(a)10.= 0.140.147\r\nF"..., len=3D592, rcv_info=3D0xbff76340) at receive.c:165 > > > > > #25 0x080843cc in udp_rcv_loop () at udp_server.c:472 > > > > > #26 0x0805cdaf in main_loop () at main.c:1056 > > > > > #27 0x0805e40b in main (argc=3D1, argv=3D0xbff76504) at main.c:1592 > > > > >=20 > > > >=20 > > > > > _______________________________________________ > > > > > sr-dev mailing list > > > > > sr-dev(a)lists.sip-router.org > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > >=20 > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --===============0258186885==-- From andrei@iptel.org Tue Aug 18 09:01:16 2009 From: Andrei Pelinescu-Onciul To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] SER crash : Segmentation fault Date: Tue, 18 Aug 2009 09:00:45 +0200 Message-ID: <20090818070044.GC7175@shell.iptel.org> In-Reply-To: <1250512923.29814.3.camel@legos01.legos.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0066280191==" --===============0066280191== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Aug 17, 2009 at 14:42, inge wrote: > Hi Andrei, >=20 > Hope you are fine. > Do you have any update on our crash ? > Is there anything we can do to find the segmentation fault cause, maybe > as a well-known bug, without bothering you ? There are lots of changes between 0.9.5-pre and the latest 0.9.x version. You should try updating to the latest code on the rel_0_9_0 branch and see if you run into this problem again. To get the latest 0.9.x code either get the latest snapshot from http://ftp.iptel.org/pub/ser/daily-snapshots/stable/ , use cvs to get the rel_0_9_0 branch (CVSROOT=3D:pserver:anonymous(a)cvs.berlios.de:/cvsroot/ser ; export CVSROOT ; cvs co -r rel_0_9_0 sip_router ), or use git and the ser repository (see http://sip-router.org/wiki/git/ser-repository). Here's a short changelog for tm, between 0.9.5 and 0.9.7+ (git log --oneline v_0_9_5..origin/rel_0_9_0 modules/tm): - tm: fix delete_cell() when the transaction is referenced - variable timer fix: variable timers (avps) won't be exteneded anymore=20 - fix for free_rdata_list() which used to access the "next" pointer af - deadlock when t_relay-ing a message from the failure_route fixed (e2e - added sems specific patch. This patch is present in the ser version ship - added diversion and rpid header cloning -bug fix: tm insert_timer used to eat too much cpu, decreasing dramatic - fixed misplaced set_avp list, courtesy of cesc.santa(a)gmail.com - int2reverse_hex/reverse_hex2int fixes (tm with large "labels" was aff - fix of local ACK matching provided by cesc.santa(a)gmail.com - avp race condition fix (backported from HEAD) - CANCEL terminates retransmission timers properly (backported) Andrei >=20 > Le vendredi 14 ao??t 2009 ?? 17:03 +0200, inge a ??crit : > > Please find the requested information in attached. > >=20 > > I'm aware of the need for an update. It's in the list of tasks to be > > done, however, the priority is to troubleshoot the problem and maybe > > find a workaround. > >=20 > > Regards, > >=20 > > Adrien > >=20 > > Le vendredi 14 ao??t 2009 ?? 16:34 +0200, Andrei Pelinescu-Onciul a > > ??crit : > > > On Aug 14, 2009 at 15:01, inge wrote: > > > > Hi Andrei, > > > >=20 > > > > Thanks for your reply. > > > >=20 > > > > I use ser 0.9.5-pre4.=20 > > > >=20 > > > > I don't really understand the bug you have identify, where can I find= a > > > > description ? > > >=20 > > > Sorry, I was wrong (that bug was in RR and appears only in newer code). > > >=20 > > > Could you run gdb on the core again , type "frame 0" and then send me t= he=20 > > > output of the following commands: > > >=20 > > > print p_cell > > > print p_msg > > > print p_msg->buf > > > print p_cell->uas.local_totag.len > > > print p_cell->uas.local_totag.s > > > print p_msg->to > > > print p_msg->to->parsed > > > print *((struct to_body*)(p_msg->to->parsed)) > > > print ((struct to_body*)(p_msg->to->parsed))->tag_value.len > > > print ((struct to_body*)(p_msg->to->parsed))->tag_value.s > > >=20 > > >=20 > > > Andrei > > > P.S.: you could try also upgrading to ser 2.0, 2.1 or sip-router. > > >=20 > > >=20 > > > >=20 > > > > Regards, > > > >=20 > > > > Adrien > > > >=20 > > > > Le vendredi 14 ao??t 2009 ?? 14:45 +0200, Andrei Pelinescu-Onciul a > > > > ??crit : > > > > > On Aug 13, 2009 at 15:32, inge wrote: > > > > > > Hi Klaus, > > > > > >=20 > > > > > > Thanks. > > > > > >=20 > > > > > > I put the output of gdb in attached. > > > > > >=20 > > > > > > I hope someone can decrypt this. Thank you. > > > > >=20 > > > > >=20 > > > > > If you are using ser 2.1/latest cvs or sip-router then just update = to > > > > > the latest cvs or git. It's a known fixed bug (sip router > > > > > git 6fcd5e or ser 2.1 commit starting with "rr: fix from header > > > > > access"). > > > > >=20 > > > > > If you are using another version then tell me which one (ser -V)=20 > > > > > and I'll fix it. > > > > >=20 > > > > > Andrei > > > > >=20 > > > > > >=20 > > > > > > Le jeudi 13 ao??t 2009 ?? 13:53 +0200, Klaus Darilion a ??crit : > > > > > > > locate the core file (either in the working dir or /tmp or /) > > > > > > > then execute: > > > > > > >=20 > > > > > > > gdb /usr/local/sbin/ser /path/to/core > > > > > > > (gdb) bt > > > > > > >=20 > > > > > > > regards > > > > > > > klaus > > > > > > >=20 > > > > > > > inge schrieb: > > > > > > > > Hi all, > > > > > > > >=20 > > > > > > > > My SER process had crashed today with the following logs > > > > > > > > in /var/log/messages :=20 > > > > > > > >=20 > > > > > > > > ser[378]: child process 418 exited by a signal 11 > > > > > > > > ser[378]: core was generated > > > > > > > > ser[378]: INFO: terminating due to SIGCHLD > > > > > > > > ser[421]: INFO: signal 15 received > > > > > > > > ... > > > > > > > >=20 > > > > > > > > Can someone help me to determine what kind of problem is it ?= I think I > > > > > > > > need to use gdb to extract some information from the core dum= p. How can > > > > > > > > I use it to extract the uses informations ? > > > > > > > >=20 > > > > > > > > Regards, > > > > > > > >=20 > > > > > > > > Adrien > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > _______________________________________________ > > > > > > > > sr-dev mailing list > > > > > > > > sr-dev(a)lists.sip-router.org > > > > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > >=20 > > > > > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff= 74f38, skip_method=3D4294967294) at t_lookup.c:222 > > > > > > 222 if (memcmp(get_to(ack)->tag_value.s,p_cell->uas.l= ocal_totag.s, > > > > > > (gdb) bt > > > > > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xbff= 74f38, skip_method=3D4294967294) at t_lookup.c:222 > > > > > > #1 0x00e96aff in t_lookup_request (p_msg=3D0x81647e8, leave_new_= locked=3D1) at t_lookup.c:421 > > > > > > #2 0x00e992a0 in t_newtran (p_msg=3D0x81647e8) at t_lookup.c:1085 > > > > > > #3 0x00e9116a in t_relay_to (p_msg=3D0x81647e8, proxy=3D0x0, pro= to=3D0, replicate=3D0) at t_funcs.c:224 > > > > > > #4 0x00e9c410 in w_t_relay (p_msg=3D0x81647e8, _foo=3D0x0, _bar= =3D0x0) at tm.c:889 > > > > > > #5 0x0804fc81 in do_action (a=3D0x8117818, msg=3D0x81647e8) at a= ction.c:610 > > > > > > #6 0x0805099d in run_actions (a=3D0x8117818, msg=3D0x81647e8) at= action.c:718 > > > > > > #7 0x08073f08 in eval_elem (e=3D0x8117840, msg=3D0x81647e8) at r= oute.c:605 > > > > > > #8 0x08074392 in eval_expr (e=3D0x8117840, msg=3D0x81647e8) at r= oute.c:654 > > > > > > #9 0x080743ce in eval_expr (e=3D0x8117860, msg=3D0x81647e8) at r= oute.c:670 > > > > > > #10 0x0804ec95 in do_action (a=3D0x8117bc8, msg=3D0x81647e8) at a= ction.c:586 > > > > > > #11 0x0805099d in run_actions (a=3D0x8117630, msg=3D0x81647e8) at= action.c:718 > > > > > > #12 0x0804ffdf in do_action (a=3D0x8114f70, msg=3D0x81647e8) at a= ction.c:375 > > > > > > #13 0x0805099d in run_actions (a=3D0x8114f70, msg=3D0x81647e8) at= action.c:718 > > > > > > #14 0x0804ecd3 in do_action (a=3D0x8114fc0, msg=3D0x81647e8) at a= ction.c:603 > > > > > > #15 0x0805099d in run_actions (a=3D0x8114fc0, msg=3D0x81647e8) at= action.c:718 > > > > > > #16 0x0804ecd3 in do_action (a=3D0x8114fe8, msg=3D0x81647e8) at a= ction.c:603 > > > > > > #17 0x0805099d in run_actions (a=3D0x8114fe8, msg=3D0x81647e8) at= action.c:718 > > > > > > #18 0x0804ecd3 in do_action (a=3D0x8115010, msg=3D0x81647e8) at a= ction.c:603 > > > > > > #19 0x0805099d in run_actions (a=3D0x8115010, msg=3D0x81647e8) at= action.c:718 > > > > > > #20 0x0804ecd3 in do_action (a=3D0x8115038, msg=3D0x81647e8) at a= ction.c:603 > > > > > > #21 0x0805099d in run_actions (a=3D0x8115038, msg=3D0x81647e8) at= action.c:718 > > > > > > #22 0x0804ecd3 in do_action (a=3D0x8115060, msg=3D0x81647e8) at a= ction.c:603 > > > > > > #23 0x0805099d in run_actions (a=3D0x810fe88, msg=3D0x81647e8) at= action.c:718 > > > > > > #24 0x0806d062 in receive_msg ( > > > > > > buf=3D0x80d61e0 "ACK sip:0389719641(a)domain.tld:5060 SIP/2.0= \r\nMax-Forwards: 16\r\nContent-Length: 0\r\nVia: SIP/2.0/UDP 10.0.140.147:50= 60;branch=3Dz9hG4bK4f1b8571c\r\nCall-ID: bf85c76a5e2066256679e3945f6b4e36(a)1= 0.0.140.147\r\nF"..., len=3D592, rcv_info=3D0xbff76340) at receive.c:165 > > > > > > #25 0x080843cc in udp_rcv_loop () at udp_server.c:472 > > > > > > #26 0x0805cdaf in main_loop () at main.c:1056 > > > > > > #27 0x0805e40b in main (argc=3D1, argv=3D0xbff76504) at main.c:15= 92 > > > > > >=20 > > > > >=20 > > > > > > _______________________________________________ > > > > > > sr-dev mailing list > > > > > > sr-dev(a)lists.sip-router.org > > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > >=20 > > _______________________________________________ > > sr-dev mailing list > > sr-dev(a)lists.sip-router.org > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --===============0066280191==-- From henning.westerholt@1und1.de Wed Aug 19 16:56:57 2009 From: Henning Westerholt To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: cr: documentation extension related to the prime route behaviour (port r5898) Date: Wed, 19 Aug 2009 16:56:57 +0200 Message-ID: <20090819145657.1BFE9EF8070@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1439053602==" --===============1439053602== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: 5ec9f271fad97a4abbf151e55eaf509c3d9f5722 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3D5ec9f271fad97a4abbf151e55eaf509c3d9f5722 Author: Henning Westerholt Committer: Henning Westerholt Date: Wed Aug 19 16:40:04 2009 +0200 cr: documentation extension related to the prime route behaviour (port r5898) --- modules/carrierroute/README | 12 ++++++++++-- modules/carrierroute/doc/carrierroute_admin.xml | 12 +++++++++++- 2 files changed, 21 insertions(+), 3 deletions(-) diff --git a/modules/carrierroute/README b/modules/carrierroute/README index eba27e5..7192926 100644 --- a/modules/carrierroute/README +++ b/modules/carrierroute/README @@ -511,8 +511,16 @@ rewrite_user, hash_source, descavp) the destination or the number of channels. This function is only usable with rewrite_user and prefix_matching containing a valid string. This string needs to be numerical if the - match_mode parameter is set to 10. It uses the prime hash - algorithm to calculate the hash values. + match_mode parameter is set to 10. + + It uses the prime hash algorithm to calculate the hash values. + This means that the fuction behaves different then the normal + routing function. If you don't know what this prime + functionality is, you should just use the cr_route function. + The prime routing algorithm not use the configured + probabilities in order to route requests, it just uses a fixed + hash distribution. If one of the hash targets is not available, + and no backup rule is configured, the function will return -1. =20 Meaning of the parameters is as follows: * carrier - The routing tree to be used. Additional to a diff --git a/modules/carrierroute/doc/carrierroute_admin.xml b/modules/carrie= rroute/doc/carrierroute_admin.xml index d6b927f..7814d83 100644 --- a/modules/carrierroute/doc/carrierroute_admin.xml +++ b/modules/carrierroute/doc/carrierroute_admin.xml @@ -507,7 +507,17 @@ cr_tree_rewrite_uri(tree, domain) number of channels. This function is only usable with rewrite_user and prefix_matching containing a valid string. This string needs to be numerical if the = match_mode - parameter is set to 10. It uses the prime hash algorithm to calculate the = hash values. + parameter is set to 10. + + + It uses the prime hash algorithm to calculate the hash values. This + means that the fuction behaves different then the normal routing + function. If you don't know what this prime functionality is, + you should just use the cr_route function. The + prime routing algorithm not use the configured probabilities in + order to route requests, it just uses a fixed hash distribution. If + one of the hash targets is not available, and no backup rule is + configured, the function will return -1. Meaning of the parameters is as follows: --===============1439053602==-- From henning.westerholt@1und1.de Wed Aug 19 16:56:57 2009 From: Henning Westerholt To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: lib kmi: fix double allocation length calculation in mi_add_attr function Date: Wed, 19 Aug 2009 16:56:57 +0200 Message-ID: <20090819145657.35CE7EF8076@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1281308422==" --===============1281308422== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: c742ca80bcdfdd844a0dd03138b1c67c6995be57 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3Dc742ca80bcdfdd844a0dd03138b1c67c6995be57 Author: Henning Westerholt Committer: Henning Westerholt Date: Wed Aug 19 16:51:44 2009 +0200 lib kmi: fix double allocation length calculation in mi_add_attr function - patch from marius zbihlei, marius dot zbihlei at 1and1 dot ro, port from r5= 882 --- lib/kmi/attr.c | 8 -------- 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/lib/kmi/attr.c b/lib/kmi/attr.c index 4a1b81b..1610cde 100644 --- a/lib/kmi/attr.c +++ b/lib/kmi/attr.c @@ -101,14 +101,6 @@ struct mi_attr *add_mi_attr(struct mi_node *node, int fl= ags, new->value.s =3D value; } } - if(flags & MI_DUP_NAME){ - name_pos =3D size_mem; - size_mem +=3D name_len * sizeof(char); - } - if(flags & MI_DUP_VALUE){ - value_pos =3D size_mem; - size_mem +=3D value_len * sizeof(char); - } =20 if(!(node->attributes)){ new->next =3D NULL; --===============1281308422==-- From henning.westerholt@1und1.de Wed Aug 19 16:56:57 2009 From: Henning Westerholt To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: cr: small fix in doxygen, fix obselete function description ( port from r5897) Date: Wed, 19 Aug 2009 16:56:57 +0200 Message-ID: <20090819145657.239ECEF8074@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0044376451==" --===============0044376451== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: 1a0c0dd44a6d45d6193d7adb487a2d7665474d2f URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3D1a0c0dd44a6d45d6193d7adb487a2d7665474d2f Author: Henning Westerholt Committer: Henning Westerholt Date: Wed Aug 19 16:44:48 2009 +0200 cr: small fix in doxygen, fix obselete function description (port from r5897) --- modules/carrierroute/cr_func.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules/carrierroute/cr_func.c b/modules/carrierroute/cr_func.c index 6e69ad2..74e3c8e 100644 --- a/modules/carrierroute/cr_func.c +++ b/modules/carrierroute/cr_func.c @@ -233,7 +233,7 @@ static int set_next_domain_recursor(struct dtrie_node_t *= failure_node, /** * searches for a rule int rt with hash_index prob - 1 * If the rule with the desired hash index is deactivated, - * the next working rule is used. + * the backup rule is used if available. * * @param rf the route_flags node to search for rule * @param prob the hash index --===============0044376451==-- From henning.westerholt@1und1.de Wed Aug 19 16:56:57 2009 From: Henning Westerholt To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: cr: fix stupid bug related to the (legacy..) prime_route function (port from r5911) Date: Wed, 19 Aug 2009 16:56:56 +0200 Message-ID: <20090819145656.E8C20EF8072@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1340916924==" --===============1340916924== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: 21775b41536b6d623e3bd750feb015b13b423fcf URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3D21775b41536b6d623e3bd750feb015b13b423fcf Author: Henning Westerholt Committer: Henning Westerholt Date: Wed Aug 19 16:35:06 2009 +0200 cr: fix stupid bug related to the (legacy..) prime_route function (port from = r5911) --- modules/carrierroute/carrierroute.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/carrierroute/carrierroute.c b/modules/carrierroute/carri= erroute.c index 63d9677..9984b72 100644 --- a/modules/carrierroute/carrierroute.c +++ b/modules/carrierroute/carrierroute.c @@ -89,8 +89,8 @@ static cmd_export_t cmds[]=3D{ {"cr_user_carrier", (cmd_function)cr_load_user_carrier, 3, cr_load_user_ca= rrier_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE }, {"cr_route", (cmd_function)cr_route, 5, cr_route_fixup,= 0, REQUEST_ROUTE | FAILURE_ROUTE }, {"cr_route", (cmd_function)cr_route, 6, cr_route_fixup,= 0, REQUEST_ROUTE | FAILURE_ROUTE }, - {"cr_prime_route", (cmd_function)cr_route, 5, cr_route_fixup,= 0, REQUEST_ROUTE | FAILURE_ROUTE }, - {"cr_prime_route", (cmd_function)cr_route, 6, cr_route_fixup,= 0, REQUEST_ROUTE | FAILURE_ROUTE }, + {"cr_prime_route", (cmd_function)cr_prime_route, 5, cr_route_fixup,= 0, REQUEST_ROUTE | FAILURE_ROUTE }, + {"cr_prime_route", (cmd_function)cr_prime_route, 6, cr_route_fixup,= 0, REQUEST_ROUTE | FAILURE_ROUTE }, {"cr_next_domain", (cmd_function)cr_load_next_domain, 6, cr_load_next_do= main_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE }, {0, 0, 0, 0, 0, 0} }; --===============1340916924==-- From henning.westerholt@1und1.de Wed Aug 19 16:56:57 2009 From: Henning Westerholt To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: auth_db(k): fix error in auth_db documentation for calc_ha1 ( port from r5910) Date: Wed, 19 Aug 2009 16:56:56 +0200 Message-ID: <20090819145657.0F152EF8064@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1442492885==" --===============1442492885== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: 91d2ed7e550aee380a03333abff557cb427bf03d URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3D91d2ed7e550aee380a03333abff557cb427bf03d Author: Henning Westerholt Committer: Henning Westerholt Date: Wed Aug 19 16:37:10 2009 +0200 auth_db(k): fix error in auth_db documentation for calc_ha1 (port from r5910) --- modules_k/auth_db/README | 9 +++++---- modules_k/auth_db/doc/auth_db_admin.xml | 8 ++++---- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/modules_k/auth_db/README b/modules_k/auth_db/README index 65772c6..79f79f3 100644 --- a/modules_k/auth_db/README +++ b/modules_k/auth_db/README @@ -168,10 +168,11 @@ modparam("auth_db", "password_column_2", "ha1_2") =20 1.3.6. calculate_ha1 (integer) =20 - This parameter tells the server whether it should use plaintext - passwords or a pre-calculated HA1 string for authentification. + This parameter tells the server whether it should use a + pre-calculated HA1 string or plaintext passwords for + authentification. =20 - If the parameter is set to 1 and the username parameter of + If the parameter is set to 0 and the username parameter of credentials contains also "@domain" (some user agents append the domain to the username parameter), then the server will use the HA1 values from the column specified in the @@ -179,7 +180,7 @@ modparam("auth_db", "password_column_2", "ha1_2") doesn't contain a domain, the server will use the HA1 values from the column given in the "password_column"parameter. =20 - If the parameter is set to 0 then the HA1 value will be + If the parameter is set to 1 then the HA1 value will be calculated from the column specified in the "password_column" parameter. =20 diff --git a/modules_k/auth_db/doc/auth_db_admin.xml b/modules_k/auth_db/doc/= auth_db_admin.xml index 2609bce..71180ca 100644 --- a/modules_k/auth_db/doc/auth_db_admin.xml +++ b/modules_k/auth_db/doc/auth_db_admin.xml @@ -164,11 +164,11 @@ modparam("auth_db", "password_column_2", "ha1_2")
<varname>calculate_ha1</varname> (integer) - This parameter tells the server whether it should use plaintext=20 - passwords or a pre-calculated HA1 string for authentification. + This parameter tells the server whether it should use a pre-calculated + HA1 string or plaintext passwords for authentification. - If the parameter is set to 1 and the username parameter of credentials + If the parameter is set to 0 and the username parameter of credentials contains also @domain (some user agents append the domain to the username parameter), then the server will use the HA1 values from the column specified in the=20 @@ -177,7 +177,7 @@ modparam("auth_db", "password_column_2", "ha1_2") column given in the password_columnparameter. - If the parameter is set to 0 then the HA1 value will be calculated + If the parameter is set to 1 then the HA1 value will be calculated from the column specified in the password_column parameter. --===============1442492885==-- From henning.westerholt@1und1.de Wed Aug 19 16:56:58 2009 From: Henning Westerholt To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: auth(k): fix proxy/ www_challenge function, extends docs a bit (port r5874) Date: Wed, 19 Aug 2009 16:56:57 +0200 Message-ID: <20090819145657.4C13DEF8077@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0309280017==" --===============0309280017== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: bb0fac6ac04af672dceca9ae1f4ca43106fb56d1 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3Dbb0fac6ac04af672dceca9ae1f4ca43106fb56d1 Author: Henning Westerholt Committer: Henning Westerholt Date: Wed Aug 19 16:54:53 2009 +0200 auth(k): fix proxy/ www_challenge function, extends docs a bit (port r5874) - proxy_challenge / www_challenge was not sending any reply, in case the nonce could not be created (with nonce_reuse =3D 0, default since 1.4) - added a note to the docs about return-values from the auth-module - regenerate README file --- modules_k/auth/README | 548 +++++++++++++++++++----------------- modules_k/auth/challenge.c | 5 +- modules_k/auth/doc/auth_admin.xml | 8 + 3 files changed, 301 insertions(+), 260 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommitdi= ff;h=3Dbb0fac6ac04af672dceca9ae1f4ca43106fb56d1 --===============0309280017==-- From miconda@gmail.com Thu Aug 20 09:42:46 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: core: added log_name config parameter Date: Thu, 20 Aug 2009 09:42:45 +0200 Message-ID: <20090820074245.4CA9CEF8070@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1388571563==" --===============1388571563== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: 95bf86454e277a7a0ef1c41c2995806f65eda17b URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3D95bf86454e277a7a0ef1c41c2995806f65eda17b Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Thu Aug 20 10:41:02 2009 +0300 core: added log_name config parameter - log_name allows to set app name to be used when printing to syslog - useful to filter log messages when running many instance on same server --- cfg.lex | 2 ++ cfg.y | 3 +++ dprint.h | 1 + main.c | 4 +++- 4 files changed, 9 insertions(+), 1 deletions(-) diff --git a/cfg.lex b/cfg.lex index a99968d..32aed32 100644 --- a/cfg.lex +++ b/cfg.lex @@ -281,6 +281,7 @@ DEBUG debug FORK fork LOGSTDERROR log_stderror LOGFACILITY log_facility +LOGNAME log_name LISTEN listen ALIAS alias SR_AUTO_ALIASES auto_aliases @@ -577,6 +578,7 @@ EAT_ABLE [\ \t\b\r] {FORK} { count(); yylval.strval=3Dyytext; return FORK; } {LOGSTDERROR} { yylval.strval=3Dyytext; return LOGSTDERROR; } {LOGFACILITY} { yylval.strval=3Dyytext; return LOGFACILITY; } +{LOGNAME} { yylval.strval=3Dyytext; return LOGNAME; } {LISTEN} { count(); yylval.strval=3Dyytext; return LISTEN; } {ALIAS} { count(); yylval.strval=3Dyytext; return ALIAS; } {SR_AUTO_ALIASES} { count(); yylval.strval=3Dyytext; diff --git a/cfg.y b/cfg.y index b51a272..e9e8d8a 100644 --- a/cfg.y +++ b/cfg.y @@ -345,6 +345,7 @@ static int case_check_default(struct case_stms* stms); %token FORK %token LOGSTDERROR %token LOGFACILITY +%token LOGNAME %token LISTEN %token ALIAS %token SR_AUTO_ALIASES @@ -758,6 +759,8 @@ assign_stm: default_core_cfg.log_facility=3Di_tmp; } | LOGFACILITY EQUAL error { yyerror("ID expected"); } + | LOGNAME EQUAL STRING { log_name=3D$3; } + | LOGNAME EQUAL error { yyerror("string value expected"); } | DNS EQUAL NUMBER { received_dns|=3D ($3)?DO_DNS:0; } | DNS EQUAL error { yyerror("boolean value expected"); } | REV_DNS EQUAL NUMBER { received_dns|=3D ($3)?DO_REV_DNS:0; } diff --git a/dprint.h b/dprint.h index 54d47fa..8f9d743 100644 --- a/dprint.h +++ b/dprint.h @@ -109,6 +109,7 @@ struct log_level_info { =20 #define is_printable(level) (cfg_get(core, core_cfg, debug)>=3D(level)) extern struct log_level_info log_level_info[]; +extern char *log_name; =20 #ifndef NO_SIG_DEBUG /* protection against "simultaneous" printing from signal handlers */ diff --git a/main.c b/main.c index 23455e7..9a771f8 100644 --- a/main.c +++ b/main.c @@ -321,6 +321,8 @@ int sig_flag =3D 0; /* last signal received = */ int dont_fork =3D 0; int dont_daemonize =3D 0; int log_stderr =3D 0; +/* set custom app name for syslog printing */ +char *log_name =3D 0; pid_t creator_pid =3D (pid_t) -1; int config_check =3D 0; /* check if reply first via host=3D=3Dus */ @@ -2059,7 +2061,7 @@ try_again: #endif /* USE_SCTP */ /* init_daemon? */ if (!dont_fork){ - if ( daemonize(argv[0]) <0 ) goto error; + if ( daemonize((log_name=3D=3D0)?argv[0]:log_name) <0 ) goto error; } if (install_sigs() !=3D 0){ fprintf(stderr, "ERROR: could not install the signal handlers\n"); --===============1388571563==-- From klaus.mailinglists@pernau.at Thu Aug 20 10:31:45 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] git:master: core: added log_name config parameter Date: Thu, 20 Aug 2009 10:31:16 +0200 Message-ID: <4A8D09D4.3010404@pernau.at> In-Reply-To: <20090820074245.4CA9CEF8070@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0442643636==" --===============0442643636== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable fyi: added to http://sip-router.org/wiki/cookbooks/core-cookbook/devel Daniel-Constantin Mierla schrieb: > Module: sip-router > Branch: master > Commit: 95bf86454e277a7a0ef1c41c2995806f65eda17b > URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit= ;h=3D95bf86454e277a7a0ef1c41c2995806f65eda17b >=20 > Author: Daniel-Constantin Mierla > Committer: Daniel-Constantin Mierla > Date: Thu Aug 20 10:41:02 2009 +0300 >=20 > core: added log_name config parameter >=20 > - log_name allows to set app name to be used when printing to syslog > - useful to filter log messages when running many instance on same server >=20 > --- >=20 > cfg.lex | 2 ++ > cfg.y | 3 +++ > dprint.h | 1 + > main.c | 4 +++- > 4 files changed, 9 insertions(+), 1 deletions(-) >=20 > diff --git a/cfg.lex b/cfg.lex > index a99968d..32aed32 100644 > --- a/cfg.lex > +++ b/cfg.lex > @@ -281,6 +281,7 @@ DEBUG debug > FORK fork > LOGSTDERROR log_stderror > LOGFACILITY log_facility > +LOGNAME log_name > LISTEN listen > ALIAS alias > SR_AUTO_ALIASES auto_aliases > @@ -577,6 +578,7 @@ EAT_ABLE [\ \t\b\r] > {FORK} { count(); yylval.strval=3Dyytext; return FORK; } > {LOGSTDERROR} { yylval.strval=3Dyytext; return LOGSTDERROR; } > {LOGFACILITY} { yylval.strval=3Dyytext; return LOGFACILITY; } > +{LOGNAME} { yylval.strval=3Dyytext; return LOGNAME; } > {LISTEN} { count(); yylval.strval=3Dyytext; return LISTEN; } > {ALIAS} { count(); yylval.strval=3Dyytext; return ALIAS; } > {SR_AUTO_ALIASES} { count(); yylval.strval=3Dyytext; > diff --git a/cfg.y b/cfg.y > index b51a272..e9e8d8a 100644 > --- a/cfg.y > +++ b/cfg.y > @@ -345,6 +345,7 @@ static int case_check_default(struct case_stms* stms); > %token FORK > %token LOGSTDERROR > %token LOGFACILITY > +%token LOGNAME > %token LISTEN > %token ALIAS > %token SR_AUTO_ALIASES > @@ -758,6 +759,8 @@ assign_stm: > default_core_cfg.log_facility=3Di_tmp; > } > | LOGFACILITY EQUAL error { yyerror("ID expected"); } > + | LOGNAME EQUAL STRING { log_name=3D$3; } > + | LOGNAME EQUAL error { yyerror("string value expected"); } > | DNS EQUAL NUMBER { received_dns|=3D ($3)?DO_DNS:0; } > | DNS EQUAL error { yyerror("boolean value expected"); } > | REV_DNS EQUAL NUMBER { received_dns|=3D ($3)?DO_REV_DNS:0; } > diff --git a/dprint.h b/dprint.h > index 54d47fa..8f9d743 100644 > --- a/dprint.h > +++ b/dprint.h > @@ -109,6 +109,7 @@ struct log_level_info { > =20 > #define is_printable(level) (cfg_get(core, core_cfg, debug)>=3D(level)) > extern struct log_level_info log_level_info[]; > +extern char *log_name; > =20 > #ifndef NO_SIG_DEBUG > /* protection against "simultaneous" printing from signal handlers */ > diff --git a/main.c b/main.c > index 23455e7..9a771f8 100644 > --- a/main.c > +++ b/main.c > @@ -321,6 +321,8 @@ int sig_flag =3D 0; /* last signal receive= d */ > int dont_fork =3D 0; > int dont_daemonize =3D 0; > int log_stderr =3D 0; > +/* set custom app name for syslog printing */ > +char *log_name =3D 0; > pid_t creator_pid =3D (pid_t) -1; > int config_check =3D 0; > /* check if reply first via host=3D=3Dus */ > @@ -2059,7 +2061,7 @@ try_again: > #endif /* USE_SCTP */ > /* init_daemon? */ > if (!dont_fork){ > - if ( daemonize(argv[0]) <0 ) goto error; > + if ( daemonize((log_name=3D=3D0)?argv[0]:log_name) <0 ) goto error; > } > if (install_sigs() !=3D 0){ > fprintf(stderr, "ERROR: could not install the signal handlers\n"); >=20 >=20 > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --===============0442643636==-- From miconda@gmail.com Thu Aug 20 10:33:43 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] git:master: core: added log_name config parameter Date: Thu, 20 Aug 2009 11:33:37 +0300 Message-ID: <4A8D0A61.9060602@gmail.com> In-Reply-To: <4A8D09D4.3010404@pernau.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1805191776==" --===============1805191776== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 20.08.2009 11:31 Uhr, Klaus Darilion wrote: > fyi: added to http://sip-router.org/wiki/cookbooks/core-cookbook/devel thanks! > > Daniel-Constantin Mierla schrieb: >> Module: sip-router >> Branch: master >> Commit: 95bf86454e277a7a0ef1c41c2995806f65eda17b >> URL: =20 >> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h=3D95= bf86454e277a7a0ef1c41c2995806f65eda17b=20 >> >> >> Author: Daniel-Constantin Mierla >> Committer: Daniel-Constantin Mierla >> Date: Thu Aug 20 10:41:02 2009 +0300 >> >> core: added log_name config parameter >> >> - log_name allows to set app name to be used when printing to syslog >> - useful to filter log messages when running many instance on same=20 >> server >> >> --- >> >> cfg.lex | 2 ++ >> cfg.y | 3 +++ >> dprint.h | 1 + >> main.c | 4 +++- >> 4 files changed, 9 insertions(+), 1 deletions(-) >> >> diff --git a/cfg.lex b/cfg.lex >> index a99968d..32aed32 100644 >> --- a/cfg.lex >> +++ b/cfg.lex >> @@ -281,6 +281,7 @@ DEBUG debug >> FORK fork >> LOGSTDERROR log_stderror >> LOGFACILITY log_facility >> +LOGNAME log_name >> LISTEN listen >> ALIAS alias >> SR_AUTO_ALIASES auto_aliases >> @@ -577,6 +578,7 @@ EAT_ABLE [\ \t\b\r] >> {FORK} { count(); yylval.strval=3Dyytext; return FORK; } >> {LOGSTDERROR} { yylval.strval=3Dyytext; return LOGSTDERROR; } >> {LOGFACILITY} { yylval.strval=3Dyytext; return LOGFACILITY; } >> +{LOGNAME} { yylval.strval=3Dyytext; return LOGNAME; } >> {LISTEN} { count(); yylval.strval=3Dyytext; return LISTEN; } >> {ALIAS} { count(); yylval.strval=3Dyytext; return ALIAS; } >> {SR_AUTO_ALIASES} { count(); yylval.strval=3Dyytext; >> diff --git a/cfg.y b/cfg.y >> index b51a272..e9e8d8a 100644 >> --- a/cfg.y >> +++ b/cfg.y >> @@ -345,6 +345,7 @@ static int case_check_default(struct case_stms*=20 >> stms); >> %token FORK >> %token LOGSTDERROR >> %token LOGFACILITY >> +%token LOGNAME >> %token LISTEN >> %token ALIAS >> %token SR_AUTO_ALIASES >> @@ -758,6 +759,8 @@ assign_stm: >> default_core_cfg.log_facility=3Di_tmp; >> } >> | LOGFACILITY EQUAL error { yyerror("ID expected"); } >> + | LOGNAME EQUAL STRING { log_name=3D$3; } >> + | LOGNAME EQUAL error { yyerror("string value expected"); } >> | DNS EQUAL NUMBER { received_dns|=3D ($3)?DO_DNS:0; } >> | DNS EQUAL error { yyerror("boolean value expected"); } >> | REV_DNS EQUAL NUMBER { received_dns|=3D ($3)?DO_REV_DNS:0; } >> diff --git a/dprint.h b/dprint.h >> index 54d47fa..8f9d743 100644 >> --- a/dprint.h >> +++ b/dprint.h >> @@ -109,6 +109,7 @@ struct log_level_info { >> =20 >> #define is_printable(level) (cfg_get(core, core_cfg, debug)>=3D(level)) >> extern struct log_level_info log_level_info[]; >> +extern char *log_name; >> =20 >> #ifndef NO_SIG_DEBUG >> /* protection against "simultaneous" printing from signal handlers */ >> diff --git a/main.c b/main.c >> index 23455e7..9a771f8 100644 >> --- a/main.c >> +++ b/main.c >> @@ -321,6 +321,8 @@ int sig_flag =3D 0; /* last signal=20 >> received */ >> int dont_fork =3D 0; >> int dont_daemonize =3D 0; >> int log_stderr =3D 0; >> +/* set custom app name for syslog printing */ >> +char *log_name =3D 0; >> pid_t creator_pid =3D (pid_t) -1; >> int config_check =3D 0; >> /* check if reply first via host=3D=3Dus */ >> @@ -2059,7 +2061,7 @@ try_again: >> #endif /* USE_SCTP */ >> /* init_daemon? */ >> if (!dont_fork){ >> - if ( daemonize(argv[0]) <0 ) goto error; >> + if ( daemonize((log_name=3D=3D0)?argv[0]:log_name) <0 ) goto erro= r; >> } >> if (install_sigs() !=3D 0){ >> fprintf(stderr, "ERROR: could not install the signal=20 >> handlers\n"); >> >> >> _______________________________________________ >> sr-dev mailing list >> sr-dev(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --=20 Daniel-Constantin Mierla * http://www.asipto.com/ --===============1805191776==-- From inge@legos.fr Thu Aug 20 10:41:06 2009 From: inge To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] SER crash : Segmentation fault Date: Thu, 20 Aug 2009 10:40:34 +0200 Message-ID: <1250757634.29814.12.camel@legos01.legos.fr> In-Reply-To: <20090818070044.GC7175@shell.iptel.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1848070991==" --===============1848070991== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Andrei, As I understand, this changelog only apply to the tm module. Is there any clues that this module caused the crash we experienced ? We would like to determine which of the known and corrected bug could have caused the crash, in order to find a short-time workaround letting us some time to deploy abn upgrade to the latest rel in the 0.9.0 branch. Adrien Le mardi 18 ao=C3=BBt 2009 =C3=A0 09:00 +0200, Andrei Pelinescu-Onciul a =C3= =A9crit : > On Aug 17, 2009 at 14:42, inge wrote: > > Hi Andrei, > >=20 > > Hope you are fine. > > Do you have any update on our crash ? > > Is there anything we can do to find the segmentation fault cause, maybe > > as a well-known bug, without bothering you ? >=20 >=20 > There are lots of changes between 0.9.5-pre and the latest 0.9.x > version. > You should try updating to the latest code on the rel_0_9_0 branch and > see if you run into this problem again. > To get the latest 0.9.x code either get the latest snapshot from > http://ftp.iptel.org/pub/ser/daily-snapshots/stable/ , use cvs to > get the rel_0_9_0 branch > (CVSROOT=3D:pserver:anonymous(a)cvs.berlios.de:/cvsroot/ser ; > export CVSROOT ; cvs co -r rel_0_9_0 sip_router ), or use git and the > ser repository (see http://sip-router.org/wiki/git/ser-repository). >=20 > Here's a short changelog for tm, between 0.9.5 and 0.9.7+ > (git log --oneline v_0_9_5..origin/rel_0_9_0 modules/tm): > - tm: fix delete_cell() when the transaction is referenced > - variable timer fix: variable timers (avps) won't be exteneded anymore=20 > - fix for free_rdata_list() which used to access the "next" pointer af > - deadlock when t_relay-ing a message from the failure_route fixed (e2e > - added sems specific patch. This patch is present in the ser version ship > - added diversion and rpid header cloning > -bug fix: tm insert_timer used to eat too much cpu, decreasing dramatic > - fixed misplaced set_avp list, courtesy of cesc.santa(a)gmail.com > - int2reverse_hex/reverse_hex2int fixes (tm with large "labels" was aff > - fix of local ACK matching provided by cesc.santa(a)gmail.com > - avp race condition fix (backported from HEAD) > - CANCEL terminates retransmission timers properly (backported) >=20 >=20 > Andrei >=20 >=20 > >=20 > > Le vendredi 14 ao??t 2009 ?? 17:03 +0200, inge a ??crit : > > > Please find the requested information in attached. > > >=20 > > > I'm aware of the need for an update. It's in the list of tasks to be > > > done, however, the priority is to troubleshoot the problem and maybe > > > find a workaround. > > >=20 > > > Regards, > > >=20 > > > Adrien > > >=20 > > > Le vendredi 14 ao??t 2009 ?? 16:34 +0200, Andrei Pelinescu-Onciul a > > > ??crit : > > > > On Aug 14, 2009 at 15:01, inge wrote: > > > > > Hi Andrei, > > > > >=20 > > > > > Thanks for your reply. > > > > >=20 > > > > > I use ser 0.9.5-pre4.=20 > > > > >=20 > > > > > I don't really understand the bug you have identify, where can I fi= nd a > > > > > description ? > > > >=20 > > > > Sorry, I was wrong (that bug was in RR and appears only in newer code= ). > > > >=20 > > > > Could you run gdb on the core again , type "frame 0" and then send me= the=20 > > > > output of the following commands: > > > >=20 > > > > print p_cell > > > > print p_msg > > > > print p_msg->buf > > > > print p_cell->uas.local_totag.len > > > > print p_cell->uas.local_totag.s > > > > print p_msg->to > > > > print p_msg->to->parsed > > > > print *((struct to_body*)(p_msg->to->parsed)) > > > > print ((struct to_body*)(p_msg->to->parsed))->tag_value.len > > > > print ((struct to_body*)(p_msg->to->parsed))->tag_value.s > > > >=20 > > > >=20 > > > > Andrei > > > > P.S.: you could try also upgrading to ser 2.0, 2.1 or sip-router. > > > >=20 > > > >=20 > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Adrien > > > > >=20 > > > > > Le vendredi 14 ao??t 2009 ?? 14:45 +0200, Andrei Pelinescu-Onciul a > > > > > ??crit : > > > > > > On Aug 13, 2009 at 15:32, inge wrote: > > > > > > > Hi Klaus, > > > > > > >=20 > > > > > > > Thanks. > > > > > > >=20 > > > > > > > I put the output of gdb in attached. > > > > > > >=20 > > > > > > > I hope someone can decrypt this. Thank you. > > > > > >=20 > > > > > >=20 > > > > > > If you are using ser 2.1/latest cvs or sip-router then just updat= e to > > > > > > the latest cvs or git. It's a known fixed bug (sip router > > > > > > git 6fcd5e or ser 2.1 commit starting with "rr: fix from header > > > > > > access"). > > > > > >=20 > > > > > > If you are using another version then tell me which one (ser -V) = > > > > > > and I'll fix it. > > > > > >=20 > > > > > > Andrei > > > > > >=20 > > > > > > >=20 > > > > > > > Le jeudi 13 ao??t 2009 ?? 13:53 +0200, Klaus Darilion a ??crit : > > > > > > > > locate the core file (either in the working dir or /tmp or /) > > > > > > > > then execute: > > > > > > > >=20 > > > > > > > > gdb /usr/local/sbin/ser /path/to/core > > > > > > > > (gdb) bt > > > > > > > >=20 > > > > > > > > regards > > > > > > > > klaus > > > > > > > >=20 > > > > > > > > inge schrieb: > > > > > > > > > Hi all, > > > > > > > > >=20 > > > > > > > > > My SER process had crashed today with the following logs > > > > > > > > > in /var/log/messages :=20 > > > > > > > > >=20 > > > > > > > > > ser[378]: child process 418 exited by a signal 11 > > > > > > > > > ser[378]: core was generated > > > > > > > > > ser[378]: INFO: terminating due to SIGCHLD > > > > > > > > > ser[421]: INFO: signal 15 received > > > > > > > > > ... > > > > > > > > >=20 > > > > > > > > > Can someone help me to determine what kind of problem is it= ? I think I > > > > > > > > > need to use gdb to extract some information from the core d= ump. How can > > > > > > > > > I use it to extract the uses informations ? > > > > > > > > >=20 > > > > > > > > > Regards, > > > > > > > > >=20 > > > > > > > > > Adrien > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > _______________________________________________ > > > > > > > > > sr-dev mailing list > > > > > > > > > sr-dev(a)lists.sip-router.org > > > > > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > > >=20 > > > > > > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xb= ff74f38, skip_method=3D4294967294) at t_lookup.c:222 > > > > > > > 222 if (memcmp(get_to(ack)->tag_value.s,p_cell->uas= .local_totag.s, > > > > > > > (gdb) bt > > > > > > > #0 0x00e964d3 in matching_3261 (p_msg=3D0x81647e8, trans=3D0xb= ff74f38, skip_method=3D4294967294) at t_lookup.c:222 > > > > > > > #1 0x00e96aff in t_lookup_request (p_msg=3D0x81647e8, leave_ne= w_locked=3D1) at t_lookup.c:421 > > > > > > > #2 0x00e992a0 in t_newtran (p_msg=3D0x81647e8) at t_lookup.c:1= 085 > > > > > > > #3 0x00e9116a in t_relay_to (p_msg=3D0x81647e8, proxy=3D0x0, p= roto=3D0, replicate=3D0) at t_funcs.c:224 > > > > > > > #4 0x00e9c410 in w_t_relay (p_msg=3D0x81647e8, _foo=3D0x0, _ba= r=3D0x0) at tm.c:889 > > > > > > > #5 0x0804fc81 in do_action (a=3D0x8117818, msg=3D0x81647e8) at= action.c:610 > > > > > > > #6 0x0805099d in run_actions (a=3D0x8117818, msg=3D0x81647e8) = at action.c:718 > > > > > > > #7 0x08073f08 in eval_elem (e=3D0x8117840, msg=3D0x81647e8) at= route.c:605 > > > > > > > #8 0x08074392 in eval_expr (e=3D0x8117840, msg=3D0x81647e8) at= route.c:654 > > > > > > > #9 0x080743ce in eval_expr (e=3D0x8117860, msg=3D0x81647e8) at= route.c:670 > > > > > > > #10 0x0804ec95 in do_action (a=3D0x8117bc8, msg=3D0x81647e8) at= action.c:586 > > > > > > > #11 0x0805099d in run_actions (a=3D0x8117630, msg=3D0x81647e8) = at action.c:718 > > > > > > > #12 0x0804ffdf in do_action (a=3D0x8114f70, msg=3D0x81647e8) at= action.c:375 > > > > > > > #13 0x0805099d in run_actions (a=3D0x8114f70, msg=3D0x81647e8) = at action.c:718 > > > > > > > #14 0x0804ecd3 in do_action (a=3D0x8114fc0, msg=3D0x81647e8) at= action.c:603 > > > > > > > #15 0x0805099d in run_actions (a=3D0x8114fc0, msg=3D0x81647e8) = at action.c:718 > > > > > > > #16 0x0804ecd3 in do_action (a=3D0x8114fe8, msg=3D0x81647e8) at= action.c:603 > > > > > > > #17 0x0805099d in run_actions (a=3D0x8114fe8, msg=3D0x81647e8) = at action.c:718 > > > > > > > #18 0x0804ecd3 in do_action (a=3D0x8115010, msg=3D0x81647e8) at= action.c:603 > > > > > > > #19 0x0805099d in run_actions (a=3D0x8115010, msg=3D0x81647e8) = at action.c:718 > > > > > > > #20 0x0804ecd3 in do_action (a=3D0x8115038, msg=3D0x81647e8) at= action.c:603 > > > > > > > #21 0x0805099d in run_actions (a=3D0x8115038, msg=3D0x81647e8) = at action.c:718 > > > > > > > #22 0x0804ecd3 in do_action (a=3D0x8115060, msg=3D0x81647e8) at= action.c:603 > > > > > > > #23 0x0805099d in run_actions (a=3D0x810fe88, msg=3D0x81647e8) = at action.c:718 > > > > > > > #24 0x0806d062 in receive_msg ( > > > > > > > buf=3D0x80d61e0 "ACK sip:0389719641(a)domain.tld:5060 SIP/2= .0\r\nMax-Forwards: 16\r\nContent-Length: 0\r\nVia: SIP/2.0/UDP 10.0.140.147:= 5060;branch=3Dz9hG4bK4f1b8571c\r\nCall-ID: bf85c76a5e2066256679e3945f6b4e36(a= )10.0.140.147\r\nF"..., len=3D592, rcv_info=3D0xbff76340) at receive.c:165 > > > > > > > #25 0x080843cc in udp_rcv_loop () at udp_server.c:472 > > > > > > > #26 0x0805cdaf in main_loop () at main.c:1056 > > > > > > > #27 0x0805e40b in main (argc=3D1, argv=3D0xbff76504) at main.c:= 1592 > > > > > > >=20 > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > sr-dev mailing list > > > > > > > sr-dev(a)lists.sip-router.org > > > > > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > > >=20 > > > _______________________________________________ > > > sr-dev mailing list > > > sr-dev(a)lists.sip-router.org > > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --===============1848070991==-- From miconda@gmail.com Thu Aug 20 10:58:02 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: tm: use server signature from config var Date: Thu, 20 Aug 2009 10:58:01 +0200 Message-ID: <20090820085801.EF287EF8070@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1546000307==" --===============1546000307== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: d3be842237ba670d671b8af0f59a39dda7503545 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3Dd3be842237ba670d671b8af0f59a39dda7503545 Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Thu Aug 20 11:48:35 2009 +0300 tm: use server signature from config var --- modules/tm/t_msgbuilder.c | 17 +++++++++++------ 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/modules/tm/t_msgbuilder.c b/modules/tm/t_msgbuilder.c index fe0eed4..a76c3db 100644 --- a/modules/tm/t_msgbuilder.c +++ b/modules/tm/t_msgbuilder.c @@ -154,7 +154,7 @@ char *build_local(struct cell *Trans,unsigned int branch, =20 /* User Agent */ if (server_signature) { - *len +=3D USER_AGENT_LEN + CRLF_LEN; + *len +=3D user_agent_hdr.len + CRLF_LEN; } /* Content Length, EoM */ *len+=3DCONTENT_LENGTH_LEN+1 + CRLF_LEN + CRLF_LEN; @@ -194,7 +194,8 @@ char *build_local(struct cell *Trans,unsigned int branch, =20 /* User Agent header */ if (server_signature) { - append_str(p,USER_AGENT CRLF, USER_AGENT_LEN+CRLF_LEN ); + append_str(p, user_agent_hdr.s, user_agent_hdr.len ); + append_str(p, CRLF, CRLF_LEN ); } /* Content Length, EoM */ append_str(p, CONTENT_LENGTH "0" CRLF CRLF , @@ -1026,7 +1027,7 @@ char *build_dlg_ack(struct sip_msg* rpl, struct cell *T= rans, *len +=3D calc_routeset_len(list, cont); =09 /* User Agent */ - if (server_signature) *len +=3D USER_AGENT_LEN + CRLF_LEN; + if (server_signature) *len +=3D user_agent_hdr.len + CRLF_LEN; /* extra headers */ if (hdrs) *len +=3D hdrs->len; @@ -1077,7 +1078,8 @@ char *build_dlg_ack(struct sip_msg* rpl, struct cell *T= rans, =09 /* User Agent header */ if (server_signature) { - append_str(p, USER_AGENT CRLF, USER_AGENT_LEN + CRLF_LEN); + append_str(p, user_agent_hdr.s, user_agent_hdr.len); + append_str(p, CRLF, CRLF_LEN); } =09 /* extra headers */ @@ -1342,7 +1344,7 @@ char* build_uac_req(str* method, str* headers, str* bod= y, dlg_t* dialog, int bra *len +=3D calculate_routeset_length(dialog); = /* Route set */ *len +=3D CONTENT_LENGTH_LEN + content_length.len + CRLF_LEN; /* Content- Length */ - *len +=3D (server_signature ? (USER_AGENT_LEN + CRLF_LEN) : 0); = /* Signature */ + *len +=3D (server_signature ? (user_agent_hdr.len + CRLF_LEN) : 0); = /* Signature */ *len +=3D (headers ? headers->len : 0); = /* Additional headers */ *len +=3D (body ? body->len : 0); = /* Message body */ *len +=3D CRLF_LEN; = /* End of Header */ @@ -1369,7 +1371,10 @@ char* build_uac_req(str* method, str* headers, str* bo= dy, dlg_t* dialog, int bra memapp(w, CRLF, CRLF_LEN); =09 /* Server signature */ - if (server_signature) memapp(w, USER_AGENT CRLF, USER_AGENT_LEN + CRLF_LEN); + if (server_signature) { + memapp(w, user_agent_hdr.s, user_agent_hdr.len); + memapp(w, CRLF, CRLF_LEN); + } if (headers) memapp(w, headers->s, headers->len); memapp(w, CRLF, CRLF_LEN); if (body) memapp(w, body->s, body->len); --===============1546000307==-- From miconda@gmail.com Thu Aug 20 10:58:02 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: core: server signature value can be set via param Date: Thu, 20 Aug 2009 10:58:02 +0200 Message-ID: <20090820085802.17EEEEF8072@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1463295637==" --===============1463295637== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: c745469fb8af0101b26de8bee82c4314dfcafab9 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3Dc745469fb8af0101b26de8bee82c4314dfcafab9 Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Thu Aug 20 11:49:14 2009 +0300 core: server signature value can be set via param - server and user agent signature were only defines so far - two new parameters server_header and user_agent_header allow to define them via cfg parameters - default values are the same so far --- cfg.lex | 4 ++++ cfg.y | 10 ++++++++++ globals.h | 2 ++ main.c | 2 ++ msg_translator.c | 6 +++--- 5 files changed, 21 insertions(+), 3 deletions(-) diff --git a/cfg.lex b/cfg.lex index 32aed32..e15c71b 100644 --- a/cfg.lex +++ b/cfg.lex @@ -329,6 +329,8 @@ MEMLOG "memlog"|"mem_log" MEMDBG "memdbg"|"mem_dbg" SIP_WARNING sip_warning SERVER_SIGNATURE server_signature +SERVER_HEADER server_header +USER_AGENT_HEADER user_agent_header REPLY_TO_VIA reply_to_via USER "user"|"uid" GROUP "group"|"gid" @@ -765,6 +767,8 @@ EAT_ABLE [\ \t\b\r] {SCTP_MAX_BURST} { count(); yylval.strval=3Dyytext; return SCTP_MAX_BURST; } {SERVER_SIGNATURE} { count(); yylval.strval=3Dyytext; return SERVER= _SIGNATURE; } +{SERVER_HEADER} { count(); yylval.strval=3Dyytext; return SERVER_HE= ADER; } +{USER_AGENT_HEADER} { count(); yylval.strval=3Dyytext; return USER_= AGENT_HEADER; } {REPLY_TO_VIA} { count(); yylval.strval=3Dyytext; return REPLY_TO_V= IA; } {ADVERTISED_ADDRESS} { count(); yylval.strval=3Dyytext; return ADVERTISED_ADDRESS; } diff --git a/cfg.y b/cfg.y index e9e8d8a..8a240c6 100644 --- a/cfg.y +++ b/cfg.y @@ -390,6 +390,8 @@ static int case_check_default(struct case_stms* stms); %token MEMDBG %token SIP_WARNING %token SERVER_SIGNATURE +%token SERVER_HEADER +%token USER_AGENT_HEADER %token REPLY_TO_VIA %token LOADMODULE %token LOADPATH @@ -1362,6 +1364,14 @@ assign_stm: | SCTP_MAX_BURST EQUAL error { yyerror("number expected"); } | SERVER_SIGNATURE EQUAL NUMBER { server_signature=3D$3; } | SERVER_SIGNATURE EQUAL error { yyerror("boolean value expected"); } + | SERVER_HEADER EQUAL STRING { server_hdr.s=3D$3; + server_hdr.len=3Dstrlen(server_hdr.s); + } + | SERVER_HEADER EQUAL error { yyerror("string value expected"); } + | USER_AGENT_HEADER EQUAL STRING { user_agent_hdr.s=3D$3; + user_agent_hdr.len=3Dstrlen(user_agent_hdr.s); + } + | USER_AGENT_HEADER EQUAL error { yyerror("string value expected"); } | REPLY_TO_VIA EQUAL NUMBER { reply_to_via=3D$3; } | REPLY_TO_VIA EQUAL error { yyerror("boolean value expected"); } | LISTEN EQUAL id_lst { diff --git a/globals.h b/globals.h index f7ef9f8..add1f40 100644 --- a/globals.h +++ b/globals.h @@ -108,6 +108,8 @@ extern int syn_branch; extern int child_rank; extern int sip_warning; extern int server_signature; +extern str server_hdr; +extern str user_agent_hdr; extern char* user; extern char* group; extern char* sock_user; diff --git a/main.c b/main.c index 9a771f8..c975057 100644 --- a/main.c +++ b/main.c @@ -345,6 +345,8 @@ int sip_warning =3D 1; be default yes, good for trouble-shooting */ int server_signature=3D1; +str server_hdr =3D {SERVER_HDR, SERVER_HDR_LEN}; +str user_agent_hdr =3D {USER_AGENT, USER_AGENT_LEN}; /* should ser try to locate outbound interface on multihomed * host? by default not -- too expensive */ diff --git a/msg_translator.c b/msg_translator.c index 2f14505..b6273b0 100644 --- a/msg_translator.c +++ b/msg_translator.c @@ -1953,7 +1953,7 @@ char * build_res_buf_from_sip_req( unsigned int code, c= har *text ,str *new_tag, } /* server header */ if (server_signature) - len +=3D SERVER_HDR_LEN + CRLF_LEN; + len +=3D server_hdr.len + CRLF_LEN; /* warning hdr */ if (sip_warning) { warning_buf =3D warning_builder(msg,&warning_len); @@ -2092,8 +2092,8 @@ char * build_res_buf_from_sip_req( unsigned int code, c= har *text ,str *new_tag, } /* server header */ if (server_signature) { - memcpy( p, SERVER_HDR , SERVER_HDR_LEN ); - p+=3DSERVER_HDR_LEN; + memcpy( p, server_hdr.s, server_hdr.len ); + p+=3Dserver_hdr.len; memcpy( p, CRLF, CRLF_LEN ); p+=3DCRLF_LEN; } --===============1463295637==-- From miconda@gmail.com Thu Aug 20 11:59:24 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: core: support to add rport parameter to local via hdr Date: Thu, 20 Aug 2009 11:59:23 +0200 Message-ID: <20090820095923.E84F7EF8070@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1985980162==" --===============1985980162== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: c37c22b4af29fed88c5655a5405876ffc640e5b2 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3Dc37c22b4af29fed88c5655a5405876ffc640e5b2 Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Thu Aug 20 12:57:01 2009 +0300 core: support to add rport parameter to local via hdr - new cfg function - add_local_rport() - to add rport parameter to local via header (rfc3581) --- action.c | 4 ++++ cfg.lex | 3 +++ cfg.y | 3 +++ msg_translator.c | 25 +++++++++++++++++++++---- parser/msg_parser.h | 1 + route_struct.h | 1 + 6 files changed, 33 insertions(+), 4 deletions(-) diff --git a/action.c b/action.c index 848ec59..8e21ee6 100644 --- a/action.c +++ b/action.c @@ -1129,6 +1129,10 @@ match_cleanup: msg->msg_flags|=3DFL_FORCE_RPORT; ret=3D1; /* continue processing */ break; + case ADD_LOCAL_RPORT_T: + msg->msg_flags|=3DFL_ADD_LOCAL_RPORT; + ret=3D1; /* continue processing */ + break; case UDP_MTU_TRY_PROTO_T: msg->msg_flags|=3D (unsigned int)a->val[0].u.number & FL_MTU_FB_MASK; ret=3D1; /* continue processing */ diff --git a/cfg.lex b/cfg.lex index e15c71b..ebe2b6d 100644 --- a/cfg.lex +++ b/cfg.lex @@ -166,6 +166,7 @@ ROUTE_SEND onsend_route ROUTE_EVENT event_route EXEC exec FORCE_RPORT "force_rport"|"add_rport" +ADD_LOCAL_RPORT "add_local_rport" FORCE_TCP_ALIAS "force_tcp_alias"|"add_tcp_alias" UDP_MTU "udp_mtu" UDP_MTU_TRY_PROTO "udp_mtu_try_proto" @@ -534,6 +535,8 @@ EAT_ABLE [\ \t\b\r] {SET_USERPHONE} { count(); yylval.strval=3Dyytext; return SET_USERPHONE; } {FORCE_RPORT} { count(); yylval.strval=3Dyytext; return FORCE_RPORT= ; } +{ADD_LOCAL_RPORT} { count(); yylval.strval=3Dyytext; + return ADD_LOCAL_RPORT; } {FORCE_TCP_ALIAS} { count(); yylval.strval=3Dyytext; return FORCE_TCP_ALIAS; } {UDP_MTU} { count(); yylval.strval=3Dyytext; return UDP_MTU; } diff --git a/cfg.y b/cfg.y index 8a240c6..6950d88 100644 --- a/cfg.y +++ b/cfg.y @@ -295,6 +295,7 @@ static int case_check_default(struct case_stms* stms); %token SET_URI %token REVERT_URI %token FORCE_RPORT +%token ADD_LOCAL_RPORT %token FORCE_TCP_ALIAS %token UDP_MTU %token UDP_MTU_TRY_PROTO @@ -2886,6 +2887,8 @@ cmd: | REVERT_URI { $$=3Dmk_action(REVERT_URI_T, 0); } | FORCE_RPORT LPAREN RPAREN { $$=3Dmk_action(FORCE_RPORT_T, 0); } | FORCE_RPORT {$$=3Dmk_action(FORCE_RPORT_T, 0); } + | ADD_LOCAL_RPORT LPAREN RPAREN { $$=3Dmk_action(ADD_LOCAL_RPORT_T, 0); } + | ADD_LOCAL_RPORT {$$=3Dmk_action(ADD_LOCAL_RPORT_T, 0); } | FORCE_TCP_ALIAS LPAREN NUMBER RPAREN { #ifdef USE_TCP $$=3Dmk_action(FORCE_TCP_ALIAS_T, 1, NUMBER_ST, (void*)$3); diff --git a/msg_translator.c b/msg_translator.c index b6273b0..e486579 100644 --- a/msg_translator.c +++ b/msg_translator.c @@ -2382,14 +2382,31 @@ char* create_via_hf( unsigned int *len, } #endif /* USE_TCP || USE_SCTP */ =20 + /* test and add rport parameter to local via - rfc3581 */ + if(msg->msg_flags&FL_ADD_LOCAL_RPORT) { + /* params so far + ';rport' + '\0' */ + via =3D (char*)pkg_malloc(extra_params.len+RPORT_LEN); + if(via=3D=3D0) { + LM_ERR("building local rport via param failed\n"); + if (extra_params.s) pkg_free(extra_params.s); + return 0; + } + if(extra_params.len!=3D0) { + memcpy(via, extra_params.s, extra_params.len); + pkg_free(extra_params.s); + } + memcpy(via + extra_params.len, RPORT, RPORT_LEN-1); + extra_params.s =3D via; + extra_params.len +=3D RPORT_LEN-1; + extra_params.s[extra_params.len]=3D'\0'; + } + set_hostport(&hp, msg); via =3D via_builder( len, send_info, branch, extra_params.len?&extra_params:0, &hp); =20 -#if defined USE_TCP || defined USE_SCTP - /* we do not need id_buf any more, the id is already in the new via header = */ - if (id_buf) pkg_free(id_buf); -#endif + /* we do not need extra_params any more, already in the new via header */ + if (extra_params.s) pkg_free(extra_params.s); return via; } =20 diff --git a/parser/msg_parser.h b/parser/msg_parser.h index a811b61..1ce00bb 100644 --- a/parser/msg_parser.h +++ b/parser/msg_parser.h @@ -109,6 +109,7 @@ enum request_method { #define FL_MTU_TCP_FB (1 << 8) #define FL_MTU_TLS_FB (1 << 9) #define FL_MTU_SCTP_FB (1 << 10) +#define FL_ADD_LOCAL_RPORT (1 << 11) /* add 'rport' to local via hdr */ =20 /* WARNING: Value (1 << 29) is temporarily reserved for use in kamailio acc * module (flag FL_REQ_UPSTREAM)! */ diff --git a/route_struct.h b/route_struct.h index 090388c..9274340 100644 --- a/route_struct.h +++ b/route_struct.h @@ -97,6 +97,7 @@ enum action_type{ FORWARD_SCTP_T, SEND_TCP_T, FORCE_RPORT_T, + ADD_LOCAL_RPORT_T, SET_ADV_ADDR_T, SET_ADV_PORT_T, FORCE_TCP_ALIAS_T, --===============1985980162==-- From klaus.mailinglists@pernau.at Thu Aug 20 12:20:33 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] git:master: core: server signature value can be set via param Date: Thu, 20 Aug 2009 12:20:03 +0200 Message-ID: <4A8D2353.4090603@pernau.at> In-Reply-To: <20090820085802.17EEEEF8072@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1325703913==" --===============1325703913== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable btw: I never understood in which case which header is used. Is there a=20 simple rule? regards klaus Daniel-Constantin Mierla schrieb: > Module: sip-router > Branch: master > Commit: c745469fb8af0101b26de8bee82c4314dfcafab9 > URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit= ;h=3Dc745469fb8af0101b26de8bee82c4314dfcafab9 >=20 > Author: Daniel-Constantin Mierla > Committer: Daniel-Constantin Mierla > Date: Thu Aug 20 11:49:14 2009 +0300 >=20 > core: server signature value can be set via param >=20 > - server and user agent signature were only defines so far > - two new parameters server_header and user_agent_header allow > to define them via cfg parameters > - default values are the same so far >=20 > --- >=20 > cfg.lex | 4 ++++ > cfg.y | 10 ++++++++++ > globals.h | 2 ++ > main.c | 2 ++ > msg_translator.c | 6 +++--- > 5 files changed, 21 insertions(+), 3 deletions(-) >=20 > diff --git a/cfg.lex b/cfg.lex > index 32aed32..e15c71b 100644 > --- a/cfg.lex > +++ b/cfg.lex > @@ -329,6 +329,8 @@ MEMLOG "memlog"|"mem_log" > MEMDBG "memdbg"|"mem_dbg" > SIP_WARNING sip_warning > SERVER_SIGNATURE server_signature > +SERVER_HEADER server_header > +USER_AGENT_HEADER user_agent_header > REPLY_TO_VIA reply_to_via > USER "user"|"uid" > GROUP "group"|"gid" > @@ -765,6 +767,8 @@ EAT_ABLE [\ \t\b\r] > {SCTP_MAX_BURST} { count(); yylval.strval=3Dyytext; > return SCTP_MAX_BURST; } > {SERVER_SIGNATURE} { count(); yylval.strval=3Dyytext; return SERV= ER_SIGNATURE; } > +{SERVER_HEADER} { count(); yylval.strval=3Dyytext; return SERVER_= HEADER; } > +{USER_AGENT_HEADER} { count(); yylval.strval=3Dyytext; return USE= R_AGENT_HEADER; } > {REPLY_TO_VIA} { count(); yylval.strval=3Dyytext; return REPLY_TO= _VIA; } > {ADVERTISED_ADDRESS} { count(); yylval.strval=3Dyytext; > return ADVERTISED_ADDRESS; } > diff --git a/cfg.y b/cfg.y > index e9e8d8a..8a240c6 100644 > --- a/cfg.y > +++ b/cfg.y > @@ -390,6 +390,8 @@ static int case_check_default(struct case_stms* stms); > %token MEMDBG > %token SIP_WARNING > %token SERVER_SIGNATURE > +%token SERVER_HEADER > +%token USER_AGENT_HEADER > %token REPLY_TO_VIA > %token LOADMODULE > %token LOADPATH > @@ -1362,6 +1364,14 @@ assign_stm: > | SCTP_MAX_BURST EQUAL error { yyerror("number expected"); } > | SERVER_SIGNATURE EQUAL NUMBER { server_signature=3D$3; } > | SERVER_SIGNATURE EQUAL error { yyerror("boolean value expected"); } > + | SERVER_HEADER EQUAL STRING { server_hdr.s=3D$3; > + server_hdr.len=3Dstrlen(server_hdr.s); > + } > + | SERVER_HEADER EQUAL error { yyerror("string value expected"); } > + | USER_AGENT_HEADER EQUAL STRING { user_agent_hdr.s=3D$3; > + user_agent_hdr.len=3Dstrlen(user_agent_hdr.s); > + } > + | USER_AGENT_HEADER EQUAL error { yyerror("string value expected"); } > | REPLY_TO_VIA EQUAL NUMBER { reply_to_via=3D$3; } > | REPLY_TO_VIA EQUAL error { yyerror("boolean value expected"); } > | LISTEN EQUAL id_lst { > diff --git a/globals.h b/globals.h > index f7ef9f8..add1f40 100644 > --- a/globals.h > +++ b/globals.h > @@ -108,6 +108,8 @@ extern int syn_branch; > extern int child_rank; > extern int sip_warning; > extern int server_signature; > +extern str server_hdr; > +extern str user_agent_hdr; > extern char* user; > extern char* group; > extern char* sock_user; > diff --git a/main.c b/main.c > index 9a771f8..c975057 100644 > --- a/main.c > +++ b/main.c > @@ -345,6 +345,8 @@ int sip_warning =3D 1; > be default yes, good for trouble-shooting > */ > int server_signature=3D1; > +str server_hdr =3D {SERVER_HDR, SERVER_HDR_LEN}; > +str user_agent_hdr =3D {USER_AGENT, USER_AGENT_LEN}; > /* should ser try to locate outbound interface on multihomed > * host? by default not -- too expensive > */ > diff --git a/msg_translator.c b/msg_translator.c > index 2f14505..b6273b0 100644 > --- a/msg_translator.c > +++ b/msg_translator.c > @@ -1953,7 +1953,7 @@ char * build_res_buf_from_sip_req( unsigned int code,= char *text ,str *new_tag, > } > /* server header */ > if (server_signature) > - len +=3D SERVER_HDR_LEN + CRLF_LEN; > + len +=3D server_hdr.len + CRLF_LEN; > /* warning hdr */ > if (sip_warning) { > warning_buf =3D warning_builder(msg,&warning_len); > @@ -2092,8 +2092,8 @@ char * build_res_buf_from_sip_req( unsigned int code,= char *text ,str *new_tag, > } > /* server header */ > if (server_signature) { > - memcpy( p, SERVER_HDR , SERVER_HDR_LEN ); > - p+=3DSERVER_HDR_LEN; > + memcpy( p, server_hdr.s, server_hdr.len ); > + p+=3Dserver_hdr.len; > memcpy( p, CRLF, CRLF_LEN ); > p+=3DCRLF_LEN; > } >=20 >=20 > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --===============1325703913==-- From miconda@gmail.com Thu Aug 20 12:36:13 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] git:master: core: server signature value can be set via param Date: Thu, 20 Aug 2009 13:36:10 +0300 Message-ID: <4A8D271A.6000508@gmail.com> In-Reply-To: <4A8D2353.4090603@pernau.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0006139125==" --===============0006139125== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 20.08.2009 13:20 Uhr, Klaus Darilion wrote: > btw: I never understood in which case which header is used. Is there a=20 > simple rule? Hi Klaus, the server header is added in local generated replies and user agent in=20 requests. Not sure if there is RFC clarifying better when and where they=20 must be used, but since SR core had two distinct defines, one for each,=20 it was the way to go. Cheers, Daniel > > regards > klaus > > > > Daniel-Constantin Mierla schrieb: >> Module: sip-router >> Branch: master >> Commit: c745469fb8af0101b26de8bee82c4314dfcafab9 >> URL: =20 >> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h=3Dc7= 45469fb8af0101b26de8bee82c4314dfcafab9=20 >> >> >> Author: Daniel-Constantin Mierla >> Committer: Daniel-Constantin Mierla >> Date: Thu Aug 20 11:49:14 2009 +0300 >> >> core: server signature value can be set via param >> >> - server and user agent signature were only defines so far >> - two new parameters server_header and user_agent_header allow >> to define them via cfg parameters >> - default values are the same so far --=20 Daniel-Constantin Mierla * http://www.asipto.com/ --===============0006139125==-- From miconda@gmail.com Thu Aug 20 15:18:37 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: pv: new pv class $sel(name) Date: Thu, 20 Aug 2009 15:18:36 +0200 Message-ID: <20090820131836.68026EF8070@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0235543259==" --===============0235543259== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: 6dac6b618015314811b94127490e906d535f44fd URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3D6dac6b618015314811b94127490e906d535f44fd Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Thu Aug 20 16:12:35 2009 +0300 pv: new pv class $sel(name) - access select (ser cfg variables) values via PV framework - read-only PV - examples: $sel(@ruri), $sel(@via[2].host) --- modules_k/pv/pv.c | 4 +++ modules_k/pv/pv_select.c | 67 ++++++++++++++++++++++++++++++++++++++++++++= ++ modules_k/pv/pv_select.h | 36 ++++++++++++++++++++++++ 3 files changed, 107 insertions(+), 0 deletions(-) diff --git a/modules_k/pv/pv.c b/modules_k/pv/pv.c index f990a55..b284bbd 100644 --- a/modules_k/pv/pv.c +++ b/modules_k/pv/pv.c @@ -35,6 +35,7 @@ #include "pv_shv.h" #include "pv_time.h" #include "pv_trans.h" +#include "pv_select.h" =20 =20 MODULE_VERSION @@ -64,6 +65,9 @@ static pv_export_t mod_pvs[] =3D { { {"stat", sizeof("stat")-1}, /* statistics */ PVT_OTHER, pv_get_stat, 0, pv_parse_stat_name, 0, 0, 0 }, + { {"sel", sizeof("sel")-1}, /* select */ + PVT_OTHER, pv_get_select, 0, + pv_parse_select_name, 0, 0, 0 }, =20 {{"avp", (sizeof("avp")-1)}, PVT_AVP, pv_get_avp, pv_set_avp, pv_parse_avp_name, pv_parse_index, 0, 0}, diff --git a/modules_k/pv/pv_select.c b/modules_k/pv/pv_select.c new file mode 100644 index 0000000..8634052 --- /dev/null +++ b/modules_k/pv/pv_select.c @@ -0,0 +1,67 @@ +/* + * $Id$ + * + * Copyright (C) 2001-2003 FhG Fokus + * + * This file is part of Kamailio, a free SIP server. + * + * Kamailio is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version + * + * Kamailio is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License=20 + * along with this program; if not, write to the Free Software=20 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +/*! + * \file + * \brief Implementation for Select Pseudo-variables + */ + +#include "../../select.h" +#include "pv_select.h" + +int pv_parse_select_name(pv_spec_p sp, str *in) +{ + select_t *sel =3D 0; + char c; + char *p; + if (in =3D=3D NULL || in->s =3D=3D NULL || sp =3D=3D NULL) + return -1; + + c =3D in->s[in->len]; + in->s[in->len] =3D '\0'; + p =3D in->s; + if(parse_select(&p, &sel)<0) + { + LM_ERR("invalid select name [%.*s]\n", + in->len, in->s); + in->s[in->len] =3D c; + return -1; + } + in->s[in->len] =3D c; + sp->pvp.pvn.u.dname =3D (void*)sel; + sp->pvp.pvn.type =3D PV_NAME_OTHER; + return 0; +} + + +int pv_get_select(struct sip_msg *msg, pv_param_t *param, pv_value_t *res) +{ + str s =3D {0, 0}; + select_t *sel =3D 0; + + sel =3D (select_t*)param->pvn.u.dname; + + if(sel=3D=3D0 || run_select(&s, sel, msg)<0 || s.s=3D=3D0) + return pv_get_null(msg, param, res); + return pv_get_strval(msg, param, res, &s); +} + diff --git a/modules_k/pv/pv_select.h b/modules_k/pv/pv_select.h new file mode 100644 index 0000000..84c872f --- /dev/null +++ b/modules_k/pv/pv_select.h @@ -0,0 +1,36 @@ +/* + * $Id$ + * + * Copyright (C) 2001-2003 FhG Fokus + * + * This file is part of Kamailio, a free SIP server. + * + * Kamailio is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version + * + * Kamailio is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License=20 + * along with this program; if not, write to the Free Software=20 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +/*! + * \file + * \brief Headers for Stats Pseudo-variables + */ + +#ifndef _PV_SELECT_H_ +#define _PV_SELECT_H_ + +#include "../../pvar.h" + +int pv_parse_select_name(pv_spec_p sp, str *in); +int pv_get_select(struct sip_msg *msg, pv_param_t *param, pv_value_t *res); + +#endif --===============0235543259==-- From miconda@gmail.com Thu Aug 20 15:23:24 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] are selects documented somewhere? Date: Thu, 20 Aug 2009 16:23:21 +0300 Message-ID: <4A8D4E49.2010004@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0679709761==" --===============0679709761== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, is there a list with available selects in ser? I only found short introduction at: http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs Thanks, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============0679709761==-- From klaus.mailinglists@pernau.at Thu Aug 20 15:31:01 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Thu, 20 Aug 2009 15:30:31 +0200 Message-ID: <4A8D4FF7.7040107@pernau.at> In-Reply-To: <4A8D4E49.2010004@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0442486486==" --===============0442486486== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Recently posted by Miklos: -------- Original-Nachricht -------- Betreff: Re: [SR-Users] sip-router select Datum: Wed, 12 Aug 2009 10:13:11 +0200 Von: Miklos Tirpak An: M=C3=89SZ=C3=81ROS Mih=C3=A1ly CC: sr-users(a)lists.sip-router.org Referenzen: <4A817281.4040301(a)niif.hu> Hi, selects come from SER, I found these pages about them: http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpairs http://www.iptel.org/attribute_value_pairs_and_selects For the list of available selects you can use http://www.iptel.org/ser/doc/search (Uncheck F, R, and P) It shows a bit older state though. Miklos On 08/11/2009 03:30 PM, M=C3=89SZ=C3=81ROS Mih=C3=A1ly wrote: > Hi! > > Can any of you explain how select framework is working? > Where can i find any documentation about it. > I am experiencing problem when i am try using it. > Any help highly appreciated! > > Regards, > Misi > Daniel-Constantin Mierla schrieb: > Hello, >=20 > is there a list with available selects in ser? I only found short=20 > introduction at: >=20 > http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpa= irs=20 >=20 >=20 > Thanks, > Daniel >=20 --===============0442486486==-- From miconda@gmail.com Thu Aug 20 15:32:34 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Thu, 20 Aug 2009 16:32:31 +0300 Message-ID: <4A8D506F.70309@gmail.com> In-Reply-To: <4A8D4FF7.7040107@pernau.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0367618993==" --===============0367618993== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: > Recently posted by Miklos: ahh, thanks, I did miss this mail... Cheers, Daniel > > -------- Original-Nachricht -------- > Betreff: Re: [SR-Users] sip-router select > Datum: Wed, 12 Aug 2009 10:13:11 +0200 > Von: Miklos Tirpak > An: M=C3=89SZ=C3=81ROS Mih=C3=A1ly > CC: sr-users(a)lists.sip-router.org > Referenzen: <4A817281.4040301(a)niif.hu> > > Hi, > > selects come from SER, I found these pages about them: > http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpa= irs=20 > > http://www.iptel.org/attribute_value_pairs_and_selects > > For the list of available selects you can use > http://www.iptel.org/ser/doc/search > (Uncheck F, R, and P) > It shows a bit older state though. > > Miklos > > On 08/11/2009 03:30 PM, M=C3=89SZ=C3=81ROS Mih=C3=A1ly wrote: > > Hi! > > > > Can any of you explain how select framework is working? > > Where can i find any documentation about it. > > I am experiencing problem when i am try using it. > > Any help highly appreciated! > > > > Regards, > > Misi > > > > Daniel-Constantin Mierla schrieb: >> Hello, >> >> is there a list with available selects in ser? I only found short=20 >> introduction at: >> >> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avp= airs=20 >> >> >> Thanks, >> Daniel >> --=20 Daniel-Constantin Mierla * http://www.asipto.com/ --===============0367618993==-- From jan@ryngle.com Thu Aug 20 15:48:05 2009 From: Jan Janak To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Thu, 20 Aug 2009 15:47:33 +0200 Message-ID: In-Reply-To: <4A8D506F.70309@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1473443379==" --===============1473443379== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Up-to-date list of implemented selects does not exist, but we once wrote a tool that can generate such list from compiled SER modules (by traversing the data structures in modules). The tool most likely won't work anymore with sip-router code, but we can try to update it if people think would be a good idea and a good think to have. The tool was called ser_objdump and its git import is here: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=3Dser;a=3Dtree;h=3Drefs/heads/= master;hb=3Drefs/heads/master In addition to selects it also produced lists if implemented module functions, module parameters, and rcp commands. The output of that tool is what is being searched by the search tool recommended by Miklos and available on iptel.org site. Jan. On Thu, Aug 20, 2009 at 3:32 PM, Daniel-Constantin Mierla wrote: > > > On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >> >> Recently posted by Miklos: > > ahh, thanks, I did miss this mail... > > Cheers, > Daniel > >> >> -------- Original-Nachricht -------- >> Betreff: Re: [SR-Users] sip-router select >> Datum: Wed, 12 Aug 2009 10:13:11 +0200 >> Von: Miklos Tirpak >> An: M=C3=89SZ=C3=81ROS Mih=C3=A1ly >> CC: sr-users(a)lists.sip-router.org >> Referenzen: <4A817281.4040301(a)niif.hu> >> >> Hi, >> >> selects come from SER, I found these pages about them: >> >> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avp= airs >> http://www.iptel.org/attribute_value_pairs_and_selects >> >> For the list of available selects you can use >> http://www.iptel.org/ser/doc/search >> (Uncheck F, R, and P) >> It shows a bit older state though. >> >> Miklos >> >> On 08/11/2009 03:30 PM, M=C3=89SZ=C3=81ROS Mih=C3=A1ly wrote: >> > Hi! >> > >> > Can any of you explain how select framework is working? >> > Where can i find any documentation about it. >> > I am experiencing problem when i am try using it. >> > Any help highly appreciated! >> > >> > Regards, >> > Misi >> > >> >> Daniel-Constantin Mierla schrieb: >>> >>> Hello, >>> >>> is there a list with available selects in ser? I only found short >>> introduction at: >>> >>> >>> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_av= pairs >>> >>> Thanks, >>> Daniel >>> > > -- > Daniel-Constantin Mierla > * http://www.asipto.com/ > > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > --===============1473443379==-- From miconda@gmail.com Thu Aug 20 15:49:43 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Thu, 20 Aug 2009 16:49:10 +0300 Message-ID: <4A8D5456.1020402@gmail.com> In-Reply-To: <4A8D4FF7.7040107@pernau.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1762627687==" --===============1762627687== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: > Recently posted by Miklos: I started a dedicated wiki page in cookbook format: http://sip-router.org/wiki/cookbooks/selects/devel Anyone having time to dig and contribute, is very welcome. Thanks, Daniel > > -------- Original-Nachricht -------- > Betreff: Re: [SR-Users] sip-router select > Datum: Wed, 12 Aug 2009 10:13:11 +0200 > Von: Miklos Tirpak > An: M=C3=89SZ=C3=81ROS Mih=C3=A1ly > CC: sr-users(a)lists.sip-router.org > Referenzen: <4A817281.4040301(a)niif.hu> > > Hi, > > selects come from SER, I found these pages about them: > http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avpa= irs=20 > > http://www.iptel.org/attribute_value_pairs_and_selects > > For the list of available selects you can use > http://www.iptel.org/ser/doc/search > (Uncheck F, R, and P) > It shows a bit older state though. > > Miklos > > On 08/11/2009 03:30 PM, M=C3=89SZ=C3=81ROS Mih=C3=A1ly wrote: > > Hi! > > > > Can any of you explain how select framework is working? > > Where can i find any documentation about it. > > I am experiencing problem when i am try using it. > > Any help highly appreciated! > > > > Regards, > > Misi > > > > Daniel-Constantin Mierla schrieb: >> Hello, >> >> is there a list with available selects in ser? I only found short=20 >> introduction at: >> >> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avp= airs=20 >> >> >> Thanks, >> Daniel >> > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > --=20 Daniel-Constantin Mierla * http://www.asipto.com/ --===============1762627687==-- From jan@ryngle.com Thu Aug 20 16:07:03 2009 From: Jan Janak To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Thu, 20 Aug 2009 16:06:32 +0200 Message-ID: In-Reply-To: <4A8D5456.1020402@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1606299329==" --===============1606299329== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Aug 20, 2009 at 3:49 PM, Daniel-Constantin Mierla wrote: > > > On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >> >> Recently posted by Miklos: > > I started a dedicated wiki page in cookbook format: > http://sip-router.org/wiki/cookbooks/selects/devel > > Anyone having time to dig and contribute, is very welcome. I found a list I generated a while ago. It is not completely up-to-date but it won't be far from it. The list in CSV format is attached in case you wanted to import it in the wiki page. The meaning of comma separated fields is as follows * module name * ser version * function/parameter/select name * Symbol type (0-function, 1-rpc, 2-param, 3-select * Number of parameters (functions) * Flags (failure route, onsend route, ...) * Documentation string (rpc functions) Jan. --===============1606299329== Content-Type: text/csv Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ser.csv" MIME-Version: 1.0 dGxzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdGxzX21ldGhvZCwyLDAsMHg0 LChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdmVyaWZ5X2Nl cnRpZmljYXRlLDIsMCwweDIsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSx2ZXJpZnlfZGVwdGgsMiwwLDB4MiwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLHJlcXVpcmVfY2VydGlmaWNhdGUsMiwwLDB4MiwobnVsbCkNCnRs cyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHByaXZhdGVfa2V5LDIsMCwweDEs KG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxjYV9saXN0LDIs MCwweDEsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxjZXJ0 aWZpY2F0ZSwyLDAsMHgxLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksY2lwaGVyX2xpc3QsMiwwLDB4MSwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLGhhbmRzaGFrZV90aW1lb3V0LDIsMCwweDIsKG51bGwpDQp0bHMsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzZW5kX3RpbWVvdXQsMiwwLDB4MiwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGNvbm5lY3Rpb25fdGlt ZW91dCwyLDAsMHgyLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksdGxzX2xvZywyLDAsMHgyLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksc2Vzc2lvbl9jYWNoZSwyLDAsMHgyLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksc2Vzc2lvbl9pZCwyLDAsMHg0LChudWxsKQ0KdGxzLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksY29uZmlnLDIsMCwweDQsKG51bGwpDQpkaWFs b2csc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxiaW5kX2RsZ19tb2QsMCwtMSww eDAsKG51bGwpDQpkaWFsb2csc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl9t b2RlLDIsMCwweDIsKG51bGwpDQpkaWFsb2csc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxkYl91cmwsMiwwLDB4NCwobnVsbCkNCnVyaV9kYixzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLGxvb2t1cF91c2VyLDAsMSwweDMsKG51bGwpDQp1cmlfZGIsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsb29rdXBfdXNlciwwLDIsMHgzLChudWxsKQ0KdXJp X2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksY2hlY2tfdXJpLDAsMSwweDMs KG51bGwpDQp1cmlfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl91cmws MiwwLDB4NCwobnVsbCkNCnVyaV9kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LHVyaV90YWJsZSwyLDAsMHg0LChudWxsKQ0KdXJpX2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksdWlkX2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KdXJpX2RiLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGlkX2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KdXJpX2Ri LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdXNlcm5hbWVfY29sdW1uLDIsMCww eDQsKG51bGwpDQp1cmlfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmbGFn c19jb2x1bW4sMiwwLDB4NCwobnVsbCkNCnVyaV9kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLHNjaGVtZV9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCnhsb2csc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx4bG9nLDAsMiwweGYsKG51bGwpDQp4bG9nLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkseGRiZywwLDEsMHhmLChudWxsKQ0KeGxvZyxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHhwcmludCwwLC0xLDB4MCwobnVsbCkNCnhs b2csc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx4cGFyc2UsMCwtMSwweDAsKG51 bGwpDQp4bG9nLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkseG51bHN0ciwwLC0x LDB4MCwobnVsbCkNCnhsb2csc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxidWZf c2l6ZSwyLDAsMHgyLChudWxsKQ0KYWNjX3JhZGl1cyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLGFjY19yYWRfbG9nLDAsMCwweDMsKG51bGwpDQphY2NfcmFkaXVzLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYWNjX3JhZF9taXNzZWQsMCwwLDB4MywobnVsbCkN CmFjY19yYWRpdXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhY2NfcmFkX2xv ZywwLDEsMHgzLChudWxsKQ0KYWNjX3JhZGl1cyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLGFjY19yYWRfbWlzc2VkLDAsMSwweDMsKG51bGwpDQphY2NfcmFkaXVzLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZWFybHlfbWVkaWEsMiwwLDB4MiwobnVsbCkNCmFj Y19yYWRpdXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmYWlsZWRfdHJhbnNh Y3Rpb25zLDIsMCwweDIsKG51bGwpDQphY2NfcmFkaXVzLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCkscmVwb3J0X2FjaywyLDAsMHgyLChudWxsKQ0KYWNjX3JhZGl1cyxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJlcG9ydF9jYW5jZWxzLDIsMCwweDIsKG51bGwp DQphY2NfcmFkaXVzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9nX2ZsYWcs MiwwLDB4MiwobnVsbCkNCmFjY19yYWRpdXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxsb2dfZmxhZywyLDAsMHg4MDAwMDAwMSwobnVsbCkNCmFjY19yYWRpdXMsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsb2dfbWlzc2VkX2ZsYWcsMiwwLDB4MiwobnVsbCkN CmFjY19yYWRpdXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsb2dfbWlzc2Vk X2ZsYWcsMiwwLDB4ODAwMDAwMDEsKG51bGwpDQphY2NfcmFkaXVzLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksbG9nX2ZtdCwyLDAsMHgxLChudWxsKQ0KYWNjX3JhZGl1cyxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGF0dHJzLDIsMCwweDEsKG51bGwpDQphY2Nf cmFkaXVzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmFkaXVzX2NvbmZpZywy LDAsMHgxLChudWxsKQ0KYWNjX3JhZGl1cyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLHNlcnZpY2VfdHlwZSwyLDAsMHgyLChudWxsKQ0KYWNjX3JhZGl1cyxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLHN3YXBfZGlyZWN0aW9uLDIsMCwweDIsKG51bGwpDQpkaXNw YXRjaGVyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZHNfc2VsZWN0X2RzdCww LDIsMHgxLChudWxsKQ0KZGlzcGF0Y2hlcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLGRzX3NlbGVjdF9uZXcsMCwyLDB4MSwobnVsbCkNCmRpc3BhdGNoZXIsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsaXN0X2ZpbGUsMiwwLDB4MSwobnVsbCkNCmRpc3BhdGNo ZXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmb3JjZV9kc3QsMiwwLDB4Miwo bnVsbCkNCmRpc3BhdGNoZXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmbGFn cywyLDAsMHgyLChudWxsKQ0KcGR0LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks cHJlZml4MmRvbWFpbiwwLDAsMHgzLChudWxsKQ0KcGR0LHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCkscHJlZml4MmRvbWFpbiwwLDEsMHgzLChudWxsKQ0KcGR0LHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCkscGR0LmFkZCwxLDAsMHgwLEFkZCBuZXcgcHJlZml4L2Rv bWFpbiB0cmFuc2xhdGlvbiBydWxlLg0KcGR0LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCkscGR0LmRlbGV0ZSwxLDAsMHgwLERlbGV0ZSBwcmVmaXgvZG9tYWluIHRyYW5zbGF0aW9u IHJ1bGUuDQpwZHQsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxwZHQubGlzdCwx LDAsMHgxLExpc3QgZXhpc3RpbiBwcmVmaXgvZG9tYWluIHRyYW5zbGF0aW9uIHJ1bGVzDQpwZHQs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl91cmwsMiwwLDB4MSwobnVsbCkN CnBkdCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRiX3RhYmxlLDIsMCwweDEs KG51bGwpDQpwZHQsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxwcmVmaXhfY29s dW1uLDIsMCwweDEsKG51bGwpDQpwZHQsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSxkb21haW5fY29sdW1uLDIsMCwweDEsKG51bGwpDQpwZHQsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxwcmVmaXgsMiwwLDB4NCwobnVsbCkNCnBkdCxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGhzaXplXzJwb3csMiwwLDB4MiwobnVsbCkNCnBkdCxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHN5bmNfdGltZSwyLDAsMHgyLChudWxsKQ0KcGR0 LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksY2xlYW5fdGltZSwyLDAsMHgyLChu dWxsKQ0KeGNhcCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHhjYXBfcXVlcnks MCwwLDB4ZmZmZmZmZmYsKG51bGwpDQp4Y2FwLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksZmlsbF94Y2FwX3BhcmFtcywwLDAsMHhmZmZmZmZmZiwobnVsbCkNCnhjYXAsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzZXRfeGNhcF9yb290LDAsMSwweDMsKG51bGwp DQp4Y2FwLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2V0X3hjYXBfZmlsZW5h bWUsMCwxLDB4MywobnVsbCkNCnhjYXAsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSx4Y2FwX3Jvb3QsMiwwLDB4NCwobnVsbCkNCmFjY19zeXNsb2csc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSxhY2Nfc3lzbG9nX2xvZywwLDAsMHgzLChudWxsKQ0KYWNjX3N5c2xv ZyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGFjY19zeXNsb2dfbWlzc2VkLDAs MCwweDMsKG51bGwpDQphY2Nfc3lzbG9nLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksYWNjX3N5c2xvZ19sb2csMCwxLDB4MywobnVsbCkNCmFjY19zeXNsb2csc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhY2Nfc3lzbG9nX21pc3NlZCwwLDEsMHgzLChudWxsKQ0K YWNjX3N5c2xvZyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGVhcmx5X21lZGlh LDIsMCwweDIsKG51bGwpDQphY2Nfc3lzbG9nLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksZmFpbGVkX3RyYW5zYWN0aW9ucywyLDAsMHgyLChudWxsKQ0KYWNjX3N5c2xvZyxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJlcG9ydF9hY2ssMiwwLDB4MiwobnVsbCkN CmFjY19zeXNsb2csc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZXBvcnRfY2Fu Y2VscywyLDAsMHgyLChudWxsKQ0KYWNjX3N5c2xvZyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLGxvZ19mbGFnLDIsMCwweDIsKG51bGwpDQphY2Nfc3lzbG9nLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9nX2ZsYWcsMiwwLDB4ODAwMDAwMDEsKG51bGwpDQph Y2Nfc3lzbG9nLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9nX21pc3NlZF9m bGFnLDIsMCwweDIsKG51bGwpDQphY2Nfc3lzbG9nLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksbG9nX21pc3NlZF9mbGFnLDIsMCwweDgwMDAwMDAxLChudWxsKQ0KYWNjX3N5c2xv ZyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGxvZ19sZXZlbCwyLDAsMHgyLChu dWxsKQ0KYWNjX3N5c2xvZyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGxvZ19m bXQsMiwwLDB4MSwobnVsbCkNCmFjY19zeXNsb2csc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxhdHRycywyLDAsMHgxLChudWxsKQ0KY3RsLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksY3RsLndobywxLDAsMHgwLGxpc3Qgb3BlbiBjb25uZWN0aW9ucw0KY3RsLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksY3RsLmNvbm5lY3Rpb25zLDEsMCwweDAs cmV0dXJucyBudW1iZXIgb2Ygb3BlbiBjb25uZWN0aW9ucw0KY3RsLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksY3RsLmxpc3RlbiwxLDAsMHgwLGxpc3QgY3RsIGxpc3RlbiBzb2Nr ZXRzDQpjdGwsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmaWZvLDIsMCwweDgw MDAwMDAxLChudWxsKQ0KY3RsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYmlu cnBjLDIsMCwweDgwMDAwMDAxLChudWxsKQ0KY3RsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksbW9kZSwyLDAsMHgyLChudWxsKQ0KY3RsLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksdXNlciwyLDAsMHg4MDAwMDAwMSwobnVsbCkNCmN0bCxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLGdyb3VwLDIsMCwweDgwMDAwMDAxLChudWxsKQ0KbmF0aGVs cGVyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZml4X25hdGVkX2NvbnRhY3Qs MCwwLDB4NSwobnVsbCkNCm5hdGhlbHBlcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLGZpeF9uYXRlZF9zZHAsMCwxLDB4NywobnVsbCkNCm5hdGhlbHBlcixzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLHVuZm9yY2VfcnRwX3Byb3h5LDAsMCwweDcsKG51bGwpDQpu YXRoZWxwZXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx1bmZvcmNlX3J0cF9w cm94eSwwLDEsMHg3LChudWxsKQ0KbmF0aGVscGVyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksZm9yY2VfcnRwX3Byb3h5LDAsMCwweDUsKG51bGwpDQpuYXRoZWxwZXIsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmb3JjZV9ydHBfcHJveHksMCwxLDB4NSwobnVs bCkNCm5hdGhlbHBlcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGZvcmNlX3J0 cF9wcm94eSwwLDIsMHg1LChudWxsKQ0KbmF0aGVscGVyLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksbmF0X3VhY190ZXN0LDAsMSwweDcsKG51bGwpDQpuYXRoZWxwZXIsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmaXhfbmF0ZWRfcmVnaXN0ZXIsMCwwLDB4MSwo bnVsbCkNCm5hdGhlbHBlcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHBpbmdf Y29udGFjdCwwLDEsMHgxLChudWxsKQ0KbmF0aGVscGVyLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksbmF0cGluZ19pbnRlcnZhbCwyLDAsMHgyLChudWxsKQ0KbmF0aGVscGVyLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbmF0cGluZ19tZXRob2QsMiwwLDB4MSwo bnVsbCkNCm5hdGhlbHBlcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHBpbmdf bmF0ZWRfb25seSwyLDAsMHgyLChudWxsKQ0KbmF0aGVscGVyLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCkscnRwcHJveHlfc29jaywyLDAsMHgxLChudWxsKQ0KbmF0aGVscGVyLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscnRwcHJveHlfZGlzYWJsZSwyLDAsMHgy LChudWxsKQ0KbmF0aGVscGVyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscnRw cHJveHlfZGlzYWJsZV90b3V0LDIsMCwweDIsKG51bGwpDQpuYXRoZWxwZXIsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxydHBwcm94eV9yZXRyLDIsMCwweDIsKG51bGwpDQpuYXRo ZWxwZXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxydHBwcm94eV90b3V0LDIs MCwweDIsKG51bGwpDQpuYXRoZWxwZXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSxmb3JjZV9zb2NrZXQsMiwwLDB4MSwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLHVsX3JlZ2lzdGVyX3Vkb21haW4sMCwxLDB4MCwobnVsbCkNCnVzcmxv YyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVsX2luc2VydF91cmVjb3JkLDAs MSwweDAsKG51bGwpDQp1c3Jsb2Msc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx1 bF9kZWxldGVfdXJlY29yZCwwLDEsMHgwLChudWxsKQ0KdXNybG9jLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksdWxfZ2V0X3VyZWNvcmQsMCwxLDB4MCwobnVsbCkNCnVzcmxvYyxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVsX2xvY2tfdWRvbWFpbiwwLDEsMHgw LChudWxsKQ0KdXNybG9jLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdWxfdW5s b2NrX3Vkb21haW4sMCwxLDB4MCwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLHVsX3JlbGVhc2VfdXJlY29yZCwwLDEsMHgwLChudWxsKQ0KdXNybG9jLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdWxfaW5zZXJ0X3Vjb250YWN0LDAsMSww eDAsKG51bGwpDQp1c3Jsb2Msc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx1bF9k ZWxldGVfdWNvbnRhY3QsMCwxLDB4MCwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLHVsX2dldF91Y29udGFjdCwwLDEsMHgwLChudWxsKQ0KdXNybG9jLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdWxfZ2V0X3Vjb250YWN0X2J5X2luc3Qs MCwxLDB4MCwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LHVsX2dldF9hbGxfdWNvbnRhY3RzLDAsMSwweDAsKG51bGwpDQp1c3Jsb2Msc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx1bF91cGRhdGVfdWNvbnRhY3QsMCwxLDB4MCwobnVsbCkN CnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVsX3JlZ2lzdGVyX3dh dGNoZXIsMCwxLDB4MCwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLHVsX3VucmVnaXN0ZXJfd2F0Y2hlciwwLDEsMHgwLChudWxsKQ0KdXNybG9jLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdWxfYmluZF91c3Jsb2MsMCwxLDB4MCwobnVs bCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVsX3JlZ2lzdGVy X3VsY2IsMCwxLDB4MCwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLHJlYWRfcmVnX2F2cHMsMCwyLDB4YiwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLHVpZF9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCnVzcmxvYyxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGNvbnRhY3RfY29sdW1uLDIsMCwweDQs KG51bGwpDQp1c3Jsb2Msc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxleHBpcmVz X2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KdXNybG9jLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCkscV9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGNhbGxpZF9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCnVzcmxvYyxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGNzZXFfY29sdW1uLDIsMCwweDQsKG51 bGwpDQp1c3Jsb2Msc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxtZXRob2RfY29s dW1uLDIsMCwweDQsKG51bGwpDQp1c3Jsb2Msc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxmbGFnc19jb2x1bW4sMiwwLDB4NCwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGRiX3VybCwyLDAsMHg0LChudWxsKQ0KdXNybG9jLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdGltZXJfaW50ZXJ2YWwsMiwwLDB4MiwobnVsbCkN CnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRiX21vZGUsMiwwLDB4 MiwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRlc2Nf dGltZV9vcmRlciwyLDAsMHgyLChudWxsKQ0KdXNybG9jLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksdXNlcl9hZ2VudF9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCnVzcmxvYyxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJlY2VpdmVkX2NvbHVtbiwyLDAsMHg0LChu dWxsKQ0KdXNybG9jLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksaW5zdGFuY2Vf Y29sdW1uLDIsMCwweDQsKG51bGwpDQp1c3Jsb2Msc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxhb3JfY29sdW1uLDIsMCwweDQsKG51bGwpDQp1c3Jsb2Msc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxyZWdfYXZwX3RhYmxlLDIsMCwweDEsKG51bGwpDQp1c3Jsb2Ms c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZWdfYXZwX2NvbHVtbiwyLDAsMHgx LChudWxsKQ0KdXNybG9jLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmVnYXZw X3VpZF9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLHJlZ2F2cF9jb250YWN0X2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KdXNybG9j LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmVnYXZwX25hbWVfY29sdW1uLDIs MCwweDEsKG51bGwpDQp1c3Jsb2Msc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxy ZWdhdnBfdmFsdWVfY29sdW1uLDIsMCwweDEsKG51bGwpDQp1c3Jsb2Msc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxyZWdhdnBfdHlwZV9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCnVz cmxvYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJlZ2F2cF9mbGFnc19jb2x1 bW4sMiwwLDB4MSwobnVsbCkNCnVzcmxvYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLHJlZ19hdnBfZmxhZywyLDAsMHgxLChudWxsKQ0KZmxhdHN0b3JlLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksZGJfdXNlX3RhYmxlLDAsMiwweDAsKG51bGwpDQpmbGF0c3Rv cmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl9pbml0LDAsMSwweDAsKG51 bGwpDQpmbGF0c3RvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl9jbG9z ZSwwLDIsMHgwLChudWxsKQ0KZmxhdHN0b3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksZGJfaW5zZXJ0LDAsMiwweDAsKG51bGwpDQpmbGF0c3RvcmUsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxmbHVzaCwyLDAsMHgyLChudWxsKQ0KZmxhdHN0b3JlLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZmllbGRfZGVsaW1pdGVyLDIsMCwweDEsKG51 bGwpDQpmbGF0c3RvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZWNvcmRf ZGVsaW1pdGVyLDIsMCwweDEsKG51bGwpDQpmbGF0c3RvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxlc2NhcGVfY2hhciwyLDAsMHgxLChudWxsKQ0KYXZwLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2V0X2lhdHRyLDAsMiwweDcsKG51bGwpDQphdnAsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzZXRfc2F0dHIsMCwyLDB4NywobnVsbCkN CmF2cCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNldF9hdHRyLDAsMiwweDcs KG51bGwpDQphdnAsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxwcmludF9hdHRy LDAsMSwweDcsKG51bGwpDQphdnAsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxk ZWxfYXR0ciwwLDEsMHg3LChudWxsKQ0KYXZwLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksZGVsX2F0dHJzLDAsMSwweDcsKG51bGwpDQphdnAsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxzdWJzdF9hdHRyLDAsMiwweDcsKG51bGwpDQphdnAsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmbGFnczJhdHRyLDAsMSwweDcsKG51bGwpDQphdnAsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhdHRyMnVyaSwwLDEsMHgzLChudWxsKQ0K YXZwLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYXR0cjJ1cmksMCwyLDB4Mywo bnVsbCkNCmF2cCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGR1bXBfYXR0cnMs MCwwLDB4NywobnVsbCkNCmF2cCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGR1 bXBfYXR0cnMsMCwxLDB4NywobnVsbCkNCmF2cCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLGF0dHJfZXF1YWxzLDAsMiwweDcsKG51bGwpDQphdnAsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSxhdHRyX2V4aXN0cywwLDEsMHg3LChudWxsKQ0KYXZwLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYXR0cl9lcXVhbHNfeGwsMCwyLDB4NywobnVsbCkN CmF2cCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHhsc2V0X2F0dHIsMCwyLDB4 NywobnVsbCkNCmF2cCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGluc2VydF9h dHRyX2hmLDAsMiwweDMsKG51bGwpDQphdnAsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxpbnNlcnRfYXR0cl9oZiwwLDEsMHgzLChudWxsKQ0KYXZwLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksYXBwZW5kX2F0dHJfaGYsMCwyLDB4MywobnVsbCkNCmF2cCxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGFwcGVuZF9hdHRyX2hmLDAsMSwweDMsKG51 bGwpDQphdnAsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZXBsYWNlX2F0dHJf aGYsMCwyLDB4MywobnVsbCkNCmF2cCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LHJlcGxhY2VfYXR0cl9oZiwwLDEsMHgzLChudWxsKQ0KYXZwLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksYXR0cl90b19yZXBseSwwLDIsMHgzLChudWxsKQ0KYXZwLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYXR0cl90b19yZXBseSwwLDEsMHgzLChudWxsKQ0K YXZwLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYXR0cl9kZXN0aW5hdGlvbiww LDEsMHgxLChudWxsKQ0KYXZwLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkseGxz ZXRfZGVzdGluYXRpb24sMCwxLDB4MSwobnVsbCkNCmF2cCxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLGhkcl9ib2R5MmF0dHJzLDAsMiwweDcsKG51bGwpDQphdnAsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxoZHJfYm9keTJhdHRyczIsMCwyLDB4NywobnVsbCkN CmF2cCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHhsYnVmX3NpemUsMiwwLDB4 MiwobnVsbCkNCmphYmJlcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGphYl9z ZW5kX21lc3NhZ2UsMCwwLDB4MSwobnVsbCkNCmphYmJlcixzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLGphYl9qb2luX2pjb25mLDAsMCwweDEsKG51bGwpDQpqYWJiZXIsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxqYWJfZXhpdF9qY29uZiwwLDAsMHgxLChudWxs KQ0KamFiYmVyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksamFiX2dvX29ubGlu ZSwwLDAsMHgxLChudWxsKQ0KamFiYmVyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksamFiX2dvX29mZmxpbmUsMCwwLDB4MSwobnVsbCkNCmphYmJlcixzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGphYl9yZWdpc3Rlcl93YXRjaGVyLDAsMSwweDAsKG51bGwpDQpq YWJiZXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxqYWJfdW5yZWdpc3Rlcl93 YXRjaGVyLDAsMSwweDAsKG51bGwpDQpqYWJiZXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxsb2FkX3hqYWIsMCwxLDB4MCwobnVsbCkNCmphYmJlcixzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGRiX3VybCwyLDAsMHgxLChudWxsKQ0KamFiYmVyLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksamFkZHJlc3MsMiwwLDB4MSwobnVsbCkNCmphYmJl cixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGFsaWFzZXMsMiwwLDB4MSwobnVs bCkNCmphYmJlcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHByb3h5LDIsMCww eDEsKG51bGwpDQpqYWJiZXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxqZG9t YWluLDIsMCwweDEsKG51bGwpDQpqYWJiZXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxyZWdpc3RyYXIsMiwwLDB4MSwobnVsbCkNCmphYmJlcixzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLGpwb3J0LDIsMCwweDIsKG51bGwpDQpqYWJiZXIsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx3b3JrZXJzLDIsMCwweDIsKG51bGwpDQpqYWJiZXIsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxtYXhfam9icywyLDAsMHgyLChudWxsKQ0K amFiYmVyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksY2FjaGVfdGltZSwyLDAs MHgyLChudWxsKQ0KamFiYmVyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGVs YXlfdGltZSwyLDAsMHgyLChudWxsKQ0KamFiYmVyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksc2xlZXBfdGltZSwyLDAsMHgyLChudWxsKQ0KamFiYmVyLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksY2hlY2tfdGltZSwyLDAsMHgyLChudWxsKQ0KcHJpbnRfc3Rk b3V0LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscHJpbnQsMCwwLDB4MSwobnVs bCkNCnByaW50X3N0ZG91dCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHByaW50 LDAsMSwweDEsKG51bGwpDQpwcmludF9zdGRvdXQsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxwcmludCwwLDIsMHgxLChudWxsKQ0KcHJpbnRfc3Rkb3V0LHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksc3RyaW5nX3BhcmFtLDIsMCwweDEsKG51bGwpDQpwcmludF9z dGRvdXQsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzdHJfcGFyYW0sMiwwLDB4 NCwobnVsbCkNCnByaW50X3N0ZG91dCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGludF9wYXJhbSwyLDAsMHgyLChudWxsKQ0Kc21zLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksc21zX3NlbmRfbXNnX3RvX25ldCwwLDEsMHgxLChudWxsKQ0Kc21zLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc21zX3NlbmRfbXNnLDAsMCwweDEsKG51bGwpDQpz bXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxuZXR3b3JrcywyLDAsMHgxLChu dWxsKQ0Kc21zLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbW9kZW1zLDIsMCww eDEsKG51bGwpDQpzbXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsaW5rcywy LDAsMHgxLChudWxsKQ0Kc21zLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGVm YXVsdF9uZXQsMiwwLDB4MSwobnVsbCkNCnNtcyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLG1heF9zbXNfcGFydHMsMiwwLDB4MiwobnVsbCkNCnNtcyxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGRvbWFpbiwyLDAsMHgxLChudWxsKQ0Kc21zLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksdXNlX2NvbnRhY3QsMiwwLDB4MiwobnVsbCkNCnNtcyxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNtc19yZXBvcnRfdHlwZSwyLDAsMHgy LChudWxsKQ0Kc3BlZWRkaWFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2Rf bG9va3VwLDAsMSwweDEsKG51bGwpDQpzcGVlZGRpYWwsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChp Mzg2L2xpbnV4KSxkYl91cmwsMiwwLDB4MSwobnVsbCkNCnNwZWVkZGlhbCxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLHVpZF9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCnNwZWVkZGlh bCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRpYWxfdXNlcm5hbWVfY29sdW1u LDIsMCwweDEsKG51bGwpDQpzcGVlZGRpYWwsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxkaWFsX2RpZF9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCnNwZWVkZGlhbCxzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLG5ld191cmlfY29sdW1uLDIsMCwweDEsKG51bGwpDQpk Yl9vcHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl9xdWVyeSwwLDEsMHgx ZiwobnVsbCkNCmRiX29wcyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRiX3F1 ZXJ5LDAsMiwweDFmLChudWxsKQ0KZGJfb3BzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksZGJfY2xvc2UsMCwxLDB4MWYsKG51bGwpDQpkYl9vcHMsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSxkYl9mb3JlYWNoLDAsMiwweDFmLChudWxsKQ0KZGJfb3BzLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGJfdXJsLDIsMCwweDEsKG51bGwpDQpkYl9v cHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkZWNsYXJlX3F1ZXJ5LDIsMCww eDgwMDAwMDAxLChudWxsKQ0KZGJfb3BzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCkseGxidWZfc2l6ZSwyLDAsMHgyLChudWxsKQ0KZGJfb3BzLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksbWF4X3F1ZXJpZXMsMiwwLDB4MiwobnVsbCkNCmFjY19kYixzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGFjY19kYl9sb2csMCwwLDB4MywobnVsbCkNCmFj Y19kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGFjY19kYl9taXNzZWQsMCww LDB4MywobnVsbCkNCmFjY19kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGFj Y19kYl9sb2csMCwxLDB4MywobnVsbCkNCmFjY19kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLGFjY19kYl9taXNzZWQsMCwxLDB4MywobnVsbCkNCmFjY19kYixzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGVhcmx5X21lZGlhLDIsMCwweDIsKG51bGwpDQphY2Nf ZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmYWlsZWRfdHJhbnNhY3Rpb25z LDIsMCwweDIsKG51bGwpDQphY2NfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSxyZXBvcnRfYWNrLDIsMCwweDIsKG51bGwpDQphY2NfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxyZXBvcnRfY2FuY2VscywyLDAsMHgyLChudWxsKQ0KYWNjX2RiLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9nX2ZsYWcsMiwwLDB4MiwobnVsbCkNCmFj Y19kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGxvZ19mbGFnLDIsMCwweDgw MDAwMDAxLChudWxsKQ0KYWNjX2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks bG9nX21pc3NlZF9mbGFnLDIsMCwweDIsKG51bGwpDQphY2NfZGIsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSxsb2dfbWlzc2VkX2ZsYWcsMiwwLDB4ODAwMDAwMDEsKG51bGwpDQph Y2NfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsb2dfZm10LDIsMCwweDEs KG51bGwpDQphY2NfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhdHRycywy LDAsMHgxLChudWxsKQ0KYWNjX2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks ZGJfdXJsLDIsMCwweDQsKG51bGwpDQphY2NfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxhY2NfdGFibGUsMiwwLDB4NCwobnVsbCkNCmFjY19kYixzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLG1jX3RhYmxlLDIsMCwweDQsKG51bGwpDQphY2NfZGIsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhdHRyc19jb2x1bW4sMiwwLDB4NCwobnVsbCkN CmFjY19kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGNhbGxpZF9jb2x1bW4s MiwwLDB4NCwobnVsbCkNCmFjY19kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LHRvdGFnX2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KYWNjX2RiLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksZnJvbV9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCmFjY19kYixzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGZsYWdzX2NvbHVtbiwyLDAsMHg0LChudWxsKQ0K YWNjX2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksaXVyaV9jb2x1bW4sMiww LDB4NCwobnVsbCkNCmFjY19kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLG1l dGhvZF9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCmFjY19kYixzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLGNzZXFfY29sdW1uLDIsMCwweDQsKG51bGwpDQphY2NfZGIsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxvdXJpX2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KYWNj X2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZnJvbXRhZ19jb2x1bW4sMiww LDB4NCwobnVsbCkNCmFjY19kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRv X2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KYWNjX2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksZGlndXNlcl9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCmFjY19kYixzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJlcXRpbWVzdGFtcF9jb2x1bW4sMiwwLDB4NCwobnVs bCkNCmFjY19kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRvZGlkX2NvbHVt biwyLDAsMHg0LChudWxsKQ0KYWNjX2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksZnJvbXVyaV9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCmFjY19kYixzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGZyb211aWRfY29sdW1uLDIsMCwweDQsKG51bGwpDQphY2NfZGIs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmcm9tZGlkX2NvbHVtbiwyLDAsMHg0 LChudWxsKQ0KYWNjX2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGlncmVh bG1fY29sdW1uLDIsMCwweDQsKG51bGwpDQphY2NfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChp Mzg2L2xpbnV4KSxzdGF0dXNfY29sdW1uLDIsMCwweDQsKG51bGwpDQphY2NfZGIsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0b3VyaV9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCmFj Y19kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRvdWlkX2NvbHVtbiwyLDAs MHg0LChudWxsKQ0KYWNjX2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmVz dGltZXN0YW1wX2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KYWNjX2RiLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksc3JjX2lwX2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KYWNjX2RiLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc3JjX3BvcnRfY29sdW1uLDIsMCwweDQs KG51bGwpDQptZWRpYXByb3h5LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZml4 X2NvbnRhY3QsMCwwLDB4NSwobnVsbCkNCm1lZGlhcHJveHksc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSx1c2VfbWVkaWFfcHJveHksMCwwLDB4NSwobnVsbCkNCm1lZGlhcHJveHks c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxlbmRfbWVkaWFfc2Vzc2lvbiwwLDAs MHg3LChudWxsKQ0KbWVkaWFwcm94eSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGNsaWVudF9uYXRfdGVzdCwwLDEsMHg3LChudWxsKQ0KbWVkaWFwcm94eSxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLG1lZGlhcHJveHlfc29ja2V0LDIsMCwweDEsKG51bGwpDQpt ZWRpYXByb3h5LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2lwX2FzeW1tZXRy aWNzLDIsMCwweDEsKG51bGwpDQptZWRpYXByb3h5LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCkscnRwX2FzeW1tZXRyaWNzLDIsMCwweDEsKG51bGwpDQptZWRpYXByb3h5LHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbmF0cGluZ19pbnRlcnZhbCwyLDAsMHgyLChu dWxsKQ0KYXV0aCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGNvbnN1bWVfY3Jl ZGVudGlhbHMsMCwwLDB4MSwobnVsbCkNCmF1dGgsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxiaW5kX2F1dGgsMCwwLDB4MCwobnVsbCkNCmF1dGgsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSxzZWNyZXQsMiwwLDB4MSwobnVsbCkNCmF1dGgsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxub25jZV9leHBpcmUsMiwwLDB4MiwobnVsbCkNCmF1dGgs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxwcm90ZWN0X2NvbnRhY3RzLDIsMCww eDIsKG51bGwpDQphdXRoLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksY2hhbGxl bmdlX2F0dHIsMiwwLDB4NCwobnVsbCkNCmF1dGgsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxwcm94eV9jaGFsbGVuZ2VfaGVhZGVyLDIsMCwweDQsKG51bGwpDQphdXRoLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksd3d3X2NoYWxsZW5nZV9oZWFkZXIsMiwwLDB4 NCwobnVsbCkNCmF1dGgsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxxb3AsMiww LDB4NCwobnVsbCkNCmRpdmVyc2lvbixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGFkZF9kaXZlcnNpb24sMCwxLDB4MywobnVsbCkNCmRpdmVyc2lvbixzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLHN1ZmZpeCwyLDAsMHg0LChudWxsKQ0KbXlzcWwsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl91c2VfdGFibGUsMCwyLDB4MCwobnVsbCkNCm15 c3FsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGJfaW5pdCwwLDEsMHgwLChu dWxsKQ0KbXlzcWwsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl9jbG9zZSww LDIsMHgwLChudWxsKQ0KbXlzcWwsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxk Yl9xdWVyeSwwLDIsMHgwLChudWxsKQ0KbXlzcWwsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxkYl9yYXdfcXVlcnksMCwyLDB4MCwobnVsbCkNCm15c3FsLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksZGJfZnJlZV9yZXN1bHQsMCwyLDB4MCwobnVsbCkNCm15c3Fs LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGJfaW5zZXJ0LDAsMiwweDAsKG51 bGwpDQpteXNxbCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRiX2RlbGV0ZSww LDIsMHgwLChudWxsKQ0KbXlzcWwsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxk Yl91cGRhdGUsMCwyLDB4MCwobnVsbCkNCm15c3FsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksZGJfcmVwbGFjZSwwLDIsMHgwLChudWxsKQ0KbXlzcWwsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxwaW5nX2ludGVydmFsLDIsMCwweDIsKG51bGwpDQpteXNxbCxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGF1dG9fcmVjb25uZWN0LDIsMCwweDIs KG51bGwpDQpkYnRleHQsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl91c2Vf dGFibGUsMCwyLDB4MCwobnVsbCkNCmRidGV4dCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLGRiX2luaXQsMCwxLDB4MCwobnVsbCkNCmRidGV4dCxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLGRiX2Nsb3NlLDAsMiwweDAsKG51bGwpDQpkYnRleHQsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl9xdWVyeSwwLDIsMHgwLChudWxsKQ0KZGJ0ZXh0 LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGJfcmF3X3F1ZXJ5LDAsMiwweDAs KG51bGwpDQpkYnRleHQsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl9mcmVl X3Jlc3VsdCwwLDIsMHgwLChudWxsKQ0KZGJ0ZXh0LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksZGJfaW5zZXJ0LDAsMiwweDAsKG51bGwpDQpkYnRleHQsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxkYl9kZWxldGUsMCwyLDB4MCwobnVsbCkNCmRidGV4dCxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRiX3VwZGF0ZSwwLDIsMHgwLChudWxsKQ0K cG9zdGdyZXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl91c2VfdGFibGUs MCwyLDB4MCwobnVsbCkNCnBvc3RncmVzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksZGJfaW5pdCwwLDEsMHgwLChudWxsKQ0KcG9zdGdyZXMsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxkYl9jbG9zZSwwLDIsMHgwLChudWxsKQ0KcG9zdGdyZXMsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl9xdWVyeSwwLDIsMHgwLChudWxsKQ0KcG9zdGdy ZXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl9yYXdfcXVlcnksMCwyLDB4 MCwobnVsbCkNCnBvc3RncmVzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGJf ZnJlZV9yZXN1bHQsMCwyLDB4MCwobnVsbCkNCnBvc3RncmVzLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksZGJfaW5zZXJ0LDAsMiwweDAsKG51bGwpDQpwb3N0Z3JlcyxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRiX2RlbGV0ZSwwLDIsMHgwLChudWxsKQ0KcG9z dGdyZXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl91cGRhdGUsMCwyLDB4 MCwobnVsbCkNCnBvc3RncmVzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksY29u bmVjdF90aW1lb3V0LDIsMCwweDIsKG51bGwpDQpwb3N0Z3JlcyxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLHJlY29ubmVjdF9hdHRlbXB0cywyLDAsMHgyLChudWxsKQ0KYXZwX2Ri LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9hZF9hdHRycywwLDIsMHgzLChu dWxsKQ0KYXZwX2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGJfdXJsLDIs MCwweDEsKG51bGwpDQphdnBfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx1 c2VyX2F0dHJzX3RhYmxlLDIsMCwweDEsKG51bGwpDQphdnBfZGIsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSx1cmlfYXR0cnNfdGFibGUsMiwwLDB4MSwobnVsbCkNCmF2cF9kYixz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVpZF9jb2x1bW4sMiwwLDB4MSwobnVs bCkNCmF2cF9kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVzZXJuYW1lX2Nv bHVtbiwyLDAsMHgxLChudWxsKQ0KYXZwX2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksZGlkX2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KYXZwX2RiLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksbmFtZV9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCmF2cF9kYixzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHR5cGVfY29sdW1uLDIsMCwweDEsKG51bGwp DQphdnBfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx2YWx1ZV9jb2x1bW4s MiwwLDB4MSwobnVsbCkNCmF2cF9kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGZsYWdzX2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KYXZwX2RiLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksc2NoZW1lX2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KdGltZXIsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0aW1lcl9lbmFibGUsMCwyLDB4MWYsKG51bGwp DQp0aW1lcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRlY2xhcmVfdGltZXIs MiwwLDB4ODAwMDAwMDEsKG51bGwpDQphdnBvcHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxhdnBfZGJfbG9hZCwwLDIsMHgzLChudWxsKQ0KYXZwb3BzLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksYXZwX2RiX3N0b3JlLDAsMiwweDMsKG51bGwpDQphdnBvcHMs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhdnBfZGJfZGVsZXRlLDAsMiwweDMs KG51bGwpDQphdnBvcHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhdnBfd3Jp dGUsMCwyLDB4MywobnVsbCkNCmF2cG9wcyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLGF2cF9kZWxldGUsMCwxLDB4MywobnVsbCkNCmF2cG9wcyxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLGF2cF9wdXNodG8sMCwyLDB4MywobnVsbCkNCmF2cG9wcyxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGF2cF9jaGVjaywwLDIsMHgzLChudWxsKQ0KYXZw b3BzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYXZwX2NvcHksMCwyLDB4Mywo bnVsbCkNCmF2cG9wcyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGF2cF9wcmlu dCwwLDAsMHgzLChudWxsKQ0KYXZwb3BzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksYXZwX3VybCwyLDAsMHgxLChudWxsKQ0KYXZwb3BzLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksYXZwX3RhYmxlLDIsMCwweDEsKG51bGwpDQphdnBvcHMsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhdnBfYWxpYXNlcywyLDAsMHg4MDAwMDAwMSwobnVsbCkN CmF2cG9wcyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVzZV9kb21haW4sMiww LDB4MiwobnVsbCkNCmF2cG9wcyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVp ZF9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCmF2cG9wcyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLG5hbWVfY29sdW1uLDIsMCwweDEsKG51bGwpDQphdnBvcHMsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx2YWx1ZV9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCmF2cG9w cyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHR5cGVfY29sdW1uLDIsMCwweDEs KG51bGwpDQphdnBvcHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx1c2VybmFt ZV9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCmF2cG9wcyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLGRvbWFpbl9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCmF2cG9wcyxzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRiX3NjaGVtZSwyLDAsMHg4MDAwMDAwMSwobnVsbCkN CmVudW0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxlbnVtX3F1ZXJ5LDAsMCww eDEsKG51bGwpDQplbnVtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZW51bV9x dWVyeSwwLDEsMHgxLChudWxsKQ0KZW51bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLGVudW1fcXVlcnksMCwyLDB4MSwobnVsbCkNCmVudW0sc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxpc19lMTY0LDAsMSwweDEsKG51bGwpDQplbnVtLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksZG9tYWluX3N1ZmZpeCwyLDAsMHg0LChudWxsKQ0KZW51bSxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRlbF91cmlfcGFyYW1zLDIsMCwweDQs KG51bGwpDQplbnVtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGVmYXVsdF9z ZXJ2aWNlLDIsMCwweDQsKG51bGwpDQpybHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxoYW5kbGVfcmxzX3N1YnNjcmlwdGlvbiwwLDEsMHgzLChudWxsKQ0KcmxzLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksaXNfc2ltcGxlX3Jsc190YXJnZXQsMCwxLDB4Mywo bnVsbCkNCnJscyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHF1ZXJ5X3Jsc19z ZXJ2aWNlcywwLDAsMHgzLChudWxsKQ0KcmxzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCkscXVlcnlfcmVzb3VyY2VfbGlzdCwwLDEsMHgzLChudWxsKQ0KcmxzLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksaGF2ZV9mbGF0X2xpc3QsMCwwLDB4MywobnVsbCkNCnJs cyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLG1pbl9leHBpcmF0aW9uLDIsMCww eDIsKG51bGwpDQpybHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxtYXhfZXhw aXJhdGlvbiwyLDAsMHgyLChudWxsKQ0KcmxzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksZGVmYXVsdF9leHBpcmF0aW9uLDIsMCwweDIsKG51bGwpDQpybHMsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhdXRoLDIsMCwweDEsKG51bGwpDQpybHMsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl9tb2RlLDIsMCwweDIsKG51bGwpDQpybHMsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl91cmwsMiwwLDB4MSwobnVsbCkNCnJs cyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJlZHVjZV94Y2FwX25lZWRzLDIs MCwweDIsKG51bGwpDQpybHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxtYXhf bm90aWZpY2F0aW9uc19hdF9vbmNlLDIsMCwweDIsKG51bGwpDQpybHMsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSx0aW1lcl9pbnRlcnZhbCwyLDAsMHgyLChudWxsKQ0KcmxzLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbWF4X2xpc3RfbmVzdGluZ19sZXZlbCwy LDAsMHgyLChudWxsKQ0KcmxzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZXhw aXJhdGlvbl90aW1lcl9wZXJpb2QsMiwwLDB4MiwobnVsbCkNCnJscyxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGlnbm9yZV80MDhfb25fbm90aWZ5LDIsMCwweDIsKG51bGwpDQpy bHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxpbml0X3RpbWVyX2RlbGF5LDIs MCwweDIsKG51bGwpDQpnZmxhZ3Msc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxz ZXRfZ2ZsYWcsMCwxLDB4NywobnVsbCkNCmdmbGFncyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLHJlc2V0X2dmbGFnLDAsMSwweDcsKG51bGwpDQpnZmxhZ3Msc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxpc19nZmxhZywwLDEsMHg3LChudWxsKQ0KZ2ZsYWdzLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZmx1c2hfZ2ZsYWdzLDAsMCwweDcsKG51 bGwpDQpnZmxhZ3Msc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxnZmxhZ3Muc2V0 LDEsMCwweDAsTG9hZCBhIENQTCBzY3JpcHQgdG8gdGhlIHNlcnZlci4NCmdmbGFncyxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGdmbGFncy5pc19zZXQsMSwwLDB4MCxMb2FkIGEg Q1BMIHNjcmlwdCB0byB0aGUgc2VydmVyLg0KZ2ZsYWdzLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksZ2ZsYWdzLnJlc2V0LDEsMCwweDAsTG9hZCBhIENQTCBzY3JpcHQgdG8gdGhl IHNlcnZlci4NCmdmbGFncyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGdmbGFn cy5mbHVzaCwxLDAsMHgwLExvYWQgYSBDUEwgc2NyaXB0IHRvIHRoZSBzZXJ2ZXIuDQpnZmxhZ3Ms c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxnZmxhZ3MuZHVtcCwxLDAsMHgwLExv YWQgYSBDUEwgc2NyaXB0IHRvIHRoZSBzZXJ2ZXIuDQpnZmxhZ3Msc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSxnbG9iYWwucmVsb2FkLDEsMCwweDAsUmVsb2FkIGdsb2JhbCBhdHRy aWJ1dGVzIGZyb20gZGF0YWJhc2UNCmdmbGFncyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLGluaXRpYWwsMiwwLDB4MiwobnVsbCkNCmdmbGFncyxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLGRiX3VybCwyLDAsMHgxLChudWxsKQ0KZ2ZsYWdzLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9hZF9nbG9iYWxfYXR0cnMsMiwwLDB4MiwobnVsbCkN CmdmbGFncyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGdsb2JhbF9hdHRyc190 YWJsZSwyLDAsMHgxLChudWxsKQ0KZ2ZsYWdzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksZ2xvYmFsX2F0dHJzX25hbWUsMiwwLDB4MSwobnVsbCkNCmdmbGFncyxzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGdsb2JhbF9hdHRyc190eXBlLDIsMCwweDEsKG51bGwp DQpnZmxhZ3Msc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxnbG9iYWxfYXR0cnNf dmFsdWUsMiwwLDB4MSwobnVsbCkNCmdmbGFncyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLGdsb2JhbF9hdHRyc19mbGFncywyLDAsMHgxLChudWxsKQ0KeG1scnBjLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGlzcGF0Y2hfcnBjLDAsMCwweDEsKG51bGwpDQp4 bWxycGMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx4bWxycGNfcmVwbHksMCwy LDB4MSwobnVsbCkNCnhtbHJwYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGVu YWJsZV9pbnN0cm9zcGVjdGlvbiwyLDAsMHgyLChudWxsKQ0KeG1scnBjLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCkscm91dGUsMiwwLDB4MSwobnVsbCkNCmV2YWwsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxldmFsX2FkZCwwLDIsMHgxZiwobnVsbCkNCmV2YWws c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxldmFsX2FkZCwwLDEsMHgxZiwobnVs bCkNCmV2YWwsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxldmFsX3B1c2gsMCwy LDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZXZh bF9wdXNoLDAsMSwweDFmLChudWxsKQ0KZXZhbCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLGV2YWxfaW5zZXJ0LDAsMiwweDFmLChudWxsKQ0KZXZhbCxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGV2YWxfaW5zZXJ0LDAsMSwweDFmLChudWxsKQ0KZXZhbCxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGV2YWxfeGNoZywwLDIsMHgxZiwobnVsbCkN CmV2YWwsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxldmFsX3hjaGcsMCwxLDB4 MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZXZhbF9n ZXQsMCwyLDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksZXZhbF9nZXQsMCwxLDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksZXZhbF9wdXQsMCwyLDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksZXZhbF9wdXQsMCwxLDB4MWYsKG51bGwpDQpldmFsLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZXZhbF9wb3AsMCwyLDB4MWYsKG51bGwpDQpl dmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZXZhbF9wb3AsMCwxLDB4MWYs KG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZXZhbF9hZGRf dmFsdWUsMCwyLDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksZXZhbF9hZGRfdmFsdWUsMCwxLDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksZXZhbF9pbnNlcnRfdmFsdWUsMCwyLDB4MWYsKG51bGwpDQpl dmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZXZhbF9pbnNlcnRfdmFsdWUs MCwxLDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks ZXZhbF9yZW1vdmUsMCwwLDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksZXZhbF9yZW1vdmUsMCwxLDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksZXZhbF9yZW1vdmUsMCwyLDB4MWYsKG51bGwpDQpldmFs LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZXZhbF9jbGVhciwwLDEsMHgxZiwo bnVsbCkNCmV2YWwsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxldmFsX29wZXIs MCwyLDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks ZXZhbF9vcGVyLDAsMSwweDFmLChudWxsKQ0KZXZhbCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLGV2YWxfd2hpbGUsMCwxLDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksZXZhbF93aGlsZSwwLDIsMHgxZiwobnVsbCkNCmV2YWwsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxldmFsX3doaWxlX3N0YWNrLDAsMSwweDFm LChudWxsKQ0KZXZhbCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGV2YWxfd2hp bGVfc3RhY2ssMCwyLDB4MWYsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksZXZhbF9kdW1wLDAsMCwweDFmLChudWxsKQ0KZXZhbCxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGRlY2xhcmVfcmVnaXN0ZXIsMiwwLDB4ODAwMDAwMDEsKG51bGwp DQpldmFsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkseGxidWZfc2l6ZSwyLDAs MHgyLChudWxsKQ0Kb3NwLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksY2hlY2tv c3BoZWFkZXIsMCwwLDB4MywobnVsbCkNCm9zcCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLGNoZWNrX29zcF9oZWFkZXIsMCwwLDB4MywobnVsbCkNCm9zcCxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLHZhbGlkYXRlb3NwaGVhZGVyLDAsMCwweDMsKG51bGwpDQpv c3Asc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx2YWxpZGF0ZV9vc3BfaGVhZGVy LDAsMCwweDMsKG51bGwpDQpvc3Asc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxy ZXF1ZXN0b3Nwcm91dGluZywwLDAsMHgzLChudWxsKQ0Kb3NwLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCkscmVxdWVzdF9vc3Bfcm91dGluZywwLDAsMHgzLChudWxsKQ0Kb3NwLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscHJlcGFyZWZpcnN0b3Nwcm91dGUsMCww LDB4MywobnVsbCkNCm9zcCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHByZXBh cmVfMXN0X29zcF9yb3V0ZSwwLDAsMHgzLChudWxsKQ0Kb3NwLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCkscHJlcGFyZW5leHRvc3Byb3V0ZSwwLDAsMHgzLChudWxsKQ0Kb3NwLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscHJlcGFyZV9uZXh0X29zcF9yb3V0ZSww LDAsMHgzLChudWxsKQ0Kb3NwLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscHJl cGFyZWFsbG9zcHJvdXRlcywwLDAsMHgzLChudWxsKQ0Kb3NwLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCkscHJlcGFyZV9hbGxfb3NwX3JvdXRlcywwLDAsMHgzLChudWxsKQ0Kb3Nw LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmVwb3J0b3NwdXNhZ2UsMCwwLDB4 MSwobnVsbCkNCm9zcCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJlcG9ydF9v c3BfdXNhZ2UsMCwwLDB4MSwobnVsbCkNCm9zcCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLHNwMV91cmksMiwwLDB4MSwobnVsbCkNCm9zcCxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLHNwMV93ZWlnaHQsMiwwLDB4MiwobnVsbCkNCm9zcCxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLHNwMl91cmksMiwwLDB4MSwobnVsbCkNCm9zcCxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNwMl93ZWlnaHQsMiwwLDB4MiwobnVsbCkNCm9z cCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRldmljZV9pcCwyLDAsMHgxLChu dWxsKQ0Kb3NwLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGV2aWNlX3BvcnQs MiwwLDB4MSwobnVsbCkNCm9zcCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHBy aXZhdGVfa2V5LDIsMCwweDEsKG51bGwpDQpvc3Asc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxsb2NhbF9jZXJ0aWZpY2F0ZSwyLDAsMHgxLChudWxsKQ0Kb3NwLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksY2FfY2VydGlmaWNhdGVzLDIsMCwweDEsKG51bGwpDQpv c3Asc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxlbmFibGVfY3J5cHRvX2hhcmR3 YXJlX3N1cHBvcnQsMiwwLDB4MiwobnVsbCkNCm9zcCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLHZhbGlkYXRlX2NhbGxfaWQsMiwwLDB4MiwobnVsbCkNCm9zcCxzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRva2VuX2Zvcm1hdCwyLDAsMHgyLChudWxsKQ0Kb3Nw LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc3NsX2xpZmV0aW1lLDIsMCwweDIs KG51bGwpDQpvc3Asc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxwZXJzaXN0ZW5j ZSwyLDAsMHgyLChudWxsKQ0Kb3NwLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks cmV0cnlfZGVsYXksMiwwLDB4MiwobnVsbCkNCm9zcCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLHJldHJ5X2xpbWl0LDIsMCwweDIsKG51bGwpDQpvc3Asc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSx0aW1lb3V0LDIsMCwweDIsKG51bGwpDQpvc3Asc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxtYXhfZGVzdGluYXRpb25zLDIsMCwweDIsKG51bGwp DQp1cmksc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxpc191c2VyLDAsMSwweDEs KG51bGwpDQp1cmksc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxoYXNfdG90YWcs MCwwLDB4MSwobnVsbCkNCnVyaSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVy aV9wYXJhbSwwLDEsMHgxLChudWxsKQ0KdXJpLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksdXJpX3BhcmFtLDAsMiwweDEsKG51bGwpDQp1cmksc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxhZGRfdXJpX3BhcmFtLDAsMSwweDEsKG51bGwpDQp1cmksc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0ZWwyc2lwLDAsMCwweDEsKG51bGwpDQpjcGwtYyxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGNwbF9ydW5fc2NyaXB0LDAsMiwweDEs KG51bGwpDQpjcGwtYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGNwbF9wcm9j ZXNzX3JlZ2lzdGVyLDAsMCwweDEsKG51bGwpDQpjcGwtYyxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLGNwbF9wcm9jZXNzX3JlZ2lzdGVyX25vcnBsLDAsMCwweDEsKG51bGwpDQpj cGwtYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGNwbF9kYiwyLDAsMHgxLChu dWxsKQ0KY3BsLWMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxjcGxfdGFibGUs MiwwLDB4MSwobnVsbCkNCmNwbC1jLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks Y3BsX2R0ZF9maWxlLDIsMCwweDEsKG51bGwpDQpjcGwtYyxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLHByb3h5X3JlY3Vyc2UsMiwwLDB4MiwobnVsbCkNCmNwbC1jLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscHJveHlfcm91dGUsMiwwLDB4MiwobnVsbCkNCmNw bC1jLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbmF0X2ZsYWcsMiwwLDB4Miwo bnVsbCkNCmNwbC1jLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9nX2Rpciwy LDAsMHgxLChudWxsKQ0KY3BsLWMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxj YXNlX3NlbnNpdGl2ZSwyLDAsMHgyLChudWxsKQ0KY3BsLWMsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxyZWFsbV9wcmVmaXgsMiwwLDB4NCwobnVsbCkNCmNwbC1jLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9va3VwX2RvbWFpbiwyLDAsMHgxLChudWxsKQ0K Y3BsLWMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsb29rdXBfYXBwZW5kX2Jy YW5jaGVzLDIsMCwweDIsKG51bGwpDQpjcGwtYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLHRpbWVyX2F2cCwyLDAsMHgxLChudWxsKQ0KYXZwX3JhZGl1cyxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLHJhZGl1c19sb2FkX2F0dHJzLDAsMiwweDMsKG51bGwpDQph dnBfcmFkaXVzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmFkaXVzX2NvbmZp ZywyLDAsMHgxLChudWxsKQ0KZXhlYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGV4ZWNfZHNldCwwLDEsMHgzLChudWxsKQ0KZXhlYyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLGV4ZWNfbXNnLDAsMSwweDMsKG51bGwpDQpleGVjLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksdGltZV90b19raWxsLDIsMCwweDIsKG51bGwpDQpleGVjLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2V0dmFycywyLDAsMHgyLChudWxsKQ0KYXV0 aF9yYWRpdXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyYWRpdXNfd3d3X2F1 dGhvcml6ZSwwLDEsMHgxLChudWxsKQ0KYXV0aF9yYWRpdXMsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxyYWRpdXNfcHJveHlfYXV0aG9yaXplLDAsMSwweDEsKG51bGwpDQphdXRo X3JhZGl1cyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJhZGl1c193d3dfYXV0 aGVudGljYXRlLDAsMSwweDEsKG51bGwpDQphdXRoX3JhZGl1cyxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLHJhZGl1c19wcm94eV9hdXRoZW50aWNhdGUsMCwxLDB4MSwobnVsbCkN CmF1dGhfcmFkaXVzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmFkaXVzX2Nv bmZpZywyLDAsMHgxLChudWxsKQ0KYXV0aF9yYWRpdXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChp Mzg2L2xpbnV4KSxzZXJ2aWNlX3R5cGUsMiwwLDB4MiwobnVsbCkNCmF1dGhfcmFkaXVzLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdXNlX2RpZCwyLDAsMHgyLChudWxsKQ0KcGVy bWlzc2lvbnMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhbGxvd19yb3V0aW5n LDAsMCwweDMsKG51bGwpDQpwZXJtaXNzaW9ucyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLGFsbG93X3JvdXRpbmcsMCwxLDB4MywobnVsbCkNCnBlcm1pc3Npb25zLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYWxsb3dfcm91dGluZywwLDIsMHgzLChudWxsKQ0K cGVybWlzc2lvbnMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhbGxvd19yZWdp c3RlciwwLDEsMHgzLChudWxsKQ0KcGVybWlzc2lvbnMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChp Mzg2L2xpbnV4KSxhbGxvd19yZWdpc3RlciwwLDIsMHgzLChudWxsKQ0KcGVybWlzc2lvbnMsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhbGxvd19yZWZlcl90bywwLDEsMHgzLChu dWxsKQ0KcGVybWlzc2lvbnMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhbGxv d19yZWZlcl90bywwLDIsMHgzLChudWxsKQ0KcGVybWlzc2lvbnMsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSxhbGxvd190cnVzdGVkLDAsMCwweDMsKG51bGwpDQpwZXJtaXNzaW9u cyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGlwbWF0Y2gsMCwxLDB4NywobnVs bCkNCnBlcm1pc3Npb25zLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksaXBtYXRj aCwwLDIsMHg3LChudWxsKQ0KcGVybWlzc2lvbnMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxpcG1hdGNoX29uc2VuZCwwLDEsMHgxMCwobnVsbCkNCnBlcm1pc3Npb25zLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksaXBtYXRjaF9maWx0ZXIsMCwxLDB4MTcsKG51 bGwpDQpwZXJtaXNzaW9ucyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRiX3Vy bCwyLDAsMHgxLChudWxsKQ0KcGVybWlzc2lvbnMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxkYl9tb2RlLDIsMCwweDIsKG51bGwpDQpwZXJtaXNzaW9ucyxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLGRlZmF1bHRfYWxsb3dfZmlsZSwyLDAsMHgxLChudWxsKQ0K cGVybWlzc2lvbnMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkZWZhdWx0X2Rl bnlfZmlsZSwyLDAsMHgxLChudWxsKQ0KcGVybWlzc2lvbnMsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxjaGVja19hbGxfYnJhbmNoZXMsMiwwLDB4MiwobnVsbCkNCnBlcm1pc3Np b25zLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYWxsb3dfc3VmZml4LDIsMCww eDEsKG51bGwpDQpwZXJtaXNzaW9ucyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGRlbnlfc3VmZml4LDIsMCwweDEsKG51bGwpDQpwZXJtaXNzaW9ucyxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLG1heF9ydWxlX2ZpbGVzLDIsMCwweDIsKG51bGwpDQpwZXJtaXNz aW9ucyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNhZmVfZmlsZV9sb2FkLDIs MCwweDIsKG51bGwpDQpwZXJtaXNzaW9ucyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLHRydXN0ZWRfdGFibGUsMiwwLDB4MSwobnVsbCkNCnBlcm1pc3Npb25zLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksc291cmNlX2NvbCwyLDAsMHgxLChudWxsKQ0KcGVybWlz c2lvbnMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxwcm90b19jb2wsMiwwLDB4 MSwobnVsbCkNCnBlcm1pc3Npb25zLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks ZnJvbV9jb2wsMiwwLDB4MSwobnVsbCkNCnBlcm1pc3Npb25zLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksaXBtYXRjaF90YWJsZSwyLDAsMHgxLChudWxsKQ0KbWF4ZndkLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbWZfcHJvY2Vzc19tYXhmd2RfaGVhZGVyLDAs MSwweDEsKG51bGwpDQptYXhmd2Qsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxw cm9jZXNzX21heGZ3ZCwwLDEsMHgxLChudWxsKQ0KbWF4ZndkLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksbWZfbG93bGltaXQsMCwxLDB4MSwobnVsbCkNCm1heGZ3ZCxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLG1heF9saW1pdCwyLDAsMHgyLChudWxsKQ0KcmF0 ZWxpbWl0LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmxfY2hlY2ssMCwwLDB4 MSwobnVsbCkNCnJhdGVsaW1pdCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJs LnN0YXRzLDEsMCwweDAsUHJpbnQgcmF0ZWxpbWl0IHN0YXRpc3RpY3MNCnJhdGVsaW1pdCxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJsLmludml0ZV9saW1pdCwxLDAsMHgwLFNl dCBJTlZJVEVzIHBlciB0aW1lciBpbnRlcnZhbCBsaW1pdA0KcmF0ZWxpbWl0LHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmwucmVnaXN0ZXJfbGltaXQsMSwwLDB4MCxTZXQgUkVH SVNURVJzIHBlciB0aW1lciBpbnRlcnZhbCBsaW1pdA0KcmF0ZWxpbWl0LHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCkscmwuc3Vic2NyaWJlX2xpbWl0LDEsMCwweDAsU2V0IFNVQlND UklCRXMgcGVyIHRpbWVyIGludGVydmFsIGxpbWl0DQpyYXRlbGltaXQsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxybC50aW1lcl9pbnRlcnZhbCwxLDAsMHgwLFNldCB0aGUgcmF0 ZWxpbWl0IHRpbWVyX2ludGVydmFsIGxlbmd0aA0KcmF0ZWxpbWl0LHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksaW52aXRlX2xpbWl0LDIsMCwweDIsKG51bGwpDQpyYXRlbGltaXQs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZWdpc3Rlcl9saW1pdCwyLDAsMHgy LChudWxsKQ0KcmF0ZWxpbWl0LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc3Vi c2NyaWJlX2xpbWl0LDIsMCwweDIsKG51bGwpDQpyYXRlbGltaXQsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSx0aW1lcl9pbnRlcnZhbCwyLDAsMHgyLChudWxsKQ0KdG0sc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0X25ld3RyYW4sMCwwLDB4MSwobnVsbCkNCnRt LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdF9sb29rdXBfcmVxdWVzdCwwLDAs MHgxLChudWxsKQ0KdG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0X2xvb2t1 cF9jYW5jZWwsMCwwLDB4MSwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksdF9yZXBseSwwLDIsMHgzLChudWxsKQ0KdG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChp Mzg2L2xpbnV4KSx0X3JldHJhbnNtaXRfcmVwbHksMCwwLDB4MSwobnVsbCkNCnRtLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdF9yZWxlYXNlLDAsMCwweDEsKG51bGwpDQp0bSxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRfcmVsYXlfdG9fdWRwLDAsMiwweDMs KG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRfcmVsYXlfdG9f dGNwLDAsMiwweDMsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LHRfcmVsYXlfdG9fdGxzLDAsMiwweDMsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLHRfcmVwbGljYXRlLDAsMiwweDEsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLHRfcmVwbGljYXRlX3VkcCwwLDIsMHgxLChudWxsKQ0KdG0s c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0X3JlcGxpY2F0ZV90Y3AsMCwyLDB4 MSwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdF9yZXBsaWNh dGVfdGxzLDAsMiwweDEsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLHRfcmVwbGljYXRlX3RvLDAsMiwweDEsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLHRfcmVsYXksMCwwLDB4MywobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksdF9yZWxheV90bywwLDIsMHgxLChudWxsKQ0KdG0sc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0X2ZvcndhcmRfbm9uYWNrLDAsMiwweDEsKG51 bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRfZm9yd2FyZF9ub25h Y2tfdXJpLDAsMCwweDEsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLHRfZm9yd2FyZF9ub25hY2tfdWRwLDAsMiwweDEsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLHRfZm9yd2FyZF9ub25hY2tfdGNwLDAsMiwweDEsKG51bGwp DQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRfZm9yd2FyZF9ub25hY2tf dGxzLDAsMiwweDEsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LHRfZm9yd2FyZF9ub25hY2tfdG8sMCwyLDB4MSwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksdF9vbl9mYWlsdXJlLDAsMSwweDcsKG51bGwpDQp0bSxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRfb25fcmVwbHksMCwxLDB4NywobnVsbCkNCnRt LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdF9vbl9icmFuY2gsMCwxLDB4Mywo bnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdF9jaGVja19zdGF0 dXMsMCwxLDB4NywobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks dF93cml0ZV9yZXEsMCwyLDB4MywobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksdF93cml0ZV91bml4LDAsMiwweDMsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLHRfc2V0X2ZyLDAsMSwweGYsKG51bGwpDQp0bSxzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRfc2V0X2ZyLDAsMiwweGYsKG51bGwpDQp0bSxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRfYnJhbmNoX3RpbWVvdXQsMCwwLDB4Miwo bnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdF9icmFuY2hfcmVw bGllZCwwLDAsMHgyLChudWxsKQ0KdG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSx0X2FueV90aW1lb3V0LDAsMCwweGYsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLHRfYW55X3JlcGxpZWQsMCwwLDB4ZiwobnVsbCkNCnRtLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksdF9pc19jYW5jZWxlZCwwLDAsMHhmLChudWxsKQ0KdG0s c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZWdpc3Rlcl90bWNiLDAsLTEsMHgw LChudWxsKQ0KdG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsb2FkX3RtLDAs LTEsMHgwLChudWxsKQ0KdG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0X3Jl cGx5X3dpdGhfYm9keSwwLC0xLDB4MCwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksdF9pc19sb2NhbCwwLC0xLDB4MCwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksdF9nZXRfdHJhbnNfaWRlbnQsMCwtMSwweDAsKG51bGwpDQp0 bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRfbG9va3VwX2lkZW50LDAsLTEs MHgwLChudWxsKQ0KdG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0X2FkZF9i bGluZCwwLC0xLDB4MCwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksdF9yZXF1ZXN0X3dpdGhpbiwwLC0xLDB4MCwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksdF9yZXF1ZXN0X291dHNpZGUsMCwtMSwweDAsKG51bGwpDQp0bSxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRfcmVxdWVzdCwwLC0xLDB4MCwobnVs bCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbmV3X2RsZ191YWMsMCwt MSwweDAsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRsZ19y ZXNwb25zZV91YWMsMCwtMSwweDAsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLG5ld19kbGdfdWFzLDAsLTEsMHgwLChudWxsKQ0KdG0sc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSx1cGRhdGVfZGxnX3VhcywwLC0xLDB4MCwobnVsbCkNCnRtLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGxnX3JlcXVlc3RfdWFzLDAsLTEsMHgw LChudWxsKQ0KdG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzZXRfZGxnX3Rh cmdldCwwLC0xLDB4MCwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksZnJlZV9kbGcsMCwtMSwweDAsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLHByaW50X2RsZywwLC0xLDB4MCwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksdF9nZXR0LDAsLTEsMHgwLChudWxsKQ0KdG0sc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxjYWxjdWxhdGVfaG9va3MsMCwtMSwweDAsKG51bGwpDQp0 bSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRfdWFjLDAsLTEsMHgwLChudWxs KQ0KdG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0X3VhY193aXRoX2lkcyww LC0xLDB4MCwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdF91 bnJlZiwwLC0xLDB4MCwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCkscnVuX2ZhaWx1cmVfaGFuZGxlcnMsMCwtMSwweDAsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLGNhbmNlbF91YWNzLDAsLTEsMHgwLChudWxsKQ0KdG0sc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0bS5jYW5jZWwsMSwwLDB4MCwobnVsbCkN CnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdG0ucmVwbHksMSwwLDB4MCwo bnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdG0uc3RhdHMsMSww LDB4MCwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscnVyaV9t YXRjaGluZywyLDAsMHgyLChudWxsKQ0KdG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSx2aWExX21hdGNoaW5nLDIsMCwweDIsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLGZyX3RpbWVyLDIsMCwweDIsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLGZyX2ludl90aW1lciwyLDAsMHgyLChudWxsKQ0KdG0sc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx3dF90aW1lciwyLDAsMHgyLChudWxsKQ0K dG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkZWxldGVfdGltZXIsMiwwLDB4 MiwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmV0cl90aW1l cjEsMiwwLDB4MiwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks cmV0cl90aW1lcjIsMiwwLDB4MiwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksbm9pc3lfY3RpbWVyLDIsMCwweDIsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLHVhY19mcm9tLDIsMCwweDEsKG51bGwpDQp0bSxzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVuaXhfdHhfdGltZW91dCwyLDAsMHgyLChudWxsKQ0K dG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZXN0YXJ0X2ZyX29uX2VhY2hf cmVwbHksMiwwLDB4MiwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksZnJfdGltZXJfYXZwLDIsMCwweDEsKG51bGwpDQp0bSxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLGZyX2ludl90aW1lcl9hdnAsMiwwLDB4MSwobnVsbCkNCnRtLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdHdfYXBwZW5kLDIsMCwweDgwMDAwMDAxLChudWxs KQ0KdG0sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxwYXNzX3Byb3Zpc2lvbmFs X3JlcGxpZXMsMiwwLDB4MiwobnVsbCkNCnRtLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksYWdncmVnYXRlX2NoYWxsZW5nZXMsMiwwLDB4MiwobnVsbCkNCnRtLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGVmYXVsdF9jb2RlLDIsMCwweDIsKG51bGwpDQp0bSxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRlZmF1bHRfcmVhc29uLDIsMCwweDQs KG51bGwpDQpwcmVzZW5jZV9iMmIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxo YW5kbGVfbm90aWZ5LDAsMCwweDEsKG51bGwpDQpwcmVzZW5jZV9iMmIsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxkZWZhdWx0X2V4cGlyYXRpb24sMiwwLDB4MiwobnVsbCkNCnBy ZXNlbmNlX2IyYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLG9uX2Vycm9yX3Jl dHJ5X3RpbWUsMiwwLDB4MiwobnVsbCkNCnByZXNlbmNlX2IyYixzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLHByZXNlbmNlX3JvdXRlLDIsMCwweDQsKG51bGwpDQpwcmVzZW5jZV9i MmIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhZGRpdGlvbmFsX3ByZXNlbmNl X2hlYWRlcnMsMiwwLDB4NCwobnVsbCkNCnByZXNlbmNlX2IyYixzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLHdhaXRfZm9yX3Rlcm1fbm90aWZ5LDIsMCwweDIsKG51bGwpDQpwcmVz ZW5jZV9iMmIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZXN1YnNjcmliZV9k ZWx0YSwyLDAsMHgyLChudWxsKQ0KcHJlc2VuY2VfYjJiLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksbWluX3Jlc3Vic2NyaWJlX3RpbWUsMiwwLDB4MiwobnVsbCkNCnByZXNlbmNl X2IyYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGhhbmRsZV9wcmVzZW5jZV9z dWJzY3JpcHRpb25zLDIsMCwweDIsKG51bGwpDQpwcmVzZW5jZV9iMmIsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxwcmVzZW5jZV9vdXRib3VuZF9wcm94eSwyLDAsMHg0LChudWxs KQ0KcHJlc2VuY2VfYjJiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbWF4X3N1 YnNjcmliZV9kZWxheSwyLDAsMHgyLChudWxsKQ0KZmlmbyxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLGZpZm9fZmlsZSwyLDAsMHgxLChudWxsKQ0KZmlmbyxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLGZpZm9fZGlyLDIsMCwweDEsKG51bGwpDQpmaWZvLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdXNlciwyLDAsMHgxLChudWxsKQ0KZmlmbyxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLG1vZGUsMiwwLDB4MiwobnVsbCkNCmZp Zm8sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxncm91cCwyLDAsMHgxLChudWxs KQ0KZmlmbyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJlcGx5X3JldHJpZXMs MiwwLDB4MiwobnVsbCkNCmZpZm8sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxy ZXBseV93YWl0LDIsMCwweDIsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksc2VhcmNoLDAsMSwweDE3LChudWxsKQ0KdGV4dG9wcyxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLHNlYXJjaF9hcHBlbmQsMCwyLDB4NywobnVsbCkNCnRleHRv cHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZXBsYWNlLDAsMiwweDcsKG51 bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmVwbGFjZV9h bGwsMCwyLDB4NywobnVsbCkNCnRleHRvcHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxhcHBlbmRfdG9fcmVwbHksMCwxLDB4MSwobnVsbCkNCnRleHRvcHMsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhcHBlbmRfaGYsMCwxLDB4ZiwobnVsbCkNCnRleHRvcHMs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhcHBlbmRfdXJpaGYsMCwyLDB4Mywo bnVsbCkNCnRleHRvcHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZW1vdmVf aGYsMCwxLDB4NywobnVsbCkNCnRleHRvcHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxpc19wcmVzZW50X2hmLDAsMSwweDcsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksc3Vic3QsMCwxLDB4NywobnVsbCkNCnRleHRvcHMsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzdWJzdF91cmksMCwxLDB4NywobnVsbCkNCnRl eHRvcHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzdWJzdF91c2VyLDAsMSww eDcsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYXBw ZW5kX3RpbWUsMCwwLDB4MSwobnVsbCkNCnRleHRvcHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChp Mzg2L2xpbnV4KSxhcHBlbmRfaGZfdmFsdWUsMCwyLDB4ZiwobnVsbCkNCnRleHRvcHMsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxpbnNlcnRfaGZfdmFsdWUsMCwyLDB4ZiwobnVs bCkNCnRleHRvcHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZW1vdmVfaGZf dmFsdWUsMCwxLDB4ZiwobnVsbCkNCnRleHRvcHMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxhc3NpZ25faGZfdmFsdWUsMCwyLDB4ZiwobnVsbCkNCnRleHRvcHMsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZW1vdmVfaGZfdmFsdWUyLDAsMSwweGYsKG51bGwp DQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYXNzaWduX2hmX3Zh bHVlMiwwLDIsMHhmLChudWxsKQ0KdGV4dG9wcyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLGluY2x1ZGVfaGZfdmFsdWUsMCwyLDB4ZiwobnVsbCkNCnRleHRvcHMsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxleGNsdWRlX2hmX3ZhbHVlLDAsMiwweGYsKG51bGwp DQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksaGZfdmFsdWVfZXhp c3RzLDAsMiwweGYsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCkseGxidWZfc2l6ZSwyLDAsMHgyLChudWxsKQ0Kc2wsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxzbF9zZW5kX3JlcGx5LDAsMiwweDEsKG51bGwpDQpzbCxzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNsX3JlcGx5LDAsMiwweDEsKG51bGwpDQpzbCxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNsX3JlcGx5X2Vycm9yLDAsMCwweDEsKG51 bGwpDQpzbCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGJpbmRfc2wsMCwwLDB4 MCwobnVsbCkNCnNsLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYXBpX3NsX3Jl cGx5LDAsMiwweDAsKG51bGwpDQpzbCxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGRlZmF1bHRfY29kZSwyLDAsMHgyLChudWxsKQ0Kc2wsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChp Mzg2L2xpbnV4KSxkZWZhdWx0X3JlYXNvbiwyLDAsMHg0LChudWxsKQ0KcGlrZSxzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHBpa2VfY2hlY2tfcmVxLDAsMCwweDEsKG51bGwpDQpw aWtlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscGlrZV9jaGVja19yZXEsMCwx LDB4MSwobnVsbCkNCnBpa2Usc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzYW1w bGluZ190aW1lX3VuaXQsMiwwLDB4MiwobnVsbCkNCnBpa2Usc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxyZXFzX2RlbnNpdHlfcGVyX3VuaXQsMiwwLDB4MiwobnVsbCkNCnBpa2Us c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZW1vdmVfbGF0ZW5jeSwyLDAsMHgy LChudWxsKQ0KbGNyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9hZF9nd3Ms MCwwLDB4MSwobnVsbCkNCmxjcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLG5l eHRfZ3csMCwwLDB4MywobnVsbCkNCmxjcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLGZyb21fZ3csMCwwLDB4MywobnVsbCkNCmxjcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLHRvX2d3LDAsMCwweDMsKG51bGwpDQpsY3Isc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxsb2FkX2NvbnRhY3RzLDAsMCwweDEsKG51bGwpDQpsY3Isc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxuZXh0X2NvbnRhY3RzLDAsMCwweDMsKG51bGwpDQps Y3Isc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl91cmwsMiwwLDB4NCwobnVs bCkNCmxjcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGd3X3RhYmxlLDIsMCww eDQsKG51bGwpDQpsY3Isc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxnd19uYW1l X2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KbGNyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksaXBfYWRkcl9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCmxjcixzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLHBvcnRfY29sdW1uLDIsMCwweDQsKG51bGwpDQpsY3Isc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx1cmlfc2NoZW1lX2NvbHVtbiwyLDAsMHg0LChu dWxsKQ0KbGNyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdHJhbnNwb3J0X2Nv bHVtbiwyLDAsMHg0LChudWxsKQ0KbGNyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksZ3JwX2lkX2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KbGNyLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksbGNyX3RhYmxlLDIsMCwweDQsKG51bGwpDQpsY3Isc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxwcmVmaXhfY29sdW1uLDIsMCwweDQsKG51bGwpDQpsY3Is c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmcm9tX3VyaV9jb2x1bW4sMiwwLDB4 NCwobnVsbCkNCmxjcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHByaW9yaXR5 X2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KbGNyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksZ3dfdXJpX2F2cCwyLDAsMHg0LChudWxsKQ0KbGNyLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksY29udGFjdF9hdnAsMiwwLDB4NCwobnVsbCkNCmxjcixzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGZyX2ludl90aW1lcl9hdnAsMiwwLDB4NCwobnVsbCkN CmxjcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGZyX2ludl90aW1lciwyLDAs MHgyLChudWxsKQ0KbGNyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZnJfaW52 X3RpbWVyX25leHQsMiwwLDB4MiwobnVsbCkNCmxjcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLGZyX2ludl90aW1lcl9wYXJhbSwyLDAsMHg0LChudWxsKQ0KbGNyLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZnJfaW52X3RpbWVyX25leHRfcGFyYW0sMiwwLDB4 NCwobnVsbCkNCmxjcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJwaWRfYXZw LDIsMCwweDQsKG51bGwpDQpvcHRpb25zLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksb3B0aW9uc19yZXBseSwwLDAsMHgzLChudWxsKQ0Kb3B0aW9ucyxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGFjY2VwdCwyLDAsMHg0LChudWxsKQ0Kb3B0aW9ucyxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGFjY2VwdF9lbmNvZGluZywyLDAsMHg0LChudWxs KQ0Kb3B0aW9ucyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGFjY2VwdF9sYW5n dWFnZSwyLDAsMHg0LChudWxsKQ0Kb3B0aW9ucyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLHN1cHBvcnRlZCwyLDAsMHg0LChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxoYW5kbGVfc3Vic2NyaXB0aW9uLDAsMSwweDMsKG51bGwpDQpwYSxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGhhbmRsZV9wdWJsaXNoLDAsMSwweDMsKG51 bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRhcmdldF9vbmxpbmUs MCwxLDB4MywobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksY2hl Y2tfc3Vic2NyaXB0aW9uX3N0YXR1cywwLDEsMHgzLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxzdG9yZV93aW5mbywwLDEsMHgzLChudWxsKQ0KcGEsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkdW1wX3N0b3JlZF93aW5mbywwLDIsMHgzLChu dWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhdXRob3JpemVfbWVz c2FnZSwwLDEsMHgzLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSxkZWZhdWx0X2V4cGlyZXMsMiwwLDB4MiwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksbWF4X3N1YnNjcmlwdGlvbl9leHBpcmF0aW9uLDIsMCwweDIsKG51bGwp DQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLG1heF9wdWJsaXNoX2V4cGly YXRpb24sMiwwLDB4MiwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51 eCksYXV0aCwyLDAsMHgxLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSx3aW5mb19hdXRoLDIsMCwweDEsKG51bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLHVzZV9kYiwyLDAsMHgyLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSx1c2VfY2FsbGJhY2tzLDIsMCwweDIsKG51bGwpDQpwYSxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGFjY2VwdF9pbnRlcm5hbF9zdWJzY3JpcHRpb25z LDIsMCwweDIsKG51bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHdh dGNoZXJpbmZvX25vdGlmeSwyLDAsMHgyLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSx1c2Vfb2ZmbGluZV93aW5mbywyLDAsMHgyLChudWxsKQ0KcGEsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxvZmZsaW5lX3dpbmZvX2V4cGlyYXRpb24sMiww LDB4MiwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksb2ZmbGlu ZV93aW5mb190aW1lciwyLDAsMHgyLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChp Mzg2L2xpbnV4KSxkYl91cmwsMiwwLDB4NCwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCkscHJlc19ydWxlc19maWxlLDIsMCwweDQsKG51bGwpDQpwYSxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGlnbm9yZV80MDhfb25fbm90aWZ5LDIsMCwweDIs KG51bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRlZmF1bHRfcHJp b3JpdHlfcGVyY2VudGFnZSwyLDAsMHgyLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxhdXRoX3J1bGVzX3JlZnJlc2hfdGltZSwyLDAsMHgyLChudWxsKQ0KcGEs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhc3luY19hdXRoX3F1ZXJpZXMsMiww LDB4MiwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbWF4X2F1 dGhfcmVxdWVzdHNfcGVyX3RpY2ssMiwwLDB4MiwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksc3Vic2NyaWJlX3RvX3VzZXJzLDIsMCwweDIsKG51bGwpDQpwYSxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHBhX3N1YnNjcmlwdGlvbl91cmksMiww LDB4NCwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscHJlc2Vu dGl0eV90YWJsZSwyLDAsMHgxLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxwcmVzZW50aXR5X2NvbnRhY3RfdGFibGUsMiwwLDB4MSwobnVsbCkNCnBhLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksd2F0Y2hlcmluZm9fdGFibGUsMiwwLDB4MSwo bnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscGxhY2VfdGFibGUs MiwwLDB4MSwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdGlt ZXJfaW50ZXJ2YWwsMiwwLDB4MiwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksdXNlX3BsYWNlX3RhYmxlLDIsMCwweDIsKG51bGwpDQpwYSxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLHVzZV9ic2VhcmNoLDIsMCwweDIsKG51bGwpDQpwYSxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVzZV9sb2NhdGlvbl9wYWNrYWdlLDIsMCww eDIsKG51bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLG9mZmxpbmVf d2luZm9fdGFibGUsMiwwLDB4MSwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksdWlkX2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSx3YXRjaGVyX2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KcGEsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxldmVudHNfY29sdW1uLDIsMCwweDEsKG51bGwp DQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRvbWFpbl9jb2x1bW4sMiww LDB4MSwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc3RhdHVz X2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxjcmVhdGVkX29uX2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxleHBpcmVzX29uX2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KcGEs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYmlkX2NvbHVtbiwyLDAsMHgxLChu dWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxwcmVzX2lkX2NvbHVt biwyLDAsMHgxLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxi YXNpY19jb2x1bW4sMiwwLDB4MSwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksZXhwaXJlc19jb2x1bW4sMiwwLDB4MSwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCkscHJpb3JpdHlfY29sdW1uLDIsMCwweDEsKG51bGwpDQpwYSxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGNvbnRhY3RfY29sdW1uLDIsMCwweDEs KG51bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHR1cGxlaWRfY29s dW1uLDIsMCwweDEsKG51bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGV0YWdfY29sdW1uLDIsMCwweDEsKG51bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLHB1Ymxpc2hlZF9pZF9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCnBhLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZWxlbWVudF9jb2x1bW4sMiwwLDB4MSwobnVsbCkN CnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbm90ZV9jb2x1bW4sMiwwLDB4 MSwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbGFuZ19jb2x1 bW4sMiwwLDB4MSwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks dXJpX2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxwZG9tYWluX2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KcGEsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSx4Y2FwX3BhcmFtc19jb2x1bW4sMiwwLDB4MSwobnVsbCkNCnBh LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc3RhdHVzX2V4dGVuc2lvbl9jb2x1 bW4sMiwwLDB4MSwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks d191cmlfY29sdW1uLDIsMCwweDEsKG51bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLGRpc3BsYXlfbmFtZV9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCnBhLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc19pZF9jb2x1bW4sMiwwLDB4MSwobnVsbCkNCnBh LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscGFja2FnZV9jb2x1bW4sMiwwLDB4 MSwobnVsbCkNCnBhLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZXZlbnRfY29s dW1uLDIsMCwweDEsKG51bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGFjY2VwdHNfY29sdW1uLDIsMCwweDEsKG51bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLHNlcnZlcl9jb250YWN0X2NvbHVtbiwyLDAsMHgxLChudWxsKQ0KcGEsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkaWFsb2dfY29sdW1uLDIsMCwweDEsKG51 bGwpDQpwYSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRvY19pbmRleF9jb2x1 bW4sMiwwLDB4MSwobnVsbCkNCmRvbWFpbixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLGlzX2xvY2FsLDAsMSwweDMsKG51bGwpDQpkb21haW4sc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSxsb29rdXBfZG9tYWluLDAsMiwweDMsKG51bGwpDQpkb21haW4sc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxnZXRfZGlkLDAsMCwweDAsKG51bGwpDQpkb21h aW4sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkYl91cmwsMiwwLDB4NCwobnVs bCkNCmRvbWFpbixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRiX21vZGUsMiww LDB4MiwobnVsbCkNCmRvbWFpbixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRv bWFpbl90YWJsZSwyLDAsMHg0LChudWxsKQ0KZG9tYWluLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksZG9tYWluX2NvbCwyLDAsMHg0LChudWxsKQ0KZG9tYWluLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGlkX2NvbCwyLDAsMHg0LChudWxsKQ0KZG9tYWluLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZmxhZ3NfY29sLDIsMCwweDQsKG51bGwp DQpkb21haW4sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkb21hdHRyX3RhYmxl LDIsMCwweDQsKG51bGwpDQpkb21haW4sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSxkb21hdHRyX2RpZCwyLDAsMHg0LChudWxsKQ0KZG9tYWluLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksZG9tYXR0cl9uYW1lLDIsMCwweDQsKG51bGwpDQpkb21haW4sc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkb21hdHRyX3R5cGUsMiwwLDB4NCwobnVsbCkN CmRvbWFpbixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRvbWF0dHJfdmFsdWUs MiwwLDB4NCwobnVsbCkNCmRvbWFpbixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGRvbWF0dHJfZmxhZ3MsMiwwLDB4NCwobnVsbCkNCmRvbWFpbixzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLGxvYWRfZG9tYWluX2F0dHJzLDIsMCwweDIsKG51bGwpDQpzYW5pdHks c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzYW5pdHlfY2hlY2ssMCwwLDB4MSwo bnVsbCkNCnNhbml0eSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNhbml0eV9j aGVjaywwLDEsMHgxLChudWxsKQ0Kc2FuaXR5LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksc2FuaXR5X2NoZWNrLDAsMiwweDEsKG51bGwpDQpzYW5pdHksc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxkZWZhdWx0X2NoZWNrcywyLDAsMHgyLChudWxsKQ0Kc2FuaXR5 LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdXJpX2NoZWNrcywyLDAsMHgyLChu dWxsKQ0Kc2FuaXR5LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscHJveHlfcmVx dWlyZSwyLDAsMHg0LChudWxsKQ0KbXNpbG8sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxtX3N0b3JlLDAsMiwweDMsKG51bGwpDQptc2lsbyxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLG1fZHVtcCwwLDEsMHgxLChudWxsKQ0KbXNpbG8sc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxkYl91cmwsMiwwLDB4MSwobnVsbCkNCm1zaWxvLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGJfdGFibGUsMiwwLDB4MSwobnVsbCkNCm1zaWxv LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmVnaXN0cmFyLDIsMCwweDEsKG51 bGwpDQptc2lsbyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGV4cGlyZV90aW1l LDIsMCwweDIsKG51bGwpDQptc2lsbyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGNoZWNrX3RpbWUsMiwwLDB4MiwobnVsbCkNCm1zaWxvLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksY2xlYW5fcGVyaW9kLDIsMCwweDIsKG51bGwpDQptc2lsbyxzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVzZV9jb250YWN0LDIsMCwweDIsKG51bGwpDQptc2ls byxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNjX21pZCwyLDAsMHgxLChudWxs KQ0KbXNpbG8sc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzY19mcm9tLDIsMCww eDEsKG51bGwpDQptc2lsbyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNjX3Rv LDIsMCwweDEsKG51bGwpDQptc2lsbyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LHNjX3J1cmksMiwwLDB4MSwobnVsbCkNCm1zaWxvLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksc2NfdWlkLDIsMCwweDEsKG51bGwpDQptc2lsbyxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLHNjX2JvZHksMiwwLDB4MSwobnVsbCkNCm1zaWxvLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2NfY3R5cGUsMiwwLDB4MSwobnVsbCkNCm1zaWxvLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2NfZXhwX3RpbWUsMiwwLDB4MSwobnVs bCkNCm1zaWxvLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2NfaW5jX3RpbWUs MiwwLDB4MSwobnVsbCkNCmF1dGhfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSx3d3dfYXV0aGVudGljYXRlLDAsMiwweDEsKG51bGwpDQphdXRoX2RiLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksd3d3X2F1dGhvcml6ZSwwLDIsMHgxLChudWxsKQ0KYXV0aF9k YixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHByb3h5X2F1dGhlbnRpY2F0ZSww LDIsMHgxLChudWxsKQ0KYXV0aF9kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LHByb3h5X2F1dGhvcml6ZSwwLDIsMHgxLChudWxsKQ0KYXV0aF9kYixzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGRiX3VybCwyLDAsMHgxLChudWxsKQ0KYXV0aF9kYixzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHVzZXJuYW1lX2NvbHVtbiwyLDAsMHg0LChudWxs KQ0KYXV0aF9kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRpZF9jb2x1bW4s MiwwLDB4NCwobnVsbCkNCmF1dGhfZGIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSxyZWFsbV9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCmF1dGhfZGIsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSxwYXNzd29yZF9jb2x1bW4sMiwwLDB4NCwobnVsbCkNCmF1dGhfZGIs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxwYXNzd29yZF9jb2x1bW5fMiwyLDAs MHg0LChudWxsKQ0KYXV0aF9kYixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGZs YWdzX2NvbHVtbiwyLDAsMHg0LChudWxsKQ0KYXV0aF9kYixzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLGNhbGN1bGF0ZV9oYTEsMiwwLDB4MiwobnVsbCkNCmF1dGhfZGIsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsb2FkX2NyZWRlbnRpYWxzLDIsMCwweDQsKG51 bGwpDQphdXRoX2RiLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdXNlX2RpZCwy LDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGZv cndhcmQsMCwxLDB4MywobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxmb3J3YXJkLDAsMiwweDMsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksZm9yd2FyZF91ZHAsMCwxLDB4MywobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxmb3J3YXJkX3VkcCwwLDIsMHgzLChudWxsKQ0KY29yZSxz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGZvcndhcmRfdGNwLDAsMSwweDMsKG51 bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZm9yd2FyZF90Y3As MCwyLDB4MywobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxm b3J3YXJkX3RscywwLDEsMHgzLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLGZvcndhcmRfdGxzLDAsMiwweDMsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksc2VuZCwwLDEsMHgzLChudWxsKQ0KY29yZSxzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNlbmQsMCwyLDB4MywobnVsbCkNCmNvcmUsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzZW5kX3VkcCwwLDEsMHgzLChudWxsKQ0KY29y ZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNlbmRfdWRwLDAsMiwweDMsKG51 bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2VuZF90Y3AsMCwx LDB4MywobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzZW5k X3RjcCwwLDIsMHgzLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLHNlbmRfdGxzLDAsMSwweDMsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksc2VuZF90bHMsMCwyLDB4MywobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxkcm9wLDAsMCwweDcsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksZHJvcCwwLDEsMHg3LChudWxsKQ0KY29yZSxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGV4aXQsMCwwLDB4NywobnVsbCkNCmNvcmUsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxleGl0LDAsMSwweDcsKG51bGwpDQpjb3Jl LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmV0dXJuLDAsMCwweDcsKG51bGwp DQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmV0dXJuLDAsMSwweDcs KG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYnJlYWssMCww LDB4NywobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsb2cs MCwxLDB4NywobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxs b2csMCwyLDB4NywobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSxzZXRmbGFnLDAsMiwweDcsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCkscmVzZXRmbGFnLDAsMiwweDcsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0 LXRscyAoaTM4Ni9saW51eCksaXNmbGFnc2V0LDAsMiwweDcsKG51bGwpDQpjb3JlLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZXJyb3IsMCwxLDB4NywobnVsbCkNCmNvcmUsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyb3V0ZSwwLDEsMHg3LChudWxsKQ0KY29y ZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGV4ZWMsMCwxLDB4NywobnVsbCkN CmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzZXRob3N0LDAsMSwweDMs KG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscHJlZml4LDAs MSwweDMsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc3Ry aXBfdGFpbCwwLDEsMHgzLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLHN0cmlwLDAsMSwweDMsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksYXBwZW5kX2JyYW5jaCwwLDAsMHgzLChudWxsKQ0KY29yZSxzZXIgMC4xMC45 OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGFwcGVuZF9icmFuY2gsMCwxLDB4MywobnVsbCkNCmNv cmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhcHBlbmRfYnJhbmNoLDAsMiww eDMsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2V0aG9z dHBvcnQsMCwyLDB4MywobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxzZXRwb3J0LDAsMSwweDMsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksc2V0dXNlciwwLDEsMHgzLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLHNldHVzZXJwYXNzLDAsMSwweDMsKG51bGwpDQpjb3JlLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2V0dXJpLDAsMSwweDMsKG51bGwpDQpjb3Jl LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmV2ZXJ0X3VyaSwwLDAsMHgzLChu dWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGZvcmNlX3Jwb3J0 LDAsMCwweDMsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks Zm9yY2VfdGNwX2FsaWFzLDAsMCwweDMsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksZm9yY2VfdGNwX2FsaWFzLDAsMSwweDMsKG51bGwpDQpjb3JlLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2V0X2FkdmVydGlzZWRfYWRkcmVzcywwLDAs MHgzLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNldF9h ZHZlcnRpc2VkX2FkZHJlc3MsMCwxLDB4MywobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSxzZXRfYWR2ZXJ0aXNlZF9wb3J0LDAsMCwweDMsKG51bGwpDQpjb3Jl LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2V0X2FkdmVydGlzZWRfcG9ydCww LDEsMHgzLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGZv cmNlX3NlbmRfc29ja2V0LDAsMSwweDMsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksZGVidWcsMiwwLDB4MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSxmb3JrLDIsMCwweDIsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9nX3N0ZGVycm9yLDIsMCwweDIsKG51bGwpDQpjb3Jl LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9nX2ZhY2lsaXR5LDIsMCwweDQs KG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZG5zLDIsMCww eDIsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmV2X2Ru cywyLDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGRuc190cnlfaXB2NiwyLDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLGRuc19yZXRyX3RpbWUsMiwwLDB4MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkbnNfcmV0cl9ubywyLDAsMHgyLChudWxsKQ0KY29y ZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRuc19zZXJ2ZXJzX25vLDIsMCww eDIsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZG5zX3Vz ZV9zZWFyY2hfbGlzdCwyLDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLGRuc191c2VfY2FjaGUsMiwwLDB4MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx1c2VfZG5zX2ZhaWxvdmVyLDIsMCwweDIsKG51bGwp DQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZG5zX2NhY2hlX2ZsYWdz LDIsMCwweDIsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks ZG5zX2NhY2hlX25lZ2F0aXZlX3R0bCwyLDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLGRuc19jYWNoZV9tYXhfdHRsLDIsMCwweDIsKG51bGwpDQpj b3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZG5zX2NhY2hlX21pbl90dGws MiwwLDB4MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxk bnNfY2FjaGVfbWVtLDIsMCwweDIsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksZG5zX2NhY2hlX2djX2ludGVydmFsLDIsMCwweDIsKG51bGwpDQpjb3JlLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdXNlX2RzdF9ibGFja2xpc3QsMiwwLDB4 MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkc3RfYmxh Y2tsaXN0X21lbSwyLDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLGRzdF9ibGFja2xpc3RfZXhwaXJlLDIsMCwweDIsKG51bGwpDQpjb3JlLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZHN0X2JsYWNrbGlzdF9nY19pbnRlcnZhbCwy LDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHBv cnQsMiwwLDB4MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSxtYXhidWZmZXIsMiwwLDB4MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChp Mzg2L2xpbnV4KSxjaGlsZHJlbiwyLDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLGNoZWNrX3ZpYSwyLDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHN5bl9icmFuY2gsMiwwLDB4MiwobnVsbCkNCmNv cmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxtZW1sb2csMiwwLDB4MiwobnVs bCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxtZW1kYmcsMiwwLDB4 MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzaXBfd2Fy bmluZywyLDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLHVzZXIsMiwwLDB4NCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2 L2xpbnV4KSxncm91cCwyLDAsMHg0LChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMg KGkzODYvbGludXgpLGNocm9vdCwyLDAsMHg0LChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLHdvcmtkaXIsMiwwLDB4NCwobnVsbCkNCmNvcmUsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxtaG9tZWQsMiwwLDB4MiwobnVsbCkNCmNvcmUsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxkaXNhYmxlX3RjcCwyLDAsMHgyLChudWxs KQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRjcF9hY2NlcHRfYWxp YXNlcywyLDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLHRjcF9jaGlsZHJlbiwyLDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLHRjcF9jb25uZWN0X3RpbWVvdXQsMiwwLDB4MiwobnVsbCkNCmNvcmUs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0Y3Bfc2VuZF90aW1lb3V0LDIsMCww eDIsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdGNwX2Nv bm5lY3Rpb25fbGlmZXRpbWUsMiwwLDB4MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQt dGxzIChpMzg2L2xpbnV4KSx0Y3BfcG9sbF9tZXRob2QsMiwwLDB4NCwobnVsbCkNCmNvcmUsc2Vy IDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0Y3BfbWF4X2Nvbm5lY3Rpb25zLDIsMCww eDIsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGlzYWJs ZV90bHMsMiwwLDB4MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSx0bHNfbG9nLDIsMCwweDIsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksdGxzX3BvcnRfbm8sMiwwLDB4MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0bHNfbWV0aG9kLDIsMCwweDQsKG51bGwpDQpjb3JlLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdGxzX3ZlcmlmeSwyLDAsMHgyLChudWxs KQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHRsc19yZXF1aXJlX2Nl cnRpZmljYXRlLDIsMCwweDIsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksdGxzX2NlcnRpZmljYXRlLDIsMCwweDQsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5 LWRldjY0LXRscyAoaTM4Ni9saW51eCksdGxzX3ByaXZhdGVfa2V5LDIsMCwweDQsKG51bGwpDQpj b3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksdGxzX2NhX2xpc3QsMiwwLDB4 NCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0bHNfaGFu ZHNoYWtlX3RpbWVvdXQsMiwwLDB4MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxz IChpMzg2L2xpbnV4KSx0bHNfc2VuZF90aW1lb3V0LDIsMCwweDIsKG51bGwpDQpjb3JlLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2VydmVyX3NpZ25hdHVyZSwyLDAsMHgyLChu dWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJlcGx5X3RvX3Zp YSwyLDAsMHgyLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGxpc3RlbiwyLDAsMHg0LChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLGFsaWFzLDIsMCwweDQsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksYWR2ZXJ0aXNlZF9hZGRyZXNzLDIsMCwweDQsKG51bGwpDQpjb3JlLHNlciAw LjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYWR2ZXJ0aXNlZF9wb3J0LDIsMCwweDIsKG51 bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZGlzYWJsZV9jb3Jl X2R1bXAsMiwwLDB4MiwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxvcGVuX2ZpbGVzX2xpbWl0LDIsMCwweDIsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRl djY0LXRscyAoaTM4Ni9saW51eCksbWNhc3RfbG9vcGJhY2ssMiwwLDB4MiwobnVsbCkNCmNvcmUs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxtY2FzdF90dGwsMiwwLDB4MiwobnVs bCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx0b3MsMiwwLDB4Miwo bnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzZXJfa2lsbF90 aW1lb3V0LDIsMCwweDIsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCksc3R1bl9yZWZyZXNoX2ludGVydmFsLDIsMCwweDIsKG51bGwpDQpjb3JlLHNlciAwLjEw Ljk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc3R1bl9hbGxvd19zdHVuLDIsMCwweDIsKG51bGwp DQpjb3JlLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc3R1bl9hbGxvd19mcCwy LDAsMHgyLChudWxsKQ0KdXJpX3JhZGl1cyxzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLHJhZGl1c19kb2VzX3VyaV9leGlzdCwwLDAsMHgxLChudWxsKQ0KdXJpX3JhZGl1cyxzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJhZGl1c19jb25maWcsMiwwLDB4MSwobnVs bCkNCnVyaV9yYWRpdXMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxzZXJ2aWNl X3R5cGUsMiwwLDB4MiwobnVsbCkNCnJlZ2lzdHJhcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLHNhdmVfY29udGFjdHMsMCwxLDB4MywobnVsbCkNCnJlZ2lzdHJhcixzZXIgMC4x MC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNhdmVfY29udGFjdHMsMCwyLDB4MywobnVsbCkN CnJlZ2lzdHJhcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNhdmUsMCwxLDB4 MywobnVsbCkNCnJlZ2lzdHJhcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNh dmUsMCwyLDB4MywobnVsbCkNCnJlZ2lzdHJhcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYv bGludXgpLHNhdmVfY29udGFjdHNfbm9yZXBseSwwLDEsMHgzLChudWxsKQ0KcmVnaXN0cmFyLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2F2ZV9jb250YWN0c19ub3JlcGx5LDAs MiwweDMsKG51bGwpDQpyZWdpc3RyYXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4 KSxzYXZlX25vcmVwbHksMCwxLDB4MywobnVsbCkNCnJlZ2lzdHJhcixzZXIgMC4xMC45OS1kZXY2 NC10bHMgKGkzODYvbGludXgpLHNhdmVfbm9yZXBseSwwLDIsMHgzLChudWxsKQ0KcmVnaXN0cmFy LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksc2F2ZV9tZW1vcnksMCwxLDB4Mywo bnVsbCkNCnJlZ2lzdHJhcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNhdmVf bWVtb3J5LDAsMiwweDMsKG51bGwpDQpyZWdpc3RyYXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChp Mzg2L2xpbnV4KSxsb29rdXBfY29udGFjdHMsMCwxLDB4MywobnVsbCkNCnJlZ2lzdHJhcixzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGxvb2t1cF9jb250YWN0cywwLDIsMHgzLChu dWxsKQ0KcmVnaXN0cmFyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9va3Vw LDAsMSwweDMsKG51bGwpDQpyZWdpc3RyYXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSxsb29rdXAsMCwyLDB4MywobnVsbCkNCnJlZ2lzdHJhcixzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLHJlZ2lzdGVyZWQsMCwxLDB4MywobnVsbCkNCnJlZ2lzdHJhcixzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJlZ2lzdGVyZWQsMCwyLDB4MywobnVsbCkN CnJlZ2lzdHJhcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGRlZmF1bHRfZXhw aXJlcywyLDAsMHgyLChudWxsKQ0KcmVnaXN0cmFyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksZGVmYXVsdF9xLDIsMCwweDIsKG51bGwpDQpyZWdpc3RyYXIsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxhcHBlbmRfYnJhbmNoZXMsMiwwLDB4MiwobnVsbCkNCnJl Z2lzdHJhcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHNhdmVfbmF0X2ZsYWcs MiwwLDB4MiwobnVsbCkNCnJlZ2lzdHJhcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGlu dXgpLHNhdmVfbmF0X2ZsYWcsMiwwLDB4ODAwMDAwMDEsKG51bGwpDQpyZWdpc3RyYXIsc2VyIDAu MTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsb2FkX25hdF9mbGFnLDIsMCwweDIsKG51bGwp DQpyZWdpc3RyYXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxsb2FkX25hdF9m bGFnLDIsMCwweDgwMDAwMDAxLChudWxsKQ0KcmVnaXN0cmFyLHNlciAwLjEwLjk5LWRldjY0LXRs cyAoaTM4Ni9saW51eCksbWluX2V4cGlyZXMsMiwwLDB4MiwobnVsbCkNCnJlZ2lzdHJhcixzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLG1heF9leHBpcmVzLDIsMCwweDIsKG51bGwp DQpyZWdpc3RyYXIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZWNlaXZlZF9w YXJhbSwyLDAsMHg0LChudWxsKQ0KcmVnaXN0cmFyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCksbWF4X2NvbnRhY3RzLDIsMCwweDIsKG51bGwpDQpyZWdpc3RyYXIsc2VyIDAuMTAu OTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZWNlaXZlZF90b191cmksMiwwLDB4MiwobnVsbCkN CnJlZ2lzdHJhcixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLHJlcGx5X2NvZGVf YXR0ciwyLDAsMHg0LChudWxsKQ0KcmVnaXN0cmFyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4 Ni9saW51eCkscmVwbHlfcmVhc29uX2F0dHIsMiwwLDB4NCwobnVsbCkNCnJlZ2lzdHJhcixzZXIg MC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLGNvbnRhY3RfYXR0ciwyLDAsMHg0LChudWxs KQ0KcmVnaXN0cmFyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYW9yX2F0dHIs MiwwLDB4NCwobnVsbCkNCnJyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksbG9v c2Vfcm91dGUsMCwwLDB4MSwobnVsbCkNCnJyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9s aW51eCkscmVjb3JkX3JvdXRlLDAsMCwweDEsKG51bGwpDQpycixzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLHJlY29yZF9yb3V0ZV9wcmVzZXQsMCwxLDB4MSwobnVsbCkNCnJyLHNl ciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCkscmVjb3JkX3JvdXRlX3N0cmljdCwwLDAs MHgwLChudWxsKQ0KcnIsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSxyZW1vdmVf cmVjb3JkX3JvdXRlLDAsMCwweDMsKG51bGwpDQpycixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkz ODYvbGludXgpLGFwcGVuZF9mcm9tdGFnLDIsMCwweDIsKG51bGwpDQpycixzZXIgMC4xMC45OS1k ZXY2NC10bHMgKGkzODYvbGludXgpLGVuYWJsZV9kb3VibGVfcnIsMiwwLDB4MiwobnVsbCkNCnJy LHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZW5hYmxlX2Z1bGxfbHIsMiwwLDB4 MiwobnVsbCkNCnJyLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksYWRkX3VzZXJu YW1lLDIsMCwweDQsKG51bGwpDQpycixzZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgp LGNvb2tpZV9maWx0ZXIsMiwwLDB4MSwobnVsbCkNCnJyLHNlciAwLjEwLjk5LWRldjY0LXRscyAo aTM4Ni9saW51eCksY29va2llX3NlY3JldCwyLDAsMHg0LChudWxsKQ0KcnIsc2VyIDAuMTAuOTkt ZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx1c2VyX3BhcnRfYXZwLDIsMCwweDQsKG51bGwpDQpycixz ZXIgMC4xMC45OS1kZXY2NC10bHMgKGkzODYvbGludXgpLG5leHRfcm91dGVfYXZwLDIsMCwweDQs KG51bGwpDQp1YWMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx1YWNfcmVwbGFj ZV9mcm9tLDAsMiwweDMsKG51bGwpDQp1YWMsc2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xp bnV4KSx1YWNfcmVwbGFjZV9mcm9tLDAsMSwweDMsKG51bGwpDQp1YWMsc2VyIDAuMTAuOTktZGV2 NjQtdGxzIChpMzg2L2xpbnV4KSx1YWNfcmVzdG9yZV9mcm9tLDAsMCwweDcsKG51bGwpDQp1YWMs c2VyIDAuMTAuOTktZGV2NjQtdGxzIChpMzg2L2xpbnV4KSx1YWNfYXV0aCwwLDAsMHgyLChudWxs KQ0KdWFjLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCksZnJvbV9zdG9yZV9wYXJh bSwyLDAsMHgxLChudWxsKQ0KdWFjLHNlciAwLjEwLjk5LWRldjY0LXRscyAoaTM4Ni9saW51eCks ZnJvbV9yZXN0b3JlX21vZGUsMiwwLDB4MiwobnVsbCkNCnVhYyxzZXIgMC4xMC45OS1kZXY2NC10 bHMgKGkzODYvbGludXgpLGNyZWRlbnRpYWwsMiwwLDB4ODAwMDAwMDEsKG51bGwpDQo= --===============1606299329==-- From klaus.mailinglists@pernau.at Thu Aug 20 16:11:53 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Thu, 20 Aug 2009 16:11:23 +0200 Message-ID: <4A8D598B.6060708@pernau.at> In-Reply-To: <4A8D5456.1020402@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1770184007==" --===============1770184007== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Daniel-Constantin Mierla schrieb: >=20 >=20 > On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >> Recently posted by Miklos: > I started a dedicated wiki page in cookbook format: > http://sip-router.org/wiki/cookbooks/selects/devel >=20 > Anyone having time to dig and contribute, is very welcome. IMO it should be generated automatically by the tool Jan mentioned. klaus >=20 > Thanks, > Daniel >=20 >> >> -------- Original-Nachricht -------- >> Betreff: Re: [SR-Users] sip-router select >> Datum: Wed, 12 Aug 2009 10:13:11 +0200 >> Von: Miklos Tirpak >> An: M=C3=89SZ=C3=81ROS Mih=C3=A1ly >> CC: sr-users(a)lists.sip-router.org >> Referenzen: <4A817281.4040301(a)niif.hu> >> >> Hi, >> >> selects come from SER, I found these pages about them: >> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_avp= airs=20 >> >> http://www.iptel.org/attribute_value_pairs_and_selects >> >> For the list of available selects you can use >> http://www.iptel.org/ser/doc/search >> (Uncheck F, R, and P) >> It shows a bit older state though. >> >> Miklos >> >> On 08/11/2009 03:30 PM, M=C3=89SZ=C3=81ROS Mih=C3=A1ly wrote: >> > Hi! >> > >> > Can any of you explain how select framework is working? >> > Where can i find any documentation about it. >> > I am experiencing problem when i am try using it. >> > Any help highly appreciated! >> > >> > Regards, >> > Misi >> > >> >> Daniel-Constantin Mierla schrieb: >>> Hello, >>> >>> is there a list with available selects in ser? I only found short=20 >>> introduction at: >>> >>> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_av= pairs=20 >>> >>> >>> Thanks, >>> Daniel >>> >> >> _______________________________________________ >> sr-dev mailing list >> sr-dev(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >> >=20 --===============1770184007==-- From miconda@gmail.com Thu Aug 20 17:24:35 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Thu, 20 Aug 2009 18:24:32 +0300 Message-ID: <4A8D6AB0.6010304@gmail.com> In-Reply-To: <4A8D598B.6060708@pernau.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0384485535==" --===============0384485535== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 20.08.2009 17:11 Uhr, Klaus Darilion wrote: > > > Daniel-Constantin Mierla schrieb: >> >> >> On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >>> Recently posted by Miklos: >> I started a dedicated wiki page in cookbook format: >> http://sip-router.org/wiki/cookbooks/selects/devel >> >> Anyone having time to dig and contribute, is very welcome. > > IMO it should be generated automatically by the tool Jan mentioned. fine with me, I didn't know about it, feel free to do it. However, some=20 description/examples should be added as well. Cheers, Daniel > > klaus > > >> >> Thanks, >> Daniel >> >>> >>> -------- Original-Nachricht -------- >>> Betreff: Re: [SR-Users] sip-router select >>> Datum: Wed, 12 Aug 2009 10:13:11 +0200 >>> Von: Miklos Tirpak >>> An: M=C3=89SZ=C3=81ROS Mih=C3=A1ly >>> CC: sr-users(a)lists.sip-router.org >>> Referenzen: <4A817281.4040301(a)niif.hu> >>> >>> Hi, >>> >>> selects come from SER, I found these pages about them: >>> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_av= pairs=20 >>> >>> http://www.iptel.org/attribute_value_pairs_and_selects >>> >>> For the list of available selects you can use >>> http://www.iptel.org/ser/doc/search >>> (Uncheck F, R, and P) >>> It shows a bit older state though. >>> >>> Miklos >>> >>> On 08/11/2009 03:30 PM, M=C3=89SZ=C3=81ROS Mih=C3=A1ly wrote: >>> > Hi! >>> > >>> > Can any of you explain how select framework is working? >>> > Where can i find any documentation about it. >>> > I am experiencing problem when i am try using it. >>> > Any help highly appreciated! >>> > >>> > Regards, >>> > Misi >>> > >>> >>> Daniel-Constantin Mierla schrieb: >>>> Hello, >>>> >>>> is there a list with available selects in ser? I only found short=20 >>>> introduction at: >>>> >>>> http://www.iptel.org/introduction_to_selects_and_attribute_value_pairs_a= vpairs=20 >>>> >>>> >>>> Thanks, >>>> Daniel >>>> >>> >>> _______________________________________________ >>> sr-dev mailing list >>> sr-dev(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >>> >> --=20 Daniel-Constantin Mierla * http://www.asipto.com/ --===============0384485535==-- From miconda@gmail.com Thu Aug 20 17:26:05 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Thu, 20 Aug 2009 18:26:01 +0300 Message-ID: <4A8D6B09.1070001@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0873391939==" --===============0873391939== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thanks Jan, the tool sounds interesting, however, the file you attached does not include the selects ... or I overlooked something. Cheers, Daniel On 20.08.2009 17:06 Uhr, Jan Janak wrote: > On Thu, Aug 20, 2009 at 3:49 PM, Daniel-Constantin > Mierla wrote: > >> On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >> >>> Recently posted by Miklos: >>> >> I started a dedicated wiki page in cookbook format: >> http://sip-router.org/wiki/cookbooks/selects/devel >> >> Anyone having time to dig and contribute, is very welcome. >> > > I found a list I generated a while ago. It is not completely > up-to-date but it won't be far from it. The list in CSV format is > attached in case you wanted to import it in the wiki page. > > The meaning of comma separated fields is as follows > * module name > * ser version > * function/parameter/select name > * Symbol type (0-function, 1-rpc, 2-param, 3-select > * Number of parameters (functions) > * Flags (failure route, onsend route, ...) > * Documentation string (rpc functions) > > Jan. > -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============0873391939==-- From jan@ryngle.com Thu Aug 20 17:35:59 2009 From: Jan Janak To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Thu, 20 Aug 2009 17:35:28 +0200 Message-ID: In-Reply-To: <4A8D6B09.1070001@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0012765108==" --===============0012765108== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Aug 20, 2009 at 5:26 PM, Daniel-Constantin Mierla wrote: > Thanks Jan, the tool sounds interesting, however, the file you attached does > not include the selects ... or I overlooked something. You are right, I overlooked this. I must have another file with just selects then because I remember generating it, I'll have a look tomorrow and get back to you. Jan. --===============0012765108==-- From klaus.mailinglists@pernau.at Thu Aug 20 18:01:32 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Thu, 20 Aug 2009 18:01:03 +0200 Message-ID: <4A8D733F.3050703@pernau.at> In-Reply-To: <4A8D6AB0.6010304@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1083737920==" --===============1083737920== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla schrieb: > > > On 20.08.2009 17:11 Uhr, Klaus Darilion wrote: >> >> >> Daniel-Constantin Mierla schrieb: >>> >>> >>> On 20.08.2009 16:30 Uhr, Klaus Darilion wrote: >>>> Recently posted by Miklos: >>> I started a dedicated wiki page in cookbook format: >>> http://sip-router.org/wiki/cookbooks/selects/devel >>> >>> Anyone having time to dig and contribute, is very welcome. >> >> IMO it should be generated automatically by the tool Jan mentioned. > fine with me, I didn't know about it, feel free to do it. However, some > description/examples should be added as well. maybe two lists? - all selects (autogenerated, undocumented) - documented selects I think some selects will be self-explanatory if the basic selects are described klaus --===============1083737920==-- From jh@tutpro.com Mon Aug 24 09:32:26 2009 From: jh@tutpro.com To: sr-dev@lists.kamailio.org Subject: [sr-dev] async (delayed reply) support for t_uac_dlg in first release? Date: Mon, 24 Aug 2009 10:32:09 +0300 Message-ID: <19090.16889.220892.672670@tutpro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0707505435==" --===============0707505435== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit andrei you wrote in july regarding async (delayed reply) support for t_uac_dlg: Ok, I'll add async support (in fact delayed reply support since it's not true async), at least to xmlrpc (turns out that it's quite easy since xmlrpc reuses sr tcp). For ctl/binrpc it would be easy for datagram sockets (udp or unix datagram socket) and more difficult (but possible) for stream sockets (tcp or unix stream). However it might take a while until there will be a workable version. any idea, if this will be available in first release of sip-router? if yes, i could plan to start using sip-router. if not, i need to plan for something else. -- juha --===============0707505435==-- From jan@ryngle.com Mon Aug 24 10:57:20 2009 From: Jan Janak To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Mon, 24 Aug 2009 10:56:49 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1918637398==" --===============1918637398== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Attached is the select list. Jan. On Thu, Aug 20, 2009 at 5:35 PM, Jan Janak wrote: > On Thu, Aug 20, 2009 at 5:26 PM, Daniel-Constantin > Mierla wrote: >> Thanks Jan, the tool sounds interesting, however, the file you attached do= es >> not include the selects ... or I overlooked something. > > You are right, I overlooked this. I must have another file with just > selects then because I remember generating it, I'll have a look > tomorrow and get back to you. > > =C2=A0Jan. > --===============1918637398== Content-Type: text/csv Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="selects.csv" MIME-Version: 1.0 dGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscywzLDAsMHgwLChudWxs KQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy52ZXJzaW9uLDMs MCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxz LmRlc2MsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGlu dXgpLEB0bHMuZGVzY3JpcHRpb24sMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2 Ni10bHMgKGkzODYvbGludXgpLEB0bHMuY2lwaGVyLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAu MTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLmNpcGhlci5iaXRzLDMsMCwweDAsKG51 bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIsMyww LDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMu cGVlci5zdWJqZWN0LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChp Mzg2L2xpbnV4KSxAdGxzLnBlZXIuc3ViamVjdC5jbiwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAw LjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnN1YmplY3QuY29tbW9uTmFt ZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCks QHRscy5wZWVyLnN1YmplY3QuY29tbW9uX25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4x MC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5zdWJqZWN0Lm5hbWUsMywwLDB4 MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVl ci5zdWJqZWN0LmwsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkz ODYvbGludXgpLEB0bHMucGVlci5zdWJqZWN0LmxvY2FsaXR5TmFtZSwzLDAsMHgwLChudWxsKQ0K dGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnN1YmplY3Qu bG9jYWxpdHlfbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQHRscy5wZWVyLnN1YmplY3QubG9jYWxpdHksMywwLDB4MCwobnVsbCkNCnRs cyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5zdWJqZWN0LmMs MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMucGVlci5zdWJqZWN0LmNvdW50cnlOYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAu OTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIuc3ViamVjdC5jb3VudHJ5X25hbWUs MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMucGVlci5zdWJqZWN0LmNvdW50cnksMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1k ZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5zdWJqZWN0LnN0LDMsMCwweDAsKG51bGwp DQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIuc3ViamVj dC5zdGF0ZU9yUHJvdmluY2VOYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2 NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIuc3ViamVjdC5zdGF0ZV9vcl9wcm92aW5jZV9u YW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4 KSxAdGxzLnBlZXIuc3ViamVjdC5zdGF0ZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnN1YmplY3QubywzLDAsMHgwLChudWxs KQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnN1Ympl Y3Qub3JnYW5pemF0aW9uTmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2 LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnN1YmplY3Qub3JnYW5pemF0aW9uX25hbWUsMyww LDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMu cGVlci5zdWJqZWN0Lm9yZ2FuaXphdGlvbiwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnN1YmplY3Qub3UsMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5zdWJq ZWN0Lm9yZ2FuaXphdGlvbmFsVW5pdE5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45 OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5zdWJqZWN0Lm9yZ2FuaXphdGlvbmFs X3VuaXRfbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4 Ni9saW51eCksQHRscy5wZWVyLnN1YmplY3QudW5pdCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAw LjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnN1YmosMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5zdWJq LmNuLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4 KSxAdGxzLnBlZXIuc3Viai5jb21tb25OYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAu OTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIuc3Viai5jb21tb25fbmFtZSwzLDAs MHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5w ZWVyLnN1YmoubmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQHRscy5wZWVyLnN1YmoubCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEw Ljk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnN1YmoubG9jYWxpdHlOYW1lLDMs MCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxz LnBlZXIuc3Viai5sb2NhbGl0eV9uYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTkt ZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIuc3Viai5sb2NhbGl0eSwzLDAsMHgwLChu dWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnN1 YmouYywzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQHRscy5wZWVyLnN1YmouY291bnRyeU5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4x MC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5zdWJqLmNvdW50cnlfbmFtZSwz LDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRs cy5wZWVyLnN1YmouY291bnRyeSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2 LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnN1Ymouc3QsMywwLDB4MCwobnVsbCkNCnRscyxz ZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5zdWJqLnN0YXRlT3JQ cm92aW5jZU5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkz ODYvbGludXgpLEB0bHMucGVlci5zdWJqLnN0YXRlX29yX3Byb3ZpbmNlX25hbWUsMywwLDB4MCwo bnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5z dWJqLnN0YXRlLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2 L2xpbnV4KSxAdGxzLnBlZXIuc3Viai5vLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTkt ZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIuc3Viai5vcmdhbml6YXRpb25OYW1lLDMs MCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxz LnBlZXIuc3Viai5vcmdhbml6YXRpb25fbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEw Ljk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnN1Ymoub3JnYW5pemF0aW9uLDMs MCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxz LnBlZXIuc3Viai5vdSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQHRscy5wZWVyLnN1Ymoub3JnYW5pemF0aW9uYWxVbml0TmFtZSwzLDAsMHgw LChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVy LnN1Ymoub3JnYW5pemF0aW9uYWxfdW5pdF9uYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAu MTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIuc3Viai51bml0LDMsMCwweDAs KG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIu aXNzdWVyLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xp bnV4KSxAdGxzLnBlZXIuaXNzdWVyLmNuLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTkt ZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIuaXNzdWVyLmNvbW1vbk5hbWUsMywwLDB4 MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVl ci5pc3N1ZXIuY29tbW9uX25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2 Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5pc3N1ZXIubmFtZSwzLDAsMHgwLChudWxsKQ0K dGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLmlzc3Vlci5s LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxA dGxzLnBlZXIuaXNzdWVyLmxvY2FsaXR5TmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEw Ljk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLmlzc3Vlci5sb2NhbGl0eV9uYW1l LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxA dGxzLnBlZXIuaXNzdWVyLmxvY2FsaXR5LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTkt ZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIuaXNzdWVyLmMsMywwLDB4MCwobnVsbCkN CnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5pc3N1ZXIu Y291bnRyeU5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkz ODYvbGludXgpLEB0bHMucGVlci5pc3N1ZXIuY291bnRyeV9uYW1lLDMsMCwweDAsKG51bGwpDQp0 bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIuaXNzdWVyLmNv dW50cnksMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGlu dXgpLEB0bHMucGVlci5pc3N1ZXIuc3QsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1k ZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5pc3N1ZXIuc3RhdGVPclByb3ZpbmNlTmFt ZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCks QHRscy5wZWVyLmlzc3Vlci5zdGF0ZV9vcl9wcm92aW5jZV9uYW1lLDMsMCwweDAsKG51bGwpDQp0 bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIuaXNzdWVyLnN0 YXRlLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4 KSxAdGxzLnBlZXIuaXNzdWVyLm8sMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2 Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5pc3N1ZXIub3JnYW5pemF0aW9uTmFtZSwzLDAs MHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5w ZWVyLmlzc3Vlci5vcmdhbml6YXRpb25fbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEw Ljk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLmlzc3Vlci5vcmdhbml6YXRpb24s MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMucGVlci5pc3N1ZXIub3UsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10 bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5pc3N1ZXIub3JnYW5pemF0aW9uYWxVbml0TmFtZSwz LDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRs cy5wZWVyLmlzc3Vlci5vcmdhbml6YXRpb25hbF91bml0X25hbWUsMywwLDB4MCwobnVsbCkNCnRs cyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5pc3N1ZXIudW5p dCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCks QHRscy5wZWVyLnZlcmlmaWVkLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYt dGxzIChpMzg2L2xpbnV4KSxAdGxzLnBlZXIucmV2b2tlZCwzLDAsMHgwLChudWxsKQ0KdGxzLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLmV4cGlyZWQsMywwLDB4 MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVl ci5zZWxmX3NpZ25lZCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQHRscy5wZWVyLnZlcnNpb24sMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4x MC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5zbiwzLDAsMHgwLChudWxsKQ0K dGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLnNlcmlhbE51 bWJlciwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQHRscy5wZWVyLnNlcmlhbF9udW1iZXIsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45 OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5ub3RCZWZvcmUsMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5ub3Rf YmVmb3JlLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xp bnV4KSxAdGxzLnBlZXIubm90QWZ0ZXIsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1k ZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5ub3RfYWZ0ZXIsMywwLDB4MCwobnVsbCkN CnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5lbWFpbCwz LDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRs cy5wZWVyLmVtYWlsQWRkcmVzcywzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2 LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLmVtYWlsX2FkZHJlc3MsMywwLDB4MCwobnVsbCkN CnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci5ob3N0LDMs MCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxz LnBlZXIuaG9zdG5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMg KGkzODYvbGludXgpLEB0bHMucGVlci5kbnMsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45 OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci51cmksMywwLDB4MCwobnVsbCkNCnRs cyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVlci51cmwsMywwLDB4 MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMucGVl ci51cm4sMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGlu dXgpLEB0bHMucGVlci5pcCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRs cyAoaTM4Ni9saW51eCksQHRscy5wZWVyLklQQWRkcmVzcywzLDAsMHgwLChudWxsKQ0KdGxzLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5wZWVyLmlwX2FkZHJlc3MsMyww LDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMu bXksMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgp LEB0bHMubXkuc3ViamVjdCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRs cyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJqZWN0LmNuLDMsMCwweDAsKG51bGwpDQp0bHMsc2Vy IDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15LnN1YmplY3QuY29tbW9uTmFt ZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCks QHRscy5teS5zdWJqZWN0LmNvbW1vbl9uYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAu OTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15LnN1YmplY3QubmFtZSwzLDAsMHgwLChu dWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJq ZWN0LmwsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGlu dXgpLEB0bHMubXkuc3ViamVjdC5sb2NhbGl0eU5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIg MC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3ViamVjdC5sb2NhbGl0eV9u YW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4 KSxAdGxzLm15LnN1YmplY3QubG9jYWxpdHksMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45 OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3ViamVjdC5jLDMsMCwweDAsKG51bGwp DQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15LnN1YmplY3Qu Y291bnRyeU5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkz ODYvbGludXgpLEB0bHMubXkuc3ViamVjdC5jb3VudHJ5X25hbWUsMywwLDB4MCwobnVsbCkNCnRs cyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3ViamVjdC5jb3Vu dHJ5LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4 KSxAdGxzLm15LnN1YmplY3Quc3QsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2 Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3ViamVjdC5zdGF0ZU9yUHJvdmluY2VOYW1lLDMs MCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxz Lm15LnN1YmplY3Quc3RhdGVfb3JfcHJvdmluY2VfbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJqZWN0LnN0YXRlLDMs MCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxz Lm15LnN1YmplY3QubywzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQHRscy5teS5zdWJqZWN0Lm9yZ2FuaXphdGlvbk5hbWUsMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3ViamVj dC5vcmdhbml6YXRpb25fbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2 LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJqZWN0Lm9yZ2FuaXphdGlvbiwzLDAsMHgwLChu dWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJq ZWN0Lm91LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xp bnV4KSxAdGxzLm15LnN1YmplY3Qub3JnYW5pemF0aW9uYWxVbml0TmFtZSwzLDAsMHgwLChudWxs KQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJqZWN0 Lm9yZ2FuaXphdGlvbmFsX3VuaXRfbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJqZWN0LnVuaXQsMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3Viaiwz LDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRs cy5teS5zdWJqLmNuLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChp Mzg2L2xpbnV4KSxAdGxzLm15LnN1YmouY29tbW9uTmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJqLmNvbW1vbl9uYW1l LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxA dGxzLm15LnN1YmoubmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRs cyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJqLmwsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4x MC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3Viai5sb2NhbGl0eU5hbWUsMyww LDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMu bXkuc3Viai5sb2NhbGl0eV9uYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2 NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15LnN1YmoubG9jYWxpdHksMywwLDB4MCwobnVsbCkN CnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3Viai5jLDMs MCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxz Lm15LnN1YmouY291bnRyeU5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2 Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3Viai5jb3VudHJ5X25hbWUsMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3Viai5j b3VudHJ5LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xp bnV4KSxAdGxzLm15LnN1Ymouc3QsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2 Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3Viai5zdGF0ZU9yUHJvdmluY2VOYW1lLDMsMCww eDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15 LnN1Ymouc3RhdGVfb3JfcHJvdmluY2VfbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEw Ljk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJqLnN0YXRlLDMsMCwweDAsKG51 bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15LnN1Ymou bywzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCks QHRscy5teS5zdWJqLm9yZ2FuaXphdGlvbk5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4x MC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuc3Viai5vcmdhbml6YXRpb25fbmFt ZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCks QHRscy5teS5zdWJqLm9yZ2FuaXphdGlvbiwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJqLm91LDMsMCwweDAsKG51bGwpDQp0 bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15LnN1Ymoub3JnYW5p emF0aW9uYWxVbml0TmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRs cyAoaTM4Ni9saW51eCksQHRscy5teS5zdWJqLm9yZ2FuaXphdGlvbmFsX3VuaXRfbmFtZSwzLDAs MHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5t eS5zdWJqLnVuaXQsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkz ODYvbGludXgpLEB0bHMubXkuaXNzdWVyLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTkt ZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15Lmlzc3Vlci5jbiwzLDAsMHgwLChudWxsKQ0K dGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5pc3N1ZXIuY29t bW9uTmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9s aW51eCksQHRscy5teS5pc3N1ZXIuY29tbW9uX25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIg MC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuaXNzdWVyLm5hbWUsMywwLDB4 MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXku aXNzdWVyLmwsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYv bGludXgpLEB0bHMubXkuaXNzdWVyLmxvY2FsaXR5TmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5pc3N1ZXIubG9jYWxpdHlf bmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQHRscy5teS5pc3N1ZXIubG9jYWxpdHksMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45 OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuaXNzdWVyLmMsMywwLDB4MCwobnVsbCkN CnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuaXNzdWVyLmNv dW50cnlOYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2 L2xpbnV4KSxAdGxzLm15Lmlzc3Vlci5jb3VudHJ5X25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxz ZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuaXNzdWVyLmNvdW50cnks MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMubXkuaXNzdWVyLnN0LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxz IChpMzg2L2xpbnV4KSxAdGxzLm15Lmlzc3Vlci5zdGF0ZU9yUHJvdmluY2VOYW1lLDMsMCwweDAs KG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15Lmlz c3Vlci5zdGF0ZV9vcl9wcm92aW5jZV9uYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAu OTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15Lmlzc3Vlci5zdGF0ZSwzLDAsMHgwLChu dWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5pc3N1 ZXIubywzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQHRscy5teS5pc3N1ZXIub3JnYW5pemF0aW9uTmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5pc3N1ZXIub3JnYW5pemF0 aW9uX25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYv bGludXgpLEB0bHMubXkuaXNzdWVyLm9yZ2FuaXphdGlvbiwzLDAsMHgwLChudWxsKQ0KdGxzLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5pc3N1ZXIub3UsMywwLDB4 MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXku aXNzdWVyLm9yZ2FuaXphdGlvbmFsVW5pdE5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4x MC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuaXNzdWVyLm9yZ2FuaXphdGlvbmFs X3VuaXRfbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4 Ni9saW51eCksQHRscy5teS5pc3N1ZXIudW5pdCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEw Ljk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS52ZXJpZmllZCwzLDAsMHgwLChudWxs KQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5yZXZva2Vk LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxA dGxzLm15LmV4cGlyZWQsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMg KGkzODYvbGludXgpLEB0bHMubXkuc2VsZl9zaWduZWQsMywwLDB4MCwobnVsbCkNCnRscyxzZXIg MC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkudmVyc2lvbiwzLDAsMHgwLChu dWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5zbiwz LDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRs cy5teS5zZXJpYWxOdW1iZXIsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10 bHMgKGkzODYvbGludXgpLEB0bHMubXkuc2VyaWFsX251bWJlciwzLDAsMHgwLChudWxsKQ0KdGxz LHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5ub3RCZWZvcmUsMyww LDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMu bXkubm90X2JlZm9yZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQHRscy5teS5ub3RBZnRlciwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEw Ljk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5ub3RfYWZ0ZXIsMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuZW1haWws MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMubXkuZW1haWxBZGRyZXNzLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYt dGxzIChpMzg2L2xpbnV4KSxAdGxzLm15LmVtYWlsX2FkZHJlc3MsMywwLDB4MCwobnVsbCkNCnRs cyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuaG9zdCwzLDAsMHgw LChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS5o b3N0bmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9s aW51eCksQHRscy5teS5kbnMsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10 bHMgKGkzODYvbGludXgpLEB0bHMubXkudXJpLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAu OTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15LnVybCwzLDAsMHgwLChudWxsKQ0KdGxz LHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teS51cm4sMywwLDB4MCwo bnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXkuaXAs MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMubXkuSVBBZGRyZXNzLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxz IChpMzg2L2xpbnV4KSxAdGxzLm15LmlwX2FkZHJlc3MsMywwLDB4MCwobnVsbCkNCnRscyxzZXIg MC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUsMywwLDB4MCwobnVsbCkNCnRs cyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuc3ViamVjdCwzLDAs MHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5t ZS5zdWJqZWN0LmNuLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChp Mzg2L2xpbnV4KSxAdGxzLm1lLnN1YmplY3QuY29tbW9uTmFtZSwzLDAsMHgwLChudWxsKQ0KdGxz LHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5zdWJqZWN0LmNvbW1v bl9uYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xp bnV4KSxAdGxzLm1lLnN1YmplY3QubmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5zdWJqZWN0LmwsMywwLDB4MCwobnVsbCkN CnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuc3ViamVjdC5s b2NhbGl0eU5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkz ODYvbGludXgpLEB0bHMubWUuc3ViamVjdC5sb2NhbGl0eV9uYW1lLDMsMCwweDAsKG51bGwpDQp0 bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1YmplY3QubG9j YWxpdHksMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGlu dXgpLEB0bHMubWUuc3ViamVjdC5jLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2 NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1YmplY3QuY291bnRyeU5hbWUsMywwLDB4MCwo bnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuc3Vi amVjdC5jb3VudHJ5X25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10 bHMgKGkzODYvbGludXgpLEB0bHMubWUuc3ViamVjdC5jb3VudHJ5LDMsMCwweDAsKG51bGwpDQp0 bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1YmplY3Quc3Qs MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMubWUuc3ViamVjdC5zdGF0ZU9yUHJvdmluY2VOYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2Vy IDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1YmplY3Quc3RhdGVfb3Jf cHJvdmluY2VfbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQHRscy5tZS5zdWJqZWN0LnN0YXRlLDMsMCwweDAsKG51bGwpDQp0bHMsc2Vy IDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1YmplY3QubywzLDAsMHgw LChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5z dWJqZWN0Lm9yZ2FuaXphdGlvbk5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1k ZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuc3ViamVjdC5vcmdhbml6YXRpb25fbmFtZSwz LDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRs cy5tZS5zdWJqZWN0Lm9yZ2FuaXphdGlvbiwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5zdWJqZWN0Lm91LDMsMCwweDAsKG51bGwp DQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1YmplY3Qu b3JnYW5pemF0aW9uYWxVbml0TmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRl djY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5zdWJqZWN0Lm9yZ2FuaXphdGlvbmFsX3VuaXRf bmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQHRscy5tZS5zdWJqZWN0LnVuaXQsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1k ZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuc3ViaiwzLDAsMHgwLChudWxsKQ0KdGxzLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5zdWJqLmNuLDMsMCwweDAs KG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1 YmouY29tbW9uTmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQHRscy5tZS5zdWJqLmNvbW1vbl9uYW1lLDMsMCwweDAsKG51bGwpDQp0bHMs c2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1YmoubmFtZSwzLDAs MHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5t ZS5zdWJqLmwsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYv bGludXgpLEB0bHMubWUuc3Viai5sb2NhbGl0eU5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIg MC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuc3Viai5sb2NhbGl0eV9uYW1l LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxA dGxzLm1lLnN1YmoubG9jYWxpdHksMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2 Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuc3Viai5jLDMsMCwweDAsKG51bGwpDQp0bHMsc2Vy IDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1YmouY291bnRyeU5hbWUs MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMubWUuc3Viai5jb3VudHJ5X25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1k ZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuc3Viai5jb3VudHJ5LDMsMCwweDAsKG51bGwp DQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1Ymouc3Qs MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMubWUuc3Viai5zdGF0ZU9yUHJvdmluY2VOYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAu MTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1Ymouc3RhdGVfb3JfcHJvdmlu Y2VfbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9s aW51eCksQHRscy5tZS5zdWJqLnN0YXRlLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTkt ZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1YmoubywzLDAsMHgwLChudWxsKQ0KdGxz LHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5zdWJqLm9yZ2FuaXph dGlvbk5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYv bGludXgpLEB0bHMubWUuc3Viai5vcmdhbml6YXRpb25fbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxz LHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5zdWJqLm9yZ2FuaXph dGlvbiwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQHRscy5tZS5zdWJqLm91LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYt dGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLnN1Ymoub3JnYW5pemF0aW9uYWxVbml0TmFtZSwzLDAs MHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5t ZS5zdWJqLm9yZ2FuaXphdGlvbmFsX3VuaXRfbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAw LjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5zdWJqLnVuaXQsMywwLDB4MCwo bnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuaXNz dWVyLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4 KSxAdGxzLm1lLmlzc3Vlci5jbiwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2 LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5pc3N1ZXIuY29tbW9uTmFtZSwzLDAsMHgwLChudWxs KQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5pc3N1ZXIu Y29tbW9uX25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkz ODYvbGludXgpLEB0bHMubWUuaXNzdWVyLm5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4x MC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuaXNzdWVyLmwsMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuaXNzdWVy LmxvY2FsaXR5TmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQHRscy5tZS5pc3N1ZXIubG9jYWxpdHlfbmFtZSwzLDAsMHgwLChudWxsKQ0K dGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5pc3N1ZXIubG9j YWxpdHksMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGlu dXgpLEB0bHMubWUuaXNzdWVyLmMsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2 Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuaXNzdWVyLmNvdW50cnlOYW1lLDMsMCwweDAsKG51 bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLmlzc3Vl ci5jb3VudHJ5X25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMg KGkzODYvbGludXgpLEB0bHMubWUuaXNzdWVyLmNvdW50cnksMywwLDB4MCwobnVsbCkNCnRscyxz ZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuaXNzdWVyLnN0LDMsMCww eDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1l Lmlzc3Vlci5zdGF0ZU9yUHJvdmluY2VOYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAu OTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLmlzc3Vlci5zdGF0ZV9vcl9wcm92aW5j ZV9uYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xp bnV4KSxAdGxzLm1lLmlzc3Vlci5zdGF0ZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5pc3N1ZXIubywzLDAsMHgwLChudWxsKQ0K dGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5pc3N1ZXIub3Jn YW5pemF0aW9uTmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQHRscy5tZS5pc3N1ZXIub3JnYW5pemF0aW9uX25hbWUsMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuaXNzdWVy Lm9yZ2FuaXphdGlvbiwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQHRscy5tZS5pc3N1ZXIub3UsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4x MC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuaXNzdWVyLm9yZ2FuaXphdGlvbmFs VW5pdE5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYv bGludXgpLEB0bHMubWUuaXNzdWVyLm9yZ2FuaXphdGlvbmFsX3VuaXRfbmFtZSwzLDAsMHgwLChu dWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5pc3N1 ZXIudW5pdCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9s aW51eCksQHRscy5tZS52ZXJpZmllZCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRl djY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5yZXZva2VkLDMsMCwweDAsKG51bGwpDQp0bHMs c2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1lLmV4cGlyZWQsMywwLDB4 MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUu c2VsZl9zaWduZWQsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkz ODYvbGludXgpLEB0bHMubWUudmVyc2lvbiwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5zbiwzLDAsMHgwLChudWxsKQ0KdGxzLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5zZXJpYWxOdW1iZXIsMyww LDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMu bWUuc2VyaWFsX251bWJlciwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRs cyAoaTM4Ni9saW51eCksQHRscy5tZS5ub3RCZWZvcmUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIg MC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUubm90X2JlZm9yZSwzLDAsMHgw LChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5u b3RBZnRlciwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9s aW51eCksQHRscy5tZS5ub3RfYWZ0ZXIsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1k ZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuZW1haWwsMywwLDB4MCwobnVsbCkNCnRscyxz ZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuZW1haWxBZGRyZXNzLDMs MCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxz Lm1lLmVtYWlsX2FkZHJlc3MsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10 bHMgKGkzODYvbGludXgpLEB0bHMubWUuaG9zdCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEw Ljk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5ob3N0bmFtZSwzLDAsMHgwLChudWxs KQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5tZS5kbnMsMyww LDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMu bWUudXJpLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xp bnV4KSxAdGxzLm1lLnVybCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRs cyAoaTM4Ni9saW51eCksQHRscy5tZS51cm4sMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45 OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuaXAsMywwLDB4MCwobnVsbCkNCnRscyxz ZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubWUuSVBBZGRyZXNzLDMsMCww eDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm1l LmlwX2FkZHJlc3MsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkz ODYvbGludXgpLEB0bHMubXlzZWxmLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2 NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5zdWJqZWN0LDMsMCwweDAsKG51bGwpDQp0 bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5zdWJqZWN0 LmNuLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4 KSxAdGxzLm15c2VsZi5zdWJqZWN0LmNvbW1vbk5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIg MC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLnN1YmplY3QuY29tbW9u X25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGlu dXgpLEB0bHMubXlzZWxmLnN1YmplY3QubmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEw Ljk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuc3ViamVjdC5sLDMsMCwweDAs KG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2Vs Zi5zdWJqZWN0LmxvY2FsaXR5TmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRl djY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuc3ViamVjdC5sb2NhbGl0eV9uYW1lLDMs MCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxz Lm15c2VsZi5zdWJqZWN0LmxvY2FsaXR5LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTkt ZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5zdWJqZWN0LmMsMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLnN1 YmplY3QuY291bnRyeU5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10 bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLnN1YmplY3QuY291bnRyeV9uYW1lLDMsMCwweDAs KG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2Vs Zi5zdWJqZWN0LmNvdW50cnksMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10 bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLnN1YmplY3Quc3QsMywwLDB4MCwobnVsbCkNCnRs cyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLnN1YmplY3Qu c3RhdGVPclByb3ZpbmNlTmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2 LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuc3ViamVjdC5zdGF0ZV9vcl9wcm92aW5jZV9u YW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4 KSxAdGxzLm15c2VsZi5zdWJqZWN0LnN0YXRlLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAu OTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5zdWJqZWN0Lm8sMywwLDB4MCwo bnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxm LnN1YmplY3Qub3JnYW5pemF0aW9uTmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuc3ViamVjdC5vcmdhbml6YXRpb25f bmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQHRscy5teXNlbGYuc3ViamVjdC5vcmdhbml6YXRpb24sMywwLDB4MCwobnVsbCkNCnRscyxz ZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLnN1YmplY3Qub3Us MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMubXlzZWxmLnN1YmplY3Qub3JnYW5pemF0aW9uYWxVbml0TmFtZSwzLDAsMHgwLChudWxsKQ0K dGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuc3ViamVj dC5vcmdhbml6YXRpb25hbF91bml0X25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45 OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLnN1YmplY3QudW5pdCwzLDAsMHgw LChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNl bGYuc3ViaiwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9s aW51eCksQHRscy5teXNlbGYuc3Viai5jbiwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuc3Viai5jb21tb25OYW1lLDMsMCww eDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15 c2VsZi5zdWJqLmNvbW1vbl9uYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2 NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5zdWJqLm5hbWUsMywwLDB4MCwobnVsbCkN CnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLnN1Ymou bCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCks QHRscy5teXNlbGYuc3Viai5sb2NhbGl0eU5hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4x MC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLnN1YmoubG9jYWxpdHlfbmFt ZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCks QHRscy5teXNlbGYuc3Viai5sb2NhbGl0eSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuc3Viai5jLDMsMCwweDAsKG51bGwp DQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5zdWJq LmNvdW50cnlOYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChp Mzg2L2xpbnV4KSxAdGxzLm15c2VsZi5zdWJqLmNvdW50cnlfbmFtZSwzLDAsMHgwLChudWxsKQ0K dGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuc3Viai5j b3VudHJ5LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xp bnV4KSxAdGxzLm15c2VsZi5zdWJqLnN0LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTkt ZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5zdWJqLnN0YXRlT3JQcm92aW5jZU5h bWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgp LEB0bHMubXlzZWxmLnN1Ymouc3RhdGVfb3JfcHJvdmluY2VfbmFtZSwzLDAsMHgwLChudWxsKQ0K dGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuc3Viai5z dGF0ZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQHRscy5teXNlbGYuc3Viai5vLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2 NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5zdWJqLm9yZ2FuaXphdGlvbk5hbWUsMyww LDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMu bXlzZWxmLnN1Ymoub3JnYW5pemF0aW9uX25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4x MC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLnN1Ymoub3JnYW5pemF0aW9u LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxA dGxzLm15c2VsZi5zdWJqLm91LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYt dGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5zdWJqLm9yZ2FuaXphdGlvbmFsVW5pdE5hbWUs MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMubXlzZWxmLnN1Ymoub3JnYW5pemF0aW9uYWxfdW5pdF9uYW1lLDMsMCwweDAsKG51bGwpDQp0 bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5zdWJqLnVu aXQsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgp LEB0bHMubXlzZWxmLmlzc3VlciwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2 LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuaXNzdWVyLmNuLDMsMCwweDAsKG51bGwpDQp0 bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5pc3N1ZXIu Y29tbW9uTmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4 Ni9saW51eCksQHRscy5teXNlbGYuaXNzdWVyLmNvbW1vbl9uYW1lLDMsMCwweDAsKG51bGwpDQp0 bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5pc3N1ZXIu bmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQHRscy5teXNlbGYuaXNzdWVyLmwsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1k ZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLmlzc3Vlci5sb2NhbGl0eU5hbWUsMyww LDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMu bXlzZWxmLmlzc3Vlci5sb2NhbGl0eV9uYW1lLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAu OTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5pc3N1ZXIubG9jYWxpdHksMyww LDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMu bXlzZWxmLmlzc3Vlci5jLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxz IChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5pc3N1ZXIuY291bnRyeU5hbWUsMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLmlz c3Vlci5jb3VudHJ5X25hbWUsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10 bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLmlzc3Vlci5jb3VudHJ5LDMsMCwweDAsKG51bGwp DQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5pc3N1 ZXIuc3QsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGlu dXgpLEB0bHMubXlzZWxmLmlzc3Vlci5zdGF0ZU9yUHJvdmluY2VOYW1lLDMsMCwweDAsKG51bGwp DQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5pc3N1 ZXIuc3RhdGVfb3JfcHJvdmluY2VfbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuaXNzdWVyLnN0YXRlLDMsMCwweDAs KG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2Vs Zi5pc3N1ZXIubywzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4 Ni9saW51eCksQHRscy5teXNlbGYuaXNzdWVyLm9yZ2FuaXphdGlvbk5hbWUsMywwLDB4MCwobnVs bCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLmlz c3Vlci5vcmdhbml6YXRpb25fbmFtZSwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRl djY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuaXNzdWVyLm9yZ2FuaXphdGlvbiwzLDAs MHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5t eXNlbGYuaXNzdWVyLm91LDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxz IChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5pc3N1ZXIub3JnYW5pemF0aW9uYWxVbml0TmFtZSwz LDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRs cy5teXNlbGYuaXNzdWVyLm9yZ2FuaXphdGlvbmFsX3VuaXRfbmFtZSwzLDAsMHgwLChudWxsKQ0K dGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuaXNzdWVy LnVuaXQsMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGlu dXgpLEB0bHMubXlzZWxmLnZlcmlmaWVkLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTkt ZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5yZXZva2VkLDMsMCwweDAsKG51bGwp DQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5leHBp cmVkLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4 KSxAdGxzLm15c2VsZi5zZWxmX3NpZ25lZCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5 LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYudmVyc2lvbiwzLDAsMHgwLChudWxs KQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuc24s MywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEB0 bHMubXlzZWxmLnNlcmlhbE51bWJlciwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRl djY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuc2VyaWFsX251bWJlciwzLDAsMHgwLChu dWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYu bm90QmVmb3JlLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2 L2xpbnV4KSxAdGxzLm15c2VsZi5ub3RfYmVmb3JlLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAu MTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5ub3RBZnRlciwzLDAsMHgw LChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNl bGYubm90X2FmdGVyLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChp Mzg2L2xpbnV4KSxAdGxzLm15c2VsZi5lbWFpbCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEw Ljk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYuZW1haWxBZGRyZXNzLDMsMCww eDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15 c2VsZi5lbWFpbF9hZGRyZXNzLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYt dGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5ob3N0LDMsMCwweDAsKG51bGwpDQp0bHMsc2Vy IDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5ob3N0bmFtZSwzLDAs MHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5t eXNlbGYuZG5zLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2 L2xpbnV4KSxAdGxzLm15c2VsZi51cmksMywwLDB4MCwobnVsbCkNCnRscyxzZXIgMC4xMC45OS1k ZXY2Ni10bHMgKGkzODYvbGludXgpLEB0bHMubXlzZWxmLnVybCwzLDAsMHgwLChudWxsKQ0KdGxz LHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHRscy5teXNlbGYudXJuLDMsMCww eDAsKG51bGwpDQp0bHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15 c2VsZi5pcCwzLDAsMHgwLChudWxsKQ0KdGxzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9s aW51eCksQHRscy5teXNlbGYuSVBBZGRyZXNzLDMsMCwweDAsKG51bGwpDQp0bHMsc2VyIDAuMTAu OTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAdGxzLm15c2VsZi5pcF9hZGRyZXNzLDMsMCwweDAs KG51bGwpDQpuYXRoZWxwZXIsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAbmF0 aGVscGVyLnJld3JpdGVfY29udGFjdFslaV0sMywwLDB4MCwobnVsbCkNCm5hdGhlbHBlcixzZXIg MC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEBuYXRoZWxwZXIucmV3cml0ZV9jb250YWN0 WyVpXS5uYW1lYWRkciwzLDAsMHgwLChudWxsKQ0KZGJfb3BzLHNlciAwLjEwLjk5LWRldjY2LXRs cyAoaTM4Ni9saW51eCksQGRiLnF1ZXJ5WyVpXSwzLDAsMHgwLChudWxsKQ0KZGJfb3BzLHNlciAw LjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQGRiLnF1ZXJ5WyVpXS5uYW1lYWRkciwzLDAs MHgwLChudWxsKQ0KZGJfb3BzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQGRi LnF1ZXJ5WyVpXS51cmksMywwLDB4MCwobnVsbCkNCmRiX29wcyxzZXIgMC4xMC45OS1kZXY2Ni10 bHMgKGkzODYvbGludXgpLEBkYi5xdWVyeVslaV0uY291bnQsMywwLDB4MCwobnVsbCkNCmRiX29w cyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEBkYi5xdWVyeVslaV0uZmllbGRb JWldLDMsMCwweDAsKG51bGwpDQpkYl9vcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xp bnV4KSxAZGIucXVlcnlbJWldLmZpZWxkWyVpXS5uYW1lYWRkciwzLDAsMHgwLChudWxsKQ0KZGJf b3BzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQGRiLnF1ZXJ5WyVpXS5maWVs ZFslaV0udXJpLDMsMCwweDAsKG51bGwpDQpkYl9vcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChp Mzg2L2xpbnV4KSxAZGIucXVlcnlbJWldLnJvd1slaV0sMywwLDB4MCwobnVsbCkNCmRiX29wcyxz ZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEBkYi5xdWVyeVslaV0ucm93WyVpXS5m aWVsZFslaV0sMywwLDB4MCwobnVsbCkNCmRiX29wcyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkz ODYvbGludXgpLEBkYi5xdWVyeVslaV0ucm93WyVpXS5maWVsZFslaV0ubmFtZWFkZHIsMywwLDB4 MCwobnVsbCkNCmRiX29wcyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEBkYi5x dWVyeVslaV0ucm93WyVpXS5maWVsZFslaV0udXJpLDMsMCwweDAsKG51bGwpDQpkYl9vcHMsc2Vy IDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAZGIuZmV0Y2hbJWldLDMsMCwweDAsKG51 bGwpDQpkYl9vcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAZGIuZmV0Y2hb JWldLm5hbWVhZGRyLDMsMCwweDAsKG51bGwpDQpkYl9vcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxz IChpMzg2L2xpbnV4KSxAZGIuZmV0Y2hbJWldLnVyaSwzLDAsMHgwLChudWxsKQ0KZGJfb3BzLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQGRiLmZldGNoWyVpXS5jb3VudCwzLDAs MHgwLChudWxsKQ0KZGJfb3BzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQGRi LmZldGNoWyVpXS5yb3dfbm8sMywwLDB4MCwobnVsbCkNCmRiX29wcyxzZXIgMC4xMC45OS1kZXY2 Ni10bHMgKGkzODYvbGludXgpLEBkYi5mZXRjaFslaV0uZmllbGRbJWldLDMsMCwweDAsKG51bGwp DQpkYl9vcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAZGIuZmV0Y2hbJWld LmZpZWxkWyVpXS5uYW1lYWRkciwzLDAsMHgwLChudWxsKQ0KZGJfb3BzLHNlciAwLjEwLjk5LWRl djY2LXRscyAoaTM4Ni9saW51eCksQGRiLmZldGNoWyVpXS5maWVsZFslaV0udXJpLDMsMCwweDAs KG51bGwpDQpkYl9vcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAZGIuZmV0 Y2hbJWldLnJvd1slaV0sMywwLDB4MCwobnVsbCkNCmRiX29wcyxzZXIgMC4xMC45OS1kZXY2Ni10 bHMgKGkzODYvbGludXgpLEBkYi5mZXRjaFslaV0ucm93WyVpXS5maWVsZFslaV0sMywwLDB4MCwo bnVsbCkNCmRiX29wcyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEBkYi5mZXRj aFslaV0ucm93WyVpXS5maWVsZFslaV0ubmFtZWFkZHIsMywwLDB4MCwobnVsbCkNCmRiX29wcyxz ZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEBkYi5mZXRjaFslaV0ucm93WyVpXS5m aWVsZFslaV0udXJpLDMsMCwweDAsKG51bGwpDQp0aW1lcixzZXIgMC4xMC45OS1kZXY2Ni10bHMg KGkzODYvbGludXgpLEB0aW1lclslaV0uZW5hYmxlZCwzLDAsMHgwLChudWxsKQ0KeG1scnBjLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQHhtbHJwYy5tZXRob2QsMywwLDB4MCwo bnVsbCkNCmV2YWwsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAZXZhbC5wb3Bb JWldLDMsMCwweDAsKG51bGwpDQpldmFsLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQGV2YWwuZ2V0WyVpXSwzLDAsMHgwLChudWxsKQ0KZXZhbCxzZXIgMC4xMC45OS1kZXY2Ni10 bHMgKGkzODYvbGludXgpLEBldmFsLmdldFslaV0ubmFtZWFkZHIsMywwLDB4MCwobnVsbCkNCmV2 YWwsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAZXZhbC5nZXRbJWldLnVyaSwz LDAsMHgwLChudWxsKQ0KZXZhbCxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEBl dmFsLnJlZ1slc10sMywwLDB4MCwobnVsbCkNCmV2YWwsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChp Mzg2L2xpbnV4KSxAZXZhbC5yZWdbJXNdLm5hbWVhZGRyLDMsMCwweDAsKG51bGwpDQpldmFsLHNl ciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQGV2YWwucmVnWyVzXS51cmksMywwLDB4 MCwobnVsbCkNCmV2YWwsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAZXZhbC51 dWlkLDMsMCwweDAsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9s aW51eCksQGhmX3ZhbHVlLiVzLDMsMCwweDAsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRl djY2LXRscyAoaTM4Ni9saW51eCksQGhmX3ZhbHVlLiVzLnBhcmFtWyVzXSwzLDAsMHgwLChudWxs KQ0KdGV4dG9wcyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEBoZl92YWx1ZS4l cy5wWyVzXSwzLDAsMHgwLChudWxsKQ0KdGV4dG9wcyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkz ODYvbGludXgpLEBoZl92YWx1ZS4lcy51cmksMywwLDB4MCwobnVsbCkNCnRleHRvcHMsc2VyIDAu MTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAaGZfdmFsdWUuJXMudXJpLDMsMCwweDAsKG51 bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51eCksQGhmX3ZhbHVl LiVzLm5hbWUsMywwLDB4MCwobnVsbCkNCnRleHRvcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChp Mzg2L2xpbnV4KSxAaGZfdmFsdWUuJXMubmFtZWFkZHIsMywwLDB4MCwobnVsbCkNCnRleHRvcHMs c2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAaGZfdmFsdWUuJXMuJXMsMywwLDB4 MCwobnVsbCkNCnRleHRvcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAaGZf dmFsdWUuJXNbJWldLDMsMCwweDAsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY2LXRs cyAoaTM4Ni9saW51eCksQGhmX3ZhbHVlLiVzWyVpXS5wYXJhbVslc10sMywwLDB4MCwobnVsbCkN CnRleHRvcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAaGZfdmFsdWUuJXNb JWldLnBbJXNdLDMsMCwweDAsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQGhmX3ZhbHVlLiVzWyVpXS51cmksMywwLDB4MCwobnVsbCkNCnRleHRvcHMs c2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAaGZfdmFsdWUuJXNbJWldLnVyaSwz LDAsMHgwLChudWxsKQ0KdGV4dG9wcyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgp LEBoZl92YWx1ZS4lc1slaV0ubmFtZSwzLDAsMHgwLChudWxsKQ0KdGV4dG9wcyxzZXIgMC4xMC45 OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEBoZl92YWx1ZS4lc1slaV0ubmFtZWFkZHIsMywwLDB4 MCwobnVsbCkNCnRleHRvcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAaGZf dmFsdWUuJXNbJWldLiVzLDMsMCwweDAsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY2 LXRscyAoaTM4Ni9saW51eCksQGhmX3ZhbHVlX2V4aXN0c1slc10uJXMsMywwLDB4MCwobnVsbCkN CnRleHRvcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAaGZfdmFsdWUyLiVz LDMsMCwweDAsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQGhmX3ZhbHVlMi4lcy4lcywzLDAsMHgwLChudWxsKQ0KdGV4dG9wcyxzZXIgMC4xMC45OS1k ZXY2Ni10bHMgKGkzODYvbGludXgpLEBoZl92YWx1ZTIuJXMuJXMsMywwLDB4MCwobnVsbCkNCnRl eHRvcHMsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAaGZfdmFsdWUyLiVzLiVz LDMsMCwweDAsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY2LXRscyAoaTM4Ni9saW51 eCksQGhmX3ZhbHVlMi4lc1slaV0sMywwLDB4MCwobnVsbCkNCnRleHRvcHMsc2VyIDAuMTAuOTkt ZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAaGZfdmFsdWUyLiVzWyVpXS4lcywzLDAsMHgwLChudWxs KQ0KdGV4dG9wcyxzZXIgMC4xMC45OS1kZXY2Ni10bHMgKGkzODYvbGludXgpLEBoZl92YWx1ZTIu JXNbJWldLiVzLDMsMCwweDAsKG51bGwpDQp0ZXh0b3BzLHNlciAwLjEwLjk5LWRldjY2LXRscyAo aTM4Ni9saW51eCksQGhmX3ZhbHVlMi4lc1slaV0uJXMsMywwLDB4MCwobnVsbCkNCmNvcmUsc2Vy IDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBtZXRob2QsMywwLDB4MCwobnVsbCkNCmNvcmUs c2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBydXJpLDMsMCwweDAsKG51bGwpDQpjb3Jl LHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcnVyaS50eXBlLDMsMCwweDAsKG51bGwp DQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcnVyaS51c2VyLDMsMCwweDAs KG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcnVyaS5wd2QsMyww LDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBydXJpLmhv c3QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBy dXJpLnBvcnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGlu dXgpLEBydXJpLnBhcmFtcywzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAo aTM4Ni9saW51eCksQHJ1cmkucGFyYW1zWyVzXSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4x MC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHJ1cmkuaG9zdHBvcnQsMywwLDB4MCwobnVsbCkNCmNv cmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBkc3RfdXJpLDMsMCwweDAsKG51bGwp DQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAZHN0X3VyaS50eXBlLDMsMCww eDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAZHN0X3VyaS51 c2VyLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxA ZHN0X3VyaS5wd2QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYv bGludXgpLEBkc3RfdXJpLmhvc3QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2 NjYgKGkzODYvbGludXgpLEBkc3RfdXJpLnBvcnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAu MTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBkc3RfdXJpLnBhcmFtcywzLDAsMHgwLChudWxsKQ0K Y29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGRzdF91cmkucGFyYW1zWyVzXSwz LDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGRzdF91 cmkuaG9zdHBvcnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYv bGludXgpLEBuZXh0X2hvcCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAo aTM4Ni9saW51eCksQG5leHRfaG9wLnR5cGUsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAu OTktZGV2NjYgKGkzODYvbGludXgpLEBuZXh0X2hvcC51c2VyLDMsMCwweDAsKG51bGwpDQpjb3Jl LHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbmV4dF9ob3AucHdkLDMsMCwweDAsKG51 bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbmV4dF9ob3AuaG9zdCwz LDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQG5leHRf aG9wLnBvcnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGlu dXgpLEBuZXh0X2hvcC5wYXJhbXMsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2 NjYgKGkzODYvbGludXgpLEBuZXh0X2hvcC5wYXJhbXNbJXNdLDMsMCwweDAsKG51bGwpDQpjb3Jl LHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbmV4dF9ob3AuaG9zdHBvcnQsMywwLDB4 MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBmcm9tLDMsMCww eDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAZnJvbS51cmks MywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBmcm9t LnVyaS50eXBlLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xp bnV4KSxAZnJvbS51cmkudXNlciwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2 NiAoaTM4Ni9saW51eCksQGZyb20udXJpLnB3ZCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4x MC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGZyb20udXJpLmhvc3QsMywwLDB4MCwobnVsbCkNCmNv cmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBmcm9tLnVyaS5wb3J0LDMsMCwweDAs KG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAZnJvbS51cmkucGFy YW1zLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxA ZnJvbS51cmkucGFyYW1zWyVzXSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2 NiAoaTM4Ni9saW51eCksQGZyb20udXJpLmhvc3Rwb3J0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNl ciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAZnJvbS50YWcsMywwLDB4MCwobnVsbCkNCmNv cmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBmcm9tLm5hbWUsMywwLDB4MCwobnVs bCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBmcm9tLnBhcmFtc1slc10s MywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBmLDMs MCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAZi51cmks MywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBmLnVy aS50eXBlLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4 KSxAZi51cmkudXNlciwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4 Ni9saW51eCksQGYudXJpLnB3ZCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2 NiAoaTM4Ni9saW51eCksQGYudXJpLmhvc3QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAu OTktZGV2NjYgKGkzODYvbGludXgpLEBmLnVyaS5wb3J0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNl ciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAZi51cmkucGFyYW1zLDMsMCwweDAsKG51bGwp DQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAZi51cmkucGFyYW1zWyVzXSwz LDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGYudXJp Lmhvc3Rwb3J0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xp bnV4KSxAZi50YWcsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYv bGludXgpLEBmLm5hbWUsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkz ODYvbGludXgpLEBmLnBhcmFtc1slc10sMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTkt ZGV2NjYgKGkzODYvbGludXgpLEB0bywzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1k ZXY2NiAoaTM4Ni9saW51eCksQHRvLnVyaSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45 OS1kZXY2NiAoaTM4Ni9saW51eCksQHRvLnVyaS50eXBlLDMsMCwweDAsKG51bGwpDQpjb3JlLHNl ciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAdG8udXJpLnVzZXIsMywwLDB4MCwobnVsbCkN CmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEB0by51cmkucHdkLDMsMCwweDAs KG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAdG8udXJpLmhvc3Qs MywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEB0by51 cmkucG9ydCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51 eCksQHRvLnVyaS5wYXJhbXMsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYg KGkzODYvbGludXgpLEB0by51cmkucGFyYW1zWyVzXSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIg MC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHRvLnVyaS5ob3N0cG9ydCwzLDAsMHgwLChudWxs KQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHRvLnRhZywzLDAsMHgwLChu dWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHRvLm5hbWUsMywwLDB4 MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEB0by5wYXJhbXNb JXNdLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxA dCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHQu dXJpLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxA dC51cmkudHlwZSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9s aW51eCksQHQudXJpLnVzZXIsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYg KGkzODYvbGludXgpLEB0LnVyaS5wd2QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTkt ZGV2NjYgKGkzODYvbGludXgpLEB0LnVyaS5ob3N0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAw LjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAdC51cmkucG9ydCwzLDAsMHgwLChudWxsKQ0KY29y ZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHQudXJpLnBhcmFtcywzLDAsMHgwLChu dWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHQudXJpLnBhcmFtc1sl c10sMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEB0 LnVyaS5ob3N0cG9ydCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4 Ni9saW51eCksQHQudGFnLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChp Mzg2L2xpbnV4KSxAdC5uYW1lLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2 IChpMzg2L2xpbnV4KSxAdC5wYXJhbXNbJXNdLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEw Ljk5LWRldjY2IChpMzg2L2xpbnV4KSxAY29udGFjdCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIg MC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGNvbnRhY3QudXJpLDMsMCwweDAsKG51bGwpDQpj b3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAY29udGFjdC51cmkudHlwZSwzLDAs MHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGNvbnRhY3Qu dXJpLnVzZXIsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGlu dXgpLEBjb250YWN0LnVyaS5wd2QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2 NjYgKGkzODYvbGludXgpLEBjb250YWN0LnVyaS5ob3N0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNl ciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAY29udGFjdC51cmkucG9ydCwzLDAsMHgwLChu dWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGNvbnRhY3QudXJpLnBh cmFtcywzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCks QGNvbnRhY3QudXJpLnBhcmFtc1slc10sMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTkt ZGV2NjYgKGkzODYvbGludXgpLEBjb250YWN0LnVyaS5ob3N0cG9ydCwzLDAsMHgwLChudWxsKQ0K Y29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGNvbnRhY3QubmFtZSwzLDAsMHgw LChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGNvbnRhY3QucSwz LDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGNvbnRh Y3QuZXhwaXJlcywzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9s aW51eCksQGNvbnRhY3QubWV0aG9kLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRl djY2IChpMzg2L2xpbnV4KSxAY29udGFjdC5yZWNlaXZlZCwzLDAsMHgwLChudWxsKQ0KY29yZSxz ZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGNvbnRhY3QuaW5zdGFuY2UsMywwLDB4MCwo bnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBjb250YWN0LnBhcmFt c1slc10sMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgp LEBtLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxA bS51cmksMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgp LEBtLnVyaS50eXBlLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2 L2xpbnV4KSxAbS51cmkudXNlciwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2 NiAoaTM4Ni9saW51eCksQG0udXJpLnB3ZCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45 OS1kZXY2NiAoaTM4Ni9saW51eCksQG0udXJpLmhvc3QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2Vy IDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBtLnVyaS5wb3J0LDMsMCwweDAsKG51bGwpDQpj b3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbS51cmkucGFyYW1zLDMsMCwweDAs KG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbS51cmkucGFyYW1z WyVzXSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCks QG0udXJpLmhvc3Rwb3J0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChp Mzg2L2xpbnV4KSxAbS5uYW1lLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2 IChpMzg2L2xpbnV4KSxAbS5xLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2 IChpMzg2L2xpbnV4KSxAbS5leHBpcmVzLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5 LWRldjY2IChpMzg2L2xpbnV4KSxAbS5tZXRob2QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAu MTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBtLnJlY2VpdmVkLDMsMCwweDAsKG51bGwpDQpjb3Jl LHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbS5pbnN0YW5jZSwzLDAsMHgwLChudWxs KQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQG0ucGFyYW1zWyVzXSwzLDAs MHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHZpYSwzLDAs MHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHZpYS5uYW1l LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAdmlh LnZlcnNpb24sMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGlu dXgpLEB2aWEudHJhbnNwb3J0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2 IChpMzg2L2xpbnV4KSxAdmlhLmhvc3QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTkt ZGV2NjYgKGkzODYvbGludXgpLEB2aWEucG9ydCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4x MC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHZpYS5jb21tZW50LDMsMCwweDAsKG51bGwpDQpjb3Jl LHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAdmlhLmJyYW5jaCwzLDAsMHgwLChudWxs KQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHZpYS5yZWNlaXZlZCwzLDAs MHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHZpYS5ycG9y dCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHZp YS5pLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxA dmlhLmFsaWFzLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xp bnV4KSxAdmlhLnBhcmFtc1slc10sMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2 NjYgKGkzODYvbGludXgpLEB2aWFbJWldLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5 LWRldjY2IChpMzg2L2xpbnV4KSxAdmlhWyVpXS5uYW1lLDMsMCwweDAsKG51bGwpDQpjb3JlLHNl ciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAdmlhWyVpXS52ZXJzaW9uLDMsMCwweDAsKG51 bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAdmlhWyVpXS50cmFuc3Bv cnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEB2 aWFbJWldLmhvc3QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYv bGludXgpLEB2aWFbJWldLnBvcnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2 NjYgKGkzODYvbGludXgpLEB2aWFbJWldLmNvbW1lbnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2Vy IDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEB2aWFbJWldLmJyYW5jaCwzLDAsMHgwLChudWxs KQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHZpYVslaV0ucmVjZWl2ZWQs MywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEB2aWFb JWldLnJwb3J0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xp bnV4KSxAdmlhWyVpXS5pLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChp Mzg2L2xpbnV4KSxAdmlhWyVpXS5hbGlhcywzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45 OS1kZXY2NiAoaTM4Ni9saW51eCksQHZpYVslaV0ucGFyYW1zWyVzXSwzLDAsMHgwLChudWxsKQ0K Y29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHYsMywwLDB4MCwobnVsbCkNCmNv cmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEB2Lm5hbWUsMywwLDB4MCwobnVsbCkN CmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEB2LnZlcnNpb24sMywwLDB4MCwo bnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEB2LnRyYW5zcG9ydCwz LDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHYuaG9z dCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHYu cG9ydCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCks QHYuY29tbWVudCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9s aW51eCksQHYuYnJhbmNoLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChp Mzg2L2xpbnV4KSxAdi5yZWNlaXZlZCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1k ZXY2NiAoaTM4Ni9saW51eCksQHYucnBvcnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAu OTktZGV2NjYgKGkzODYvbGludXgpLEB2LmksMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAu OTktZGV2NjYgKGkzODYvbGludXgpLEB2LmFsaWFzLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAw LjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAdi5wYXJhbXNbJXNdLDMsMCwweDAsKG51bGwpDQpj b3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAdlslaV0sMywwLDB4MCwobnVsbCkN CmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEB2WyVpXS5uYW1lLDMsMCwweDAs KG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAdlslaV0udmVyc2lv biwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHZb JWldLnRyYW5zcG9ydCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4 Ni9saW51eCksQHZbJWldLmhvc3QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2 NjYgKGkzODYvbGludXgpLEB2WyVpXS5wb3J0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEw Ljk5LWRldjY2IChpMzg2L2xpbnV4KSxAdlslaV0uY29tbWVudCwzLDAsMHgwLChudWxsKQ0KY29y ZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHZbJWldLmJyYW5jaCwzLDAsMHgwLChu dWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHZbJWldLnJlY2VpdmVk LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAdlsl aV0ucnBvcnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGlu dXgpLEB2WyVpXS5pLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2 L2xpbnV4KSxAdlslaV0uYWxpYXMsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2 NjYgKGkzODYvbGludXgpLEB2WyVpXS5wYXJhbXNbJXNdLDMsMCwweDAsKG51bGwpDQpjb3JlLHNl ciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAZXZlbnQsMywwLDB4MCwobnVsbCkNCmNvcmUs c2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEByZWNvcmRfcm91dGUsMywwLDB4MCwobnVs bCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEByZWNvcmRfcm91dGUudXJp LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcmVj b3JkX3JvdXRlLnVyaS50eXBlLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2 IChpMzg2L2xpbnV4KSxAcmVjb3JkX3JvdXRlLnVyaS51c2VyLDMsMCwweDAsKG51bGwpDQpjb3Jl LHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcmVjb3JkX3JvdXRlLnVyaS5wd2QsMyww LDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEByZWNvcmRf cm91dGUudXJpLmhvc3QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkz ODYvbGludXgpLEByZWNvcmRfcm91dGUudXJpLnBvcnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2Vy IDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEByZWNvcmRfcm91dGUudXJpLnBhcmFtcywzLDAs MHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHJlY29yZF9y b3V0ZS51cmkucGFyYW1zWyVzXSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2 NiAoaTM4Ni9saW51eCksQHJlY29yZF9yb3V0ZS51cmkuaG9zdHBvcnQsMywwLDB4MCwobnVsbCkN CmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEByZWNvcmRfcm91dGUubmFtZSwz LDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHJlY29y ZF9yb3V0ZS5wYXJhbXNbJXNdLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2 IChpMzg2L2xpbnV4KSxAcnIsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYg KGkzODYvbGludXgpLEByci51cmksMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2 NjYgKGkzODYvbGludXgpLEByci51cmkudHlwZSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4x MC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHJyLnVyaS51c2VyLDMsMCwweDAsKG51bGwpDQpjb3Jl LHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcnIudXJpLnB3ZCwzLDAsMHgwLChudWxs KQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHJyLnVyaS5ob3N0LDMsMCww eDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcnIudXJpLnBv cnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBy ci51cmkucGFyYW1zLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2 L2xpbnV4KSxAcnIudXJpLnBhcmFtc1slc10sMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAu OTktZGV2NjYgKGkzODYvbGludXgpLEByci51cmkuaG9zdHBvcnQsMywwLDB4MCwobnVsbCkNCmNv cmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEByci5uYW1lLDMsMCwweDAsKG51bGwp DQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcnIucGFyYW1zWyVzXSwzLDAs MHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGNzZXEsMyww LDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBjc2VxLm51 bSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGNz ZXEubWV0aG9kLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xp bnV4KSxAbXNnLiVzLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2 L2xpbnV4KSxAbXNnLiVzLm5hbWVhZGRyLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5 LWRldjY2IChpMzg2L2xpbnV4KSxAbXNnLiVzLm5hbWVhZGRyLm5hbWUsMywwLDB4MCwobnVsbCkN CmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBtc2cuJXMubmFtZWFkZHIudXJp LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbXNn LiVzLm5hbWVhZGRyLnVyaS50eXBlLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRl djY2IChpMzg2L2xpbnV4KSxAbXNnLiVzLm5hbWVhZGRyLnVyaS51c2VyLDMsMCwweDAsKG51bGwp DQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbXNnLiVzLm5hbWVhZGRyLnVy aS5wd2QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgp LEBtc2cuJXMubmFtZWFkZHIudXJpLmhvc3QsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAu OTktZGV2NjYgKGkzODYvbGludXgpLEBtc2cuJXMubmFtZWFkZHIudXJpLnBvcnQsMywwLDB4MCwo bnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBtc2cuJXMubmFtZWFk ZHIudXJpLnBhcmFtcywzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4 Ni9saW51eCksQG1zZy4lcy5uYW1lYWRkci51cmkucGFyYW1zWyVzXSwzLDAsMHgwLChudWxsKQ0K Y29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQG1zZy4lcy5uYW1lYWRkci51cmku aG9zdHBvcnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGlu dXgpLEBtc2cuJXMubmFtZWFkZHIucGFyYW1zLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEw Ljk5LWRldjY2IChpMzg2L2xpbnV4KSxAbXNnLiVzLm5hbWVhZGRyLnBhcmFtc1slc10sMywwLDB4 MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBtc2cuJXMucGFy YW1zWyVzXSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51 eCksQG1zZy4lc1slaV0sMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkz ODYvbGludXgpLEBtc2cuJXNbJWldLm5hbWVhZGRyLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAw LjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbXNnLiVzWyVpXS5uYW1lYWRkci5uYW1lLDMsMCww eDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbXNnLiVzWyVp XS5uYW1lYWRkci51cmksMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkz ODYvbGludXgpLEBtc2cuJXNbJWldLm5hbWVhZGRyLnVyaS50eXBlLDMsMCwweDAsKG51bGwpDQpj b3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbXNnLiVzWyVpXS5uYW1lYWRkci51 cmkudXNlciwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51 eCksQG1zZy4lc1slaV0ubmFtZWFkZHIudXJpLnB3ZCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIg MC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQG1zZy4lc1slaV0ubmFtZWFkZHIudXJpLmhvc3Qs MywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBtc2cu JXNbJWldLm5hbWVhZGRyLnVyaS5wb3J0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5 LWRldjY2IChpMzg2L2xpbnV4KSxAbXNnLiVzWyVpXS5uYW1lYWRkci51cmkucGFyYW1zLDMsMCww eDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbXNnLiVzWyVp XS5uYW1lYWRkci51cmkucGFyYW1zWyVzXSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45 OS1kZXY2NiAoaTM4Ni9saW51eCksQG1zZy4lc1slaV0ubmFtZWFkZHIudXJpLmhvc3Rwb3J0LDMs MCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAbXNnLiVz WyVpXS5uYW1lYWRkci5wYXJhbXMsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2 NjYgKGkzODYvbGludXgpLEBtc2cuJXNbJWldLm5hbWVhZGRyLnBhcmFtc1slc10sMywwLDB4MCwo bnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBtc2cuJXNbJWldLnBh cmFtc1slc10sMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGlu dXgpLEBwcm94eV9hdXRob3JpemF0aW9uWyVzXSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4x MC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHByb3h5X2F1dGhvcml6YXRpb25bJXNdLnVzZXJuYW1l LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcHJv eHlfYXV0aG9yaXphdGlvblslc10udXNlcm5hbWUudXNlciwzLDAsMHgwLChudWxsKQ0KY29yZSxz ZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQHByb3h5X2F1dGhvcml6YXRpb25bJXNdLnVz ZXJuYW1lLmRvbWFpbiwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4 Ni9saW51eCksQHByb3h5X2F1dGhvcml6YXRpb25bJXNdLnJlYWxtLDMsMCwweDAsKG51bGwpDQpj b3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcHJveHlfYXV0aG9yaXphdGlvblsl c10ubm9uY2UsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGlu dXgpLEBwcm94eV9hdXRob3JpemF0aW9uWyVzXS51cmksMywwLDB4MCwobnVsbCkNCmNvcmUsc2Vy IDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBwcm94eV9hdXRob3JpemF0aW9uWyVzXS5jbm9u Y2UsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBw cm94eV9hdXRob3JpemF0aW9uWyVzXS5uYywzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45 OS1kZXY2NiAoaTM4Ni9saW51eCksQHByb3h5X2F1dGhvcml6YXRpb25bJXNdLnJlc3BvbnNlLDMs MCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcHJveHlf YXV0aG9yaXphdGlvblslc10ub3BhcXVlLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5 LWRldjY2IChpMzg2L2xpbnV4KSxAcHJveHlfYXV0aG9yaXphdGlvblslc10uYWxnb3JpdGhtLDMs MCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcHJveHlf YXV0aG9yaXphdGlvblslc10ucW9wLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRl djY2IChpMzg2L2xpbnV4KSxAYXV0aG9yaXphdGlvblslc10sMywwLDB4MCwobnVsbCkNCmNvcmUs c2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBhdXRob3JpemF0aW9uWyVzXS51c2VybmFt ZSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGF1 dGhvcml6YXRpb25bJXNdLnVzZXJuYW1lLnVzZXIsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAu MTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBhdXRob3JpemF0aW9uWyVzXS51c2VybmFtZS5kb21h aW4sMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBh dXRob3JpemF0aW9uWyVzXS5yZWFsbSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1k ZXY2NiAoaTM4Ni9saW51eCksQGF1dGhvcml6YXRpb25bJXNdLm5vbmNlLDMsMCwweDAsKG51bGwp DQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAYXV0aG9yaXphdGlvblslc10u dXJpLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxA YXV0aG9yaXphdGlvblslc10uY25vbmNlLDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5 LWRldjY2IChpMzg2L2xpbnV4KSxAYXV0aG9yaXphdGlvblslc10ubmMsMywwLDB4MCwobnVsbCkN CmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBhdXRob3JpemF0aW9uWyVzXS5y ZXNwb25zZSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51 eCksQGF1dGhvcml6YXRpb25bJXNdLm9wYXF1ZSwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4x MC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGF1dGhvcml6YXRpb25bJXNdLmFsZ29yaXRobSwzLDAs MHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGF1dGhvcml6 YXRpb25bJXNdLnFvcCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4 Ni9saW51eCksQHNyYy5pcCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAo aTM4Ni9saW51eCksQHNyYy5wb3J0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRl djY2IChpMzg2L2xpbnV4KSxAc3JjLmlwX3BvcnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAu MTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBkc3QuaXAsMywwLDB4MCwobnVsbCkNCmNvcmUsc2Vy IDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEBkc3QucG9ydCwzLDAsMHgwLChudWxsKQ0KY29y ZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51eCksQGRzdC5pcF9wb3J0LDMsMCwweDAsKG51 bGwpDQpjb3JlLHNlciAwLjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcmVjZWl2ZWQucHJvdG8s MywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYgKGkzODYvbGludXgpLEByZWNl aXZlZC5pcCwzLDAsMHgwLChudWxsKQ0KY29yZSxzZXIgMC4xMC45OS1kZXY2NiAoaTM4Ni9saW51 eCksQHJlY2VpdmVkLnBvcnQsMywwLDB4MCwobnVsbCkNCmNvcmUsc2VyIDAuMTAuOTktZGV2NjYg KGkzODYvbGludXgpLEByZWNlaXZlZC5pcF9wb3J0LDMsMCwweDAsKG51bGwpDQpjb3JlLHNlciAw LjEwLjk5LWRldjY2IChpMzg2L2xpbnV4KSxAcmVjZWl2ZWQucHJvdG9faXBfcG9ydCwzLDAsMHgw LChudWxsKQ0KcnIsc2VyIDAuMTAuOTktZGV2NjYtdGxzIChpMzg2L2xpbnV4KSxAcnIuZGlhbG9n X2Nvb2tpZSwzLDAsMHgwLChudWxsKQ0K --===============1918637398==-- From miconda@gmail.com Mon Aug 24 12:02:53 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 13:02:17 +0300 Message-ID: <4A926529.5030307@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0000484092==" --===============0000484092== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello everybody, during the last IRC devel meeting, we pinned end of summer to be the time to enter testing phase for the new major release - codenamed kamailio 3.0. There was quite a lot of brand new features, considering that most of devel effort was directed to integration. A try to collect new items is available at: http://sip-router.org/wiki/features/new-in-devel Of course, all ser features are available as well, resulting a large amount of new stuff in kamailio 3.0 vs kamailio 1.5.x. See: http://sip-router.org/benefits/ http://www.iptel.org/ser/features I propose to start the testing phase sometime next week. Meanwhile, let's see if something important was forgotten from kamailio core or tm. To my knowledge: - path support in tm - Andrei has it on his todo afaik - in a way or another, it must get in next release - drop compatibility - drop reply in reply_route - internally drop and exit are now differentiated by core, needs review and update of handling after running the routes - on my to-do Apart seas, all Kamailio modules are fully ugraded to new core - I started but lack of test env + busy summer resulted in delays - can be done during testing period, being just api updates. If you have discovered something else, let us know. Thanks, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============0000484092==-- From miconda@gmail.com Mon Aug 24 12:24:29 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Mon, 24 Aug 2009 13:24:26 +0300 Message-ID: <4A926A5A.9090504@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0010984835==" --===============0010984835== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks, I used awk to generate listing in dokuwiki: http://sip-router.org/wiki/cookbooks/selects/devel#raw_list Cheers, Daniel On 24.08.2009 11:56 Uhr, Jan Janak wrote: > Attached is the select list. > > Jan. > > On Thu, Aug 20, 2009 at 5:35 PM, Jan Janak wrote: > =20 >> On Thu, Aug 20, 2009 at 5:26 PM, Daniel-Constantin >> Mierla wrote: >> =20 >>> Thanks Jan, the tool sounds interesting, however, the file you attached d= oes >>> not include the selects ... or I overlooked something. >>> =20 >> You are right, I overlooked this. I must have another file with just >> selects then because I remember generating it, I'll have a look >> tomorrow and get back to you. >> >> Jan. >> >> =20 --=20 Daniel-Constantin Mierla * http://www.asipto.com/ --===============0010984835==-- From miconda@gmail.com Mon Aug 24 12:35:12 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] new PV class: $sel(name) Date: Mon, 24 Aug 2009 13:34:39 +0300 Message-ID: <4A926CBF.1010702@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2083093492==" --===============2083093492== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, there is a new PV class that provides access to SER select variables. A list with available selects can be found at: http://sip-router.org/wiki/cookbooks/selects/devel Therefore, all Kamailio modules relying on PV framework can get access to select values without any change. See example of usage from config at: http://sip-router.org/wiki/cookbooks/pseudo-variables/devel#selects Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============2083093492==-- From martin.hoffmann@telio.ch Mon Aug 24 12:38:01 2009 From: Martin Hoffmann To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Mon, 24 Aug 2009 12:37:10 +0200 Message-ID: <20090824103710.GA12773@mlap.hq.telio.no> In-Reply-To: <4A926A5A.9090504@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0537456206==" --===============0537456206== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla wrote: > Thanks, I used awk to generate listing in dokuwiki: > http://sip-router.org/wiki/cookbooks/selects/devel#raw_list How do we procede from there? Should we keep the page in some format that allows magically adding new selects from ser_objdump output or do we just take it as a starter and happily modify away? Regards, Martin, who consideres spending some time on it --===============0537456206== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC45IChHTlUv TGludXgpCgppRVlFQVJFQ0FBWUZBa3FTYlZZQUNna1FpZzYvc0VOTS9aeGkzUUNlT3FhSWJEMFhq ZVd3UWdHaHlLNHhVbGMrClMzNEFuM2w2TGtnZUNRREE3WjcweEYxc0Z1ZWErK3JVCj1oOHVlCi0t LS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============0537456206==-- From miconda@gmail.com Mon Aug 24 12:46:52 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Mon, 24 Aug 2009 13:46:19 +0300 Message-ID: <4A926F7B.2030105@gmail.com> In-Reply-To: <20090824103710.GA12773@mlap.hq.telio.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1071536444==" --===============1071536444== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Martin, On 24.08.2009 13:37 Uhr, Martin Hoffmann wrote: > Daniel-Constantin Mierla wrote: > >> Thanks, I used awk to generate listing in dokuwiki: >> http://sip-router.org/wiki/cookbooks/selects/devel#raw_list >> > > How do we procede from there? Should we keep the page in some format > that allows magically adding new selects from ser_objdump output or do > we just take it as a starter and happily modify away? > imo, would be good to have a read-only section where we can easily update from ser_objdump (or maybe a new dokuwiki page). It is why I wrote that adding details, examples, comments, a.s.o, should create a new entry in the section above: Selects Classes. Or, if developers commit to update the page once they add new selects, we can work directly on the list, merging the two sections. It is what we do in Kamailio side of PV/transformations - but there was no objdump tool for auto-generation, though. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============1071536444==-- From jh@tutpro.com Mon Aug 24 12:47:27 2009 From: jh@tutpro.com To: sr-dev@lists.kamailio.org Subject: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 13:47:10 +0300 Message-ID: <19090.28590.281902.881662@tutpro.com> In-Reply-To: <4A926529.5030307@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1616541936==" --===============1616541936== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla writes: > If you have discovered something else, let us know. well, just before your message i send a question to andrei about async (or delayed reply) support for t_uac_dlg. without that i'm not able to start using sip router, because having to use two xmlrpc management interfaces to manage one proxy is not acceptable to me. -- juha --===============1616541936==-- From ibc@aliax.net Mon Aug 24 12:49:38 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 12:49:07 +0200 Message-ID: In-Reply-To: <4A926529.5030307@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2096009034==" --===============2096009034== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 2009/8/24 Daniel-Constantin Mierla : > Hello everybody, > > during the last IRC devel meeting, we pinned end of summer to be the time to > enter testing phase for the new major release - codenamed kamailio 3.0. > > There was quite a lot of brand new features, considering that most of devel > effort was directed to integration. A try to collect new items is available > at: > > http://sip-router.org/wiki/features/new-in-devel Hi, I read: ----------------- script mode can be switched between ser compatible, kamailio compatible and max compatibility (compatible with both as much as possible), using #!SER #!KAMAILIO #!OPENSER #!ALL #!MAXCOMPAT ----------------- Is it a good approach? why not make it strict for a definitive syntax? (this will occur soon or late and when it occurs it will break config files with all these syntaxs). -- Iñaki Baz Castillo --===============2096009034==-- From miconda@gmail.com Mon Aug 24 12:52:52 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 13:52:16 +0300 Message-ID: <4A9270E0.6080905@gmail.com> In-Reply-To: <19090.28590.281902.881662@tutpro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1380200885==" --===============1380200885== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, On 24.08.2009 13:47 Uhr, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > If you have discovered something else, let us know. > > well, just before your message i send a question to andrei about async > (or delayed reply) support for t_uac_dlg. without that i'm not able to > start using sip router, because having to use two xmlrpc management > interfaces to manage one proxy is not acceptable to me. > that is a new features for RPC interface in ser. Probably Andrei will do it if he committed to, but don't take my answer on his behalf, my knowledge about RPC interface is now very broad right now. You can still use one interface though - MI is fully available and does (pseudo) async xmlrpc commands. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============1380200885==-- From miconda@gmail.com Mon Aug 24 12:54:10 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 13:53:36 +0300 Message-ID: <4A927130.3080503@gmail.com> In-Reply-To: <4A9270E0.6080905@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0045731681==" --===============0045731681== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 24.08.2009 13:52 Uhr, Daniel-Constantin Mierla wrote: > Hello, > > On 24.08.2009 13:47 Uhr, Juha Heinanen wrote: >> Daniel-Constantin Mierla writes: >> >> > If you have discovered something else, let us know. >> >> well, just before your message i send a question to andrei about async >> (or delayed reply) support for t_uac_dlg. without that i'm not able to >> start using sip router, because having to use two xmlrpc management >> interfaces to manage one proxy is not acceptable to me. >> > that is a new features for RPC interface in ser. Probably Andrei will > do it if he committed to, but don't take my answer on his behalf, my > knowledge about RPC interface > is now very broad right now. ^^^ is not very ... Daniel > > You can still use one interface though - MI is fully available and > does (pseudo) async xmlrpc commands. > > Cheers, > Daniel > -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============0045731681==-- From jh@tutpro.com Mon Aug 24 12:58:39 2009 From: jh@tutpro.com To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 13:58:22 +0300 Message-ID: <19090.29262.195063.958231@tutpro.com> In-Reply-To: <4A9270E0.6080905@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0138931544==" --===============0138931544== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla writes: > You can still use one interface though - MI is fully available and does > (pseudo) async xmlrpc commands. that is not true if you use modules from both s and k (like domain domain module, for example, that is much more advanced in s). besides, s xmlrpc interface is much better that k's, because it each call executes a config file route block, that allows (among other things) access control. -- juha --===============0138931544==-- From miconda@gmail.com Mon Aug 24 12:59:01 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 13:58:27 +0300 Message-ID: <4A927253.3050401@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1485034239==" --===============1485034239== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, On 24.08.2009 13:49 Uhr, I=C3=B1aki Baz Castillo wrote: > 2009/8/24 Daniel-Constantin Mierla : > =20 >> Hello everybody, >> >> during the last IRC devel meeting, we pinned end of summer to be the time = to >> enter testing phase for the new major release - codenamed kamailio 3.0. >> >> There was quite a lot of brand new features, considering that most of devel >> effort was directed to integration. A try to collect new items is available >> at: >> >> http://sip-router.org/wiki/features/new-in-devel >> =20 > > Hi, I read: > > ----------------- > script mode can be switched between ser compatible, kamailio > compatible and max compatibility (compatible with both as much as > possible), using > #!SER > #!KAMAILIO > #!OPENSER > #!ALL > #!MAXCOMPAT > ----------------- > > Is it a good approach? why not make it strict for a definitive syntax? > (this will occur soon or late and when it occurs it will break config > files with all these syntaxs). > =20 this mechanism was introduced in the early phase of integration to=20 provide support for eventual major conflicts. AFAIK we haven't run into=20 a deadlock requiring selecting a specific mode. The Kamailio PVs=20 overlapping in naming with SER AVPs was the most important case, solved=20 by looking up first PV and if not found assume is avp using SER syntax. Andrei can correct me if I overlooked something. Cheers, Daniel --=20 Daniel-Constantin Mierla * http://www.asipto.com/ --===============1485034239==-- From martin.hoffmann@telio.ch Mon Aug 24 13:02:30 2009 From: Martin Hoffmann To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Mon, 24 Aug 2009 13:01:40 +0200 Message-ID: <20090824110140.GE12773@mlap.hq.telio.no> In-Reply-To: <4A926F7B.2030105@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0673709937==" --===============0673709937== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla wrote: > > Or, if developers commit to update the page once they add new > selects, we can work directly on the list, merging the two sections. > It is what we do in Kamailio side of PV/transformations - but there > was no objdump tool for auto-generation, though. I think that would be nicer. How about this: I sit down and write a little script that takes the output from ser_objdump and either merges it accordingly or warns about missing selects. Regards, Martin --===============0673709937== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC45IChHTlUv TGludXgpCgppRVlFQVJFQ0FBWUZBa3FTY3hRQUNna1FpZzYvc0VOTS9aemF0Z0NnaGpYcTZBdGxL VlZIbHVUc3VzNWlkUHg2CnJBTUFuMDFQTGNOM0xMYndxRnY4NFhkY2FjQ0MyRG9DCj16SUJMCi0t LS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============0673709937==-- From miconda@gmail.com Mon Aug 24 13:08:35 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 14:08:01 +0300 Message-ID: <4A927491.5030600@gmail.com> In-Reply-To: <19090.29262.195063.958231@tutpro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1847083489==" --===============1847083489== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 24.08.2009 13:58 Uhr, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > You can still use one interface though - MI is fully available and does > > (pseudo) async xmlrpc commands. > > that is not true if you use modules from both s and k (like domain > domain module, for example, that is much more advanced in s). > ok, I see. Solutions: - stress Andrei and/or other RPC devels :-) - add missing/needed MI commands to s modules I am considering merging sl module -- seems to be one preventing using easy some modules from both sides. > besides, s xmlrpc interface is much better that k's, because it each > call executes a config file route block, that allows (among other things) > access control. > With this one I agree. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============1847083489==-- From abalashov@evaristesys.com Mon Aug 24 13:14:05 2009 From: Alex Balashov To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 07:14:11 -0400 Message-ID: <4A927603.8050209@evaristesys.com> In-Reply-To: <4A927491.5030600@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1350955424==" --===============1350955424== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Please be careful amidst all this to remember that this "integration" could be the undoing of the Kamailio/SR project, and may drive people to OpenSIPS. In the end, it is the users that matter. The sip-router.org documentation is already excessively complicated and difficult to understand for anyone who does not routinely work with both the K and S code. At this point, the documentation, while voluminous, is overwhelming and, in places, woefully incomplete, while in other places, I would say "exhaustively" (perhaps "exhaustingly") complete. All of this confusion - starting with the fundamental difference between K and SR, which nobody *I* know in the user community yet understands in any level of substance or detail - is starting to make OpenSIPS look very straightforward and self-evident. You don't want this. I also encounter the widespread perception from my customers that a lot of time has been spent on "fun" and "interesting" integration work, not on developing features or fixing bugs. I hope they're wrong. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 --===============1350955424==-- From miconda@gmail.com Mon Aug 24 13:15:24 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] are selects documented somewhere? Date: Mon, 24 Aug 2009 14:14:52 +0300 Message-ID: <4A92762C.808@gmail.com> In-Reply-To: <20090824110140.GE12773@mlap.hq.telio.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1584648870==" --===============1584648870== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 24.08.2009 14:01 Uhr, Martin Hoffmann wrote: > Daniel-Constantin Mierla wrote: > >> Or, if developers commit to update the page once they add new >> selects, we can work directly on the list, merging the two sections. >> It is what we do in Kamailio side of PV/transformations - but there >> was no objdump tool for auto-generation, though. >> > > I think that would be nicer. How about this: I sit down and write a > little script that takes the output from ser_objdump and either merges > it accordingly or warns about missing selects. > much better. Thanks, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============1584648870==-- From ibc@aliax.net Mon Aug 24 13:36:35 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 13:32:27 +0200 Message-ID: In-Reply-To: <4A927603.8050209@evaristesys.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1877648960==" --===============1877648960== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 2009/8/24 Alex Balashov : > Please be careful amidst all this to remember that this "integration" could > be the undoing of the Kamailio/SR project, and may drive people to OpenSIPS. >  In the end, it is the users that matter. > > The sip-router.org documentation is already excessively complicated and > difficult to understand for anyone who does not routinely work with both the > K and S code.  At this point, the documentation, while voluminous, is > overwhelming and, in places, woefully incomplete, while in other places, I > would say "exhaustively" (perhaps "exhaustingly") complete. > > All of this confusion - starting with the fundamental difference between K > and SR, which nobody *I* know in the user community yet understands in any > level of substance or detail - is starting to make OpenSIPS look very > straightforward and self-evident.  You don't want this. > > I also encounter the widespread perception from my customers that a lot of > time has been spent on "fun" and "interesting" integration work, not on > developing features or fixing bugs.  I hope they're wrong. I must agree with Alex. Sincerely I will wait until SR is really released to start with it. And with "really released" I mean: when both kamailio and SER concepts disapear entirely from SR (no more K/S-modules, K/S-functions, K/S-components, K/S-pseudovariables, no more compability features and so on). What I don't understand is the reasons to make current SR working with K and S features/modules compatibility. We don't need a SR working solution right now (since Kamailio and SER do exist), do we?. Wouldn't be better to spent devel time in porting the required K/S modules to SR instead of making them working as K/S modules in any way? Please, don't take me wrong, I just wonder what's the rush to have a SR working instead of having a real an independent SR release :) -- Iñaki Baz Castillo --===============1877648960==-- From miconda@gmail.com Mon Aug 24 13:43:29 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 14:43:24 +0300 Message-ID: <4A927CDC.9040302@gmail.com> In-Reply-To: <4A927603.8050209@evaristesys.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0870516830==" --===============0870516830== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, On 24.08.2009 14:14 Uhr, Alex Balashov wrote: > The sip-router.org documentation is already excessively complicated > and difficult to understand for anyone who does not routinely work > with both the K and S code. At this point, the documentation, while > voluminous, is overwhelming and, in places, woefully incomplete, can you point such places? > while in other places, I would say "exhaustively" (perhaps > "exhaustingly") complete. From K point of view, same documentation is available, the core, pv and transformations cookbooks are updated completely -- actually only core cookbook needed a major update since we had a lot of new parameters for dns, transport layers, etc... > > All of this confusion - starting with the fundamental difference > between K and SR, which nobody *I* know in the user community yet > understands in any level of substance or detail Kamailio is the same -- will be a new major release of the sip server everybody know so far -- new features in core plus some new modules, either new development (memcache) or imported from ser (iptrtproxy). To update from kamailio 1.5 to 3.0 you will need, as usual, some db structure updates (not much afaik - lcr module, maybe cr) and some updates to config file syntax (minimal as well for most of usage cases). Your questions can be rephrased as "what is the difference between linux and debian?". Debian is just a particular packaging of available linux applications. In similar way, Kamailio, is SR core plus selection of SR modules. Like in linux, where are application that overlap in functionality, and one is preferred over the others (e.g., MTA), in SR there are modules that overlap (e.g., auth) using a different concept/database structure and one is preferred to the other. > I also encounter the widespread perception from my customers that a > lot of time has been spent on "fun" I would have liked some fun, but there wasn't, not for me, very interesting perception I would say, maybe you can point me such cases. It was quite heavy work. The goal of trying to preserve max compatibility while not messing up a lot of code in core was achieved - the core impact was kept minimal, therefore inheriting stability from ser 2.0. Several modules took the load of extra features. > and "interesting" integration work, not on developing features or > fixing bugs. I hope they're wrong. What are the bugs staying unfixed? What are missing features not adopted? There was quite a lot of new development, including transport layer such as sctp, asyncronous message processing (t_suspend/t_continue which is functional), continuing with new modules (link provided in previous email). Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============0870516830==-- From abalashov@evaristesys.com Mon Aug 24 13:44:11 2009 From: Alex Balashov To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 07:44:21 -0400 Message-ID: <4A927D15.7010407@evaristesys.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0276621116==" --===============0276621116== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Iñaki Baz Castillo wrote: > What I don't understand is the reasons to make current SR working with > K and S features/modules compatibility. We don't need a SR working > solution right now (since Kamailio and SER do exist), do we?. Wouldn't > be better to spent devel time in porting the required K/S modules to > SR instead of making them working as K/S modules in any way? I think the idea is that SR is a common layer - sort of like a kernel - from which subsequent features are derived in both K and S. What this fails to explain in any way is what the intended applications of K vs. SR are from an end-user perspective. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 --===============0276621116==-- From jh@tutpro.com Mon Aug 24 13:46:32 2009 From: jh@tutpro.com To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 14:46:15 +0300 Message-ID: <19090.32135.480823.124439@tutpro.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0326793696==" --===============0326793696== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Iñaki Baz Castillo writes: > What I don't understand is the reasons to make current SR working with > K and S features/modules compatibility. We don't need a SR working > solution right now (since Kamailio and SER do exist), do we?. Wouldn't > be better to spent devel time in porting the required K/S modules to > SR instead of making them working as K/S modules in any way? this is exactly how i also like it to be and which was discussed a couple of months ago on the mailing list. i would have liked to have sip-router, not k or s version of it, but officially it didn't go that way. -- juha --===============0326793696==-- From abalashov@evaristesys.com Mon Aug 24 13:48:12 2009 From: Alex Balashov To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 07:48:21 -0400 Message-ID: <4A927E05.7070401@evaristesys.com> In-Reply-To: <4A927CDC.9040302@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1213061105==" --===============1213061105== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla wrote: > Hello, > > On 24.08.2009 14:14 Uhr, Alex Balashov wrote: >> The sip-router.org documentation is already excessively complicated >> and difficult to understand for anyone who does not routinely work >> with both the K and S code. At this point, the documentation, while >> voluminous, is overwhelming and, in places, woefully incomplete, > > can you point such places? Yes, I will review it and make a list. >> while in other places, I would say "exhaustively" (perhaps >> "exhaustingly") complete. > > From K point of view, same documentation is available, the core, pv and > transformations cookbooks are updated completely -- actually only core > cookbook needed a major update since we had a lot of new parameters for > dns, transport layers, etc... That's good to know. Half the problem is that people who don't know this scour all the documentation in an attempt to gain a holistic grasp of what the changes are, whether or not there are any. > Your questions can be rephrased as "what is the difference between linux > and debian?". Debian is just a particular packaging of available linux > applications. In similar way, Kamailio, is SR core plus selection of SR > modules. Like in linux, where are application that overlap in > functionality, and one is preferred over the others (e.g., MTA), in SR > there are modules that overlap (e.g., auth) using a different > concept/database structure and one is preferred to the other. I already understood this. The question is - why would one be preferred to the other, from a practical perspective? What are the substantive differences? >> I also encounter the widespread perception from my customers that a >> lot of time has been spent on "fun" > > I would have liked some fun, but there wasn't, not for me, very > interesting perception I would say, maybe you can point me such cases. > It was quite heavy work. The goal of trying to preserve max > compatibility while not messing up a lot of code in core was achieved - > the core impact was kept minimal, therefore inheriting stability from > ser 2.0. Several modules took the load of extra features. It's not my perception. >> and "interesting" integration work, not on developing features or >> fixing bugs. I hope they're wrong. > What are the bugs staying unfixed? What are missing features not > adopted? There was quite a lot of new development, including transport > layer such as sctp, asyncronous message processing (t_suspend/t_continue > which is functional), continuing with new modules (link provided in > previous email). As I said, not my perception, so I personally cannot answer any of that. I personally see a lot of new and interesting features and a fair bit of stability. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 --===============1213061105==-- From martin.hoffmann@telio.ch Mon Aug 24 13:52:10 2009 From: Martin Hoffmann To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 13:51:20 +0200 Message-ID: <20090824115120.GA1811@mlap.hq.telio.no> In-Reply-To: <4A927D15.7010407@evaristesys.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0477630633==" --===============0477630633== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Alex Balashov wrote: > > What this fails to explain in any way is what the intended > applications of K vs. SR are from an end-user perspective. There is quite some substantial differences between SER 2.x and Kamailio. However, they are at a level further up -- most importantly completely different database schemas. Thus it makes sense to merge the core, which is mostly compatible between SER and Kamailio, and make two different bundles that allow people coming from Kamailio to continue using their tested and proven configs and the same for people using SER. Eventually, the difference will go away, but for starters this really is the smartest way to get people to use SIP Router -- without them actually knowing it. Regards, Martin --===============0477630633== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC45IChHTlUv TGludXgpCgppRVlFQVJFQ0FBWUZBa3FTZnJnQUNna1FpZzYvc0VOTS9aelRid0NmZlVxZ2pJZUJt MjRxN2N5eHVlWW8vcUsvClFIMEFvSXIzQTU2eFFPclFwNmRmTlR6VVhqL0hUa3ZKCj10NkxBCi0t LS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============0477630633==-- From abalashov@evaristesys.com Mon Aug 24 13:54:20 2009 From: Alex Balashov To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 07:54:29 -0400 Message-ID: <4A927F75.3010707@evaristesys.com> In-Reply-To: <20090824115120.GA1811@mlap.hq.telio.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1387161536==" --===============1387161536== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Martin Hoffmann wrote: > Alex Balashov wrote: >> What this fails to explain in any way is what the intended >> applications of K vs. SR are from an end-user perspective. > > There is quite some substantial differences between SER 2.x and > Kamailio. However, they are at a level further up -- most importantly > completely different database schemas. Thus it makes sense to merge the > core, which is mostly compatible between SER and Kamailio, and make two > different bundles that allow people coming from Kamailio to continue > using their tested and proven configs and the same for people using SER. > > Eventually, the difference will go away, but for starters this really is > the smartest way to get people to use SIP Router -- without them > actually knowing it. Perhaps. But, building in a mandatory premise of (nontrivial) future change as part of "eventually, the difference will go away" is not attractive. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 --===============1387161536==-- From jh@tutpro.com Mon Aug 24 13:55:18 2009 From: jh@tutpro.com To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 14:54:59 +0300 Message-ID: <19090.32659.565550.421581@tutpro.com> In-Reply-To: <4A927CDC.9040302@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0189489940==" --===============0189489940== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla writes: > Kamailio is the same -- will be a new major release of the sip server > everybody know so far -- new features in core plus some new modules, > either new development (memcache) or imported from ser (iptrtproxy). To > update from kamailio 1.5 to 3.0 you will need, as usual, some db > structure updates (not much afaik - lcr module, maybe cr) and some > updates to config file syntax (minimal as well for most of usage > cases). how about kamctl? i don't find it in sip-router source. i understand that it is now replaced by serctl. if what you say in above would be true, there would still be also kamctl that is an important part of k. better if there would be just sip-router with srctl to control it. -- juha --===============0189489940==-- From miconda@gmail.com Mon Aug 24 14:05:41 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 15:05:34 +0300 Message-ID: <4A92820E.50301@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0134173300==" --===============0134173300== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 24.08.2009 14:32 Uhr, Iñaki Baz Castillo wrote: > I must agree with Alex. > Sincerely I will wait until SR is really released to start with it. > And with "really released" I mean: when both kamailio and SER concepts > disapear entirely from SR (no more K/S-modules, K/S-functions, > K/S-components, K/S-pseudovariables, no more compability features and > so on). > Well, this is not easy as you may think. Even easier from coding point of view, the management of any relevant project around the world has to take in consideration backward compatibility and easy upgrades. I am personally aware of companies using Kamailio with several millions of subscribers, using kamailio database schema. Also, I am aware of companies having more or less same level of subscriber base using SER database schema. All have additional tools for management, integration with third-party application, a.s.o. Do you think that saying "hey, you were the unlucky bastard because we are going to drop tomorrow the database schema you are using" is the solution? > What I don't understand is the reasons to make current SR working with > K and S features/modules compatibility. We don't need a SR working > solution right now (since Kamailio and SER do exist), do we? Maybe not you, but there are others. I am facing many troubles because of TCP (also TLS) layer in K which do not happen with SR core - asynchronous TCP helps a lot. I use memcache and plan to move all server to server communication to SCTP for reliability and HA. Using asynchronous processing (t_suspend/t_continue) I am able to get a very scalable routing and billing engine (prepaid) which is no way possible with other technologies. > . Wouldn't > be better to spent devel time in porting the required K/S modules to > SR instead of making them working as K/S modules in any way? > All (but seas) are ported. There is nothing else to port, just some overlapping (read conflicting) from functionality/database structure point of view. You can do your Inakilio SIP server using ser auth module and kamailio location/presence modules if that suits better. Kamailio has to provide to its users of version 1.5.x a new release on the same line of modules. Cheers, Daniel > Please, don't take me wrong, I just wonder what's the rush to have a > SR working instead of having a real an independent SR release :) > -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============0134173300==-- From miconda@gmail.com Mon Aug 24 14:08:13 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 15:07:40 +0300 Message-ID: <4A92828C.3050501@gmail.com> In-Reply-To: <19090.32659.565550.421581@tutpro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1132870211==" --===============1132870211== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 24.08.2009 14:54 Uhr, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > Kamailio is the same -- will be a new major release of the sip server > > everybody know so far -- new features in core plus some new modules, > > either new development (memcache) or imported from ser (iptrtproxy). To > > update from kamailio 1.5 to 3.0 you will need, as usual, some db > > structure updates (not much afaik - lcr module, maybe cr) and some > > updates to config file syntax (minimal as well for most of usage > > cases). > > how about kamctl? i don't find it in sip-router source. i understand > that it is now replaced by serctl. if what you say in above would be > true, there would still be also kamctl that is an important part of k. > kamctl is in sip-router, check tools directory. > better if there would be just sip-router with srctl to control it. > You are more than welcome to implement the srctl, I am going to contribute if I am able to and use it. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============1132870211==-- From abalashov@evaristesys.com Mon Aug 24 14:08:36 2009 From: Alex Balashov To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 08:08:39 -0400 Message-ID: <4A9282C7.5020101@evaristesys.com> In-Reply-To: <4A92820E.50301@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0880175868==" --===============0880175868== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla wrote: > I am personally aware of companies using Kamailio with several millions > of subscribers, using kamailio database schema. Also, I am aware of > companies having more or less same level of subscriber base using SER > database schema. All have additional tools for management, integration > with third-party application, a.s.o. Do you think that saying "hey, you > were the unlucky bastard because we are going to drop tomorrow the > database schema you are using" is the solution? That's true. We can say that there should be one unified code body all we want, but, at the very least we need to acknowledge that the problem is not nearly as simple as it looks on the surface. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 --===============0880175868==-- From jh@tutpro.com Mon Aug 24 14:14:49 2009 From: jh@tutpro.com To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 15:14:30 +0300 Message-ID: <19090.33830.476206.628891@tutpro.com> In-Reply-To: <4A92828C.3050501@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0128165686==" --===============0128165686== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla writes: > kamctl is in sip-router, check tools directory. ok, i looked at scripts dir where it used to be in k. > You are more than welcome to implement the srctl, I am going to > contribute if I am able to and use it. srctl sort of exists already, but is is called serctl. -- juha --===============0128165686==-- From miconda@gmail.com Mon Aug 24 14:55:08 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 15:54:31 +0300 Message-ID: <4A928D87.6030008@gmail.com> In-Reply-To: <4A9282C7.5020101@evaristesys.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0125818488==" --===============0125818488== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 24.08.2009 15:08 Uhr, Alex Balashov wrote: > Daniel-Constantin Mierla wrote: > >> I am personally aware of companies using Kamailio with several >> millions of subscribers, using kamailio database schema. Also, I am >> aware of companies having more or less same level of subscriber base >> using SER database schema. All have additional tools for management, >> integration with third-party application, a.s.o. Do you think that >> saying "hey, you were the unlucky bastard because we are going to >> drop tomorrow the database schema you are using" is the solution? > > That's true. > > We can say that there should be one unified code if you refer to merging "duplicated" modules, could not be a solution anyhow. In the past, there were some events generating hot discussions when trying to force/limit to one way of doing things. The preliminary discussions for sip router project concluded that there must be freedom of contributors with fair control of original developer. Core, tm are sensitive parts and so called "common layer" where any piece of code getting in is carefully reviewed. Otherwise, if there is a conflict in licensing, between developers of same piece of code, creating a new module/library is the way to go. This does not mean everyone can spin off new modules, but if the contribution is relevant, has support from community members, it must get in. I see no reason of having modules for same functionality (e.g., say authentication) as long as each such module has maintainers. Time should prove which is better and obsolete the others, but also, each could be more suitable for a particular case. Just as a different example, sqlops plus some scripting could obsolete most of db-connected modules - auth_db, alias_db, speeddial, uri_db, a.s.o, but doing so is not at all a good decision. > body all we want, but, at the very least we need to acknowledge that > the problem is not nearly as simple as it looks on the surface. > Nothing is simple :-) . Also, I admit that any integration work rises controversy, which may create some degree of confusion. But all discussions were constructive so far, nothing was dismissed and the way things blended so far proves the flexibility level we achieved: keep the core and tm small and stable, build around with modules and libraries so that the impact is minimal for those not using the stuff that just got in. From my point of view, integration went smooth, but with higher work volume that anticipated, since both projects really had a lot of new features (some better documented, some not). Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============0125818488==-- From ibc@aliax.net Mon Aug 24 14:57:52 2009 From: =?utf-8?q?I=C3=B1aki?= Baz Castillo To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 14:57:21 +0200 Message-ID: In-Reply-To: <4A92820E.50301@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0769135294==" --===============0769135294== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 2009/8/24 Daniel-Constantin Mierla : > I am personally aware of companies using Kamailio with several millions of > subscribers, using kamailio database schema. Also, I am aware of companies > having more or less same level of subscriber base using SER database schema. > All have additional tools for management, integration with third-party > application, a.s.o. Do you think that saying "hey, you were the unlucky > bastard because we are going to drop tomorrow the database schema you are > using" is the solution? That's right, but I don't expect that migration to SR is a priority for those companies already using OpenSER/Kamailio. For example, I know some companies still using OpenSer 1.2. However, it seems that the idea is that Kamailio/SER will use SR as core, but the fact is that SR core uses current Kamailio and SER modules/features as separate (modules_k, modules_s...). Wouldn't make sense to unify SR code instead of having it splited in K and S? AFAIK this is the idea for a future, but in the meanwhile I don't fully understand why SR requires to run right now as it is. >> What I don't understand is the reasons to make current SR working with >> K and S features/modules compatibility. We don't need a SR working >> solution right now (since Kamailio and SER do exist), do we? > > Maybe not you, but there are others. I am facing many troubles because of > TCP (also TLS) layer in K which do not happen with SR core - asynchronous > TCP helps a lot. Sure that's a good reason :) But again you are speaking about Kamailio using SR as core (new and improved TM module) while I meant SR code itself (which for now is a mostly separate mix between K and S code instead of an unified technology). > All (but seas) are ported. Perhaps I understand it wrongly, but IMHO the modules will be really ported when there is a unique MI interface for all of them (instead of having to use K MI for K modules and S MI for S modules), when there are just an unique class of pseudovariables (instead of having K and S pvs)... Regards. -- Iñaki Baz Castillo --===============0769135294==-- From miconda@gmail.com Mon Aug 24 14:58:12 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 15:57:57 +0300 Message-ID: <4A928E55.5080404@gmail.com> In-Reply-To: <19090.33830.476206.628891@tutpro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0676211473==" --===============0676211473== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 24.08.2009 15:14 Uhr, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > kamctl is in sip-router, check tools directory. > > ok, i looked at scripts dir where it used to be in k. > > > You are more than welcome to implement the srctl, I am going to > > contribute if I am able to and use it. > > srctl sort of exists already, but is is called serctl. > :-) -- ahh, yes, imo, srctl sort of exists already, but is called kamctl. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============0676211473==-- From jh@tutpro.com Mon Aug 24 15:05:40 2009 From: jh@tutpro.com To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 16:05:24 +0300 Message-ID: <19090.36884.426541.311620@tutpro.com> In-Reply-To: <4A928E55.5080404@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0661235890==" --===============0661235890== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla writes: > :-) -- ahh, yes, imo, srctl sort of exists already, but is called > kamctl. are you saying that one can control s modules with kamctl? i know that one can control both s and k modules with serctl (except for async t_uac_dlg). -- juha --===============0661235890==-- From miconda@gmail.com Mon Aug 24 15:24:59 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 16:24:55 +0300 Message-ID: <4A9294A7.8000500@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1911118052==" --===============1911118052== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 24.08.2009 15:57 Uhr, I=C3=B1aki Baz Castillo wrote: > 2009/8/24 Daniel-Constantin Mierla : > > =20 >> I am personally aware of companies using Kamailio with several millions of >> subscribers, using kamailio database schema. Also, I am aware of companies >> having more or less same level of subscriber base using SER database schem= a. >> All have additional tools for management, integration with third-party >> application, a.s.o. Do you think that saying "hey, you were the unlucky >> bastard because we are going to drop tomorrow the database schema you are >> using" is the solution? >> =20 > > That's right, but I don't expect that migration to SR is a priority > for those companies already using OpenSER/Kamailio. For example, I > know some companies still using OpenSer 1.2. > =20 yes, I do, even older, I have a ser 0.9.4 somewhere and no plan to=20 upgrade it. It has 1 year 4 months without restart. > However, it seems that the idea is that Kamailio/SER will use SR as > core, but the fact is that SR core uses current Kamailio and SER > modules/features as separate (modules_k, modules_s...). some modules were moved under "modules" directory. The ones that have=20 names overlapping and inter-dependencies are going to stay in separate=20 directories. > Wouldn't make > sense to unify SR code instead of having it splited in K and S? probably you misunderstood something. The code is unified, but SR has=20 support to hold modules in more than one directory. Now the structure is=20 based on origin (again, the reason is name overlapping), but in the=20 future could be: modules_presence modules_db IIRC, there are over 150 modules all together, so better structuring=20 might be necessary. > AFAIK > this is the idea for a future, but in the meanwhile I don't fully > understand why SR requires to run right now as it is. > > > =20 >>> What I don't understand is the reasons to make current SR working with >>> K and S features/modules compatibility. We don't need a SR working >>> solution right now (since Kamailio and SER do exist), do we? >>> =20 >> Maybe not you, but there are others. I am facing many troubles because of >> TCP (also TLS) layer in K which do not happen with SR core - asynchronous >> TCP helps a lot. >> =20 > > Sure that's a good reason :) > But again you are speaking about Kamailio using SR as core (new and > improved TM module) while I meant SR code itself (which for now is a > mostly separate mix between K and S code instead of an unified > technology). > =20 I don't get it. Maybe you can rephrase/detail what is=20 misleading/confusing you. The existence of 3 module directories?=20 Everything is unified, one source repository, one project, if you think=20 just to SR environment. >> All (but seas) are ported. >> =20 > > Perhaps I understand it wrongly, but IMHO the modules will be really > ported when there is a unique MI interface for all of them (instead of > having to use K MI for K modules and S MI for S modules), Using RPC interface gives access to MI commands -- so ser guys are the=20 first lucky :-). However, let's get back to the root: - there are modules implementing MI - there are modules implementing RPC interface - there are modules implementing none - there might be modules implementing both Where to position a module is just a matter of developers. Similar=20 choise is for regular expressions - use posix or pcre library -=20 database - use interface v1 or v2 (which has prepared statements=20 support) - and examples can continue. I see ability to choose a great=20 feature. > when there > are just an unique class of pseudovariables (instead of having K and S > pvs)... > =20 Here is only one: config file variables - how they are referred in mails=20 is a different story, to better indentify and reflex origin, but all can=20 be used in config file. Actually, the group referred K PVs have classes. Cheers, Daniel --=20 Daniel-Constantin Mierla * http://www.asipto.com/ --===============1911118052==-- From abalashov@evaristesys.com Mon Aug 24 15:29:17 2009 From: Alex Balashov To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 09:29:27 -0400 Message-ID: <4A9295B7.6080208@evaristesys.com> In-Reply-To: <4A928D87.6030008@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1397252146==" --===============1397252146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla wrote: > Just as a different example, sqlops plus some scripting could obsolete > most of db-connected modules - auth_db, alias_db, speeddial, uri_db, > a.s.o, but doing so is not at all a good decision. In the case of my implementations, I have to do this quite frequently because I do custom integration projects that incorporate specific providers' sometimes very esoteric business logic. The sqlops module was one of the best things to ever have happened to Kamailio, and I am very thankful for it. My understanding is that the argument for using a native DB-connected module boils down to the fact that most of these modules do some sort of in-memory caching and/or buffering of large data sets, and use data structures and search algorithms that are appropriate to the nature of that data. So, this results in much faster processing with less overhead and, of course, less database load. I try to use them whenever possible. But sometimes it is not, which is why I am very grateful for the thought that went into creating parameters like this: http://www.kamailio.org/docs/modules/1.5.x/auth.html#id2505013 -- Alex -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 --===============1397252146==-- From miconda@gmail.com Mon Aug 24 15:35:15 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 16:34:41 +0300 Message-ID: <4A9296F1.108@gmail.com> In-Reply-To: <19090.36884.426541.311620@tutpro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1987570616==" --===============1987570616== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 24.08.2009 16:05 Uhr, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > :-) -- ahh, yes, imo, srctl sort of exists already, but is called > > kamctl. > > are you saying that one can control s modules with kamctl? i know that > one can control both s and k modules with serctl (except for async > t_uac_dlg). > =20 i don't think serctl can add K users nor do other K management commands. serctl (actually I refer to sercmd since I have no idea about serctl)=20 does RPC commands and since I added the mi_rpc command you can invoke a=20 MI command via RPC. Never tried, but see: http://sip-router.org/docbook/sip-router/branch/master/modules_s/ctl/ctl.html= #fifo kamctl implements that kind of communication proto. Cheers, Daniel --=20 Daniel-Constantin Mierla * http://www.asipto.com/ --===============1987570616==-- From miconda@gmail.com Mon Aug 24 15:38:29 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 16:37:55 +0300 Message-ID: <4A9297B3.1020903@gmail.com> In-Reply-To: <4A9295B7.6080208@evaristesys.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1335980106==" --===============1335980106== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 24.08.2009 16:29 Uhr, Alex Balashov wrote: > Daniel-Constantin Mierla wrote: > >> Just as a different example, sqlops plus some scripting could >> obsolete most of db-connected modules - auth_db, alias_db, speeddial, >> uri_db, a.s.o, but doing so is not at all a good decision. > > In the case of my implementations, I have to do this quite frequently > because I do custom integration projects that incorporate specific > providers' sometimes very esoteric business logic. The sqlops module > was one of the best things to ever have happened to Kamailio, and I am > very thankful for it. > > My understanding is that the argument for using a native DB-connected > module boils down to the fact that most of these modules do some sort > of in-memory caching and/or buffering of large data sets, and use data > structures and search algorithms that are appropriate to the nature of > that data. So, this results in much faster processing with less > overhead and, of course, less database load. No, no caching for above mentioned modules. They simply hide a db query in most of the cases. They are supposed to deal with quite large volume of records where caching makes no sense. So you do not loose any performance by using sqlops. You can check with benchmark module. Cheers, Daniel > > I try to use them whenever possible. But sometimes it is not, which > is why I am very grateful for the thought that went into creating > parameters like this: > > http://www.kamailio.org/docs/modules/1.5.x/auth.html#id2505013 > > -- Alex > -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============1335980106==-- From abalashov@evaristesys.com Mon Aug 24 15:47:31 2009 From: Alex Balashov To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 09:47:41 -0400 Message-ID: <4A9299FD.3060900@evaristesys.com> In-Reply-To: <4A9297B3.1020903@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1380055587==" --===============1380055587== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Daniel-Constantin Mierla wrote: > No, no caching for above mentioned modules. They simply hide a db query > in most of the cases. They are supposed to deal with quite large volume > of records where caching makes no sense. So you do not loose any > performance by using sqlops. You can check with benchmark module. Well, maybe not the above-mentioned modules, but certainly some. Otherwise, why all the db_mode parameters? I am thinking here of: http://www.kamailio.org/docs/modules/1.5.x/dialog.html#id2491994 http://www.kamailio.org/docs/modules/1.5.x/carrierroute.html#id2511124 http://www.kamailio.org/docs/modules/1.5.x/usrloc.html#id2508613 Unless I am misunderstanding these parameters, it seems to me that there is some performance benefit to using a module with database backing versus beyond just a wrapper for the queries? -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 --===============1380055587==-- From miconda@gmail.com Mon Aug 24 15:54:30 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 16:53:56 +0300 Message-ID: <4A929B74.3020607@gmail.com> In-Reply-To: <4A9299FD.3060900@evaristesys.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1902541758==" --===============1902541758== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 24.08.2009 16:47 Uhr, Alex Balashov wrote: > Daniel-Constantin Mierla wrote: > >> No, no caching for above mentioned modules. They simply hide a db >> query in most of the cases. They are supposed to deal with quite >> large volume of records where caching makes no sense. So you do not >> loose any performance by using sqlops. You can check with benchmark >> module. > > Well, maybe not the above-mentioned modules, but certainly some. definitely, yes! Cheers, Daniel > Otherwise, why all the db_mode parameters? > > I am thinking here of: > > http://www.kamailio.org/docs/modules/1.5.x/dialog.html#id2491994 > http://www.kamailio.org/docs/modules/1.5.x/carrierroute.html#id2511124 > http://www.kamailio.org/docs/modules/1.5.x/usrloc.html#id2508613 > > Unless I am misunderstanding these parameters, it seems to me that > there is some performance benefit to using a module with database > backing versus beyond just a wrapper for the queries? > -- Daniel-Constantin Mierla * http://www.asipto.com/ --===============1902541758==-- From klaus.mailinglists@pernau.at Mon Aug 24 16:26:59 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 16:26:30 +0200 Message-ID: <4A92A316.8030407@pernau.at> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1700900272==" --===============1700900272== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I=C3=B1aki Baz Castillo schrieb: > 2009/8/24 Daniel-Constantin Mierla : >=20 >> I am personally aware of companies using Kamailio with several millions of >> subscribers, using kamailio database schema. Also, I am aware of companies >> having more or less same level of subscriber base using SER database schem= a. >> All have additional tools for management, integration with third-party >> application, a.s.o. Do you think that saying "hey, you were the unlucky >> bastard because we are going to drop tomorrow the database schema you are >> using" is the solution? >=20 > That's right, but I don't expect that migration to SR is a priority > for those companies already using OpenSER/Kamailio. For example, I > know some companies still using OpenSer 1.2. >=20 > However, it seems that the idea is that Kamailio/SER will use SR as > core, but the fact is that SR core uses current Kamailio and SER > modules/features as separate (modules_k, modules_s...). Wouldn't make > sense to unify SR code instead of having it splited in K and S?=20 I always is a matter of viewpoint (If A sits next to B, B also sits next=20 to A). Of course you could have it in 3 repositories: 1xSR, 1xser and=20 1xKamailio. But the decision was to use a single repository for easier=20 developing (e.g. core API changes require module changes too). So, at the moment SR is the common repository for Kamailio=20 (modules_k+modules+core) and ser (modules_s+modules+core). So, I think=20 the next Kamailio release (source ball) might have just modules_k and=20 modules. And ser does not need to distribute modules_k. However, if=20 somebody wants to make fine selection, modules_s and modules_k can be=20 mixed too. regards Klaus AFAIK > this is the idea for a future, but in the meanwhile I don't fully > understand why SR requires to run right now as it is. >=20 >=20 >>> What I don't understand is the reasons to make current SR working with >>> K and S features/modules compatibility. We don't need a SR working >>> solution right now (since Kamailio and SER do exist), do we? >> Maybe not you, but there are others. I am facing many troubles because of >> TCP (also TLS) layer in K which do not happen with SR core - asynchronous >> TCP helps a lot. >=20 > Sure that's a good reason :) > But again you are speaking about Kamailio using SR as core (new and > improved TM module) while I meant SR code itself (which for now is a > mostly separate mix between K and S code instead of an unified > technology). >=20 >=20 >> All (but seas) are ported. >=20 > Perhaps I understand it wrongly, but IMHO the modules will be really > ported when there is a unique MI interface for all of them (instead of > having to use K MI for K modules and S MI for S modules), when there > are just an unique class of pseudovariables (instead of having K and S > pvs)... >=20 >=20 > Regards. >=20 >=20 --===============1700900272==-- From admin@sip-router.org Mon Aug 24 17:01:30 2009 From: sip-router To: sr-dev@lists.kamailio.org Subject: [sr-dev] [tracker] Assignee added: TLS modul problem Date: Mon, 24 Aug 2009 17:01:28 +0200 Message-ID: <20090824150129.13646.844875011.swift@sip-router.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1733988067==" --===============1733988067== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#14 - TLS modul problem User who did this - Anonymous user () http://sip-router.org/tracker/index.php?do=3Ddetails&task_id=3D14 You are receiving this message because you have requested it from the Flyspra= y bugtracking system. If you did not expect this message or don't want to re= ceive mails in future, you can change your notification settings at the URL s= hown above. --===============1733988067==-- From admin@sip-router.org Mon Aug 24 17:01:30 2009 From: sip-router To: sr-dev@lists.kamailio.org Subject: [sr-dev] [tracker] Task opened: TLS modul problem Date: Mon, 24 Aug 2009 17:01:29 +0200 Message-ID: <20090824150129.13646.563251852.swift@sip-router.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0317473493==" --===============0317473493== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below.=20 User who did this - Anonymous user ()=20 Attached to Project - sip-router Summary - TLS modul problem Task Type - Bug Report Category - tls Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - Linux Severity - Critical Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - I am experiencing problem "Invalid connection state (bug in TCP cod= e)"in tls_server.c in function=20 static int tls_complete_init(struct tcp_connection* c) if (c->state =3D=3D S_CONN_ACCEPT) { dom =3D tls_lookup_cfg(cfg, TLS_DOMAIN_SRV, &c->rcv.dst_ip, c-= >rcv.dst_port); } else if (c->state =3D=3D S_CONN_CONNECT) { dom =3D tls_lookup_cfg(cfg, TLS_DOMAIN_CLI, &c->rcv.dst_ip, c-= >rcv.dst_port); } else { BUG("Invalid connection state (bug in TCP code)\n"); goto error; }=20 Incoming tls connection is working fine. The problem only occurs if a worker = received a new invite and want forward and open a new TLS connection by=20 int tls_h_blocking_write(struct tcp_connection *c, int fd, const char *= buf, unsigned int len) I am debugged with gdb and i catch that c->state is S_CONN_OK So it seems it TCP is already connected. My TCP config in ser.cfg #TLS enable_tls=3Dyes #TCP settings disable_tcp=3Dno=20 tcp_async=3Dno tcp_send_timeout=3D2 #tcp_accept_aliases=3Dyes # accepts the tcp alias via option (see NEWS) tcp_delayed_ack=3Dno tcp_fd_cache=3Dno =20 More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=3Ddetails&task_id=3D14 You are receiving this message because you have requested it from the Flyspra= y bugtracking system. If you did not expect this message or don't want to re= ceive mails in future, you can change your notification settings at the URL s= hown above. --===============0317473493==-- From misi@niif.hu Mon Aug 24 17:25:17 2009 From: =?utf-8?b?TcOJU1rDgVJPUyBNaWjDoWx5?= To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 17:25:09 +0200 Message-ID: <4A92B0D5.2030809@niif.hu> In-Reply-To: <4A92A316.8030407@pernau.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1644917193==" --===============1644917193== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Klaus Darilion wrote: > > > Iñaki Baz Castillo schrieb: >> 2009/8/24 Daniel-Constantin Mierla : >> >>> I am personally aware of companies using Kamailio with several >>> millions of >>> subscribers, using kamailio database schema. Also, I am aware of >>> companies >>> having more or less same level of subscriber base using SER database >>> schema. >>> All have additional tools for management, integration with third-party >>> application, a.s.o. Do you think that saying "hey, you were the unlucky >>> bastard because we are going to drop tomorrow the database schema >>> you are >>> using" is the solution? >> >> That's right, but I don't expect that migration to SR is a priority >> for those companies already using OpenSER/Kamailio. For example, I >> know some companies still using OpenSer 1.2. >> >> However, it seems that the idea is that Kamailio/SER will use SR as >> core, but the fact is that SR core uses current Kamailio and SER >> modules/features as separate (modules_k, modules_s...). Wouldn't make >> sense to unify SR code instead of having it splited in K and S? > > I always is a matter of viewpoint (If A sits next to B, B also sits > next to A). Of course you could have it in 3 repositories: 1xSR, 1xser > and 1xKamailio. But the decision was to use a single repository for > easier developing (e.g. core API changes require module changes too). > > So, at the moment SR is the common repository for Kamailio > (modules_k+modules+core) and ser (modules_s+modules+core). So, I think > the next Kamailio release (source ball) might have just modules_k and > modules. And ser does not need to distribute modules_k. However, if > somebody wants to make fine selection, modules_s and modules_k can be > mixed too. > Hi! I want only mention my experience. (I am pretty new using sip-router.) I tried to mix the modules but it didn't work for me. So I want some modules from modules_s (xlog,auth_identiy ...) and other from modules_p (presence etc.) But i have failed. :( I must choose from the two repository. I can't use it together. The key problem was that SL modul is not merged. Many modules depends on this modul. Misi > regards > Klaus > > > AFAIK >> this is the idea for a future, but in the meanwhile I don't fully >> understand why SR requires to run right now as it is. >> >> >>>> What I don't understand is the reasons to make current SR working with >>>> K and S features/modules compatibility. We don't need a SR working >>>> solution right now (since Kamailio and SER do exist), do we? >>> Maybe not you, but there are others. I am facing many troubles >>> because of >>> TCP (also TLS) layer in K which do not happen with SR core - >>> asynchronous >>> TCP helps a lot. >> >> Sure that's a good reason :) >> But again you are speaking about Kamailio using SR as core (new and >> improved TM module) while I meant SR code itself (which for now is a >> mostly separate mix between K and S code instead of an unified >> technology). >> >> >>> All (but seas) are ported. >> >> Perhaps I understand it wrongly, but IMHO the modules will be really >> ported when there is a unique MI interface for all of them (instead of >> having to use K MI for K modules and S MI for S modules), when there >> are just an unique class of pseudovariables (instead of having K and S >> pvs)... >> >> >> Regards. >> >> > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --===============1644917193==-- From klaus.mailinglists@pernau.at Mon Aug 24 17:38:39 2009 From: Klaus Darilion To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing Date: Mon, 24 Aug 2009 17:38:11 +0200 Message-ID: <4A92B3E3.1070404@pernau.at> In-Reply-To: <4A92B0D5.2030809@niif.hu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1426769278==" --===============1426769278== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MÉSZÁROS Mihály schrieb: > Klaus Darilion wrote: >> >> >> Iñaki Baz Castillo schrieb: >>> 2009/8/24 Daniel-Constantin Mierla : >>> >>>> I am personally aware of companies using Kamailio with several >>>> millions of >>>> subscribers, using kamailio database schema. Also, I am aware of >>>> companies >>>> having more or less same level of subscriber base using SER database >>>> schema. >>>> All have additional tools for management, integration with third-party >>>> application, a.s.o. Do you think that saying "hey, you were the unlucky >>>> bastard because we are going to drop tomorrow the database schema >>>> you are >>>> using" is the solution? >>> >>> That's right, but I don't expect that migration to SR is a priority >>> for those companies already using OpenSER/Kamailio. For example, I >>> know some companies still using OpenSer 1.2. >>> >>> However, it seems that the idea is that Kamailio/SER will use SR as >>> core, but the fact is that SR core uses current Kamailio and SER >>> modules/features as separate (modules_k, modules_s...). Wouldn't make >>> sense to unify SR code instead of having it splited in K and S? >> >> I always is a matter of viewpoint (If A sits next to B, B also sits >> next to A). Of course you could have it in 3 repositories: 1xSR, 1xser >> and 1xKamailio. But the decision was to use a single repository for >> easier developing (e.g. core API changes require module changes too). >> >> So, at the moment SR is the common repository for Kamailio >> (modules_k+modules+core) and ser (modules_s+modules+core). So, I think >> the next Kamailio release (source ball) might have just modules_k and >> modules. And ser does not need to distribute modules_k. However, if >> somebody wants to make fine selection, modules_s and modules_k can be >> mixed too. >> > Hi! > > I want only mention my experience. (I am pretty new using sip-router.) > I tried to mix the modules but it didn't work for me. > So I want some modules from modules_s (xlog,auth_identiy ...) and other > from modules_p (presence etc.) > But i have failed. :( > I must choose from the two repository. I can't use it together. > The key problem was that SL modul is not merged. Many modules depends on > this modul. Yes, that's true. That's why Daniel said he tries to merge the sl modules regards klaus --===============1426769278==-- From ramona@rosdev.ro Tue Aug 25 10:38:46 2009 From: Elena-Ramona Modroiu To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: rls: fixed supported header name Date: Tue, 25 Aug 2009 10:38:45 +0200 Message-ID: <20090825083845.C9F1AEF8072@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0204165845==" --===============0204165845== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: a3b0f700d10d0b310766a34ec6e7390455e5ba64 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3Da3b0f700d10d0b310766a34ec6e7390455e5ba64 Author: Elena-Ramona Modroiu Committer: Elena-Ramona Modroiu Date: Tue Aug 25 11:16:53 2009 +0300 rls: fixed supported header name - port of K #5908 --- modules_k/rls/subscribe.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules_k/rls/subscribe.c b/modules_k/rls/subscribe.c index eada0c6..7f1c365 100644 --- a/modules_k/rls/subscribe.c +++ b/modules_k/rls/subscribe.c @@ -476,7 +476,7 @@ int rls_handle_subscribe(struct sip_msg* msg, char* s1, c= har* s2) lock_release(&rls_table[hash_code].lock); } =20 -/*** verify if it contains the 'Support: eventlist' header +/*** verify if it contains the 'Supported: eventlist' header * and if not - reply with '421 (Extension Required)' */ =20 /* @@ -490,7 +490,7 @@ int rls_handle_subscribe(struct sip_msg* msg, char* s1, c= har* s2) hdr=3D msg->headers; while(hdr) { - if(cmp_hdrname_strzn(&hdr->name, "Support", 7)=3D=3D 0) + if(cmp_hdrname_strzn(&hdr->name, "Supported", 9)=3D=3D 0) break; hdr=3D hdr->next; } --===============0204165845==-- From ramona@rosdev.ro Tue Aug 25 10:38:46 2009 From: Elena-Ramona Modroiu To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: rls: memory leak fix Date: Tue, 25 Aug 2009 10:38:45 +0200 Message-ID: <20090825083845.E493EEF8064@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1727402019==" --===============1727402019== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: 778c4352f2cbbc572a001e7ef9f2bf18d453a302 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3D778c4352f2cbbc572a001e7ef9f2bf18d453a302 Author: Elena-Ramona Modroiu Committer: Elena-Ramona Modroiu Date: Tue Aug 25 11:36:59 2009 +0300 rls: memory leak fix - port of K #5909 --- modules_k/rls/notify.c | 19 +++++++++++-------- modules_k/rls/resource_notify.c | 34 +++++++++++++++++++--------------- modules_k/rls/subscribe.c | 25 ++++++++++++++++--------- 3 files changed, 46 insertions(+), 32 deletions(-) diff --git a/modules_k/rls/notify.c b/modules_k/rls/notify.c index eaefad1..9734d6c 100644 --- a/modules_k/rls/notify.c +++ b/modules_k/rls/notify.c @@ -216,13 +216,13 @@ int agg_body_sendn_update(str* rl_uri, char* boundary_s= tring, str* rlmi_body, =20 cid=3D generate_cid(rl_uri->s, rl_uri->len); =20 - len=3D 2*strlen(boundary_string)+ 4+ 102+ strlen(cid)+ 2+ rlmi_body->len+50; + len=3D 2*strlen(boundary_string)+4+102+strlen(cid)+2+rlmi_body->len+50; if(multipart_body) len+=3D multipart_body->len; =09 init_len=3D len; =20 - body.s=3D (char*)pkg_malloc(len* sizeof(char)); + body.s=3D (char*)pkg_malloc((len+1)* sizeof(char)); if(body.s=3D=3D NULL) { ERR_MEM(PKG_MEM_STR); @@ -469,6 +469,7 @@ str* constr_multipart_body(db1_res_t* result, char** cid_= array, db_val_t *row_vals; char* content_id=3D NULL; str body=3D {0, 0}; + str ctype=3D {0, 0}; int antet_len; str* multi_body=3D NULL; =09 @@ -489,6 +490,11 @@ str* constr_multipart_body(db1_res_t* result, char** cid= _array, if(row_vals[auth_state_col].val.int_val!=3D ACTIVE_STATE) continue; =09 + body.s=3D (char*)row_vals[pres_state_col].val.string_val; + body.len=3D strlen(body.s); + ctype.s =3D (char*)row_vals[content_type_col].val.string_val; + ctype.len =3D strlen(ctype.s); + if(length+ antet_len+ body.len+ 4 > size) { REALLOC_BUF @@ -505,13 +511,10 @@ str* constr_multipart_body(db1_res_t* result, char** ci= d_array, } =20 length+=3D sprintf(buf+ length, "Content-ID: <%s>\r\n",content_id); - length+=3D sprintf(buf+ length, "Content-Type: %s\r\n\r\n", - row_vals[content_type_col].val.string_val); + length+=3D sprintf(buf+ length, "Content-Type: %.*s\r\n\r\n", + ctype.len, ctype.s); =09 - body.s=3D (char*)row_vals[pres_state_col].val.string_val; - body.len=3D strlen(body.s); - - length+=3D sprintf(buf+length,"%s\r\n\r\n", body.s); + length+=3D sprintf(buf+length,"%.*s\r\n\r\n", body.len, body.s); } =20 if(length+ strlen( boundary_string)+ 7> size ) diff --git a/modules_k/rls/resource_notify.c b/modules_k/rls/resource_notify.c index 3afc2d7..ff9a037 100644 --- a/modules_k/rls/resource_notify.c +++ b/modules_k/rls/resource_notify.c @@ -406,9 +406,17 @@ done: goto error; }=09 =20 + pkg_free(res_id->s); + pkg_free(res_id); + return 1; =20 error: + if(res_id!=3DNULL) + { + pkg_free(res_id->s); + pkg_free(res_id); + } return -1; } /* callid, from_tag, to_tag parameters must be allocated */ @@ -563,11 +571,6 @@ void timer_send_notify(unsigned int ticks,void *param) goto error; } xmlFree(rlmi_cont.s); - if(buf_len) =09 - {=09 - pkg_free(buf); - buf=3D NULL; - } xmlFreeDoc(rlmi_doc); rlmi_doc=3D NULL; pkg_free(rl_uri); @@ -576,14 +579,16 @@ void timer_send_notify(unsigned int ticks,void *param) dialog=3D NULL; } =20 - if(prev_did=3D=3D NULL || strcmp(prev_did, curr_did)) /*if first or differ= ent*/ + /*if first or different*/ + if(prev_did=3D=3DNULL || strcmp(prev_did, curr_did)!=3D0) { /* search the subscription in rlsubs_table*/ =09 if( parse_rlsubs_did(curr_did, &callid, &from_tag, &to_tag)< 0) { LM_ERR("bad format for " "resource list Subscribe dialog indentifier(rlsubs did)\n"); - goto done; + prev_did =3D NULL; + continue; =20 } hash_code=3D core_hash(&callid, &to_tag, hash_size); @@ -598,6 +603,7 @@ void timer_send_notify(unsigned int ticks,void *param) callid.len, callid.s,from_tag.len,from_tag.s, to_tag.len,to_tag.s); lock_release(&rls_table[hash_code].lock); + prev_did =3D NULL; continue; } LM_DBG("Found rl-subs record in hash table\n"); @@ -634,8 +640,10 @@ void timer_send_notify(unsigned int ticks,void *param) rl_uri[dialog->pres_uri.len]=3D '\0'; =20 xmlNewProp(list_node, BAD_CAST "uri", BAD_CAST rl_uri); - xmlNewProp(list_node, BAD_CAST "xmlns", BAD_CAST "urn:ietf:params:xml:ns:= rlmi"); - xmlNewProp(list_node, BAD_CAST "version", BAD_CAST int2str(dialog->versio= n, &len)); + xmlNewProp(list_node, BAD_CAST "xmlns", + BAD_CAST "urn:ietf:params:xml:ns:rlmi"); + xmlNewProp(list_node, BAD_CAST "version", + BAD_CAST int2str(dialog->version, &len)); xmlNewProp(list_node, BAD_CAST "fullState", BAD_CAST "false"); =20 xmlDocSetRootElement(rlmi_doc, list_node); @@ -702,7 +710,8 @@ void timer_send_notify(unsigned int ticks,void *param) REALLOC_BUF } buf_len+=3D sprintf(buf+ buf_len, "--%s\r\n\r\n", bstr.s); - buf_len+=3D sprintf(buf+ buf_len, "Content-Transfer-Encoding: binary\r\n= "); + buf_len+=3D sprintf(buf+ buf_len, + "Content-Transfer-Encoding: binary\r\n"); buf_len+=3D sprintf(buf+ buf_len, "Content-ID: <%s>\r\n", cid); buf_len+=3D sprintf(buf+ buf_len, "Content-Type: %s\r\n\r\n", =20 row_vals[content_type_col].val.string_val); @@ -750,11 +759,6 @@ void timer_send_notify(unsigned int ticks,void *param) goto error; } xmlFree(rlmi_cont.s); - if(buf_len) =09 - {=09 - pkg_free(buf); - buf=3D NULL; - } pkg_free(rl_uri); rl_uri=3D NULL; pkg_free(dialog); diff --git a/modules_k/rls/subscribe.c b/modules_k/rls/subscribe.c index 7f1c365..bdf311f 100644 --- a/modules_k/rls/subscribe.c +++ b/modules_k/rls/subscribe.c @@ -688,6 +688,21 @@ int update_rlsubs( subs_t* subs, unsigned int hash_code) memcpy(subs->pres_uri.s, s->pres_uri.s, s->pres_uri.len); subs->pres_uri.len=3D s->pres_uri.len; =20 + if(s->record_route.s!=3DNULL && s->record_route.len>0) + { + subs->record_route.s =3D + (char*)pkg_malloc(s->record_route.len* sizeof(char)); + if(subs->record_route.s=3D=3DNULL) + { + ERR_MEM(PKG_MEM_STR); + } + memcpy(subs->record_route.s, s->record_route.s, s->record_route.len); + subs->record_route.len=3D s->record_route.len; + } + + subs->local_cseq=3D s->local_cseq; + subs->version=3D s->version; + if(subs->expires=3D=3D 0) { /* delete record from hash table */ @@ -710,15 +725,7 @@ int update_rlsubs( subs_t* subs, unsigned int hash_code) ps->next=3D s->next; shm_free(s); } - else - { - s->remote_cseq=3D subs->remote_cseq; - s->expires=3D subs->expires+ (int)time(NULL); - } =09 - subs->local_cseq=3D s->local_cseq; - subs->version=3D s->version; - lock_release(&rls_table[hash_code].lock); =20 return 0; @@ -745,7 +752,7 @@ int resource_subscriptions(subs_t* subs, xmlNodePtr rl_no= de) char* uri=3D NULL; subs_info_t s; str wuri=3D {0, 0}; - static char buf[64]; + static char buf[256]; str extra_headers; str did_str=3D {0, 0}; =09 --===============1727402019==-- From miconda@gmail.com Tue Aug 25 18:41:54 2009 From: Daniel-Constantin Mierla To: sr-dev@lists.kamailio.org Subject: [sr-dev] git:master: core: support for include file in cfg Date: Tue, 25 Aug 2009 18:41:52 +0200 Message-ID: <20090825164153.0130AEF8070@rimmer> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0898984698==" --===============0898984698== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Module: sip-router Branch: master Commit: d20565193c1176312a29d75710d494707abdf6a5 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=3Dcommit;h= =3Dd20565193c1176312a29d75710d494707abdf6a5 Author: Daniel-Constantin Mierla Committer: Daniel-Constantin Mierla Date: Tue Aug 25 19:27:01 2009 +0300 core: support for include file in cfg - syntax: include path/to/file - example: include checks.cfg - path can be absolute or relative - if path is relative: - first attempt is to open the file relative to current directory - second attempt is to open the file relative to the directory of the file including it - if include file fails, then print error and exit - cfg syntax error messages print file name - there is no restriction where 'include' can be used, can have global parameters, module configs or entire/parts of route blocks --- cfg.lex | 159 ++++++++++++++++++++++++++++++++++++++++++++++++++++++= +- cfg.y | 29 ++++++----- route_struct.h | 1 + 3 files changed, 174 insertions(+), 15 deletions(-) diff --git a/cfg.lex b/cfg.lex index ebe2b6d..079613d 100644 --- a/cfg.lex +++ b/cfg.lex @@ -122,6 +122,7 @@ int column=3D1; int startcolumn=3D1; int startline=3D1; + char *finame =3D 0; static int ign_lines=3D0; static int ign_columns=3D0; char* yy_number_str=3D0; /* str correspondent for the current NUMBER token = */ @@ -132,12 +133,30 @@ static void count_more(); static void count_ignore(); =20 + #define MAX_INCLUDE_DEPTH 10 + static struct sr_yy_state { + YY_BUFFER_STATE state; + int line; + int column; + int startcolumn; + int startline; + char *finame; + } include_stack[MAX_INCLUDE_DEPTH]; + static int include_stack_ptr =3D 0; + + static int sr_push_yy_state(char *fin); + static int sr_pop_yy_state(); + + static struct sr_yy_fname { + char *fname; + struct sr_yy_fname *next; + } *sr_yy_fname_list =3D 0; =20 %} =20 /* start conditions */ %x STRING1 STRING2 STR_BETWEEN COMMENT COMMENT_LN ATTR SELECT AVP_PVAR PVAR_= P=20 -%x PVARID +%x PVARID INCL =20 /* config script types : #!SER or #!KAMAILIO or #!MAX_COMPAT */ SER_CFG SER @@ -201,6 +220,8 @@ CASE "case" DEFAULT "default" WHILE "while" =20 +INCLUDE "include" + /*ACTION LVALUES*/ URIHOST "uri:host" URIPORT "uri:port" @@ -556,6 +577,8 @@ EAT_ABLE [\ \t\b\r] {DEFAULT} { count(); yylval.strval=3Dyytext; return DEFAULT; } {WHILE} { count(); yylval.strval=3Dyytext; return WHILE; } =20 +{INCLUDE} { BEGIN(INCL); } + {URIHOST} { count(); yylval.strval=3Dyytext; return URIHOST; } {URIPORT} { count(); yylval.strval=3Dyytext; return URIPORT; } =20 @@ -1097,6 +1120,13 @@ EAT_ABLE [\ \t\b\r] =20