From nobody Tue Nov 10 12:33:38 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FFB1B3F0F for ; Tue, 10 Nov 2015 12:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl8XUjzj9t22 for ; Tue, 10 Nov 2015 12:33:37 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190B71B3F0E for ; Tue, 10 Nov 2015 12:33:36 -0800 (PST) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-11v.sys.comcast.net with comcast id fwZV1r00C5Geu2801wZc15; Tue, 10 Nov 2015 20:33:36 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-20v.sys.comcast.net with comcast id fwZb1r0081nMCLR01wZb07; Tue, 10 Nov 2015 20:33:36 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id tAAKXY3v025089; Tue, 10 Nov 2015 15:33:34 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id tAAKXYMf025082; Tue, 10 Nov 2015 15:33:34 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-Reply-To: <5624FFC2.1030708@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 10 Nov 2015 15:33:34 -0500 Message-ID: <87oaf1oaqp.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1447187616; bh=esmD9w16fOB4SVy/ECR/81JisIOL98ZX+X/7NPQRvLk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=HTgNfRPBLHdI96Z5jxe19IR7wpgTizovtCKu0vxPhLhxgJc9BnpYehuJKoVjhcj6M EEpy58C2S2YWHWBkPhxqkEh6mMn1yNt4rFGwVmGk4NSzWNxYTM0xXlV6Te44uJkpqO 5xB+E6NIiv/gVaNG92P7Xk9YlYRxhWgRNpzDtbTRFj5o6L5F3mQ9DHDNuob/cGAsFV sUyIwoGFZPodvCHVcG1/2pSM9Ojq3ieOQFHFRaYO7wrDbxw4wol972bfc6sCvXPTLv DNzhes4uJBURn1LxOOv0YKrPnJ6MaiEXR0wuAD1SZ+bmn+1ADZNQxQc7OAkUa2vbLT la7BCmDGMzfXw== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Requesting assist with expert review of media feature tag X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 20:33:38 -0000 Paul Kyzivat writes: > I have a recent request that concerns me. I am inclined to reject it, > but the decision is subjective, so I would like to have some discussion > on it first. > > The request comes from 3gpp - it has had no action in ietf. It is for > the media feature tag g.3gpp.nw-init-ussi, with semantics defined in > 3GPP TS 24.390 ("Unstructured Supplementary Service Data (USSD) using IP > Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3") > - a new mechanism is introduced for passing alert indications, rather > than reusing the defined mechanism of Alert-Info. (RFC3261 and RFC7462) I think you're right here. The alertPattern values that 24.390 uses (which are defined in 29.002) could be straightforwardly mapped into a set of 8 alert URNs (in two categories). Section 4.5.5.1 of 24.390 warns: The USSI AS should not include an Alert-Info header field into the initial INVITE request. ... Information provided in the Alert-Info header field can be in conflict with the content of the element of the application/vnd.3gpp.ussd+xml MIME body of the initial INVITE request. But that sort of problem already exists; In an INVITE the element in the body must match the user part of the request-URI. > - it establishes a media-less INVITE dialog, for the purpose of > exchanging messages in the signaling, primarily using INFO. IMO this is > inappropriate, for the same reason session-mode messaging via MESSAGE > was rejected, in favor of MSRP. As I understand the service being > provided, it is a specialized application of session mode instant messaging. This is a messier question, IMHO. As a matter of principle, you're right, of course. But the additional protocol machinery needed to set up an MSRP connection is sort of burdensome, and the IMS infrastructure might not have facilities for end-to-end TCP connections. It's possible that using MSRP would require many of the B2BUAs in the IMS architecture to implement MSRP relays. Dale From nobody Thu Nov 12 13:58:32 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C261B37F1 for ; Thu, 12 Nov 2015 13:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKcLSDwT7g3A for ; Thu, 12 Nov 2015 13:58:30 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767661B37F0 for ; Thu, 12 Nov 2015 13:58:30 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-08v.sys.comcast.net with comcast id glxm1r0034ueUHc01lyVQG; Thu, 12 Nov 2015 21:58:29 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-03v.sys.comcast.net with comcast id glyU1r0041nMCLR01lyUQg; Thu, 12 Nov 2015 21:58:29 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id tACLwRgR018051; Thu, 12 Nov 2015 16:58:27 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id tACLwRs0018048; Thu, 12 Nov 2015 16:58:27 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B24FF4@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 12 Nov 2015 16:58:27 -0500 Message-ID: <87y4e2lw1o.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1447365509; bh=xf4ntzOA/SdwxPBhY/X5xCOvWBdCs+6JN+g9cMQvlMU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=eZPbX8ovGc4CaSRahuB65BcA5HaoOZppuqFHYzA170CmgWGs7xLr8pefGxKy0Shii rrmsriLRNhyCF9wlqeUFucZl0rwXhc2MCcw5OJcH8TfeGTV2rzYxNl0sz/PWcfIQBJ SDGi5uQsRiM9MfhoIXZ6IngpVFlLG2mDxdKsYxWXLMa/z1e0SCoZB76tMdYrXkW7Rk 5NcHyN62gZQUXuMPvyQ8I8aPqysJrCC81LXzlqROH1VAfm+AgcN3yrOuwurOXtFYRE gcP5W0lZxeUADZT3GAyxszS0XxOmj1p9GIE8J68Ya1I2gOXvIn3LNq1whPDPzJOE8v 0SuNTnE7p2V7g== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] 491 for non-INVITE/UPDATE/PRACK X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 21:58:31 -0000 Christer Holmberg writes: > The case is the following (high-level, as I am not aware of the details): > > 1. An application server sends a re-INVITE, with an updated offer, to a UA > 2. When the UA receives the re-INVITE, it sends a SUBSCRIBE for an > event package (conference, afaik) to the application server. > 3. The application server receives the SUBSCRIBE before it receives > the response to the re-INVITE, so it rejects the SUBSCRIBE with > 491. It wants to get the response to the re-INVITE before it accepts > the SUBSCRIBE (exactly why I don't know). It seems to me that 491 is not a good solution to this problem. Compare to the situation where the application server received the SUBSCRIBE if it hadn't sent the re-INVITE. Presumably the AS would respond with 404, 489, or some such. Presumably that's what the AS should respond to in this race condition, as the AS isn't yet ready to provide notifications for this address/event combination. As Robert says, why can't the AS accept the subscription in some sort of inchoate state until it receives the 200? But more to the point, what is the specification of when the UA can subscribe to that event from the AS? Either the UA is allowed to subscribe as soon as the re-INVITE is sent (in which case, the AS should accept the subscription), or the UA is not allowed to subscribe until the AS changes state (in which case, the UA should wait until it receives the ACK). Dale From nobody Thu Nov 12 18:25:00 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8977A1B3ED9 for ; Thu, 12 Nov 2015 18:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPUzwaY6CbRl for ; Thu, 12 Nov 2015 18:24:57 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2161B3ED4 for ; Thu, 12 Nov 2015 18:24:56 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-05v.sys.comcast.net with comcast id gqQe1r0042Fh1PH01qQwjV; Fri, 13 Nov 2015 02:24:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with comcast id gqQv1r00P3KdFy101qQvF5; Fri, 13 Nov 2015 02:24:56 +0000 To: "Dale R. Worley" , Christer Holmberg References: <87y4e2lw1o.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <564549F6.6000108@alum.mit.edu> Date: Thu, 12 Nov 2015 21:24:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <87y4e2lw1o.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1447381496; bh=6fnVX0GDrQ7gaTbxkpn2RMgDb0H61/ybnXreVGWIL3U=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BdJbZB3+ha6OpDrZvL8wNGn+JtX5P3D9znLM+C1xRFyuJtpisbFlzV902FKQPapQx ZmIMgXiq0C0EwKIZjiEQhu8eycUqg+umSxRyGvZ+rn5WbCRzvHe6mgosoc01F0Zfai BzwEbPUESndfRhLXv+d1LBGR28JO3D4x4YqAx5ecS1WTXRn/SYXrTf09nop6qbf0e1 L7M6JcqhxZE0F2CAFWH2Whj+EKtwnGoGXitTYrqKbhCYMFErmtyK2LhaFIFNOjP3se izJ0nxfw01mdRpzzfTrF2GykZd4cWXdqI1bSjfUrFt0aorPxI8+C4DGs0a5yG1j1Ic BgoO5dH1vmdog== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] 491 for non-INVITE/UPDATE/PRACK X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 02:24:58 -0000 On 11/12/15 4:58 PM, Dale R. Worley wrote: > Christer Holmberg writes: >> The case is the following (high-level, as I am not aware of the details): >> >> 1. An application server sends a re-INVITE, with an updated offer, to a UA >> 2. When the UA receives the re-INVITE, it sends a SUBSCRIBE for an >> event package (conference, afaik) to the application server. Is this an in-dialog SUBSCRIBE, or out-of-dialog? Is the UA planning to wait for a response to the subscription before responding to the re-INVITE? >> 3. The application server receives the SUBSCRIBE before it receives >> the response to the re-INVITE, so it rejects the SUBSCRIBE with >> 491. It wants to get the response to the re-INVITE before it accepts >> the SUBSCRIBE (exactly why I don't know). This would be easier to follow if we knew what event package this was, so we could understand the dependency. I'm inclined to think such a dependency should not be imposed. > It seems to me that 491 is not a good solution to this problem. > > Compare to the situation where the application server received the > SUBSCRIBE if it hadn't sent the re-INVITE. Or, if it received the subscribe out-of-dialog. > Presumably the AS would > respond with 404, 489, or some such. Again this may be about in- or out-of- dialog. > Presumably that's what the AS > should respond to in this race condition, as the AS isn't yet ready to > provide notifications for this address/event combination. I don't know about that. I might buy it if this was happening on the initial invite. But it is less believable for re-invite. What possible state can the re-invite be establishing that must be waited for? I'm inclined to guess that the server simply can't handle two concurrent transactions on the same dialog. *That* is a bug, especially if it is trying to manage two dialog usages in one dialog. Thanks, Paul > As Robert says, why can't the AS accept the subscription in some sort of > inchoate state until it receives the 200? > > But more to the point, what is the specification of when the UA can > subscribe to that event from the AS? Either the UA is allowed to > subscribe as soon as the re-INVITE is sent (in which case, the AS should > accept the subscription), or the UA is not allowed to subscribe until > the AS changes state (in which case, the UA should wait until it > receives the ACK). > > Dale > From nobody Mon Nov 30 23:00:39 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386821A8757 for ; Mon, 30 Nov 2015 23:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bm5TvkDhMjDZ for ; Mon, 30 Nov 2015 23:00:37 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826FE1A8754 for ; Mon, 30 Nov 2015 23:00:36 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-b5-565d45925a26 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E2.08.05041.2954D565; Tue, 1 Dec 2015 08:00:34 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.31]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Tue, 1 Dec 2015 08:00:34 +0100 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: A new SIP header fields with "P-" name Thread-Index: AdErb0NStzAvzI7DQoGlsVH1re72Cw== Date: Tue, 1 Dec 2015 07:00:33 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610112AEC437ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7je4k19gwg80tchZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtR1OQUHtSoWLdnO2sD4RqWLkZNDQsBE4vy7JywQtpjEhXvr 2boYuTiEBA4zSqw/sY0ZwlnEKHFw+1tWkCo2AT2JiVuOgNkiApoSy79tZQexhQX0JRY1XGGD iJtI/J+/DKiGA8jWk7g7zQYkzCKgIjH1yHZmEJtXwFdiztn9YOWMArISV//0MoLYzALiEree zGeCOEhAYsme88wQtqjEy8f/WCFsRYn2pw1Q9fkSZ5b2sUDMFJQ4OfMJywRGoVlIRs1CUjYL SRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFpcnJtuZKSXWpSZXFycn6eXl1qy iREYEQe3/LbawXjwueMhRgEORiUe3g9XYsKEWBPLiitzDzFKcDArifD+kIoNE+JNSaysSi3K jy8qzUktPsQozcGiJM7bzPQgVEggPbEkNTs1tSC1CCbLxMEp1cDos3/qyZ15gt8+sJy6PWO+ zaI0kx3X/tXbSBxb1dnKH3ZE67VawA7OTV9Yzpy/yOQnzmH4Pfx/iPCXr1XBc3MTXa75PLt9 VWfzbJmWDvkai4VXG+rteF+Jfd/957BLv4LrXGbFBXt+1Jhcf8raOUHrcZPeJ6MQmT7hZUkr KjIWP1j6obB5n4uxEktxRqKhFnNRcSIAOcu6FYQCAAA= Archived-At: Subject: [sipcore] A new SIP header fields with "P-" name X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 07:00:39 -0000 --_000_39B5E4D390E9BD4890E2B3107900610112AEC437ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, in the last 3GPP CT1 WG meeting, 3GPP CT1 WG was unable to conclude whether= it is possible to define and to use a new "P-"header field. Some believed that IANA registration of a new "P-" header field is not poss= ible any more due to RFC5727. Others believed that IANA registration of a n= ew "P-" header field is possible as long as someone already implemented and= deployed such header field (even if it was done recently). Can you please provide guidance whether IANA registration of a new "P-" hea= der field is likely? Thanks. RFC5727 states: --------------------------- New proposals to document SIP header fields of an experimental or private nature, however, shall not use the "P-" prefix (unless existing deployments or standards use the prefix already, in which case they may be admitted as grandfathered cases at the discretion of the Designated Expert). --------------------------- Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B3107900610112AEC437ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

in the last 3GPP CT1 WG meeting, 3GPP CT1 WG was = unable to conclude whether it is possible to define and to use a new "= P-"header field.

 

Some believed that IANA registration of a new &qu= ot;P-" header field is not possible any more due to RFC5727. Others be= lieved that IANA registration of a new "P-" header field is possi= ble as long as someone already implemented and deployed such header field  (even if it was done recently).

 

Can you please provide guidance whether IANA regi= stration of a new "P-" header field is likely? Thanks.=

 

RFC5727 states:

---------------------------

New

   proposals to document SIP header fie= lds of an experimental or private

   nature, however, shall not use the &= quot;P-" prefix (unless existing

   deployments or standards use the pre= fix already, in which case they

   may be admitted as grandfathered cas= es at the discretion of the

   Designated Expert).

---------------------------

 

Kind regards

 

Ivo Sedlacek

 

 

--_000_39B5E4D390E9BD4890E2B3107900610112AEC437ESESSMB301erics_--