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

[Lorenzo Miniero <[e-mail]>]

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)" <[e-mail]> 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.
> 
> 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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Lorenzo Miniero
> > Sent: 10 July 2012 14:47
> > To: [e-mail]
> > Cc: Chris Boulton
> > Subject: [MEDIACTRL] Fw: New Version Notification for draft-ietf-
> > mediactrl-mrb-13.txt
> > 
> > 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: [e-mail]
> > A: [e-mail]
> > Cc: [e-mail], [e-mail]
> > 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
> > _______________________________________________
> > MEDIACTRL mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mediactrl
> > Supplemental Web Site:
> > http://www.standardstrack.com/ietf/mediactrl



-- 
Lorenzo Miniero, COB

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