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

[Brett Tate <[e-mail]>]

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