[MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10: technical question

[[e-mail] (Dale R. Worley)]

While reviewing draft-ietf-mediactrl-call-flows-10, one of the few
technical issues I found is this item.  I've extracted it from my
review, and I quote it below for your reference.  But it seems to be
an issue that is more general than that particular section of the
draft.

The problem is that if an AS establishes a CFW connection with an MS,
how can it route a call (SIP INVITE for media) to that same MS?  The
problem is that the URI that the AS has to locate the MS may resolve
to multiple MS instances.  So there's no guarantee that the the media
INVITE will be routed to the same MS that the CFW INVITE was routed
to.

What bothers me about this is that this problem is discussed in RFC
6230 section 3, but I can't find the specification of a solution to
this problem.  The text tells only how to ensure that once the CFW
INVITE and its response have been exchanged, the AS can reliably send
a TCP SYN to the MS that generated the CFW 200.  (It does that by
sending the SYN to the c= address in the 200.)  It doesn't tell how a
subsequent media INVITE is sent to that same MS.  But clearly the
authors worried about that problem, and presumably solved it, so I
must be missing something.

On the other hand, in section 7.3.2 of this draft, there is a
discussion of a very similar problem when an MRB is operating in
"inline-unaware" mode:  The AS sends a CFW INVITE to the MRB (thinking
the MRB is an MS), and the MRB forwards the CFW INVITE to a MS.
Apparently, there is no certain way for the MRB to forward a
subsequent media INVITE from the same AS to the chosen MS.  ...  And
yet, a solution to the problem in the paragraph above would seemingly
solve the problem in section 7.3.2.

Can anyone fill me in on what I'm missing?

Dale

    item 53) section 7.3.2

       While apparently not a problem, this raises an issue when the same
       unaware AS has several sessions with different MS: the AS would only
       see one "virtual" MS (the MRB) and so it would relay all calls there,
       making it hard for the MRB to understand where these media dialogs
       should belong: specifically, whether the UAC calling belongs to the
       AS application logic leading to MS1 or MS2, or wherever else.

    This seems to be a deficiency in the CFW protocol:  If the AS
    establishes a CFW channel with the MS (via a SIP URI to an MRB), and
    then later the AS wants to addresses a SIP INVITE to the MS, it has no
    choice but to use the same SIP URI (which routes to the MRB).  This
    makes it impossible for the MRB to associate the SIP INVITE with the
    CFW connection, and thus it is difficult for the MRB to route the
    INVITE to the same MS.

    What seems to be needed is for either the COMEDIA response
    (application/cfw) or CFW connection to provide a SIP URI that is the
    "real" SIP URI of the far-end of the CFW channel.

    Actually, this seems to be a problem even if an AS is addressing an MS
    URI, but the URI resolves to a redundant set of MSs:  There seems to
    be no way to ensure that when a CFW channel is established that a
    subsequent SIP INVITE can be sent to the same MS.  This issue seems to
    be discussed in RFC 6230 section 3, but I can't find any solution
    there.