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

[Lorenzo Miniero <[e-mail]>]

Hi Dale,

thanks for your feedback! I added a few comments inline.


Il giorno Wed, 11 Jul 2012 12:09:57 -0400
"Worley, Dale R (Dale)" <[e-mail]> ha scritto:

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


About this second scenario you're describing, this might not be that
easy. In fact, a few meetings ago (I think it was in Anaheim but I
may be wrong) what was supposed to be in the INVITE for the IAMM case
was discussed, and if I recall correctly there were objections about
having just the Consumer XML in the INVITE (that is, having the SIP
case act mostly like HTTP in the Query mode), since this would have
caused several problems according to how SIP works (but that may have
been related to the fact we involved redirects as well). This lead us to
eventually move to what we have in the draft now, that is the multipart
stuff.

That said, having just the Consumer XML in an INVITE (either as it is
or as a multipart with only the XML) could probably confuse the MRB
anyway: in fact, the Consumer XML may at the moment appear in either
case 1) or 2) of my previous mail, and so the MRB would still not know
whether it is supposed to negotiate a control channel or a media
dialog which, as you pointed out, may be part of the decision process
behind the MRB policy. But if this is a legitimate scenario, do you
think that just clarifying this in the draft, together with the points
Keith made, to be enough?


> 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?
> 


I think what Robert wanted to warn us about in his review, is that
keeping silent on what to do in the MRB for offerless INVITEs could
lead to trouble, and so just warning them without providing some
guidance might not be enough. But if there is actually a standard
behaviour implementors can follow, my opinion is that just by
highlighting the possible scenarios and warning about them as you
suggested might be the path to follow.


> Dale
> 


Thanks,
Lorenzo


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



-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com