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

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 07 Mar 2014 02:20:24 +0000

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" <[email-masked]>
To: "James Polk" <[email-masked]>; 
[email-masked]; [email-masked]
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:[email-masked]]
>>  Sent: Thursday, February 13, 2014 2:40 AM
>>  To: Paul E. Jones; Brett Tate; draft-ietf-insipid-session-
>>  [email-masked]; [email-masked]
>>  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" <[email-masked]>
>>  >To: "[email-masked]"
>>  ><[email-masked]>; "[email-masked]"
>>  ><[email-masked]>
>>  >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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: Brett Tate <[email-masked]>
Date: Fri, 7 Mar 2014 06:30:04 -0500

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

> From: Paul E. Jones [mailto:[email-masked]]
> Sent: Thursday, March 06, 2014 9:20 PM
> To: Brett Tate; James Polk; draft-ietf-insipid-session-

-- 

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.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 07 Mar 2014 21:03:22 +0000

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" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; 
[email-masked]; [email-masked]
Sent: 3/7/2014 6:30:04 AM
Subject: RE: [Insipid] draft-ietf-insipid-session-id-02: exception for 
181

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 Mar 2014 13:27:11 -0400

On Mar 6, 2014, at 9:20 PM, Paul E. Jones <[email-masked]> wrote:

> 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 :-)

I don't believe there was a definitive decision in the meeting, but I suggested that the rules for this be a MAY.  James Polk said he'd think about that more.

So something like:

"For any 1xx response prior to dialog establishment, if the intermediary generates a 1xx by itself (as opposed to forwarding one from downstream), then the intermediary MAY generate either a new local UUID or a null UUID for the "local-uuid" field in the 1xx response.  Once a dialog is established, 1xx responses MUST use the same local UUID as the dialog.  100 responses MAY always be set to a null UUID for the "local-uuid" field, even within the dialog, since they are not end-to-end and can be generated at a very low layer of a SIP stack."

Or something like that anyway.  We definitely have to allow a 100 to not have a generated local UUID, ever.  For the others, I don't think we should distinguish 181 from 180 or whatever.  B2BUAs can (and do) generate any/all 18x on their own, even 180.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 11 Mar 2014 13:01:17 +0000

Hadriel,

I'm mostly ok with this, but why would we want to allow the option for 
an intermediary to create its own UUID?  My thought was that it would be 
better if only the null UUID is used, as that would likely lead to less 
confusion and consistent behavior regardless of the 1xx value.

Paul

------ Original Message ------
From: "Hadriel Kaplan" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: "Brett Tate" <[email-masked]>; "James Polk" <[email-masked]>; 
[email-masked]; [email-masked]
Sent: 3/10/2014 1:27:11 PM
Subject: Re: [Insipid] draft-ietf-insipid-session-id-02: exception for 
181

>>  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 :-)
>
>I don't believe there was a definitive decision in the meeting, but I 
>suggested that the rules for this be a MAY. James Polk said he'd think 
>about that more.
>
>So something like:
>
>"For any 1xx response prior to dialog establishment, if the 
>intermediary generates a 1xx by itself (as opposed to forwarding one 
>from downstream), then the intermediary MAY generate either a new local 
>UUID or a null UUID for the "local-uuid" field in the 1xx response. 
>Once a dialog is established, 1xx responses MUST use the same local 
>UUID as the dialog. 100 responses MAY always be set to a null UUID for 
>the "local-uuid" field, even within the dialog, since they are not 
>end-to-end and can be generated at a very low layer of a SIP stack."
>
>Or something like that anyway. We definitely have to allow a 100 to not 
>have a generated local UUID, ever. For the others, I don't think we 
>should distinguish 181 from 180 or whatever. B2BUAs can (and do) 
>generate any/all 18x on their own, even 180.
>
>-hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 Mar 2014 12:49:37 -0400

On Mar 11, 2014, at 9:01 AM, Paul E. Jones <[email-masked]> wrote:

> Hadriel,
> 
> I'm mostly ok with this, but why would we want to allow the option for an intermediary to create its own UUID?  My thought was that it would be better if only the null UUID is used, as that would likely lead to less confusion and consistent behavior regardless of the 1xx value.

Imagine this:

UAC --> SBC1 --> B2BUA1 --> App-Server --> B2BUA2 --> SBC2 --> UAS

The App-server wants to generate rich-ringtone or find-me-follow-me media, before the UAS is even reached.  So the App-server generates its own 18x with SDP.  If you want to correlate that in the logs, vs. the final 18x/200, then having the App-Server create its own UUID would help correlation.

(that's a very common scenario, btw, not a corner-case I'm dreaming up, fwiw)

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 12 Mar 2014 12:58:10 +0000

Hadriel,

Yep, I'll buy that.

Paul

------ Original Message ------
From: "Hadriel Kaplan" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: "Brett Tate" <[email-masked]>; "James Polk" <[email-masked]>; 
[email-masked]; [email-masked]
Sent: 3/11/2014 12:49:37 PM
Subject: Re: [Insipid] draft-ietf-insipid-session-id-02: exception for 
181

>>  I'm mostly ok with this, but why would we want to allow the option 
>>for an intermediary to create its own UUID? My thought was that it 
>>would be better if only the null UUID is used, as that would likely 
>>lead to less confusion and consistent behavior regardless of the 1xx 
>>value.
>
>Imagine this:
>
>The App-server wants to generate rich-ringtone or find-me-follow-me 
>media, before the UAS is even reached. So the App-server generates its 
>own 18x with SDP. If you want to correlate that in the logs, vs. the 
>final 18x/200, then having the App-Server create its own UUID would 
>help correlation.
>