Re: [Insipid] draft-ietf-insipid-logme-reqs

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Tue, 13 September 2016 09:10 UTC

Return-Path: <Peter.Dawes@vodafone.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A31412B248 for <insipid@ietfa.amsl.com>; Tue, 13 Sep 2016 02:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=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 Odq1iCSqNWAt for <insipid@ietfa.amsl.com>; Tue, 13 Sep 2016 02:10:49 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C352C12B252 for <insipid@ietf.org>; Tue, 13 Sep 2016 02:10:48 -0700 (PDT)
Received: from [85.158.139.163] by server-14.bemta-5.messagelabs.com id 74/3C-11508-692C7D75; Tue, 13 Sep 2016 09:10:46 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRWlGSWpSXmKPExsVy+MWXdt1ph66 HG3xzs5g5+zCLReODaewW8+8/Y3Jg9pjyeyOrx85Zd9k9liz5yRTAHMWamZeUX5HAmjGx7ydb wewJzBU75kxhb2D80sXcxcjFISSwl1FiTd9dRghnJaPEtPM/WCCc5UwSD5bdgMocYZRYsX0qO 4Qzl1Fi/rHnTF2MHBxsAvYSM/bEdDFycogI6EpsWvKdEcRmFoiTeH2phw3EFhbQkrjU+4gRok ZbYvnkb0wQtpPEzpuXWUBsFgFVianHG9lARvIKhEpcPxELsWoyk8TjS7PBajgFAiVmN24Bm8M oICvxpXE1M8QucYlbT+aDzZQQEJBYsuc8M4QtKvHy8T9WiJo8idfNt8Dm8AoISpyc+YRlAqPo LCTts5CUzUJSNgvoJGYBTYn1u/QhShQlpnQ/ZIewNSRa58xlRxZfwMi+ilGjOLWoLLVI18hSL 6koMz2jJDcxM0fX0MBULze1uDgxPTUnMalYLzk/dxMjMErrGRgYdzBe3uJ3iFGSg0lJlHf+mu vhQnxJ+SmVGYnFGfFFpTmpxYcYZTg4lCR4Gw8C5QSLUtNTK9Iyc4DpAiYtwcGjJMJbDJLmLS5 IzC3OTIdInWJUlBLn9QBJCIAkMkrz4NpgKeoSo6yUMC8jAwODEE9BalFuZgmq/CtGcQ5GJWGI 7TyZeSVw018BLWYCWrxlDdjikkSElFQD48IzDL6rN76ZbLrDReX509AdLvpu02KV5zs/PLqM/ UTd7dzNkRpb77Sx/mzeszf6y6cFc3ZotpSdXpKS+G2pkL735d+JlpVF3C6yit/MhJi7H2jds1 GJmiqW3KjE+UraL/iMcbHZ5QeSoReOq/LM33xpwv5exczkl9xKmzcoe11nSOebnrV7nxJLcUa ioRZzUXEiANizUC1MAwAA
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-6.tower-188.messagelabs.com!1473757845!58790189!1
X-Originating-IP: [195.232.244.135]
X-StarScan-Received:
X-StarScan-Version: 8.84; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19941 invoked from network); 13 Sep 2016 09:10:45 -0000
Received: from mailout03.vodafone.com (HELO mailout03.vodafone.com) (195.232.244.135) by server-6.tower-188.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 13 Sep 2016 09:10:45 -0000
Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout03.vodafone.com (Postfix) with ESMTP id 3sYJn13XLVz17HLr; Tue, 13 Sep 2016 11:10:45 +0200 (CEST)
Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3sYJn12MmMzxPHw; Tue, 13 Sep 2016 11:10:45 +0200 (CEST)
Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3sYJn11b6BzxPjN; Tue, 13 Sep 2016 11:10:45 +0200 (CEST)
Received: from VOEXC29W.internal.vodafone.com (145.230.103.201) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 13 Sep 2016 11:10:44 +0200
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.18]) by voexc29w ([145.230.103.201]) with mapi id 14.03.0224.002; Tue, 13 Sep 2016 11:10:42 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: Alberto Llamas <albertollamaso@gmail.com>
Thread-Topic: draft-ietf-insipid-logme-reqs
Thread-Index: AQHR/MGX4UdRaXrMzkqff9+YjWQBnqBsak+ggAExy4CACaX4UA==
Date: Tue, 13 Sep 2016 09:10:42 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8B4AF39@VOEXM31W.internal.vodafone.com>
References: <CAHH1jkM6aTvDmcjWY4+PziWkYUHpTA_jrAsbaY_4UO0DNaVbQw@mail.gmail.com> <901FE941-6579-4694-BFD0-5193F274E688@cisco.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8B3DF6D@VOEXM31W.internal.vodafone.com> <CAHH1jkMmBuUT70BZOjUVzj++9EU_vpgMK9KUArA3=474pTLdSA@mail.gmail.com>
In-Reply-To: <CAHH1jkMmBuUT70BZOjUVzj++9EU_vpgMK9KUArA3=474pTLdSA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8B4AF39VOEXM31Winterna_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/_oH4dBvamr8qU2vDxyErPfh1wZQ>
Cc: "Arun Arunachalam \(carunach\)" <carunach@cisco.com>, "insipid@ietf.org" <insipid@ietf.org>
Subject: Re: [Insipid] draft-ietf-insipid-logme-reqs
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2016 09:10:52 -0000

Hello Albert,
Now that I understand your comment better, my preference would be to explicitly mention gateways in REQ5, such as:


REQ5: If a UA that supports "log me" marking receives a request

      with a "log me" marker, it MUST echo that "log me" marker in

      responses to that request. This requirement applies to cases

      where the UA is the endpoint of communication, where the UA

      is one side of a gateway such as a SIP/PSTN gateway, and

      where the UA is one side of a B2BUA.

Regards,
Peter

From: Alberto Llamas [mailto:albertollamaso@gmail.com]
Sent: 07 September 2016 08:44
To: Dawes, Peter, Vodafone Group
Cc: Arun Arunachalam (carunach); insipid@ietf.org
Subject: Re: draft-ietf-insipid-logme-reqs

Hello Peter,

I am glad to hear of you. Below you can find my comments related with the B2BUA behavior:


In the document (https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-07) we have:


 REQ5: If a UA that supports "log me" marking receives a request

      with a "log me" marker, it MUST echo that "log me" marker in

      responses to that request.


Your suggestion is to add a sentence like "Note that UA requirements apply to each side of a B2BUA". But it feels like we are missing the case of a SIP gateway which can be used in different scenarios like:

Interconnection between SIP/PSTN
Interconnection between SIP/Legacy PBX
Interconnection between SIP/endpoint as a fax machine
For these cases we would like to keep the "log me" marker for all SIP requests/responses related with the same SIP dialog.

In order to have this in a generic way I would suggest:

 REQ5: If a UA that supports "log me" marking receives a request

      with a "log me" marker, it MUST echo that "log me" marker in

      responses to that request. Note that UA requirements apply to
      each side of a SIP entity.

Or should we include a REQ for gateways?.


please let me know your thoughts
Regards,

On Tue, Sep 6, 2016 at 1:49 PM, Dawes, Peter, Vodafone Group <Peter.Dawes@vodafone.com<mailto:Peter.Dawes@vodafone.com>> wrote:
Hello Albert,
I agree with you that B2BUA behaviour is an important consideration for log me behaviour as illustrated by your example. The requirements certainly need to allow the behaviour you describe and but we need to decide whether the B2BUA procedures fit better in the solution description than in the requirements.
The current proposal is to cover your comments in the detailed protocol description (https://www.ietf.org/id/draft-ietf-insipid-logme-marking-05.txt) and I have copied the relevant section below. It would be great to hear if you have any comments on this description (some have already been made by Paul Giralt in https://mailarchive.ietf.org/arch/msg/insipid/1z3zSdIAISPepcW1rrSOxWBlRCE). For the requirements, I think that the UA related requirements are enough to cover the B2BUA case but we could consider adding a sentence like “Note that UA requirements apply to each side of a B2BUA” if it makes things clearer.

Regards,
Peter

from https://www.ietf.org/id/draft-ietf-insipid-logme-marking-05:

5.8.  B2BUA Handling of Log-Me Marked Dialogs

   The log-me marking behaviour of a B2BUA needs to be consistent with
   its purpose of troubleshooting user problems and regression testing.
   For example, a B2BUA that does no more than transcoding media can
   simply copy log-me marking from UAS to UAC whereas a B2BUA that
   performs varied and complex signalling tasks such as distributing
   calls in a call centre needs flexible configuration so that log-me
   marking can target specific B2BUA functions.

   B2BUA behaviour is described below for each of the B2BUA types
   described in RFC7092 [RFC7092].  Behaviour described in this clause
   applies only to dialogs that are being log-me marked.

5.8.1.  All B2BUA Roles

   For dialogs that are being log-me marked, all B2BUAs MUST log-me mark
   in-dialog SIP requests that they generate on their own, without
   needing explicit configuration to do so.  This rule applies to both
   the originating and terminating sides of a B2BUA.

5.8.2.  Proxy-B2BUA

5.8.2.1.  Terminating Behaviour

   A Proxy-B2BUA SHOULD copy log-me marking in requests and responses
   from its terminating to the originating side without needing explicit
   configuration to do so.





Dawes                   Expires February 15, 2017              [Page 10]

Internet-Draft               log me marking                  August 2016


5.8.3.  Signaling-only and SDP-Modifying Signaling-only

5.8.3.1.  Terminating Behaviour

   A signaling-only B2BUA SHOULD NOT copy log-me marking in requests and
   responses from its terminating to its originating side.  Whether a
   dialog that a signaling-only B2BUA terminates causes log-me marking
   of a dialog on its originating side SHOULD be controlled by explicit
   configuration of the originating side, in the same way that a UAC
   requires configuration to control log-me marking.

5.8.3.2.  Originating Behaviour

   Whether a signaling-only B2BUA log-me marks SIP requests that it
   generates on its own SHOULD be controlled by explicit configuration
   of the originating side, in the same way that a UAC requires
   configuration to control log-me marking.

5.8.4.  Media Relay, Media Aware, Media Termination

   Log-me marking behaviour is independent of B2BUA media-plane
   functionality.  Behaviour of signaling/media plane B2BUA roles is
   therefore dictated only by the signaling plane role as described in
   Section 5.8.2 and Section 5.8.3 in this document.



From: Arun Arunachalam (carunach) [mailto:carunach@cisco.com<mailto:carunach@cisco.com>]
Sent: 22 August 2016 23:08
To: Alberto Llamas
Cc: Dawes, Peter, Vodafone Group; insipid@ietf.org<mailto:insipid@ietf.org>
Subject: Re: draft-ietf-insipid-logme-reqs

Hi Alberto,

Thanks for the feedback !

I think your suggestion is to carry the log-me marker across an end-to-end session instead of limiting it to per-dialog.

Adding insipid mailing list.

Thanks!
Arun



On Aug 22, 2016, at 3:26 PM, Alberto Llamas <albertollamaso@gmail.com<mailto:albertollamaso@gmail.com>> wrote:

Hello Peter and Chidambaram,
I have read your proposed RFC [https://www.ietf.org/id/draft-ietf-insipid-logme-reqs-07.txt] which I find a very good document.
I believe that in section 5 you should include a requirement for the case when a B2BUA receive a request (A leg INVITE) which contains a "Log Me" marker and this entity generate another INVITE (B leg)  regarding the first one. In this case the "Log me" marker should be preserved when the second INVITE is generated.

A common example is when Diversion exists and then we receive an INVITE back with Diversion, History-info headers..etc...then we MUST be able to treat this new call as part of debugging or regression testing.
Thanks,

--
albert





--
Alberto Llamas
Telecommunications Engineer
Digium Certified Asterisk Professional (dCap)
Linux Administrator