Re: [Insipid] draft-ietf-insipid-session-id-10: comments

["Paul E. Jones" <[e-mail]>]

Brett,

OK, it sounds like you're OK with what we have. I think it would be 
important to review those examples to make sure I did put the right 
values in for Route and Record-Route. I'll publish a new version shortly 
and will be happy to modify it more.

I don't think it should be necessary to talk about 487, etc. The rules 
for how to process messages when a Session-ID is present are consistent 
for all exchanges. The CANCEL one is a special case and you successfully 
argued your point for why it should be exactly like the one found in the 
INVITE (.. and with normative language). That's an exception called out, 
but I don't think we need to enumerate every response code. 487 should 
be no different than any other 4xx or 2xx, IMO.

Anyway, let me publish a new draft and let's have another round.

Paul

------ Original Message ------
From: "Brett Tate" <[e-mail]>
To: [e-mail]; [e-mail]
Sent: 1/7/2015 12:15:42 PM
Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments

>Hi,
>
>Thanks for the response; reply is inline.
>
>>  >> >Suggested text: "A CANCEL request sent by an intermediary
>>  >> >MUST construct a Session-ID header value exactly like the
>>  >> >INVITE's Session-ID."
>>  >>
>>  >> OK, your text down below made this clearer for me.
>>  >> I agree we should do as you say.
>>  >
>>  >Potentially should make a slight modification to the
>>  >suggested text so that it only applies to CANCEL outside
>>  >of dialog.
>>
>>  Why say that? Why not have any CANCEL follow this rule?
>
>I don't have a strong opinion either way. Allowing different behavior
>within dialog, allows the CANCEL to be more accurate (for example, the 
>local
>or remote values may have changed between re-INVITE and CANCEL). Either
>way, the draft would potentially need to clarify if a CANCEL's 
>Session-ID is
>allowed to update (or has no impact upon) the dialogs session-id value 
>(for
>building CANCEL's 2xx, re-INVITE's 487, et cetera).
>
><snip>
>
>>  OK, I get your point. How about this added to the end
>>  of the next-to-the-last paragraph in Section 6:
>>
>>  "The one exception is when the UA sends a CANCEL message,
>>  in which case the Session-ID header value will be identical
>>  to the original INVITE."
>
>It sounds okay to me although "will be" potentially needs a normative
>modification if not indicated elsewhere; however it may need updating 
>based
>upon outcome of the above discussion.
>
><snip>
>
>>  >I still don't know your working definition of essential.
>>  >The Record-Route and Route stuff should be present to comply
>>  >with RFC 3261 (without requiring local policy to override
>>  >RFC 3261 default behavior) since B2BUA is not altering Contact
>>  >values. However, Record-Route and Route are not essential
>>  >for understanding Session-ID stuff within the example.
>>  >
>>  >If the ACK reflects the 2xx's Contact URI, I don't have a
>>  >strong opinion if the example shows the Record-Route and
>>  >Route stuff since easy to assume that loose routing is
>>  >occurring and Record-Route/Route deemed non-essential.
>>
>>  OK, you want this added to F2 and F3?
>>
>>  Record-Route: <sip:server10.biloxi.example.com;lr>
>
>Since version 11's F5 ACK reflects the 2xx's Contact URI, I don't have 
>a
>strong opinion what occurs concerning the Record-Route and Route stuff.
>
>If Record-Route and Route are deemed essential, yes the Record-Route 
>should
>be added to F2 and F3. The Route would also need to be added to F5.
>
>If Record-Route and Route are deemed non-essential, the Record-Route 
>added
>to version 11 F4 can be removed.
>
>
>>  >> >> >Section 9.4
>
><snip>
>
>>  >>We could just remove the text "(to change the UUID to M')"
>>  >>or change it to something else. I'm not sure what we
>>  >>should change it to that will not be a mile long. Suggestions?
>>  >
>>  >Based upon my following paragraph, you can likely leave as-is.
>>
>>  Which following paragraph? This one here right below?
>
>Yes.
>
>>  >Based upon section 9.3, the draft does not require an
>>  >intermediary to send a request solely to update Session-ID.
>>  >Does the draft require an endpoint such as the Single Focus
>>  >Conference Server to send a request solely to update the
>>  >Session-ID (if became inaccurate such as when turn 2 separate
>>  >calls into a conference)? Either way, it would help if
>>  >there were normative statements within sections 6 and 7
>>  >indicating that they MAY, SHOULD, or MUST send a request
>>  >to update the Session-ID if local UUID becomes inaccurate.
>>
>>  I don't think there will be a case where the endpoint
>>  does not know the Session-ID. The text in 9.4 is just
>>  confusing. This re-INVITE updates the UUID to M' only as a
>>  side effect. The real reason for sending the re-INVITE is
>>  to put the endpoint into the real target conference. (Note
>>  that the initial call would drop the user into the IVR system.)
>>
>>  What I'd like to suggest is to remove the words "(to change
>>  the UUID to M')", because that is not the main reason for
>>  that exchange.
>
>The proposed change is okay with me.
>
>
><snip>
>
>>  Agreed. Section 6 now has this as the next-to-the-last
>>  paragraph. Sound OK?
>
>See reply concerning "next-to-the-last paragraph in Section 6".
>
>_______________________________________________
>insipid mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/insipid