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

["Dawes, Peter, Vodafone Group" <[e-mail]>]

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:[e-mail]]
Sent: 22 August 2016 23:08
To: Alberto Llamas
Cc: Dawes, Peter, Vodafone Group; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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