Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.txt

From: [email-masked]
Date: Fri, 07 May 2010 19:26:36 +0200

Hi Sean,

see below...

> [SEAN] OK if Bob is not involved in another conference then there is no issue

[SIMON] OK!

> [SEAN] the issue here is that the delete will disconnect Bob's call   
> and then the create will restablish his call with the new conference.
> The behaviour I am looking for is that Bob get moved to another   
> conference without any disconnection and reconnection
>
>
> [SEAN] I don't think this clears my issue up.  My basic use case is   
> I want to move particpants from main conference to sidebar without   
> disconnection of their call and then back to the main conference   
> again.
> Your original call flow was:-
>
>     * 1) userRequest/delete from the main conference
>     * 2) userRequest/create on the sidebar
>     * 3) userRequest/delete from the sidebar
>     * 4) userRequest/create on the main conference
>
> The first delete will disconnect the user from the conferencing   
> bridge which is not what I want.

[SIMON] So, the problem here is to find a means for ensuring that a  
user who is temporarily moved from conference1 to conference2 does not  
appear anymore in conference1 (and does not contribute to  
conference1's transmissions) for the entire duration of such change.  
This can be easily achieved via CCMP, since the protocol can manage  
all of the fields of the XCON data model, including the many of them  
associated with conference users. Hence, you can issue a  
userRequest/update message to the server and ask it to set the  
<status> field of the interested <endpoint> element to a value of  
"on-hold". Just to clarify, here is a cut-and-paste of the definition  
of "on-hold" from RFC 4575:

    on-hold:  Active signaling dialog exists between an endpoint and a
       focus, but endpoint is "on-hold" for this conference, i.e., he/she
       is neither "hearing" the conference mix nor is his/her media being
       mixed in the conference.  (rfc 4575)

Besides this, you also have to set <user>/<provide-anonymity> to "hidden":

'hidden' value specifies that other users can not see this participant  
in the conference.

In summary,in place of the userRequest/delete messages, you can  
envisage a userRequest/update one in which you set:

  *  <endpoint>/<status> = "on-hold"
  *  <user>/<provide-anonimity> = "hidden"

Does this clarify the issues you raised?

Cheers,

Simon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Mon, 31 May 2010 15:47:09 +0100

Hi Simon,
	Should the userInfo element of 

 <xs:complexType name="userRequestType">
       <xs:sequence>
           <xs:element name="userInfo"
                       type="info:user-type" minOccurs="0" />
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

have a minOccurs of 1 and a maxOccurs of 1? Is there an example of why
it can be restricted to 1?

Sean