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

[Brett Tate <[e-mail]>]

Hi,

Thanks for the response; reply is inline.  If I mention the draft, I'm
referring to February 18 version of "-14".

> Ideally, SBCs would leave these values alone.  There are cases
> where SBCs might autonomously generate messages (as Paul K
> pointed out), so saying something about tracking these values
> is OK.

I guess that you were not understanding my use of "generating (instead of
relaying) subsequent requests and responses".

They are not all necessarily "autonomously generated" unless you consider
situations such as 3PCC activity stimulated by a user to have been
"autonomously generated" by the intermediary.


> The text with your addition says the value might be tracked,
> but generally the SBC should not alter the UUIDs.  Perhaps
> this tweak helps?

The current text indicates "intermediaries MUST NOT alter the UUID values".

The "intermediaries MUST NOT alter the UUID values" cannot be met because of
race conditions.  Does INSIPID prefer intermediaries try (and occasionally
supply incorrect values) or don't try at all?  Either way if operators were
requesting this draft, I assume operators will prefer intermediaries do the
best they can even though the MUST NOT might occasionally be violated.


> "Intermediaries MAY track the Session Identifier values
> associated with a transaction and dialog.  However, since
> it is generally NOT REQUIRED and because of other reasons,
> they might provide inaccurate Session-ID values when
> generating related requests and responses.  As a general
> rule, intermediaries MUST NOT alter the UUID values found
> in the Session-ID header, except as described in this
> section.  When autonomously originating a message, an
> intermediary MAY insert a tracked UUID value, or the “null”
> UUID or a locally generated UUID (in the case that there
> is no known UUID for the peer UA), or not include the
> Session-ID header at all to avoid miscommunicating an
> incorrect UUID value."

Doesn't this paragraph violate RFC 7206 requirement 1?


> >Consider the following race condition where the UPDATEs
> >cross between A and the proxy. If the proxy generates
> >a 407, SHOULD/MUST it indicate {C,A}, {B,A}, or something
> >else? What draft snippet supports your answer?
> >
> >A proxy
> >
> >--> UPDATE {A,B}
> ><-- UPDATE {C,A}
> ><-- 407 {?,A}
> >
> >Do you think intermediaries which generate (instead of
> >relay) requests such as BYE SHOULD/MAY/MUST track the
> >Session-ID UUIDs so that the BYE could contain the same
> >UUIDs within the Session-ID? If so, where is it
> >mentioned within the draft.
>
> I don't want to require them to track.  I would be OK if
> they inserted the "null" UUID when they do not know a vlaue.

Inserting "null" could impact the next Session-ID.  More specifically, it
might cause next UPDATE to contain {A, N}.


> As for the above exchange, why would a 407 be sent in response to an
> UPDATE?

Stale nonce, qop not used, et cetera.


> Wouldn't that be sent perhaps on an initial INVITE?

Maybe.  It depends upon if UPDATE sent in same direction as initial INVITE.


> In any case, I would expect the SBC (if it tracks UUID
> values) to send {C,A} since it knows that C is on the
> right side.

If instead of UPDATE glare, the 407 and UPDATE were reordered (i.e. 407 sent
in same direction before UPDATE); the 407 with {B,A} might be received after
UPDATE with {C,A}.  Similar to what can occur with intermediaries, A doesn't
know the correct remote-uuid; it only thinks that it knows the correct
remote-uuid.


> OK, how about this re-wording:
>
> "When an intermediary originates a request or response,
> such as a provisional response or a response to a CANCEL
> request, or a BYE message, the “remote-uuid” field will
> contain the UUID value of the receiving UA .  When the UUID
> of the other peer UA is known, the intermediary MUST insert
> the UUID of the peer UA in the “local-uuid” field of the
> message.  Otherwise, the intermediary MAY set the
> “local-uuid” field of the message to a locally generated
> UUID value or the null UUID value."

The "will contain" conflicts with the prior "MAY track" of section 7
paragraph 2.


> >If A receives the following at about the same time, does A
> >"know" that the remote-uuid is B or C? A can only assume
> >that they were sent in the order received.
> >
> >200 response with {B,A}
> >UPDATE with {C,A}
>
> It should know.  If the endpoint cannot determine its
> current state, we have a larger issue.  It should know from
> the CSeq value or state transition which message is newer.

As RFC 6141 section 4.8 indicates, SIP provides no mechanism to ensure such
a thing.  From the receivers perspective, it is occasionally indeterminate.


> >>  The one piece of text that is missing is a statement that
> >>  says something like this as a final paragraph in section 7:
> >>
> >>  ====
> >>  Having said the foregoing, intermediaries that manipulate
> >>  messages containing Session-ID header values should be
> >>  aware of what values were last received by an endpoint
> >>  and, following any kind of service interaction initiated
> >>  or affected by the intermediary, of what values the
> >>  receiving endpoint should have knowledge to ensure that
> >>  both endpoints in the session have the correct and same
> >>  values. If an intermediary can determine that an endpoint
> >>  might not have received a current, correct Session-ID
> >>  header value, the Intermediary SHOULD attempt to provide
> >>  the correct Session-ID header value to the endpoint
> >>  such as by sending a re-INVITE message.
> >>  ====
> >>
> >>  How does that sound?

Concerning the first sentence, the "should be aware" conflicts with the
prior "MAY track" of section 7 paragraph 2.  Similarly, intermediaries
typically do not know what was "last received by an endpoint"; they know
what they "last sent towards an endpoint" and have little idea about how the
endpoint and other intermediaries will reconcile the various race conditions
(glare, retries, re-ordering, et cetera).


> >I guess that you changed your mind about if an intermediary
> >should ever send a request solely to update the Session-ID.
>
> Yeah.  With standard signaling, this won't be an issue.  But,
> if an SBC is going to do something proprietary to join together
> call legs, I suppose it should take the extra step to ensure
> that the UUID values are right.

It isn't really proprietary.  It can be as simple as a B2BUA generating a
request towards one of the devices; the response indicates a different uuid
(maybe null).  If the B2BUA wants to satisfy the SHOULD, it has to generate
extra messaging solely to try updating the other endpoint and avoid an
infinite change loop during the process.

Figure 3 should be updated to comply with sending a request solely to update
the Session-ID unless you want to highlight in the last bullet section 9.3
that the B2BUA didn't follow the SHOULD.  What was the reason why the B2BUA
didn't fix the remote-uuid within figure 3?  Doesn't the section 7 paragraph
3 MUST apply (or is that paragraph intended for a more limited purpose such
as during the transfer)?