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

From: Colin Perkins <[email-masked]>
Date: Sun, 6 Feb 2005 17:04:41 +0000

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: Sun, 6 Feb 2005 17:06:18 +0000

Christer, Francois,

My reading of this discussion is that there is no change needed to 
SDP-new.
Colin

On 22 Dec 2004, at 19:16, Francois Audet wrote:
> > Hi,
> >
> > I have a small question.
> >
> > The sdp-new draft says that "inactive" is used to put users
> > on hold, while RFC3264(offer/answer) says that "sendonly" is used.
> >
> > Now, in the original SDP RFC, which RFC3246 refers to,
> > "inactive" was not defined, so I wonder if RFC3264 is to be updated?
> >
> > Or, are both hold mechanisms "according to the standard"?
>
> Yes.
>
> They are slighly different forms of "hold".
>
> SIP/SDP doesn't really have a concept of "hold" in the traditional 
> telephony
> sense.
>
>  sendonly means that you can not receive media.
>
> inactive means that you can not receive media and that you are not 
> sending
> either.
>
> They could both mean that you are "on hold". You can think of a Music 
> On Hold
> service,  versus a normal Hold service. But neither necessarily means 
> "hold" as per
> traditional telephony. You could send inactive or sendonly for reasons 
> that are
> not a logical hold, but just plain media pausing.

---

From: Colin Perkins <[email-masked]>
Date: Sun, 6 Feb 2005 17:13:16 +0000

Folks,

On 19 Dec 2004, at 16:50, Joerg Ott wrote:
> This is to announce Working Group Last Call on the revised
> SDP specification "SDP: Session Description Protocol"
> recently published as
>
>     draft-ietf-mmusic-sdp-new-23.txt
>
> The document shall be advanced to Proposed Standard (PS).
>
> The WGLC is to end on 9 January 2005.
>
> Please review the latest draft carefully and direct all comments
> to the MMUSIC list and the authors.

This last call period ended, with only minor comments (to which I have 
just responded). I propose to make the clarification change proposed by 
Francois Audet, provided we can quickly agree on wording, but make no 
other changes. If this is acceptable to the working group, I will make 
a -24 revision with this change, which will then be sent to the IESG.

Colin

---

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

Correct.

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Sunday, February 06, 2005 09:06
> To: Francois Audet
> Cc: 'Christer Holmberg (JO/LMF)'; 'Joerg Ott'; [email-masked]'
> Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt
> 
> 
> Christer, Francois,
> 
> > > The sdp-new draft says that "inactive" is used to put 
> users on hold, 
> > > while RFC3264(offer/answer) says that "sendonly" is used.
> > >
> > > Now, in the original SDP RFC, which RFC3246 refers to, "inactive" 
> > > was not defined, so I wonder if RFC3264 is to be updated?
> > >