Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt

From: "Francois Audet" <[email-masked]>
Date: Mon, 7 Feb 2005 13:50:43 -0500

Here is the exact proposal. Changes starts at line with the "->".

In the definition of <port>, add the following text to the fist paragraph,
after the reference to [21]:

	If non-contiguous ports are used or if they don't follow the parity 
	rule of even RTP ports and odd RTCP ports, the "a=rtcp:" attribute 
      MUST be used. Applications that are requested to send media to a
<port> 
	that is odd and where the "a=rtcp:" is present MUST NOT substract 1 
	to the RTP port: i.e, they MUST send the RTP to the port indicated 
	in <port> and send the RTCP to the port indicated in the "a=rtcp" 
	attribute.
     
Cheers.

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Sunday, February 06, 2005 09:05
> To: Francois Audet
> Cc: [email-masked]'; 'Cullen Jennings'; 'Joerg Ott'; 
> [email-masked]'; 'Stephen Casner'; [email-masked]'
> Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt
> 
> 
> Francois,
> 
> [Apologies for the slow response...]
> 
> On 20 Dec 2004, at 00:33, Francois Audet wrote:
> > I would like to request a clarification in section 5.14 of  
> > draft-ietf-mmusic-sdp-new-23.
> >
> > As we discovered in BEHAVE, certain SDP implementations are
> > misinterpretting RFC 3550 section 11 2nd paragraph. In a SIP 
> > Offer/Answer for example, these implementations 
> unilaterally change an 
> > odd RTP port indicated in an SDP (from the other end) with 
> to the even 
> > port that one lower. In other words, if the other end 
> indicates an RTP 
> > port of 5201, these implemenations will send RTP to 5200, 
> which will 
> > be a big problem.
> >
> > Note that this issue is slightly orthogonal to the use of the rtcp
> > attribute of RFC 3605. For example, if an application 
> discovers (with 
> > STUN or ICE) that its RTP port is 5201, it may then 
> discover that it's 
> > RTCP port is 5202 (which would satisfy the contiguity 
> rule). This is 
> > very likely to happen because NATs typically assign ports 
> > sequentially. An application could (somewhat foolishlingly) not use 
> > RFC 3605 in this case because it follows the contiguity 
> rule (but not 
> > the parity rule).
> >
> > Another issue is for implementations that do not support RTCP in the
> > first place.
> >
> > In order to avoid these problems, I propose that we explicitly state
> > that  the <port> for RTP indicates the actual port and MUST not be 
> > changed regardless of parity (i.e., DO NOT substract 1 if 
> it is odd).
> >
> > I believe that would finally put to rest this parity issue 
> for all SDP
> > based protocols.
> 
> What is the *exact* wording change you are proposing?
> 
> > Also, on a similar note, would it make sense to incorporate RFC 3605
> > (the  directly into sdp-new, instead of having it stand as 
> a separate 
> > RFC) and make its support mandatory? The biggest problem 
> with RFC 3605 
> > is that I can do the best SIP/SDP implementation possible, support 
> > STUN, ICE, 3605 and all, but if the other end doesn't support 3605 
> > (because they don't even know of NATs), the problem above 
> will still 
> > occur.
> 
> We don't mandate support for any of the attributes in SDP-new, so I 
> don't see any real benefit to including the RFC 3605 ("a=rtcp:") 
> attribute into the main SDP specification at this time.
> 
> Colin
> 
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Wed, 16 Feb 2005 11:45:35 +0000

There have been no objections, so I will make this change and submit 
-24 before the deadline.

Colin