headers
Ali C. Begen (abegen | 3 May 2010 04:50
Picon
Favicon

Re: Next steps on 4765bis - issue with obsoleting "FEC" yet saying it is ok to use it beyond backward comp.

Hi JF,

>   I started reviewing the diff between draft-07 and draft-08 but did not finish so I may send more on
> Monday 5/3.

Sure.

> 0) nits
> - Use of "old" in Old "FEC" Grouping semantics - you may want to use Deprecated or Obsoleted in the
> title of section 4.1

"Obsoleted" sounds good.

> 1) Deprecating or not deprecating a=group:FEC?
> The new text is ambivalent.  It seems to me that your section 4.1 says it is ok to still use/implement
> the "old" FEC grouping... when you say
> 	" the "FEC" semantics can be safely used. "
> 	=> to me, that means they are not deprecated and are still quite valid to use in certain cases.
> This was ok when you were "updating" 4756 but now, it seems awkward.

The goal is to obsolete 4756, but also keep a definition of the old semantics in the bis document so that
implementations willing to stay backward compatible can infer what to do solely from the bis document.

> Proposal:
>   Could this draft make it clearer in its obsolescence of RFC4756 by:
> 	- first, defining "FEC-XR" and recommending it be used
> 		-> I'd move up section 4.2 and 4.4
> 	- second, re-defining "FEC" semantics formally (if you maintain the point of 4.1)
> 		-> Use of "FEC" grouping and applicability statement
> 		  This section would basically say that implementations MAY/SHOULD implement "FEC" for
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gonzalo Camarillo | 3 May 2010 12:30
Picon
Favicon

Re: IPv6 transition and ICE

Hi,

thank you all who participated on this thread. There was a lot of useful
information shared. Now it should be clearer to everyone what people
have in mind in this area.

The next step will be for the WG to analyze these requirements and make
an educated decision on what to do now that the use cases have been
described.

Cheers,

Gonzalo
Permalink | Reply | 0 comments |
headers
Muthu ArulMozhi Perumal (mperumal | 3 May 2010 16:57
Picon
Favicon

Re: draft-ietf-mmusic-media-loopback-13 questions

These look good to me and flexible enough to also request a transcoder
to loopback a media stream. 

However, the RTP port numbers advertised by the source/mirror for the
in/out and from/to media stream pairs would typically be the same. Is it
legal/safe to pair m-lines that use the same IP address and port?

RFC3388 (section 7.5.3) forbids such an usage for the Flow
Identification (FID) group:

<snip>
   FID MUST NOT be used to group "m" lines with the same 
   IP address/port. Therefore, an SDP like the one below MUST NOT
   be generated.

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=audio 30000 RTP/AVP 8
       a=mid:2

   The correct SDP for the session above would be the following one:

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Kyzivat | 3 May 2010 17:55
Picon
Favicon

Re: draft-ietf-mmusic-media-loopback-13 questions


Muthu ArulMozhi Perumal (mperumal) wrote:
> These look good to me and flexible enough to also request a transcoder
> to loopback a media stream. 
> 
> However, the RTP port numbers advertised by the source/mirror for the
> in/out and from/to media stream pairs would typically be the same. Is it
> legal/safe to pair m-lines that use the same IP address and port?

That's a mistake in my examples. It should be as follows:

If the same format is used for the source and the mirror, then there 
will be only one m-line used bidirectionally. In case where different 
formats are used in the two directions, then different ports should be used.

> RFC3388 (section 7.5.3) forbids such an usage for the Flow
> Identification (FID) group:
> 
> <snip>
>    FID MUST NOT be used to group "m" lines with the same 
>    IP address/port. Therefore, an SDP like the one below MUST NOT
>    be generated.
> 
>        v=0
>        o=Laura 289083124 289083124 IN IP4 six.example.com
>        t=0 0
>        c=IN IP4 131.160.1.112
>        a=group:FID 1 2
>        m=audio 30000 RTP/AVP 0
>        a=mid:1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Francois Mule | 3 May 2010 18:40
Favicon

Re: Next steps on 4765bis - issue with obsoleting "FEC" yet saying it is ok to use it beyond backward comp.

Hi,

  The IESG or AD recommendations to now obsolete 4756 (instead of just updating it) does imply a few
differences in the text.
The document should be updated as if 4756bis is the only document of reference for FEC Grouping in SDP, the
one that defines FEC grouping semantics fully (not just the delta you added to meet the 2 new requirements
and SSRC-level grouping but all of it).

A) Write 4756bis as the document of reference for FEC grouping in SDP
For example, the text in the abstract would merit some editing (and the pointer to 3388bis you had in the
original 4756). 
Consider this proposed text for the new abstract:
"   This document defines the semantics for grouping the associated source and Forward Error Correction
(FEC)-based repair flows in the Session Description Protocol (SDP).
   The semantics defined in this document are to be used with "Grouping of Media Lines in the Session
Description Protocol" (RFC 3388bis) to group together "m" lines in the same session.
   This document revises the semantics defined in RFC 4756 first to allow one or more source and/or repair flow
in the same group, and second, to support describing additive repair flows.  Synchronization Source
(SSRC)-level grouping semantics are also introduced in this document for Real-time Transport Protocol
(RTP) streams using SSRC multiplexing.
"

B) Is a=group:FEC deprecated or not?

Same point as in my previous email:
> > 1) Deprecating or not deprecating a=group:FEC?
> > The new text is ambivalent.  It seems to me that your section 4.1
> says it is ok to still use/implement
> > the "old" FEC grouping... when you say
> > 	" the "FEC" semantics can be safely used. "
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kumar, Satish | 6 May 2010 16:32
Picon
Favicon

Re: draft-ietf-mmusic-media-loopback-13 questions

Hi All,

	I need to revisit my original question here. As per below explanation the SDP stated in draft (just above
sec 5.4) is wrong. Here is the snapshot.

Example:       m=audio 41352 RTP/AVP 112
               a=loopback:rtp-pkt-loopback
               a=loopback-source:0 8
               a=rtpmap:112 rtploopback/8000
                      ^^^^^^^
Hi Paul E,
Can I safely assume that for rtp-loopback, payload type change is not allowed?  Please let me know.

Thx, Satish

-----Original Message-----
From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On Behalf Of Paul Kyzivat
Sent: Friday, April 30, 2010 8:27 AM
To: Muthu ArulMozhi Perumal (mperumal)
Cc: kaynam.hedayat <at> exfo.com; mmusic <at> ietf.org
Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions

Muthu ArulMozhi Perumal (mperumal) wrote:
> Paul,
> 
> |So maybe the answer here is to always include both the "real" formats 
> |*and* the encapulated formats in both the offer and the answer, while 
> |using the loopback-source and loopback-mirror to determine who uses
> what.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
RFC Errata System | 6 May 2010 18:58
Favicon

[Technical Errata Reported] RFC4567 (2247)


The following errata report has been submitted for RFC4567,
"Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4567&eid=2247

--------------------------------------
Type: Technical
Reported by: Riccardo Bernardini <riccardo.bernardini <at> uniud.it>

Section: 3.2

Original Text
-------------
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %22 URI %22 ";"] 

Corrected Text
--------------
key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %22 URI %22 ";"] ["data" "=" %22 base64 %22 ";"]

Notes
-----
There is an inconsistency between the ABNF for key-mgmt-spec on page 6 and the two SETUP examples on top of
page 21.  In both examples a field data="..." is present in the keymgmt header, but the ABNF on page 6 does not
allow for it.  The suggested correction solves the inconsistency.

Instructions:
-------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul E. Jones | 6 May 2010 22:21
Favicon

Re: draft-ietf-mmusic-media-loopback-13 questions

Satish,

I think we need a few experts to weigh in on this one. My reading suggested
it was, but others suggested that my interpretation was wrong. Indeed, when
I re-read the offer/answer document I could see where I was wrong.

Still, I'd rather have others comment on the list if they feel the
procedures are flawed.

Paul

> -----Original Message-----
> From: Kumar, Satish [mailto:satish.kumar <at> ti.com]
> Sent: Thursday, May 06, 2010 10:32 AM
> To: Paul Kyzivat; Muthu ArulMozhi Perumal (mperumal); Paul E. Jones
> Cc: kaynam.hedayat <at> exfo.com; mmusic <at> ietf.org
> Subject: RE: [MMUSIC] draft-ietf-mmusic-media-loopback-13 questions
> 
> Hi All,
> 
> 	I need to revisit my original question here. As per below
> explanation the SDP stated in draft (just above sec 5.4) is wrong. Here
> is the snapshot.
> 
> Example:       m=audio 41352 RTP/AVP 112
>                a=loopback:rtp-pkt-loopback
>                a=loopback-source:0 8
>                a=rtpmap:112 rtploopback/8000
>                       ^^^^^^^
> Hi Paul E,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 7 May 2010 16:20
Picon
Favicon

Re: [AVT] Sockets in multicast DTLS-SRTP

> -----Original Message-----
> From: Romain Biehlmann [mailto:romain.biehlmann <at> gmail.com] 
> Sent: Friday, May 07, 2010 1:35 AM
> To: Dan Wing
> Cc: avt <at> ietf.org; Flemming Andreasen; mmusic <at> ietf.org
> Subject: Re: [AVT] Sockets in multicast DTLS-SRTP
> 
> Hi Dan,
> 
> Thank you for your answer: the first solution could solve the problem.

Great; that keeps things simplier.

> I now wonder about KTR: do you consider (a) as a replacement for (b)?
> 
> (a)
> a=dtls-srtp-ktr
> a=dtls-srtp IP4 192.168.0.1 12345
> 
> (b)
> a=dtls-srtp-ktr
> a=dtls-srtp-ktr-server:12345 IN IP4 192.168.0.1

Only difference appears to be a choice of syntax.  I was intending to follow
the same syntax of ICE (I can't follow m=/c= syntax, as they put the IP
address and port on different lines).

-d

> Romain
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simo.Veikkolainen | 10 May 2010 11:44
Picon

What to do with the ccap attribute?

Now that the discussion on ICE and v6 transition has quieted down, I would like to ask for the list's opinion
on how to proceed with the ccap attribute defined in http://tools.ietf.org/html/draft-ietf-mmusic-sdp-misc-cap

Note that this draft will be re-submitted as an individual document according to the WG decision in
IETF#77. Nevertheless it contains the most up-to-date text, hence the reference.

As a short reminder, the misc-cap document defines capability attributes for "i=", "b"= and "c=" lines
(icap, bcap and ccap, respectively). The ccap capability attribute is used to indicate alternative
connection addresses. Our use case for this has been the ability to indicate alternative IP and PSTN
addresses; a feature which is needed in some 3GPP scenarios.

As ccap is currently specified, it includes also the port number in addition to the contents of a "c=" line
(<nettype>, <addrtype> and the <connection-address>). The port number is needed in order to indicate a
port number for internet addresses, the PSTN addresses don't have a similar concept.

Now, as a side effect, the ccap attribute could also be used to circumvent ICE, if one used IP4 and IP6
addrtypes as alternatives.

In order to move forward with the misc-cap document I'm now asking how do folks feel we should handle this
issue. Possible alternatives are at least:

1. Leave the current text as is (see [1]).

2. Make a more strict statement that ccap SHOULD NOT be used for v4/v6 address pairs.

3. Come up with altogether different way of indicating alternative connection addresses that fulfill our
use case (PSTN/IP addresses). 

Regards,
Simo
(Continue reading)

Permalink | Reply | 4 comments |

Gmane