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

From: Joerg Ott <[email-masked]>
Date: Sun, 19 Dec 2004 17:50:47 +0100

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.

Joerg

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

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 19 Dec 2004 19:33:28 -0500

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.

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.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joerg Ott
> Sent: Sunday, December 19, 2004 08:51
> To: [email-masked]
> Cc: Colin Perkins
> Subject: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-new-23.txt
> 
> 
> Please review the latest draft carefully and direct all 
> comments to the MMUSIC list and the authors.
> 
> Joerg
> 
> 
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 22 Dec 2004 14:14:08 +0100

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"?

Regards,

Christer Holmberg
Ericsson Finland

> [mailto:[email-masked]]On Behalf
> Of Joerg Ott
> Sent: 19. joulukuuta 2004 18:51
> To: [email-masked]
> Cc: Colin Perkins

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 22 Dec 2004 14:16:17 -0500

> 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?
> 

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.