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

[Alberto Llamas <[e-mail]>]

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 <
[e-mail]> 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:[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]>
> wrote:
>
>
>
> Hello Peter and Chidambaram,
>
> I have read your proposed RFC [*https://www.ietf.org/id/draft-ietf-insipid-logme-reqs-07.txt
> <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