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

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: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On
> Behalf Of Lorenzo Miniero
> Sent: 10 July 2012 14:47
> To: mediactrl@ietf.org
> 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: internet-drafts@ietf.org
> A: lorenzo@meetecho.com
> Cc: gamunson@att.com, chris@ns-technologies.com
> 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
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl