Subject: [Sipping] Queries/Suggestions on draft-wu-sipping-floor-control-00.txt

From: Prashant Gupta <[email-masked]>
Date: Fri, 29 Mar 2002 02:31:22 -0500

Hi,

It appears that the FL semantic is primarily used to define a floor and
to associate a control channel for floor control information to this
floor. Is this correct?

I. If yes, consider the following scenario - assuming that there are two
media streams that require floor control, and need their own floors, but
would like to share a common floor control channel (e.g. send all this
information to the same floor control component on a server), then it
would not be possible to use the FL semantic (as currently defined)
since the same "a=mid:" (the floor control channel) cannot be used in
the multiple "a=group:FL" lines [as per the
draft-ietf-mmusic-fid-06.txt]. 

Would it then be a more generic semantic if instead of doing 2 things,
i.e., 

1. Defining the floor, and
2. Associating a Floor Control Channel with this floor

it just does the latter. And floors could be implicitly assigned, one
for each media stream or using a new a=group:XY semantic. 

II. Does sending of the sdp with the FL semantic lead to creation of the
floors? Or does this explicitly happen using a floor_create command? 

If the former, then how does the information from the sdp ( the FL
semantic) get passed on to the floor control entity on a host (so that a
match can be made with the sdp information and the xml document received
in the floor_xxx requests ?

Regards,
Prashant Gupta.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Xiaotao Wu <[email-masked]>
Date: Fri, 29 Mar 2002 10:09:15 -0500 (EST)

> to associate a control channel for floor control information to this

FL semantic is not used to define a floor. The floor is created by the
floor_create command.

For each media resource, the a=type:moderated line implicitly indicates
that there is a floor associated with the media.

FL semantic is primarily used to associate a control channel (defined in
the m=control line) with the resource that has floor for performing the
floor control commands over the floor of the resource.

> draft-ietf-mmusic-fid-06.txt].

The a=group:FL line can associate one control channel with more than one
resource. As the example in the draft, the control channel with mid:4 is
used to control both audio and video resources.

   a=group:FL 1 2 4
   a=group:FL 3 5
   m=audio 10000 RTP/AVP 0
   a=type:moderated
   a=mid:1
   m=video 20000 RTP/AVP 31
   a=type:moderated
   a=mid:2
   m=application 30000 udp wb
   a=type:moderated
   a=mid:3
   m=control 80 HTTP SOAP
   a=mid:4
   m=control 5060 SIP SOAP
   a=mid:5

> for each media stream or using a new a=group:XY semantic.

For each media, having a 'a=' line to associate a control channel with the
floor of the media is certainly a solution. However, it cannot
explicitly indicate two floors sharing one control channel, as what the
'fid' solution can do.

> floors?

No, the SDP part only indicates the port, protocol etc. of the control
channel. It will not create a floor.

> Or does this explicitly happen using a floor_create command?
>

Yes, it happens by using a floor_create command. Who can send the initial
floor_create command should be defined in the conference control level.

-Xiaotao

---

From: Prashant Gupta <[email-masked]>
Date: Fri, 29 Mar 2002 16:52:38 -0500 (EST)

Hi,

Thank you for your detailed reply.

Does the proposed usage of a=type:moderated for each m line, go against
the definition of the "a=type:" semantic, which, as per
draft-ietf-mmusic-sdp-new-06.txt (page 26) says that this is a conference
level attribute ?

some comments inline -

> used to control both audio and video resources.

[PG] I guess the paragraph right after that example stated that

"in this examples, there are two floors, one is for audio and video input
and the other is from whiteboard input"

which seems to suggest that the FL semantic is used to identify floors
also.

[end PG]

---

From: Xiaotao Wu <[email-masked]>
Date: Sat, 30 Mar 2002 10:55:44 -0500 (EST)

> draft-ietf-mmusic-sdp-new-06.txt (page 26) says that this is a conference

You are right. The type attribute is defined as session-level attribute in
SDP. I think it is a bug in SDP.

For the a=type:moderated usage of the a=type attribute, based on the
sdp-new-07, that should indicate the use of a floor control tool and that
the media tools are started so as to "mute" new sites joining the
conference.

A common senario of a conference is, people can always see each other, but
only one people can talk at a time. That means audio is moderated but not
video. When a person join the conference, the person should mute his audio
tool but not video tool so that the other people can see him.

However, if the a=type attribute is defined as the session-level
attribute, both the audio tool and video tool of the person will be
muted. That's not expected.

> and the other is from whiteboard input"

That's a mistake in the draft, it should be:

'there are two floor control channels, one is for audio floor and video
floor and the other is for whiteboard floor.'

Thanks!

-Xiaotao