Subject: [Insipid] draft-ietf-insipid-session-id-02: exception for 181

From: Brett Tate <[email-masked]>
Date: Fri, 3 Jan 2014 20:05:17 +0000

Hi,

Concerning draft-ietf-insipid-session-id-02 sections 6 and 9.8, I'm not sure that I understand the rule which allows an intermediary to avoid creating UUID for Session-ID when sending a non-100 provisional response.

"The exception to including the UUID of the transmitting entity
 mentioned above is in the case of provisional responses that occur
 before the destination UA has generated its UUID.  The 100 (Trying)
 response and the 181 (Call Forwarding) response are examples of such
 provisional responses. In these cases, the sending intermediary
 places the one known UUID in the remote-uuid field, and leaves the
 "local-uuid" blank. This placement is always where a UA expects to
 receive its UUID value in SIP responses."

The 181 with To tag creates a new dialog (at least per RFC 5359).  What makes the 181 special?  For instance, there are services enabled on some intermediaries which generate 180 or 183 to accommodate longer delays (or to play announcements) before actually receiving a 18x from the target.  It sounds like the exception also applies to 180 and 183 within this situation.

If it matters, the draft snippet does not use normative statements to indicate how the "sending intermediary" MAY, SHOULD, or MUST behave.

Thanks,
Brett

This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.