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

[Brett Tate <[e-mail]>]

Hi,

Thanks for the response; reply is inline.

> >Section 7 paragraph 6: Concerning early dialogs, the CANCEL correlates
> >to the INVITE instead of a specific early dialog. Thus the paragraph
> >should likely be reworded to always reflect the INVITE when CANCEL not
> >traversing a dialog. For instance if received multiple 18x creating
> >multiple early dialogs and received Session-IDs {B1, A} and {B2, A},
> >the current paragraph appears to recommend that the CANCEL include one
> >of these within the CANCEL.
>
> I'm not entirely clear on what you're suggesting.  All the current
> paragraph
> says is that if an intermediary sends a CANCEL and it doesn't have the
> value
> B1, for example, it is to use {A, "null"} as the Session-ID.

I'm indicating that a CANCEL should not reflect early dialog information; it
should reflect the INVITE.  Otherwise you'd be having to select a single
Session-ID from 1 of potentially many early dialogs to place within the
CANCEL (which isn't associated with a specific early dialog).  My comment is
similar to my Section 9.8.1 figure 10 comment.

Current text:

" A CANCEL request sent by an intermediary that has not received a UUID
   from the destination UA MUST construct a Session-ID header value
   exactly like the INVITE to that UA, with the known "local-uuid" value
   for the initiating UA and the null UUID as the "remote-uuid" value
   for the destination UA."

Suggested text: "A CANCEL request sent by an intermediary MUST construct a
Session-ID header value exactly like the INVITE's Session-ID."

Similar text should likely be added to section 6; for instance, maybe after
the next-to-last paragraph which indicates UAs MUST take care concerning
forking interaction.


> >Section 7 paragraph 7: Should potentially recommend what should occur
> >when B2BUA sends re-INVITE without SDP to obtain SDP to setup another
> >session.
> >More specifically, should the re-INVITE contain a new 3PCC generated
> >UUID?
> >The other options would be to resurrect the discarded UUID or use the
> >currently connected session's UUID.
>
> What changes in the text are you proposing?  The temporary value would
> persist until such time as a the 3PCC device learns what the actual UUID
> values are for Alice or Bob.  If a re-INVITE is sent, the 3PCC device
> would send
> either the same fabricated UUID to Bob if it does not know Alice's UUID.
> Or,
> it will send Alice's UUID if it knows it.

The 3PCC device can send a re-INVITE without SDP to Alice to connect Alice
to device X instead of Bob.  X's UUID would be within the Session-ID of
re-INVITE's ACK; however I'm currently not sure what UUID the draft is
recommending the 3PCC to place within re-INVITE.  Allowing the 3PCC device
to do whatever (or interpret however) it wants is okay with me; however I
thought the draft might want to clarify what should occur.

For instance, see RFC 3725 section 10.2 figure 13.  After the Controller
sends re-INVITE to place the Called Party (Bob) on hold, the Controller
sends re-INVITE (message 4) to connect Pre-Paid User (Alice)  to Media
Server (X).  I'm attempting to understand which UUIDs should go within
message 4's Session-ID.


> >Section 9.1: Concerning the SIP messages, the B2BUA appears to be a
> >proxy.
> >Thus from a RFC 7092 perspective, I guess that it is a Proxy-B2BUA that
> >hasn't originated any requests.
>
> B2BUAs don't have to originate requests.  This example (and all others
> that
> use B2BUA) shows a classic B2BUA.  I don't think it will help to make this
> clearer introducing a new type of device like "Proxy-B2BUA".

I was just commenting that the example looked like a proxy instead of a
B2BUA.  However if intentional, that is okay with me.


> >Section 9.1: The F4 Contact or F5 Request-URI potentially need a
> >different ip-address (although maybe reflecting missing Record-Route
> >without "lr").
> >F4 Contact reflects F3 Contact and doesn't match F5 Request-URI.
>
> I think you're saying that F4 needs to contain a Record-Route header.
> Correct?

Yes; unless Record-Route and Route were considered non-essential headers
(and the Request-URI was reflecting B2BUA's Record-Route entry which had no
lr).

Concerning draft-ietf-insipid-session-id-11... if Record-Route and Route are
considered essential, Record-Route should likely be added to F2 and F3; and
Route should likely be added to F5.


> >Section 9.1: Concerning F6, the B2BUA's Via header appears to be
> >missing.
> >And existing Via should contain a received parameter.
>
> Fixed (I think; please check the next draft I'll post for this all
> other corrections).

The fix looks okay to me.


> >Section 9.4 bullet 4: Potentially should clarify why this example is
> >quickly updating the Session-ID but section 9.3 example does not.
>
> I'm not sure what you are referring to here.  Nowhere do we purposely go
> out of the way to update a Session-ID.  Those values are only updated
> when there is otherwise a reason to send a message.

Figure 4 indicates "(to change the UUID to M')" within several locations
when sending re-INVITE.  Similarly section 8 has MUST statements which
appear to require the MCU to update the Session-ID.  Thus if the MCU didn't
otherwise have a need to send the re-INVITE, section 8 appears to require
sending re-INVITE to fix the Session-ID.


> >Section 9.8.1 figure 10: What should be the CANCEL session-id if Bob-1
> >had
> >sent two 18x creating two early dialogs with Session-IDs {B1x, A} and
> >{B1y, A}?
>
> I don't fully understand your question.  However, if there is a single
> call initiated from Alice to Bob-1, then there would only be {B1} at
> Bob-1, not {B1x} and a {B1y}.  If you're asking about the case where
> Alice made two separate calls to Bob-1, then Alice would be using two
> separate {A1} and {A2} values.

See my section 7 paragraph 6 comment.  If it helps, consider situation of
Alice having an outbound B2BUA which sends CANCEL while Bob's B2BUA is using
a simultaneous ringing service (instead of Call Forward No Answer service).
Should Alice's B2BUA include Session-ID {A, B1} or {A, B2} within the CANCEL
sent to Bob's B2BUA?

If I understand correctly, Figure 10 and section 7 paragraph 6 currently
imply that Alice's outbound B2BUA would send CANCEL with Session-ID {A, B1}
or Session-ID {A, B2} instead of Session-ID {A, N}.  I'm suggesting that
Figure 10 and section 7 paragraph 6 potentially be updated to indicate that
Session-ID {A, N} would be sent.


> >Section 10 last bullet: Should potentially reword the bullet. I'm not
> >sure if second sentence is indicating to ignore unknown parameters,
> >remove
> >unknown parameters, or something else (like reiterating that the above
> >bullets do not apply to them).
>
> I tried to fix that.  Please let me know if this is clearer.

Sounds okay to me.