Subject: [Insipid] Generation of a new Session-ID on behalf of an end device

From: Laura Liess <[email-masked]>
Date: Thu, 1 Aug 2013 18:50:15 +0200

Hi,

As agreed in the insipid meeting, please find below the text on how SBCs should
generate the Session-ID (or a part of it) on behalf of an end device.
It is  "copy & paste" from Hadriel's draft, parts of the Sections 4.1
and 4.5.1.
However, I think we should replace B2BUA by SBC. Application servers
and PBXs may want to insert their own UUID. I am fine
if they do not add the received Call-ID.

******Text from Hadriel's draft
***************************************************************
   If an out-of-dialog request is received by a B2BUA compliant with
   this document, and the request does *not* contain a Session-ID
   header field, the B2BUA MAY generate a new one.  The new Session-ID
   value MUST be generated by taking the Call-ID header
   value, and SHA-1 hashing it based on [RFC2104] HMAC using a locally
   generated pseudo-random 128-bit system secret key, to create a 128-
   bit resultant HMAC value. Per [RFC2104], the algorithm is thus
HMAC-SHA-1-128(Call-ID_value,
   secret_key), and the 128-bit result is encoded using lowercase
   alphanumeric hex representation, as defined in the ABNF section of
   this document.
   In order to enable trouble-shooting of in-dialog messages, a
   generator needs to remember or re-create the same Session-ID value
   for the duration of a given dialog(s).
   If any received message already had a
   Session-ID, a B2BUA compliant with this document would not replace
   it.
**************************************************************************

Thank you
Laura

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 2 Aug 2013 11:12:29 -0400

Laura,

The latest solutions draft has text that explains how an intermediary device
can generate the Session-ID.  However, it does not use a secret key of any
sort.  You had previously stated that you wanted the value to be
consistently regenerated, even in the face of calls being routed somewhere
else in the network.

So, there is a prescription for generating random values that use the
Call-ID and from/to tag.  The end result is a UUID value, following the
procedures specified in the UUID RFC.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Laura Liess
Sent: Thursday, August 01, 2013 12:50 PM
To: [email-masked]
Subject: [Insipid] Generation of a new Session-ID on behalf of an end device

Hi,

As agreed in the insipid meeting, please find below the text on how SBCs
should 
generate the Session-ID (or a part of it) on behalf of an end device. 
It is  "copy & paste" from Hadriel's draft, parts of the Sections 4.1 and
4.5.1. 

However, I think we should replace B2BUA by SBC. Application servers and
PBXs may want to insert their own UUID. I am fine 
if they do not add the received Call-ID. 

Thank you
Laura