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

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 12 Feb 2014 22:06:59 +0000

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: James Polk <[email-masked]>
Date: Thu, 13 Feb 2014 01:40:01 -0600

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

---

From: Brett Tate <[email-masked]>
Date: Thu, 27 Feb 2014 07:13:33 -0500

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
>

-- 

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.