Subject: RE: [MMUSIC] Prelim copy of comedia-02 available

From: "David Yon" <[email-masked]>
Date: Tue, 9 Apr 2002 10:37:29 -0400

Thanks Colin for looking over the draft in such detail.  Comments inline
below.

>  
>  - The Protocol Identifiers section may want to point to the 
> discussion of 
>    m= in SDP, which specifies that the identifiers are MIME 
> subtypes for
>    audio/video/application media types. This is implicit in 
> the examples,
>    and explicit in SDP, but not noted in this draft.
>  

I will add the following text to the "Protocol Identifiers" section
(directly before the "TCP" section):

	The m= line in [SDP] is where an endpoint specifies the protocol

	used for the media in the session.  See the "Media
Announcements" 
	section of [SDP] for a discussion on protocol identifiers

>  - Section 2.2 ("Semantics of direction:active") could go with an SDP
>    fragment, showing exactly where the source and destination address 
>    and port are specified (i.e. an SDP fragment including c=, m= and
>    a=direction lines).
>  

Added.

>  - How specific is this to SDP used with offer/answer? It's probably
>    appropriate to have a section explaining how comedia is used with
>    SIP (i.e. offer/answer), RTSP, MEGACO and perhaps SAP.
> 

In SIP I believe it is equally relevant to both offer/answer and
three-way handshake (INVITE/OK/ACK).  I made an attempt to describe the
semantics in protocol-independant manner to reduce the dependencies of
this draft, and I think that the language describes the scenarios
correctly.  The two sections where this is most visible are the
"Optimizing direction:both" and "Connection and Listener Lifetime
Considerations".  It would be helpful if those that are more familiar
with the upper-level protocols (especially RSTP and MEGACO) would check
the language to make sure that there are not impedance mismatches
introduced to those protocols.

>  - Section 2.6 says that you MUST NOT send media on a passive 
> port until 
>    a packet has been received. Does this include not sending RTCP? 
> 

I got that language from Rohan Mahy.  Rohan?  Clarification?

>  - In section 3, how is the source address useful given that 
> it can't be
>    trusted? More explanation of how it can be used is probably needed.
> 

There is a big "NOTE:" section in "Source-Address Considerations" that
covers this.  What am I missing?

>  - Section 4.1: the time window is the t= line?
> 

The t= line is not directly referenced since I believe the endpoint's
time window semantics can be derived from other sources (SIP Session
Timer comes to mind).

>  - The possible race when both parties select diraction:both 
> concerns me,
>    but I'm not sure I can see a better alternative (unless 
> there's some
>    trick to make one side win deterministically, for example 
> the lowest
>    IP address wins).
> 

Short of mechanisms that involve additional handshaking by the upper
layer protocol, I saw no way to completely eliminate the race.  Keep in
mind that the two-connection condition is not fatal (nor even that
cumbersome, since existing RTP/UDP implementations already have to track
different transport information for inbound vs outbound media), and that
the suggested mechanism should sufficiently reduce the likelihood of the
race that excess resource utilization should be minimized.

> Editorial comments:
> 
>  - The section numbering needs to start with the introduction 
> as section 1.

Done.

>  - The introduction and motivation sections could easily be 
> combined. Add a
>    couple of sentances to the end of the combined section 
> saying that "this
>    memo defines two new protocol identifies, TCP and TLS, 
> along with the
>    syntax and semantics of the a=direction attribute".

Done.

>  - Move the terminology section after the combined 
> introduction/motivation

Done.

>  - A couple of instances of non-ASCII characters need to be fixed.

Will hand check that in the final submission, MS Word seems to creep
those in despite my best efforts.

>  - A couple of places say "the a= line" but mean "the 
> a=direction:" line 
>    (e.g. end of section 2.2, second paragraph of section 2.3, ...)
> 
Done.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 9 Apr 2002 09:54:20 -0700 (Pacific Daylight Time)

Hi David,

A few minor comments inline.

> introduced to those protocols.

The SIP three-way handshake is now decoupled from the offer/answer
model.  If you want an offer/answer/counter-offer in SIP you actually
implement that as a pair of offer/answer exchanges.

I couldn't find anything in the draft that was incompatible with the SIP
usage.

> I got that language from Rohan Mahy.  Rohan?  Clarification?

Short answer is: the passive peer can't send RTP until it has recieved a
packet of RTP on the RTP port, and can't send RTCP until it has received a
packet of RTCP on the RTCP port.

You can't (and MUST NOT) send RTP, RTCP, UDP, TCP, etc... media  from a
passive port until a packet has arrived to that port from (presumably) the
active peer.  The reason is simple--you don't know the address/port of
your peer until your recieve that first packet.

hope this helps.
thanks,
-rohan

---

From: Colin Perkins <[email-masked]>
Date: Thu, 11 Apr 2002 20:45:18 -0400

--> Rohan Mahy writes:
...
>> >  - Section 2.6 says that you MUST NOT send media on a passive port until

Okay, that helps. Maybe the discussion in the draft could be expanded
though, to ensure there's no confusion?

Cheers,
Colin

---

From: Colin Perkins <[email-masked]>
Date: Thu, 11 Apr 2002 20:43:33 -0400

--> "David Yon" writes:
>	used for the media in the session.  See the "Media Announcements" 

Okay, looks good.

>introduced to those protocols.

Thanks, that clarifies.

>>  - In section 3, how is the source address useful given that it can't be

Do either of those uses make sense if the source address can be spoofed?
Firewalls that open ported based on untrusted SDP seem to be a risk, and
you list problems with session identification. I just think it could do
with more discussion of the risks and benefits tradeoff, maybe something
in the security considerations.

>time window semantics can be derived from other sources (SIP Session

Okay, but what if the t= line contradicts? Which takes precedence?

>race that excess resource utilization should be minimized.

Okay.

Cheers,
Colin