Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-02.txt

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Mon, 4 Jan 2010 21:35:43 -0500

Hi Chris/Lorenzo/all,

The way I read your responses is that we agree to incorporate/reflect
both (A) and (B) below in prior emails. (And again, to my thinking, this
specification is powerful/flexible enough to support both, and to limit
it only to (B) would be unnecessarily constraining and less useful.)

In which case, my overlay comments to Lorenzo's that were to my original
comments (see Lorenzo's Dec. 24 email below) are:

1) We need to explicitly state somewhere that we assume that the same
SIP URI can be used to identify a given MS Resource for both control
channel establishment and call leg establishment. 
   [Because ... if not, then we have more work to do. For example, we
don't want the AS to have to 'Query' the MRB for a control channel SIP
URI and then have to come back to it again for the SIP URI for
establishing call legs to it, or else we have to allow for two SIP URIs
in the MRB response to the AS and indicate which is which.]

2) It would be helpful to state that nothing precludes an MS Resource
from having a variety of capabilities (such as both some kinds of IVR
and some kinds of conferencing) associated with the same SIP URI.

3) It should be stated that Query and In-Line IAMM or IUMM can be used
without or without a control channel.

3) It is important to further amplify on some of the ways, and some
associated limitations, that this toolkit can be used, especially in two
regards (maybe there's more?) - how MRB knows when resources are freed
up, and how conferencing legs for the same conference all get to the
same MS Resource.
Whether this might best addressed in a new "Considerations on
Approaches" section or sprinkled piecemeal in the existing text is
editors' choice.
But I think we want to make sure we fundamentally cover
 a) For MRB to know when MS resources are freed up
     - lease mechanism works for Query or IAMM
     - leaving/having MRB in call leg signaling path works for IAMM and
IUMM
     - could also rely on status update info over Publish for any of
Query, IAMM or IUMM
    Left to implementation and context to decide what to do 
      
  b) For conferencing to ensure that all the legs get to the same MS
Resource
         - For Query, AS knows SIP URI of MS resource, so can send all
legs to same one
         - Ditto for IAMM using MRB to establish the control channel,
but send call legs directly to
           the identified MS resource (not clear to me whether this also
applies to IUMM)
           SIP URI of the identified MS resource
         - For IAMM and IUMM when sending call legs through MRB, one
could rely on providing the conference ID in 
           the SIP INVITEs

  c) If the MRB gets a SIP INVITE, how does it know whether to treat it
in Query mode or IAMM mode? Presumably that would have to be a rule
specified within MRB. Which could vary based on context, e.g., such as
which application the request came from. 

  d) This specification isn't exhaustive on considerations/limitations
of approaches (e.g., what happens if you use IAMM initially for a
control channel and then also send call leg requests through it - what's
good and bad about that ...; or MRB maintaining sanity between what is
deduces from requests wrt control SDP and requests wrt call leg SDP in
In-Line mode)

(Side note: With In-Line, having MRB staying in the signaling path for
call legs *can* be good. For IVR applications, that can be a
straightforward, timely and efficient way for MRB to know when the
requested MS resources are freed up.)

Thanks.

Cheers & Happy New Year!,

Gary

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Monday, January 04, 2010 4:00 AM
To: Lorenzo Miniero
Cc: MUNSON, GARY A, ATTLABS; [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-02.txt

Some additional comments in-line.

Chris.

>> Hi Lorenzo and folks,
>>
>> I was formulating responses to some of your specific
>> replies below, but began to suspect that perhaps there's a
>> single underlying issue that needs clearing up first
>> regarding IAMM. Let me explain the way I see IAMM working.
>>
>> (A) The way I have been thinking: The AS sends an INVITE
>> to MRB with (1) SDP characterizing the *call leg* it wants
>> to send to an MS and (2) MS characteristics it wants for
>> that call leg. MRB picks one and sends a modified INVITE
>> along to the MS. When there is a response from the MS, MRB
>> will insert toward the AS the SIP uri of the chosen MS,
>> which can be used as the basis for the AS 'directly'
>> establishing a control channel with the MS, or the AS
>> knowing that it already has one.
>>
>> (B) Are you thinking instead that with IAMM the SDP is
>> characterizing the control channel it wants? And then the
>> AS has the opportunity to set up call legs 'directly' to
>> the MS without the SIP signaling going through the MRB? I
>> had not been thinking that, although treating these MRB
>> interfaces as a toolkit, I could see that as a
>> possibility.
>>
>>     
[Chris] Agreed.  There is nothing stopping the MRB from inserting itself

into the signalling path of ALL signalling.  As you said, the toolkit 
does not preclude that option.

>> It seems to me that we need to cover the way I had been
>> thinking about it, because there's no necessity of a
>> control channel between the AS and MS (e.g., AS could be
>> happy using 4240 in a given situation). In addition one
>> could use MRB a la (B), but it does raise some more
>> questions - like how MRB knows when the MS resources are
>> freed up.
>>     
>> Yes, the way we handle it ATM is (B). This was the choice
>> considering the focus was actually on MEDIACTRL-aware
>> entities, and as a consequence on the Control Channel
>> itself. Besides, we'd rather not have the MRB on the
>> signalling path the whole time, being its scope more that of
>> a locator.
>>     
[Chris] Agreed.
>> Anyway, I think we could also add some way to achieve the
>> sort of behaviour you mentioned. I'm thinking of two
>> possible approaches:
>>
>> 1) the AS places an INVITE with just the Consumer payload
>> (no SDP) to the MRB, and gets the answer in the 200, also
>> allowing for SIP just as an additional transport for the
>> interface; this would allow the AS to deal with the creation
>> of a control channel and redirection of call legs according
>> to its business logic, exactly as in the Query mode;
>>
>> 2) or, in case we still mandate the multipart/mixed payload
>> for the creation of the control channel in IAMM, we could
>> envisage similar approaches when it comes to 4240-like
>> scenarios; for a call leg, the AS adds a Consumer payload to
>> the INVITE before sending it to the MRB (multipart/mixed but
>> with a media SDP this time) which in turn makes use of the
>> Consumer info to redirect the call to a specific MS.
>>
>> What do you think of it? Do you think they could cover the
>> scenarios you had in mind?
>>
>>     
[Chris] I need to think about it a little more BUT I am leaning towards 
(2) as it provides consistency with using the SDP to identify the type 
of connection that we are dealing with.  I am not against (1) so open to

suggestions.
>> The MRB being aware of resources being freed up can be a
>> concern, but it's the same for both Inline and Query mode.
>> For that purpose, the lease mechanism can be exploited, or
>> explicit release messages by the AS.
>>
>>     
[Chris] Agreed.  The lease mechanism should be used regardless of the MS

trigger mechanism.  These are all good scenarios that we need to keep in

mind.

Chris.

>> Thanks,
>> Lorenzo
>>
>>
>>
>>     
>> -----Original Message-----
>> From: Lorenzo Miniero [mailto:[email-masked]] 
>> Sent: Thursday, December 24, 2009 10:56 AM
>> To: MUNSON, GARY A, ATTLABS
>> Cc: Chris Boulton; [email-masked]
>> Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-02.txt
>>
>> Hi Gary,
>>
>> thanks a lot for your detailed feedback! We're glad you
>> like how the doc is going on: hopefully, with the help of
>> your comments, next doc will be almost ready to go.
>>
>> Some comments inline [LM]
>>
>> Merry Christmas and Happy New Year to you as well!
>>
>> L.
>>
>>
>> On Mon, 21 Dec 2009 20:56:07 -0500
>> "MUNSON, GARY A, ATTLABS" <[email-masked]> wrote:
>>
>>     
>>> Hi Chris and Lorenzo,
>>>
>>> Firstly, thank you very much for all your work on this
>>> draft. Looking fairly complete!
>>>
>>> Below are comments from me. Unfortunately I won't be
>>>       
>> much help on sanity
>>     
>>> checking sections 6 and 7. Hopefully others will be.
>>>
>>> I'll be on vacation now through Jan. 1 and won't be
>>> looking at email much, so no rush to react to my
>>> comments. 
>>> Merry Christmas/Happy Holidays/Happy New Year,
>>>
>>> br,
>>>
>>> Gary
>>>
>>> --- GAM Comments below ---
>>>
>>>
>>>       
>>>>> General comments below <<
>>>>>           
>>> 1) For In-line, how does the AS know the identity of the
>>>       
>> MS for purposes
>>     
>>> of 
>>> establishing a mediactrl Control Channel to it? I don't
>>> think this described anywhere, 
>>> and it is an important point to cover conspicuously. (I
>>> do see a sentence in the para 
>>> after Figure 8 that seems to say at least for In-line an
>>>       
>> AS could send a
>>     
>>> Control dialog 
>>> to MRB, so MRB would select a MS resource for that; but
>>>       
>> if so, it raises
>>     
>>> more questions 
>>> for me, like which comes first, or how you guarantee
>>> that a Control request and the 
>>> corresponding call leg request end up at the same MS
>>> resource.)  
>>>       
>> [LM] That's a good point, and Chris and I discussed while
>> updating the doc. The Consumer interface now has, in the
>> <response-session-info> element of a reply, the SIP URI of
>> the MS that the MRB has chosen for the request. This means
>> that, both in Query and IAMM mode, the AS has a way to
>> directly contact the MS for what concerns that request
>> (e.g. attaching UACs there). This solves the issue, but
>> also removes the MRB from the signaling path, meaning it
>> won't be able to infer resources being freed by itself
>> (e.g. a UAC sending a BYE). In IUMM that becomes a problem
>> , since the AS is not aware of a MRB, and just sees it as
>> a MS. The only solution to this problem is to have the MRB
>> always the same MS when the same AS uses IUMM. If you
>> think these solutions are ok, we might add some text about
>> them in the doc to provide some guidance. Otherwise, any
>> comment (from you or from any other in the list of course)
>> is more than welcome.
>>
>>
>>     
>>> 2) For In-line, in the case of conferencing, how does
>>> the MRB know to send legs of the 
>>> same conference to the same MS resource? I would think
>>> by remembering the conference ID 
>>> supplied in the SIP for the first leg it sees. This
>>>       
>> should be described.
>>     
>>> (Not needed 
>>> for Query MRB).
>>>
>>>       
>> [LM] This can be seen as the same as 1). Or did you have
>> something different in mind?
>>
>>
>>     
>>> 3) The required/optional aspect of attributes on the
>>>       
>> Consumer interface
>>     
>>> is absent in 
>>> this draft. I had thought the conclusion of the last
>>> meeting (IETF 76) was to include
>>> it.
>>>
>>>       
>> [LM] Yes, there was consensus in Hiroshima. Anyway, there
>> also were some comments on the ML that raised a few
>> concerns about this approach, specifically a post by Mark
>> Syrett:
>>
>>
>>     
> http://www.ietf.org/mail-archive/web/mediactrl/current/msg01433.html
>   
>> and the following posts. After that, the idea was that we
>> first needed to better investigate pros and cons of such
>> an approach, considering it could be considered harmful. I
>> guess it would be a good idea to keep on discussing about
>> this on the ML and update the doc accordingly. At the
>> moment, the important thing to have was a more or less
>> complete Consumer Interface per se: now that we have it,
>> we can shape and improve it.
>>
>>
>>     
>>>>> Specific sections comments below <<
>>>>>           
>>> 1) Section 1 Intro 1st paragraph. Say "selection"
>>>       
>> instead of "location".
>>     
>>>   > Because generally location is taken to mean actual
>>>       
>> location in some
>>     
>>> sense, which 
>>> isn't what is intended here.
>>>
>>>       
>> [LM] Thanks, noted.
>>
>>
>>     
>>> 2) Section 1 Intro, para above Figure 3, add words ...
>>> "In this model there are a 
>>> number (greater than 1) of application servers *,
>>> possibly supporting dissimilar 
>>> applications,* controlling a single media server."
>>>
>>>   > Because while the draft acknowledges MS resources
>>> are not necessarily homogeneous, 
>>> nowhere does it yet say likewise for applications/ASes,
>>> and that's an important point.
>>>
>>>       
>> [LM] I agree, noted.
>>
>>
>>     
>>> 3) In Abstract and Section 1, instead of "1:M and M:M"
>>> say either "1:Many and 
>>> Many:Many" or "1:M and M:N"
>>>
>>>   > Because implication is generally that M stands for
>>> an arbitrary number, but then 
>>> M:M would imply same number of AS and MS, which we don't
>>> mean. 
>>>       
>> [LM] Thanks, that was proably a typo, noted.
>>
>>
>>     
>>> 4) Section 2, Media Resource Broker MRB term. Change
>>> description to  
>>>     A logical entity that is responsible for
>>>       both collection of appropriate published Media
>>>       Server (MS) information and selecting appropriate
>>>       MS resources on behalf of consuming entities.
>>>
>>>   > Because the current description says "... and
>>>       
>> supplying appropriate
>>     
>>> MS information 
>>> to consuming entities", which is isn't really to the
>>>       
>> point at least for
>>     
>>> In-Line use.
>>>
>>>       
>> [LM] You're right, noted.
>>
>>
>>     
>>> 5) Section 2, Query MRB, change "location" to "address"
>>>
>>>   > Because 'location' is tended to mean actual location
>>> as in presence/location and/or 
>>> as in media-server-location
>>>
>>>       
>> [LM] Thanks, noted.
>>
>>
>>     
>>> 6) Section 2, In-line MRB, change description to 
>>>    
>>>     An instantiation of an MRB (See definition) that
>>>       directly receives requests on the signalling path.
>>> There is no separate query.
>>>
>>>   > Because present description says "decision making
>>>       
>> process is totally
>>     
>>> delegated to 
>>> the MRB" which a good characterization because (a) even
>>> for Query MRB, it's the MRB that 
>>> decides/picks an MS resource and (b) the AS can provide
>>>       
>> the same kind of
>>     
>>> information 
>>> with IAMM In-line as for Query.
>>>
>>>       
>> [LM] Actually, as you say in IAMM the query is still there
>> , even if it's part of the INVITE (the multipart/mixed
>> payload). Do you think just clarifying that the HTTP
>> interface is not involved will be enough?
>>
>>
>>     
>>> 7) Section 3, para 3, say "selection decisions" instead
>>> of "routing decisions".
>>>
>>>       
>> [LM] Thanks, noted.
>>
>>
>>     
>>> 8) Section 4, para 4. Revise that para to
>>>
>>>   Please note that there may be additional information
>>> that it is desirable for the MRB 
>>> to have for purposes of selecting an MS resource, such
>>> as resource allocation rules 
>>> across different applications, planned or
>>>    unplanned downtime of Media Server resources, the
>>>       
>> planned addition of
>>     
>>>    future Media Server resources, or MS resource
>>> capacity models. How the MRB acquires 
>>> such information is outside the scope of this document.
>>>
>>>   > Because the real point is that there are additional
>>> things the MRB might want to 
>>> know about MS resources to factor into its decision
>>>       
>> making process. It's
>>     
>>> not about what 
>>> else the AS might want to know.
>>>
>>>       
>> [LM] Good point, noted.
>>
>>
>>     
>>> 9) Section 4.1. At the very end of the section, last
>>>       
>> paragraph, add the
>>     
>>> sentence 
>>> "Additionally, with Query MRB, the MRB is not in the
>>> signaling path between the AS and 
>>> the selected MS resource."
>>>
>>>   > Because this is a useful distinction between Query
>>> and In-line to highlight.
>>>
>>>       
>> [LM] If we take into account the possible solution
>> proposed in 1), this also does not apply in IAMM mode,
>> since the AS would be aware of the MS that was chosen. At
>> least, that's true for UAC calls to proxy, while it's also
>> true that in the IAMM case the MRB will be in the path for
>> the Control Channel SIP dialog.
>>
>>
>>     
>>> 9a) Section 4.2, first para, revise to
>>>
>>>    The "In-line" MRB is architecturally different from
>>>       
>> the "Query" model
>>     
>>>    that was discussed in the previous section.  The
>>> Concept of a separate "Media
>>>    Server Consumer Interface" disappears.  The client of
>>>       
>> the MRB simply
>>     
>>>    uses the media server control and media dialog
>>>       
>> signalling to involve
>>     
>>> the MRB.  This  
>>>   type of deployment is illustrated in Figure 8.
>>>
>>>   > Because the current para talks about offloading the
>>>       
>> decision making
>>     
>>> process, but 
>>> that's the MRB role for Query or In-line, so isn't a
>>>       
>> distinction. (Also,
>>     
>>> it's Media 
>>> Resource Consumer Interface, not Media Server Consumer
>>>  Interface.) 
>>>       
>> [LM] Thanks, noted.
>>
>>
>>     
>>> 10) Section 4.2, the two paragraphs below Figure 8.
>>> Revise what is currently there to
>>>
>>>    The Media Servers still use the 'Media Server
>>>    Publishing Interface' to convey capabilities and
>>>    resources to the MRB - as illustrated by (1).  The
>>>       
>> media server Control and Media dialogs are sent to the MRB
>>     
>>>    (2) which then selects an appropriate Media Server
>>>       
>> (3) and would stay
>>     
>>> in the 
>>> signaling path between the AS and the MS resource for
>>> those dialogs. 
>>>   In-line MRB can be split into two distinct logical
>>>       
>> roles which can be
>>     
>>>    applied on a per request basis.  They are:
>>>
>>>    In-line Unaware MRB Mode (IUMM):  Allows an MRB to
>>>       act on behalf of clients requiring media services
>>>       who are not aware of an MRB or its operation. In
>>> this case the AS does not provide explicit information
>>>       on the kind of MS resource it needs (as in Section
>>> 5.2) and the MRB is left to deduce it
>>>       by potentially inspecting other information in the
>>> request from the AS; for 
>>>       example, SDP content, or 
>>>       address of the requesting AS, or additional
>>>       
>> Request-URI parameters
>>     
>>> as per RFC 4240.
>>>
>>>    In-line Aware MRB Mode (IAMM):  Allows an MRB to act
>>>       on behalf of clients requiring media services who
>>>       are aware of an MRB and its operation. In
>>>       
>> particular it allows the AS to explicitly the convey
>>     
>>> the same kinds of MS 
>>>       characteristics desired as does the Query MRB mode
>>>       
>> (as in Section
>>     
>>> 5.2).
>>>
>>>    In either role, the MRB would deduce that the
>>> selected MS resources are no longer 
>>> needed when the AS terminates the corresponding dialog.
>>>
>>>   > Because some of the current description in the first
>>> of the paragraph really only 
>>> applies to IUMM and not IAMM - i.e., about what the MRB
>>>     knows;  and because the "decision making" on MS
>>>       
>> resource selection is always
>>     
>>> the role of 
>>> the MRB whether for Query or either flavor of In-line.
>>>
>>>       
>> [LM] Same as before, if an AS using the IAMM mode directly
>> contacts the chosen MS when it comes to forwarding UAC
>> calls, then the MRB won't always be on the signaling path
>> (it will for the control channel, it won't for UAC). Or
>> when you say "the MRB would deduce that the selected MS
>> resources are no longer needed when the AS terminates the
>> corresponding dialog" you actually mean the Control
>> Channel SIP dialog and not any UAC dialog?
>>
>>
>>     
>>> 11) Section 5.1, para 2, revise it to
>>>
>>>    As already anticipated in the introduction, the MRB
>>>    view of MS resource availability will in practice be
>>> approximate - i.e., partial and 
>>> imperfect. The MRB Publish interface does not provide an
>>>    exhaustive view of current MS resource consumption,
>>> the MS may in some cases provide a 
>>> best-effort computed view of resource consumption 
>>>    parameters conveyed in the Publish interface (e.g.,
>>> DSP's with a fixed number of 
>>> streams versus GPU's with CPU
>>>    availability), there may be licensing constraints not
>>> factored in (e.g., even if 
>>> lots of CPU and memory
>>>    are available, licensing or other configuration
>>>       
>> elements may restrict
>>     
>>>    the number of stream types), and MS resource
>>>       
>> information may only be
>>     
>>> reported 
>>> periodically over the Publish interface to MRB. 
>>>    Nevertheless, despite such limitations and with the
>>> aid of good engineering the MRB 
>>> can still perform its function well.
>>>
>>>   > Because - seemed could benefit from better wording.
>>>       
>> I disagree about
>>     
>>> the part that 
>>> the only way an AS could be guaranteed of a specific
>>> resource is "to reserve it by 
>>> establishing a session" ... even that doesn't absolutely
>>> guarantee the entire desired 
>>> set of resources will be available when needed. And
>>> seemed good to add some words to the 
>>> effect that despite the MRB's approximate view, it can
>>> still do a good job. And I 
>>> didn't think that the observation about reporting of
>>> resource availability versus 
>>> predictive resource allocation was relevant or helpful
>>> to the primary theme of this 
>>> paragraph.
>>>
>>>       
>> [LM] You're right, and I agree that the paragraph did
>> benefit from the rewording. The "reserve the resource to
>> be sure you have it" came from face-to-face discussions,
>> and that's why we added it to the text.
>>
>>
>>     
>>> 12) Section 5.1, para 3.  I think this para (copied
>>> below as currently written for the 
>>> reader's convenience here) needs some clarification, but
>>>       
>> I don't have a
>>     
>>> specific 
>>> proposal because I'm not sure what the intent is. If the
>>> intent is to say that ASes can 
>>> figure out information on MS resource utilization by in
>>> effect making queries of MRB, I 
>>> would argue that is exceedingly awkward and limited, and
>>> not worth mentioning. Or if 
>>> ASes are thought of as hostile, I would worry about
>>> worse things like requesting 
>>> resources they don't need, and thereby tying them up
>>>       
>> from MRB's point of
>>     
>>> view. If the 
>>> intent is that given the use of the Publish interface
>>> there is the possibility of some 
>>> interloper entity other than MRB of using the interface
>>>       
>> and finding out
>>     
>>> stuff, then the 
>>> para should be clarified in that direction.
>>>
>>>    It is also worth noting that, while the scope of the
>>>    MRB is definitely on providing interested Application
>>>    Servers with the available resources, the MRB also
>>>    allows for the retrieval of information about the
>>>       
>> currently occupied resources.  While this is of
>>     
>>>    course a relevant piece of information (e.g. for
>>>    monitoring purposes), such a functionality inevitably
>>>    raises security considerations, and implementations
>>>    should take this into account. See Section 8 for more
>>> details. 
>>>       
>> [LM] This is related to th security considerations in both
>> the IVR and Mixer drafts. In fact, in both of the drafts
>> the auditing interface allows for the probing of
>> package-specific identifiers (e.g. conference and dialog
>> IDs, and the like), which means, for instance, that an
>> unauthorized AS could tear down a dialog another AS
>> allocated. The security considerations there provide some
>> guidance with respect to that, which should also apply in
>> the MRB draft for the same reason (since, for intance, we
>> report conference IDs in publish responses).
>>
>>
>>     
>>> 13) 5.2.2, first bullet under 2nd para - I don't
>>> understand why the application/sdp 
>>> part is needed.
>>>
>>>       
>> [LM] In IAMM, the AS adds both an SDP (to create a new CFW
>> control channel) and a MRB Consumer request (to ask for a
>> capable MS). According to the MRB request, the MRB chooses
>> a MS, and forwards an INVITE there by attaching the SDP
>> from the AS. The MS negotiates the control channel
>> creation by replying with its own SDP. The MRB at this
>> point can send a 200 back to the AS with a new
>> multipart/mixed payload, including both the SDP from the
>> chosen MS, and the MRB response to the original request.
>> The AS can now connect to the MS using the SDP info.
>>
>> We prepared some examples for all the modes, I guess that
>> this will be clearer when I'll send them to the list, but
>> that's basically the procedure.
>>
>>
>>
>>     
>>> 14) 5.2.3 bullet on <action> part about "If the
>>>       
>> information is identical
>>     
>>> as the 
>>> existing request, the MRB will attempt a session
>>> refresh." What does that mean? Needs 
>>> clarification.
>>>
>>>       
>> [LM] We'll reword that so that it makes more sense.
>>
>>
>>     
>>> 15) 5.2.5.1.1, part about expires:,  "If the lease is
>>> refreshed before expiry, the MRB 
>>> will re-claim the resources and they will
>>>       no longer be guaranteed."  --  I think this is
>>> meant to say "If the lease is NOT 
>>> refreshed ..." ?
>>>
>>>       
>> [LM] Yes, that was a typo, thanks for finding it.
>>
>>
>>     
>>> 16) 5.2.5.1.1, Editor's note at end of section as to
>>>       
>> whether the SIP URI
>>     
>>> is sufficient, 
>>> I don't have any ideas about what else is needed, so
>>> have nothing to suggest, other 
>>> than to ask whether this single SIP URI is one and the
>>>       
>> same for sending
>>     
>>> call legs to 
>>> the MS and for establishing a control channel?
>>> Practically, is there some value in 
>>> allowing for separate URIs for those purposes?
>>>
>>>       
>> [LM] That's a very good point, and I definitely think it
>> should be in the document. I guess these two URIs will be
>> enough, unless anyone else sees any value in having
>> others.
>>
>>
>>     
>>> 17) Section 5.3.1, very last sentence, " The techniques
>>> used for selecting an    
>>> appropriate Media Server by an MRB acting in IUMM is
>>> outside the scope of this document."  - I would think
>>> this  statement applies to any kind of MRB, so should be
>>> generalized and placed further up 
>>> front in the document, perhaps the beginning part of
>>> Section 3. 
>>>       
>> [LM] You're right, but I think it's also safer to make it
>> clear that in IUMM mode you're more into the wild than in
>> IAMM/Query. We'll reword the text to take your comment
>> into account.
>>
>>
>>     
>>> 18) Section 5.3.2 on IAMM. I would think that there are
>>>       
>> a few items from
>>     
>>> the Consumer 
>>> interface that don't apply to the IAMM case. Or if they
>>>       
>> are used, then I
>>     
>>> think need 
>>> more description (I at least wouldn't be clear on just
>>> how they would get used without 
>>> getting into problems). Specifically, 
>>>   - the ability to update/change a prior resource
>>>   request - the ability to ask for multiple ports (in so
>>>       
>> many words) at least in
>>     
>>> the IVR case
>>>   - does the lease mechanism apply? is the client
>>>       
>> required to renew? MRB
>>     
>>> knows the call 
>>> is still up if it's in the signaling path
>>>
>>>       
>> [LM] I'd rather have some redundancy here than making
>> distinctions for what concerns the Consumer interface
>> according to the protocol it is conveyed upon. Do you
>> think it's ok if we just point out that in IAMM mode you
>> have more ways to do the same thing? (leasing being one of
>> the best examples)
>>
>>
>>     
>>>>> Editorial nits below <<
>>>>>           
>>> 1) Be consistent of use of MRB Publish interface or MRB
>>> Publishing interface.
>>>
>>> 2) 5.1.1.2 para 3,  "updating/removing" instead of
>>> "update/remove" 
>>> 3) 5.1.4.4 "which represents" instead of 'which
>>> representing" 
>>> 4) 5.1.4.5 "number of RTP sessions' instead of "number
>>> of RTP session" 
>>> 5) 5.1.4.6 "which represents" instead of 'which
>>> representing" 
>>> 6) 5.1.4.11 "can" instead of "cane"
>>>
>>> 7) 5.1.3.14 "media server supports." instead of 'media
>>>       
>> server support."
>>     
>>> 8) 5.1.3.19 "... a blue or green one." instead of "... a
>>>       
>> blue or green."
>>     
>>> 9) 5.2.3  "in Section 7 and Section 7" --> "in Section
>>> 5.2 and Section 7"  ?
>>>
>>> 10) 5.2.4.1.1.1 under seq:  "information its use" -->
>>>       
>> "information about
>>     
>>> its use"
>>>
>>> 11) 5.2.5.1.1, under expires: "that the media resources
>>> reserved" --> "that the media resources are reserved"
>>>
>>>       
>> [LM] All noted, thanks.
>>
>> -- 
>> Lorenzo Miniero <[email-masked]>
>>     
>
>
> Lorenzo Miniero
> http://www.meetecho.com
>
>   

-- 
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 7 Jan 2010 15:33:27 +0100

Hi Gary,

some comments inline ([LM]).

On Mon, 4 Jan 2010 21:35:43 -0500

> in the MRB response to the AS and indicate which is which.]

[LM] As I said in reply to that mail, I think it's a very good idea to
envisage the possibility of having two SIP URIs, which can fallback to
one in case the MS doesn't make a distinction anyway. This would go in
both Publishing notifications and Consumer responses, of course.
Anyway, reading I have a little doubt: are you thinking of SIP URIs as
associated to the MS instances themselves, or to the requested
resources? The way the protocol works now is the former, i.e. what the
MS publishes (its address) goes in the Consumer response (the URI to
contact to get to that MS), so there's no new URI allocated to take
care of a specific Consumer request (since the MS is not aware of
Consumer requests anyway).

> and some kinds of conferencing) associated with the same SIP URI.

[LM] From how I see it, this is actually what should always happen,
considering how the framework is conceived: no matter how the MS is
internally partitioned/built (e.g. a proprietary conferencing mixer
here, an IVR server there), the publicly reachable URI should be the
same, and every redirection should happen transparently to the AS,
which only has to know what the MS supports as a whole.

> without or without a control channel.

[LM] Right, even though IMHO the focus should still be on the MEDIACTRL
framework (since it's a MEDIACTRL document and assumed to work within
its architecture). We can add some words stating that the MRB may also
act as a B2BUA/Proxy of some sort for media dialogs as well (especially
in IUMM, since in IAMM the AS may directly contact the MS for call
legs) or whenever simpler approaches are enough and no Control
Channel is needed (RFC4240, etc.).

>     Left to implementation and context to decide what to do 

[LM] Yes providing some guidance with respect to that definitely makes
sense. I'd also foster explicit release messages by the AS.

> could rely on providing the conference ID in 

[LM] The first two points only apply to Query and IAMM, since in both
cases the AS gets the MS SIP URI in the Consumer response. In IUMM
there's no Consumer interaction, and so everything has to be done
inline. The only way to cope with this in IUMM is to always use the
same MS for the same AS, in order to make redirections easier (MRB sends
call legs there as well), or envisage a pool of URIs in the MS each
statically associated with a different MS (just a rough idea of course).

In IAMM this is not as easy, since the same AS could issue different
Consumer requests at the same time, and end on different MS as a
consequence to those interactions. That's why I thought a direct
AS<->MS to be better in IAMM. Alternatively, in case in IAMM the MRB
*wants* to be on the signaling path for UAC calls as well, it may place
one of its own URIs in the Consumer response (i.e. in the media calls
URI) instead of the MS URI, so that a MRB-aware AS always sends calls
there. It would then be up to the MRB to associate that URI to the
right MS. Do you think such an approach would be ok?

> which application the request came from. 

[LM] I'm not sure what you mean by this example: are you talking about
call legs to redirect? Because for what concerns the Control Channel
creation, in Query mode the MRB is not involved. The same can be said
for what concerns call legs basically, since in Query mode the AS sends
the calls directly to the MS as well (unless the MRB replaced the calls
URI with one of its own, in which case the MRB would still know the
mapping with the MS to contact).

> requested MS resources are freed up.)

[LM] You're right, some discussions about pros and cons could be nice
to have in the document.

> Cheers & Happy New Year!,

[LM] Thanks for your feedback!

Lorenzo

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Thu, 7 Jan 2010 13:13:51 -0500

Hi Lorenzo,

Thanks for the comments. Sharing some iterative comments back, indicated
by [GAM] below your [LM]s.

If you think it would be helpful for the two (or a few) of us to have a
purely informal call to help clarify any potential confusion around
what's being discussed, I'm very open to that.

Thanks.

br,

Gary

-----Original Message-----
From: Lorenzo Miniero [mailto:[email-masked]] 
Sent: Thursday, January 07, 2010 9:33 AM
To: MUNSON, GARY A, ATTLABS
Cc: Chris Boulton; [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-02.txt

Hi Gary,

[GAM] I didn't know that there was a definite decision to allow for two
SIP URIs. (It's not clear to me why it's helpful.) Anyway, that's okay
with me as long as we cover the consequences. But then, as I say above,
at least for Query mode, I believe that the MRB should respond with both
SIP URIs, the one for control channel and the one for call legs, and
that MRB response of course has to indicate which is which. Otherwise,
in a typical scenario, AS has to make two MRB queries, one to find out
the control channel SIP URI for the MS and one to find out the call leg
SIP URI for the MS, and that would be very inefficient. (And with an
HTTP query, it gets even more interesting, because so far there's no way
for the AS to indicate to MRB which it is asking for - a MS control
channel SIP URI or an MS call leg SIP URI.)  Also, with IUMM, if an AS
sends a request with an SDP for a control channel, how would it know the
SIP URI for call legs? I don't see how that would work.    Separately,
regarding your embedded question ... not sure how I confused you, but I
agree with your description - MS 'publishes' SIP URI to MRB, and that
URI is what goes in the Consumer response to AS. There is no new URI
allocated to take care of a specific Consumer request.

[GAM] I just think it would be a helpful observation to include in the
document. Falls into the category of 'obvious' for those of us familiar
with MRB context. Not so obvious to others new to MRB and this document.

[GAM] Agreed, but I wouldn't discount the IAMM MRB B2BUA option for call
legs. Again, my rationale is that it's probably as efficient a way as
any for MRB to know when MS resources are freed up especially in IVR
scenarios. 

[GAM] You seem to be dismissing the idea that a conference ID could be
helpful to MRB as a possibility, in the case of IAMM or IUMM where the
call legs go through MRB. When MRB gets a request with a conference ID,
it asks itself if it had seen that ID before. If No, it remembers it for
later use. If Yes, it looks up where it had sent prior call legs with
the same conference ID. (I'm not dictating how MRB would work, just an
example of how it could meaningfully work.) So I don't see a problem
with IAMM and multiple Consumer requests at ~ the same time. (I.e., I
see a solution.) And I think for IUMM the rule that the MRB always has
to use the same MS for the same AS is overly restrictive. From the same
AS, for conference ID 13 the MRB could use MS K and for conference ID 14
the MRB could use MS J.

[GAM] To amplify ... Let's say an MRB just received a SIP INVITE from an
AS with SDP application/mrb-consumer+xml. The INVITE would also contain
SDP for control channel, or SDP for call leg; doesn't matter which. Now
how does the MRB know whether to (a) respond back to the AS as per Query
or (b) act as B2BUA and send the INVITE along to the selected MS
resource as per IAMM? There's nothing in the INVITE from the AS that
explicitly tells the MRB which to do, (a) or (b). Therefore, the MRB
must be making that decision, say, as per pre-established rules.  Of
course here I'm assuming that a given MRB can operate in both Query and
In-Line modes at the same time, and that the same MRB SIP URI can be
used by an AS for sending the INVITE to MRB, whether for Query or IAMM
(or IUMM for that matter).

Lorenzo

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 13 Jan 2010 12:24:30 +0100

Hi Gary,

some more comments inline.

On Thu, 7 Jan 2010 13:13:51 -0500

> allocated to take care of a specific Consumer request.

[LM] Sorry, I expressed my thoughts unclearly: there's no definite
decision on that, of course. I just wanted to restate my support to
that idea, in case anybody else finds it useful. You're completely
right in saying that, in case we choose to have the possibility of
reporting two URIs (CFW dialog/media dialogs), they both have to be
reported in the same message, and properly addressed in both interfaces.

About it being useful or not, my opinion is it might be, but that
probably depends on how MS are implemented and deployed: different URIs
might ease the handling of different requests, but that's just an idea
(our MS only uses one URI, for instance, as does our prototype MRB
implementation, so I'm actually not fostering it). It's true that this
may confuse unaware entities: anyway, unaware entities already have to
know a URI per configuration or something else (the MRB uri for IUMM,
for instance), so having two would just add more configuration to have
for them.

That said, I'm completely ok with both approaches.

Regarding the embedded question, I can't remember what ringed a bell in
my head, if anything: I just wanted to clarify what may not have been
completely clear in the draft.

> with MRB context. Not so obvious to others new to MRB and this document.

[LM] You're right, we'll add some text to the draft in order to make
this clear.

> any for MRB to know when MS resources are freed up especially in IVR

[LM] Of course, that's definitely a valid scenario and we are not
precluding that in the draft. I'm only a bit concerned in having the
MRB as a bottleneck of some kind, in that case, but that's probably
just a deployment issue.

> AS, for conference ID 13 the MRB could use MS K and for conference ID 14

[LM] I'm a bit confused on this point. When talking about a
conferenceID, are you talking about the SIP URL? My concern is that
this identifier is surely known by the AS, which handles the UAC call
in the first place, but may be lost when relaying the call to the MRB,
which is instead directed to a different URL. It could be useful for
the scenario you present, but I'm just not sure it's always safe to
rely on that. Or were you thinking of something different?

I definitely agree with you that some kind of token could be used for
dealing with these scenarios. That's why I was thinking of the MRB
presenting the AS with one of its own SIP URLs in order to make sure
the AS would always pass through the MRB for every SIP dialog: the
dialed URL would act as the token, which would internally be mapped to
the right MS URL. This also would let the MRB personally decide
whether or not to be on the signaling path.

Anyway, I understand your point about the restrictions in IUMM: in that
case, the aforementioned approach may not be applied, considering no MRB
request would be involved.

> (or IUMM for that matter).

[LM] At the moment, in inline mode the MRB does both at the same time:
when receiving the INVITE, the MRB chooses the MS, relays the INVITE
there, and when ready it replies to the AS with both the SDP (needed to
connect the Control Channel to the MS) and the MRB reply (the Consumer
reply with info on the chosen MS).

That's how we implemented the current version of the MRB prototype,
which is reflected in the examples I posted on the list.

Do you think this approach is ok, or are you also envisaging the
possibility for the AS to choose between (a) and (b)? My guess is it
can be done by removing the constraint that, in Inline mode, the AS
*must* include the multipart/mixed payload: in fact, allowing it to
only include the MRB payload would limit the scenario to (a), while
with the multipart payload it would be (b).

Thanks,
Lorenzo

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Wed, 13 Jan 2010 13:36:38 -0500

Hi Lorenzo,

Thanks for the iterative comments. Two more back from me, indicated by
[GAM2], continuing the discussion on a couple of the items.

cheers,

Gary

-----Original Message-----
From: Lorenzo Miniero [mailto:[email-masked]] 
Sent: Wednesday, January 13, 2010 6:25 AM
To: MUNSON, GARY A, ATTLABS
Cc: Chris Boulton; [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-02.txt

Hi Gary,

[GAM2] I was thinking about the conference ID created by the conference
factory as in XCON, which may for example show up for example as conf-id
in the user part of the SIP URI under RFC 4240. (All of which I'm sure
you're much more familiar with than I am.) That is something that I
believe the MRB would/could pass along to the selected MS resource in
the SIP INVITE setting up a call leg. So I think that's worth mentioning
as one way to address the issue in some scenarios, since it doesn't cost
anything or require anything new. 

[GAM2] Let me start over on this one, because I may be confusing you,
partly because I said one thing that isn't correct.  So ...assuming you
agree with the premise that a given implementation of MRB may be
multi-mode, i.e., the MRB may be handling any of Query, IAMM or IUMM
from various AS... there is one case that is ambiguous to the MRB, as
far as I can tell, where upon receipt of the SIP INVITE from an AS, the
MRB won't know whether the AS is expecting the MRB to behave in Query
mode or IAMM mode. That case is when the MRB receives a SIP INVITE with
multi-part payload {MRB Consumer stuff, SDP CFW stuff}. That could come
from an AS that thinks it is Querying with MRB, or IAMMing with MRB.
There is nothing in the SIP INVITE that explicitly tells MRB which mode
the AS expects MRB to be acting in and so how MRB should behave. Either
we can say it's a problem and fix it, e.g., by putting some kind of
explicit indicator in the INVITE from the AS for which mode MRB should
be in, or we could say it's not a problem because MRB could have local
policy information to infer how the AS expects the MRB to behave for
that particular request based on, say, the identity of the requesting AS
and/or the specifics of the MRB Consumer payload content.  I'm fine with
the latter, but I think this situation needs to be addressed in the
document to avoid surprises in implementations.

Thanks,
Lorenzo

> > of connection that we are dealing with.  I am not against (1) so
open
> to
> > [Chris] Agreed.  The lease mechanism should be used regardless of
the
> MS
> > 
> > trigger mechanism.  These are all good scenarios that we need to
keep
> in

---

From: Chris Boulton <[email-masked]>
Date: Thu, 14 Jan 2010 09:56:18 +0000

[Splitting out each issue as its getting a bit confusing - If I have 
missed any, can your consolidate :-)]

[Chris] I might be missing something here.  If the MRB receives an INVITE with the 'MRB consumer stuff, SDP CFW stuff' then it is acting in IAMM mode.  Had the MRB received a HTTP POST with the same payload - it is acting in Query mode.  So the MRB should act as an authority for media resource selection.

There is nothing in the SIP INVITE that explicitly tells MRB which mode
the AS expects MRB to be acting in and so how MRB should behave.

[Chris] BUT the MRB should be the authority - for Media Resources and applications.  The Application can choose which mode it wants to request resources by using either HTTP or SIP.

Either we can say it's a problem and fix it, e.g., by putting some kind of

[Chris] Just as a starting observation - I don't think that an application should be able to control decisions on the MRB.  The MRB is designed to be the authority in the network for Media Resources and their selection.

---

From: Chris Boulton <[email-masked]>
Date: Thu, 14 Jan 2010 10:13:12 +0000

[GAM] I didn't know that there was a definite decision to allow for two SIP URIs. (It's not clear to me why it's helpful.) Anyway, that's okay with me as long as we cover the consequences. But then, as I say above, at least for Query mode, I believe that the MRB should respond with both SIP URIs, the one for control channel and the one for call legs, and that MRB response of course has to indicate which is which.

[Chris] I am struggling to understand the difference.  Why are they different?  So I send a Query for X number of IVR resources to the MRB for Application A.  I receive a response from the MRB detailing an MS that can handle the number of resources I need - and I establish a control channel to that MS.  On receiving a request for an active user at Application A, I forward the request to the same destination to handle the media IVR dialog.  Why would this be different? 

Otherwise, in a typical scenario, AS has to make two MRB queries, one to find out the control channel SIP URI for the MS and one to find out the call leg SIP URI for the MS, and that would be very inefficient. (And with an HTTP query, it gets even more interesting, because so far there's no way for the AS to indicate to MRB which it is asking for - a MS control channel SIP URI or an MS call leg SIP URI.)

[Chris] Still not getting this - Why are they different?

Also, with IUMM, if an AS sends a request with an SDP for a control channel, how would it know the SIP URI for call legs? I don't see how that would work.    Separately, regarding your embedded question ... not sure how I confused you, but I agree with your description - MS 'publishes' SIP URI to MRB, and that URI is what goes in the Consumer response to AS. There is no new URI allocated to take care of a specific Consumer request.

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Thu, 14 Jan 2010 13:29:21 -0500

One response as [GAM3] since there's already [GAM2] here from before.
Important!

Cheers,

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chris Boulton
Sent: Thursday, January 14, 2010 4:56 AM
To: MUNSON, GARY A, ATTLABS
Cc: [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-02.txt - Issue 1

[Chris] I might be missing something here.  If the MRB receives an
INVITE with the 'MRB consumer stuff, SDP CFW stuff' then it is acting in
IAMM mode.  Had the MRB received a HTTP POST with the same payload - it
is acting in Query mode.  So the MRB should act as an authority for
media resource selection.

[GAM3] I think your comment reveals a big point of confusion here. I
believe you're saying that Query mode only uses HTTP; there is no SIP
option for Query mode. That was my understanding (and is still my
preference!) once upon a time. But this draft says
- Section 4.2  "The "In-line" MRB is architecturally different from the
"Query" model
   that was discussed in the previous section.  The Concept of a "Media
   Server Consumer Interface" disappears.
- Yet under Section 5.1 Consumer Interface there's a subsection "5.2.2
SIP Consumer Interface Usage".
So when I read the draft, I said to myself, Okay, this didn't used to be
here - SIP as an alternative to HTTP for Query Mode/Consumer interface.
Rather not have it, but I can live with it.  --> So if we agree that the
Query Mode/Consumer interface is only HTTP, that sounds good to me and
the document should be clarified that way. It would kill the issue I
raised here and probably some other questions I had.

[Chris] BUT the MRB should be the authority - for Media Resources and
applications.  The Application can choose which mode it wants to request
resources by using either HTTP or SIP.

Either we can say it's a problem and fix it, e.g., by putting some kind
of

[Chris] Just as a starting observation - I don't think that an
application should be able to control decisions on the MRB.  The MRB is
designed to be the authority in the network for Media Resources and
their selection.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Thu, 14 Jan 2010 13:37:57 -0500

[GAM3] below again.

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Thursday, January 14, 2010 5:13 AM
To: MUNSON, GARY A, ATTLABS
Cc: Lorenzo Miniero; [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-mrb-02.txt - issue 2

that MRB response of course has to indicate which is which.

[Chris] I am struggling to understand the difference.  Why are they
different?  So I send a Query for X number of IVR resources to the MRB
for Application A.  I receive a response from the MRB detailing an MS
that can handle the number of resources I need - and I establish a
control channel to that MS.  On receiving a request for an active user
at Application A, I forward the request to the same destination to
handle the media IVR dialog.  Why would this be different? 

[GAM3] You're assuming that the SIP URI for the control channel and for
sending call legs to the identified MS resource are the same, right?
That's *fine* with me. I don't see a need for more than that, and then I
think we should state that critical assumption in the doc't somewhere.
But at least Lorenzo was contemplating allowing the SIP URIs to be
different, in which case the situation I cite above arises, and where
the solution would be that MRB returns both URIs to the AS, but then
that should be documented.

Otherwise, in a typical scenario, AS has to make two MRB queries, one to
find out the control channel SIP URI for the MS and one to find out the
call leg SIP URI for the MS, and that would be very inefficient. (And
with an HTTP query, it gets even more interesting, because so far
there's no way for the AS to indicate to MRB which it is asking for - a
MS control channel SIP URI or an MS call leg SIP URI.)

[GAM3] This is just the consequence *if* we have different SIP URIs for
the control channel and for the call legs to the same MS resource *and*
we don't fix it to allow the MRB to return in both URIs in response to
the AS Query mode query. 

Also, with IUMM, if an AS sends a request with an SDP for a control
channel, how would it know the SIP URI for call legs? I don't see how
that would work.    Separately, regarding your embedded question ... not
sure how I confused you, but I agree with your description - MS
'publishes' SIP URI to MRB, and that URI is what goes in the Consumer
response to AS. There is no new URI allocated to take care of a specific
Consumer request.

---

From: Chris Boulton <[email-masked]>
Date: Fri, 15 Jan 2010 08:25:38 +0000

Gary - more in-line - [Chris2].

Chris.

> raised here and probably some other questions I had.
[Chris2] Yes - Its become clear from yours and other comments that this 
definitely needs text.  As you know, the draft has changed a lot in the 
past few versions and this is exactly the type of topic we were hoping 
winkle out :-).  Lorenzo and I will work on some text for section 5.2.2 
to cover the usage of SIP and 3xx style responses.  I think some of this 
has been down to interpretation of terminology (use of Query vs Consumer 
+ SIP).  We will ensure that the text and use of terminology all aligns.

---

From: Chris Boulton <[email-masked]>
Date: Fri, 15 Jan 2010 08:33:29 +0000

Gary - more in-line [Chris2].

Chris.

> sending call legs to the identified MS resource are the same, right?
[Chris2] Yes.
> think we should state that critical assumption in the doc't somewhere.
[Chris2] OK.  We will include some text.
> that should be documented.
[Chris2] OK - I've never seen this in the wild - for legacy IP Media 
Servers but I am happy to be persuaded that this is needed.  Have folks 
seen this?  Is it actually useful?  I'd always imagined that the URI 
provided for an MS instance would need to ensure that SIP routing 
guarantees media dialogs will arrive at the correct destination (GRUU 
properties) - We should probable document that at the very least?
> we don't fix it to allow the MRB to return in both URIs in response to
[Chris2] OK.  I am not convinced BUT we can address this IF the group 
feels an optional extra URI is needed for media dialogs.

Chris.