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

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 10 Jul 2012 15:46:42 +0200

Dear all,

during his AD review of the MRB draft, Robert provided us with a lot of
excellent feedback, which greatly helped improving the document. The
result so far is this new version I've just submitted, which will
hopefully need just some editorial refinement to be considered complete.

There's still a pending issue, though, that Robert asked us to bring to
the list. In order to help you understand what the issue is about, I'll
paste here the exact point Robert raised:

   The 4th bullet of section 5.2.2.1's third list of bullets inspires
   the question of whether MRBs in IAMM support offerless invites.
   Please make it clear in the document what an MRB should do with an
   INVITE that contains no SDP.  

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.

Of course these are just a few alternatives that have come to my mind:
if you have any feedback or suggestion on how to best proceed on this
matter and close this final issue, please let us know.

Thanks,
Lorenzo

Inizio messsaggio inviato:

Data: Tue, 10 Jul 2012 06:25:12 -0700
Da: [email-masked]
A: [email-masked]
Cc: [email-masked], [email-masked]
Oggetto: New Version Notification for draft-ietf-mediactrl-mrb-13.txt

A new version of I-D, draft-ietf-mediactrl-mrb-13.txt
has been successfully submitted by Lorenzo Miniero and posted to the
IETF repository.

Filename:	 draft-ietf-mediactrl-mrb
Revision:	 13
Title:		 Media Resource Brokering
Creation date:	 2012-07-10
WG ID:		 mediactrl
Number of pages: 142
URL:
http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-mrb-13.txt
Status:
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb
Htmlized:        http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-13
Diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-mediactrl-mrb-13

Abstract:
   The MediaCtrl work group in the IETF has proposed an architecture for
   controlling media services.  The Session Initiation Protocol (SIP) is
   used as the signalling protocol which provides many inherent
   capabilities for message routing.  In addition to such signalling
   properties, a need exists for intelligent, application level media
   service selection based on non-static signalling properties.  This is
   especially true when considered in conjunction with deployment
   architectures that include 1:M and M:N combinations of Application
   Servers and Media Servers.  This document introduces a Media Resource
   Broker (MRB) entity which manages the availability of Media Servers
   and the media resource demands of Application Servers.  The document
   includes potential deployment options for an MRB and appropriate
   interfaces to Application Servers and Media Servers.

The IETF Secretariat

-- 
Lorenzo Miniero, COB

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 10 Jul 2012 16:19:17 +0200

I guess my opinion would be that the offerless INVITE is a valid SIP INVITE, and therefore it should attempt to apply the MRF selection policy on such an INVITE.

Either it can do that successfully, or it can reject the request back to the source and wait for the source to come to a better request.

Given that the source may not know an MRB is involved, I am not sure that we can preclude offerless INVITES.

What is not possible is changing the MRB decision after the selection policy has been applied. Therefore if the SDP finally resolves to being video, and the decision was made on the assumption that it would turn out to be speech, then the MRF selected is not reversible, except by one entity clearing and trying again.

However in many scenarios, something can be made to work.

My view is just cover these considerations in informative text, and allow offerless INVITES (or at least not preclude them).

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Lorenzo Miniero
> Sent: 10 July 2012 14:47
> To: [email-masked]
> Cc: Chris Boulton
> Subject: [MEDIACTRL] Fw: New Version Notification for draft-ietf-
> mediactrl-mrb-13.txt
> 
> Dear all,
> 
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 11 Jul 2012 15:11:05 +0200

Keith,

thanks for your feedback!
If nobody opposes to this view, we'll incorporate your suggestion in
the next version of the draft to make it clearer for readers.

Lorenzo

Il giorno Tue, 10 Jul 2012 16:19:17 +0200
"DRAGE, Keith (Keith)" <[email-masked]> ha scritto:

> I guess my opinion would be that the offerless INVITE is a valid SIP
> INVITE, and therefore it should attempt to apply the MRF selection
> policy on such an INVITE.
> 
> Either it can do that successfully, or it can reject the request back
> to the source and wait for the source to come to a better request.
> 
> What is not possible is changing the MRB decision after the selection
> policy has been applied. Therefore if the SDP finally resolves to
> being video, and the decision was made on the assumption that it
> would turn out to be speech, then the MRF selected is not reversible,
> except by one entity clearing and trying again.
> 
> My view is just cover these considerations in informative text, and
> allow offerless INVITES (or at least not preclude them).
> 
> Keith
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Lorenzo Miniero
> > Sent: 10 July 2012 14:47
> > To: [email-masked]
> > Cc: Chris Boulton
> > during his AD review of the MRB draft, Robert provided us with a
> > lot of excellent feedback, which greatly helped improving the
> > document. The result so far is this new version I've just
> > submitted, which will hopefully need just some editorial refinement
> > to be considered complete.
> > 
> > 
> > There's still a pending issue, though, that Robert asked us to
> > bring to the list. In order to help you understand what the issue
> > is about, I'll paste here the exact point Robert raised:
> > 
> >    The 4th bullet of section 5.2.2.1's third list of bullets
> > inspires the question of whether MRBs in IAMM support offerless
> > invites. Please make it clear in the document what an MRB should do
> > with an INVITE that contains no SDP.
> > 
> > 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:
> > 
> >    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);
> > 
> >    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.
> > 
> > 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.
> > 
> > Of course these are just a few alternatives that have come to my
> > mind: if you have any feedback or suggestion on how to best proceed
> > on this matter and close this final issue, please let us know.
> > 
> > 
> > Thanks,
> > Lorenzo
> > 
> > 
> > 
> > Htmlized:
> > http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-13 Diff:
> >    The MediaCtrl work group in the IETF has proposed an
> > architecture for controlling media services.  The Session
> > Initiation Protocol (SIP) is used as the signalling protocol which
> > provides many inherent capabilities for message routing.  In
> > addition to such signalling properties, a need exists for
> > intelligent, application level media service selection based on
> > non-static signalling properties.  This is especially true when
> > considered in conjunction with deployment architectures that
> > include 1:M and M:N combinations of Application Servers and Media
> > Servers.  This document introduces a Media Resource Broker (MRB)
> > entity which manages the availability of Media Servers and the
> > media resource demands of Application Servers.  The document

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 11 Jul 2012 12:09:57 -0400

(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

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 12 Jul 2012 12:00:52 +0200

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)" <[email-masked]> ha scritto:

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

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

Thanks,
Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.