Subject: [Insipid] The value of the "local-uuid" to be inserted by SBCs

From: Laura Liess <[email-masked]>
Date: Tue, 12 Mar 2013 22:21:11 +0100

Paul,

I have a comment concerning folowing text in Section 7:

 If a SIP message having no Session-ID header is received by an
   intermediary, the intermediary MAY assign a "local-uuid" value to
   represent the sending endpoint and insert that value into all
   signaling messages on behalf of the sending endpoint.  If the
   intermediary is aware of a "remote" value that identifies the
   receiving UA, it MUST insert that value if also inserting the "local-
   uuid" value.

IMO the value of the of the local-uuid must be the hashed call-ID of
the incomming call leg.
Otherwise there is not possible for an external  monitoring device to
correlate both legs of a call  in case of a failure
of the receiving device ( the receiving device drops the call).

Thank you
Laura

2013/3/12 <[email-masked]>

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the INtermediary-safe SIP session ID Working
> Group of the IETF.
>
>         Title           : End-to-End Session Identification in IP-Based
> Multimedia Communication Networks
>         Author(s)       : Paul E. Jones
>                           Chris Pearce
>                           James Polk
>                           Gonzalo Salgueiro
>         Filename        : draft-ietf-insipid-session-id-00.txt
>         Pages           : 20
>         Date            : 2013-03-12
>
> Abstract:
>    This document describes an end-to-end Session Identifier for use in
>    IP-based Multimedia Communication systems that enables endpoints,
>    intermediate devices, and management systems to identify a session
>    end-to-end, associate multiple endpoints with a given multipoint
>    conference, track communication sessions when they are redirected,
>    and associate one or more media flows with a given communication
>    session.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-insipid-session-id-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 12 Mar 2013 17:49:32 -0400

Laura,

That would be a good idea. RFC 4122 allows for an SHA-1 hash to be used, for example. If we reserved that UUID type for this scenario, we could also tell the value was fabricated by a middle box. Other versions (like v4 - random values) could be used by endpoints that generate their own values.

We need to define the exact usage of UUIDs, of course. I like your idea.

Paul

-------- Original Message --------
From: Laura Liess <[email-masked]>
Sent: Tue Mar 12 17:21:11 EDT 2013
To: Paul Jones <[email-masked]>
Cc: [email-masked]
Subject: The value of the "local-uuid" to be inserted by SBCs

Paul,

Thank you
Laura