Re: [MEDIACTRL] Fw: New Version Notification for draft-ietf-mediactrl-mrb-13.txt

["Worley, Dale R (Dale)" <[e-mail]>]

(I've appended the essential parts of Lorenzo's message for reference.)

I've forgotten many of the details of the MRB protocol, so accept my
apologies for anything I've mis-stated.

In regard to offerless INVITEs, it is desirable to support them if there
is a reasonable way to do so, because they are a standard part of SIP
and many scenarios assume that they are supported.  On the other hand,
in most MRB applications, the AS knows that it is sending the request to
an MRB, so it would be possible to assume a limited range of scenarios.

Given Lorenzo's breakdown of the possible cases, (1) and (2) *require*
consumer request XML, and therefore cannot happen in the case of an
offerless INVITE.  So only case (3) can apply, which is what Lorenzo
recommends.  Of course, in order for the MRB to implement that, it must
have some sort of "default policy" determining which MS the request is
routed to if there is no SDP.  That MS will provide the offer SDP, which
will be sent back to the AS in the INVITE response.  If there are MSs of
widely varying capabilities, it may be that the MRB cannot implement a
"good" default policy, but that seems to be unavoidable.

A more complex case is a "virtually offerless" INVITE, where the AS
provides Consumer request XML but does not provide SDP (presumably
because the originator of the call did not provide SDP).  This could be
done by providing just a Consumer request XML as a body, or by providing
a multipart body with only one part, the Consumer request XML.  It
appears from Lorenzo's cases, that this situation is distinguishable
from the "normal" cases.  I would expect that the MRB could then process
and act on the Consumer request XML as normal, but if it establishes a
session with the MS (by sending an INVITE), it can know to send an
offerless INVITE.

So it seems to me that there is never any ambiguity as to what the MRB
"should" do, and it's not difficult for the MRB to do the right thing.
The difficulty is to warn the implementers what the "offerless" cases
are and beware to implement them.

Or am I perhaps overlooking something?

Dale


On Tue, 2012-07-10 at 15:46 +0200, Lorenzo Miniero wrote:

> The problem in giving a simple aswer to this point is that,
> considering the different scenarios that may occur in the IAMM mode, an
> offerless INVITE could confuse the MRB. Specifically, as you'll know if
> you read the draft, an INVITE reaching the MRB in IAMM mode can be any
> of the following:
> 
>    1) an INVITE an AS sends to request a new session, or update an
>    existing one, to the MRB, and negotiate a control channel with one
>    of the chosen MS (in this case, the payload is multipart, containing
>    both the Consumer request as XML and the SDP to negotiate the control
>    channel);
> 
>    2) an INVITE an AS sends to request a new session, or update an
>    existing one, to the MRB, and attach a media session to a MS (in this
>    case too, the payload is multipart, containing both the Consumer
>    request as XML and the SDP to negotiate the media streams);
> 
>    3) an INVITE an AS sends to just attach a media session to a MS (in
>    this case, the payload only contains the SDP to negotiate the media
>    streams).
> 
> All of the above scenario are documented in the Examples sections, for
> an easier understanding of how they're conceived.
> 
> The problem with offerless INVITEs is that the MRB might (WILL) be
> confused about what the AS is asking for. The easy way out might be
> just saying "the MRB doesn't support offerless INVITEs", but this could
> look overly restrictive. An alternative might be adding some text that
> explains that, whenever an MRB receives an offerless INVITE, it must
> assume it is related to the 3) case, that is, an AS will only
> originate such INVITEs when trying to attach a media dialog to a MS.