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

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 21 Mar 2013 23:14:14 -0400

Folks,

In addition to the two other items, there is this suggestion from Laura. I think it's reasonable, but I've not written the text, yet.

Do others have only on this?

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,

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: Fri, 22 Mar 2013 00:13:17 -0400

That would be "do others have an opinion on this?"

Paul

-------- Original Message --------
From: "Paul E. Jones" <[email-masked]>
Sent: Thu Mar 21 23:14:14 EDT 2013
To: [email-masked]
Subject: [Insipid] Fwd: The value of the "local-uuid" to be inserted by SBCs

Folks,

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

> ftp://ftp.ietf.org/internet-drafts/

------------------------------------------------------------------------

---

From: Brett Tate <[email-masked]>
Date: Wed, 27 Mar 2013 15:03:32 +0000

The suggestion sounds okay to me; however the request can fork and Call-ID change prior to the Session-ID being added.  Thus even though there might not be a better solution, the suggestion does not completely resolve the correlation problem.

If there are still vendors who reuse Call-ID for correlation or other reasons, it might cause the intermediary to add the same local-uuid when it potentially isn’t desirable.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Friday, March 22, 2013 12:13 AM
To: [email-masked]
Subject: Re: [Insipid] Fwd: The value of the "local-uuid" to be inserted by SBCs

Paul

________________________________
From: "Paul E. Jones" <[email-masked]<mailto:[email-masked]>>
Sent: Thu Mar 21 23:14:14 EDT 2013
To: [email-masked]<mailto:[email-masked]>
Subject: [Insipid] Fwd: The value of the "local-uuid" to be inserted by SBCs

Folks,

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

Paul,

   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

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 27 Mar 2013 11:41:39 -0400

Brett,

Yeah, you’re right.  The only suggestion I could give people in that case is that if they rely on the Session-ID header, they need to ensure it gets consistently applied.  Either the endpoints need to generate it or some intermediary needs to insert it.  Some aspects, the network admin can control.  But, if one is just monitoring a network and expecting consistent usage without putting effort in to ensure consistent usage, results will be disappointing.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: Wednesday, March 27, 2013 11:04 AM
To: Paul E. Jones; [email-masked]
Subject: Re: [Insipid] Fwd: The value of the "local-uuid" to be inserted by SBCs

 

Paul

  _____  

Folks,

Paul

  _____  

Paul,

Thank you
Laura