Subject: Re: Session Description Protocol pre-draft (1.4)

From: Ruth Lang <[email-masked]>
Date: Thu, 13 Jul 1995 14:47:59 -0700

Mark,

Thanks for advertising the availability of the revised SDP draft.  I
have a couple of structural and a couple of technical comments.

I suggest moving Section 3 (Usage) after the specification of SDP
itself.  I.e., describe SDP then describe how it is used.  You could
move from the Usage to the Background section the description of SDP
in the context of Sd (i.e., SDP v1 is the text payload format of the
Sd packet).

Section 4.1 mentions both multicast and unicast sessions.  Later in
the document (m= description), unicast is narrowed to UDP.  Some media
agents (e.g., shared workspace agents) or multi-user applications used
in a conference may require TCP.  Do you object to expanding m= to
include TCP?

Section 5, paragraph 3 describes restriction of including 1 session
description in an SDAP packet while multiple are permitted if
transmitted by other means.  This would be better mentioned in the
Usage section.

How would I go about describing a group of non-multicast multi-user
applications which use a) the same port across the group of
participants, b) different ports (i.e., host, port pair is unique per
participant)?  For a) having multiple c= lines in the session
description portion and/or permitting a list of addresses in the
address subfield (for the case in which the address type was the same)
would work.  For b), one could develop individual media descriptions
for each of the multi-user applications.  Are there other ways to go
about this?

Regards,

Ruth

---

From: Mark Handley <[email-masked]>
Date: Thu, 13 Jul 95 23:13:26 +0100

>in a conference may require TCP.  Do you object to expanding m= to

Nothing in the section on media announcements precludes TCP, but I
agree it should be defined as one of the transport protocols.  This
was one of the main points in adding a transport subfield the the
media announcement field in addition to the address type (badly
named!) subfield of the "c" field.

>transmitted by other means.  This would be better mentioned in the

Yes.  It was there last time though, but people complained it was
unclear :-)  Probably means the preceding sentences should be rephrased.

>participant)?

This depends so much on the distribution mechanism, but lets assume
for a second you dont multicast announce a unicast conference.  If you
unicast the SDP messages to each participant (using HTTP or whatever),
you can have a unique SDP message per participant.  Each c field gives
the address of the mixer or whatever it is the participant should
contact.

>For a) having multiple c= lines in the session
>would work.  

This wasn't the model - the c fields are the address the participant
should contact, not the invitee's address (which they presumably
already know).

Mark