Brett,

(Sorry for mistyping your name earlier.)

Personally, I prefer to have one approach that just prescribes what an 
intermediary does in the case that it does or does not have a UUID from 
the remote end.  If we can get away from calling out 100 explicitly, I 
think that will be better.  But, I'll discuss this with James and 
definitely welcome other input on the list.

Paul

------ Original Message ------
From: "Brett Tate" <brett@broadsoft.com>
To: "Paul E. Jones" <paulej@packetizer.com>; 
draft-ietf-insipid-session-id@tools.ietf.org; insipid@ietf.org
Sent: 3/7/2014 6:30:04 AM
Subject: RE: [Insipid] draft-ietf-insipid-session-id-02: exception for 
181

>Hi Paul,
>
>Thanks for the update. The resolution sounds okay to me. However, 
>keeping
>the special case for 100 also sounds okay since it can't create a 
>dialog and
>doesn't go end-to-end.
>
>Thanks,
>Brett
>
>>  -----Original Message-----
>>  From: Paul E. Jones [mailto:paulej@packetizer.com]
>>  Sent: Thursday, March 06, 2014 9:20 PM
>>  To: Brett Tate; James Polk; draft-ietf-insipid-session-
>>  id@tools.ietf.org; insipid@ietf.org
>>  Subject: Re: [Insipid] draft-ietf-insipid-session-id-02: exception 
>>for
>>  181
>>
>>  Brette,
>>
>>    This issue was taken up in the meeting, I think. From Roland's 
>>notes
>>  to the list, it appears the decision is that all 1xx replies will be
>>  handled with the same defined procedure.
>>
>>  I think that procedure is "if the intermediary repies and does not 
>>know
>>  the remote endpoints UUID, it will use the null UUID". I'll discuss
>>  this with James as we revise the text. Of course, any suggested text
>>  is
>>  always welcome :-)
>>
>>  Paul
>>
>>  ------ Original Message ------
>>  From: "Brett Tate" <brett@broadsoft.com>
>>  To: "James Polk" <jmpolk@cisco.com>;
>>  draft-ietf-insipid-session-id@tools.ietf.org; insipid@ietf.org
>>  Sent: 2/27/2014 7:13:33 AM
>>  Subject: Re: [Insipid] draft-ietf-insipid-session-id-02: exception 
>>for
>>  181
>>
>>  >Hi James,
>>  >
>>  >Draft-ietf-insipid-session-id-05 section 7 indicates the following.
>>  >
>>  >"When intermediaries transmit provisional responses, such as 100
>>  > (Trying) or the 181 (Call Forwarding), and when the UUID of the
>>  > destination UA is unknown, the sending intermediary MUST place the
>>  > one known UUID in the "remote-uuid" field and set the "local-uuid"
>>  > field to the null UUID value."
>>  >
>>  >Based upon the snippet, I'd assume that the B2BUA must also insert 
>>the
>>  >null UUID value if they generate 180 or 183 responses. If you don't
>>  >want
>>  >that behavior, the draft should clarify why it applies to 181 but 
>>not
>>  >180
>>  >and 183.
>>  >
>>  >If I understand your response correctly, the reason is because
>>  >intermediaries typically don't generate 180 and 183 responses and
>>  >destinations typically don't generate 181 (before forwarding
>>  >elsewhere).
>>  >I'm not sure if that is a good reason for the different behavior;
>>  >similarly I'm not sure why there should be different behavior.
>>  >
>>  >Thanks,
>>  >Brett
>>  >
>>  >> -----Original Message-----
>>  >> From: James Polk [mailto:jmpolk@cisco.com]
>>  >> Sent: Thursday, February 13, 2014 2:40 AM
>>  >> To: Paul E. Jones; Brett Tate; draft-ietf-insipid-session-
>>  >> id@tools.ietf.org; insipid@ietf.org
>>  >> Subject: Re: [Insipid] draft-ietf-insipid-session-id-02: exception
>>  >>for
>>  >> 181
>>  >>
>>  >> Brett
>>  >>
>>  >> I had a specific set of use-cases in mind when I wrote that text. 
>>I
>>  >> didn't give the same treatment for all provisional responses
>>  because
>>  >> there are two types of provisional responses (from a Session_ID
>>  point
>>  >> of view:
>>  >>
>>  >> - those that haven't reached any non-B2BUA SIP intermediary
>>  >> (180 or 183)
>>  >>
>>  >> and
>>  >>
>>  >> - those that aren't expected to have reached a destination (100 
>>and
>>  >> 181).
>>  >>
>>  >> A 180 and 183 are generally expected to have reached the ultimate
>>  >> UAS, therefore have the expectation to have replaced the null UUID
>>  >> out for "their " UUID. Neither the 100 or 181 are expected to have
>>  >> anything other than a null second UUID.
>>  >>
>>  >> With that in mind, did the text cover this point adequately 
>>enough,
>>  >> or we authors put in (somewhere) this explanation so implementors
>>  >> don't get confused down the road?
>>  >>
>>  >> oh yeah, do you agree with this explanation?
>>  >>
>>  >> James
>>  >>
>>  >> At 04:06 PM 2/12/2014, Paul E. Jones wrote:
>>  >> >Brett,
>>  >> >
>>  >> >The 100 and 180 are just examples. I think the behavior by
>>  >> >intermediaries should be the same for all provisional
>>  >> >responses. This text has changed a bit. When -05 comes out, feel
>>  >> >free to comment further.
>>  >> >
>>  >> >Paul
>>  >> >
>>  >> >------ Original Message ------
>>  >> >From: "Brett Tate" <brett@broadsoft.com>
>>  >> >To: "draft-ietf-insipid-session-id@tools.ietf.org"
>>  >> ><draft-ietf-insipid-session-id@tools.ietf.org>; 
>>"insipid@ietf.org"
>>  >> ><insipid@ietf.org>
>>  >> >Sent: 1/3/2014 3:05:17 PM
>>  >> >Subject: [Insipid] draft-ietf-insipid-session-id-02: exception 
>>for
>>  >>181
>>  >> >
>>  >> >>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.
>>  >
>>  >_______________________________________________
>>  >insipid mailing list
>>  >insipid@ietf.org
>>  >https://www.ietf.org/mailman/listinfo/insipid
>
>--
>
>
>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.
>