Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs

"Arun Arunachalam (carunach)" <> Thu, 29 September 2016 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D70B12B1FC for <>; Thu, 29 Sep 2016 11:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.836
X-Spam-Status: No, score=-16.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id neLUe_OMe_ET for <>; Thu, 29 Sep 2016 11:13:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B83A812B1A1 for <>; Thu, 29 Sep 2016 11:13:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=23394; q=dns/txt; s=iport; t=1475172798; x=1476382398; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=94GBTFK88dl0kRQA118J0UWghkyYW70LoTwoDkgbaKY=; b=mgqyB9BJ5s8MeMBcP5Q7rYJ3LsO6lVuyQ6/q+dAqiXyvdR58BIc4x4Ir LDEqSvHpRotohN5CjZA+SRWhIkGrrXRAvw3aCorKlm14B58/TNbHXnbtC 4iignUfwfTFCa4tJM0Hbf47FL29jrLUtUDvY6iNNYy8sab6Y3wGQrLBwV g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,268,1473120000"; d="scan'208,217";a="156694913"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Sep 2016 18:13:17 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u8TIDHqL016460 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2016 18:13:17 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 29 Sep 2016 13:13:16 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 29 Sep 2016 13:13:16 -0500
From: "Arun Arunachalam (carunach)" <>
To: "Paul Giralt (pgiralt)" <>
Thread-Topic: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
Thread-Index: AQHSGmo7kO+NAsnrMkyJwBUIwYUrX6CRGUkA
Date: Thu, 29 Sep 2016 18:13:16 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_6EE9E419BCE84E5AB0F12E0AE53C8BF0ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "Arun Arunachalam \(carunach\)" <>, "" <>, "Dawes, Peter, Vodafone Group" <>, "" <>, "Gonzalo Salgueiro \(gsalguei\)" <>
Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Sep 2016 18:13:21 -0000

Thanks Paul !

(1) Agree, let’s have a random test id given REQ 4 of RFC 7206<>-5>.

(2) We can update REQ 6 as shown below to incorporate your comment:

 REQ6: A SIP intermediary MAY insert a "log me" marker into requests and
      responses.  The typical case for which a intermediary needs to insert a
      "log me" marker is for compatibility with UAs that have not
      implemented "logme" marking, i.e. when a UA has not marked a
      request or when responses received on a dialog of interest for
      logging do not contain an echoed "log me" marker.  Another use
      case is when the session origination UA that inserted log me marker
      is no longer participating in the session (e.g: call transfer scenarios)
      and the intermediary adds "log me" marker in related sessions to enable
      end-to-end signaling analysis. In these cases, the entity that inserts a
      "log me" marker is stateful inasmuch as it must remember when a dialog is
      of interest for logging.  An entity that inserts a "log me" marker
      SHOULD also log the SIP request or response as per REQ4.


On Sep 29, 2016, at 11:57 AM, Paul Giralt (pgiralt) <<>> wrote:

Hi Arun,

Sorry for not replying earlier. Inline…

On Sep 22, 2016, at 10:13 AM, Arun Arunachalam (carunach) <<>> wrote:

Hi Paul,

Please see inline.

On Sep 14, 2016, at 7:30 PM, Paul Giralt (pgiralt) <<>> wrote:

Thanks Arun. See below…

On Sep 14, 2016, at 6:36 PM, Arun Arunachalam (carunach) <<>> wrote:

REQ8: Should update to latest session-id draft. Also, I have some concerns about using Session-ID as the test case identifier. The Session-ID can change (in fact will change for every session because the initial INVITE will have a null remote UUID).

How about using the local UUID of the Session-ID generated by the originating UA / proxy as a test identifier (if the admin wants the system to auto-generate a test ID)?

I think using just the local UUID makes more sense because this will be consistent throughout the life of the session as long as the originating endpoint is still in the call. It’s possible that some B2BUA could remove the originator from the session (e.g. call gets transferred) but at that point, the device that requested the session be logged is no longer in an active session anyway.

That said, what if the admin doesn’t want the system to auto-generate a test ID? Where would that go? The local UUID must be in a very specific format to comply with drafy-ietf-insipid-session-id, so you can’t put any arbitrary text in for the local UUID. I think either you need to stipulate that the test ID will always be automatically generated or find some other place to put it.

I think there is value in giving the admin the ability to specify their own identifier.

One option would be to have a user defined test identifier as shown below:

   test-identifier = (alphanum / "_") *(alphanum "_")

If the user defined test identifier is not present, the log analysis server would use the local UUID of the originator’s Session-ID as the test identifier.

I like this in concept. The concern I have is whether it meets the privacy requirements stipulated for additional parameters in the Session-ID header. If someone puts a value of the person’s name or perhaps a ticket number, that could be considered personally identifiable information which is not allowed to be present in the Session-ID header. I’m not sure how we’d reconcile these requirements. We may have to just live with the test ID being something random.

Also, should intermediaries be required to or at least allowed to continue indicating log me markings on other messages related to the session even if the originating device is no longer participating in the session?

This will be useful to perform an end-to-end call flow analysis.

The good thing about originator based log me marking is the “ability / control” to disable logging simply by disconnecting the call at the originator (the device requesting to enable logging).

This control no longer exists if we allow the intermediaries to continue marking even after the originator is no longer in the session.

I guess this could be left up to the implementation of the intermediary. It is free to add a logme marker to whatever it wants to, so even if the originator drops off, there is no reason why it can’t add the identifier to related sessions. This is probably something worth mentioning in the draft, but might not be necessary in the requirements doc.