headers
Christer Holmberg | 18 Jun 2013 08:56
Picon
Favicon

BUNDLE TEXT: ICE Procedures (18.6)

Hi,

 

I did some updates (mostly editorial) to the BUNDLE ICE Procedures section.

 

So, when reviewing BUNDLE-04, for the ICE parts, please use the text below as base :)

 

Regards,

 

Christer

 

----------------------------------

 

 

8.  Usage With ICE

 

8.1.  General

 

   This section describes how to use the BUNDLE mechanism together with

   the Interactive Connectivity Establishment (ICE) mechanism [RFC5245].

 

8.2.  ICE Candidates

 

8.2.1.  Offerer Procedures

 

   When an ICE-enabled Offerer generates an SDP Offer, with a BUNDLE

   group, the Offerer MUST assign ICE candidates [RFC5245] to each "m="

   line in the BUNDLE group.

 

   If the Offerer assigns unique addresses to each "m=" line in the

   BUNDLE group, the Offerer MUST assign assign unique ICE candidate

   values to each "m=" line in the BUNDLE group.  The Offerer MUST NOT

   assign the same ICE candidate values to "m=" lines outside the BUNDLE

   group, or to "m=" lines in another BUNDLE group.

 

   If the Offerer assigns the BUNDLE address to each "m=" line in the

   BUNDLE group, the Offerer MUST assign assign identical ICE candidate

   values to each "m=" line in the BUNDLE group.  The Offerer MUST NOT

   assign the same ICE candidate values to "m=" lines outside the BUNDLE

   group, or to "m=" lines in another BUNDLE group.

 

8.2.2.  Answerer Procedures

 

   When an ICE-enabled Answerer generates an SDP Answer, with a BUNDLE

   group, the Answerer MUST assign ICE candidates to each "m=" line in

   the BUNDLE group.  The Answerer MUST assign identical ICE candidate

   values to each "m=" line in the BUNDLE group.  The Answerer MUST NOT

   assign the same ICE candidate values to "m=" lines outside the BUNDLE

   group, or to "m=" lines in another BUNDLE group.

 

8.3.  ICE Connectivity Checks

 

   Once a BUNDLE address has been selected for the Offerer and the

   Answerer, it is RECOMMENDED to perform ICE connectivity checks and

   keep-alives [RFC5245] for the whole BUNDLE group, rather than for

   each individual "m=" line in the BUNDLE group.

 

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 3 comments |
headers
Ari Keränen | 18 Jun 2013 01:01
Picon
Favicon
Gravatar

WGLC for draft-ietf-mmusic-sdp-g723-g729-03

This is to start a 2-week Working Group Last Call for

draft-ietf-mmusic-sdp-g723-g729-03

The WGLC ends on July 2nd, 2013.

Please review the document and send your comments both to the authors 
and to the MMUSIC mailing list. If you review the document but do not 
have any comments, please send a note to that effect as well.

The document is available here:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-03

Thanks,
Ari
Permalink | Reply | 0 comments |
headers
internet-drafts | 17 Jun 2013 19:29
Picon
Favicon

I-D Action: draft-ietf-mmusic-sdp-g723-g729-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Offer/Answer Considerations for G723 Annex A and G729 Annex B
	Author(s)       : Muthu Arul Mozhi Perumal
                          Parthasarathi Ravindran
	Filename        : draft-ietf-mmusic-sdp-g723-g729-03.txt
	Pages           : 8
	Date            : 2013-06-17

Abstract:
   RFC4856 describes the annexa parameter for G723 and the annexb
   parameter for G729, G729D and G729E. However, the specification does
   not describe the offerer and answerer behavior when the value of the
   annexa or annexb parameter does not match in the Session Description
   protocol(SDP) offer and answer.  This document provides the offer/
   answer considerations for these parameters and updates RFC4856.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-g723-g729-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Permalink | Reply | 0 comments |
headers
Bernard Aboba | 17 Jun 2013 19:20
Picon
Favicon

RFC 6190 Single Session Transport

At the virtual interim, a question arose about RFC 6190 Single Session Transport. 

Here is what RFC 6190 Section 1 says:

This memo defines two basic modes for transmission of SVC data, single-session transmission (SST) and multi-session transmission (MST). In SST, a single RTP session is used for the transmission of all scalability layers comprising an SVC bitstream; in MST, the scalability layers are transported on different RTP sessions. Section 1.2.2 clarifies the usage scenarios of SST and MST: SST should be used in point-to-point unicast applications and, in general, whenever the potential benefit of using multiple RTP sessions does not justify the added complexity... MST should be used in a multicast session when different receivers may request different layers of the scalable bitstream. Since SST implies (by definition), use of a single RTP session to transport multiple layers, were plan A to be used for signaling, negotiation of SST would only be possible if both peers support BUNDLE, since otherwise distinct RTP ports would be required for each layer, which is incompatible with SST. Today, existing SST implementations typically utilize a single m line. As Jonathan noted, some implementations utilize the same SSRC for multiple layers, while others utilize distinct SSRCs.  Utilization of the same SSRC is possible, since separation of the layers can be handled within the H.264/SVC implementation.
_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 4 comments |
headers
Ari Keränen | 17 Jun 2013 16:18
Picon
Favicon
Gravatar

Virtual interim meeting material

Virtual interim meeting material available here:
http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/proceedings.html

Chair slides with agenda proposal(s): 
http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/slides/slides-interim-2013-mmusic-3-0.ppt

Cheers,
Ari
Permalink | Reply | 1 comment |
headers
Christer Holmberg | 17 Jun 2013 09:20
Picon
Favicon

BUNDLE: SDP O/A Open Issue: Allowed for Offerer to assign same address to multiple m- lines before Answerer has indicated BUNDLE support in SDP Answer?

Hi,

 

In BUNDLE-04, there are a couple of open issues associated with assigning the same address to multiple m= lines in a BUNDLE group.

 

The main technical issue is whether it should be allowed to do it *before* the Answerer has, in the SDP Answer, indicated support of BUNDLE.

 

I.e. should it be allowed to, in the *initial* SDP Offer, assign the same address to multiple m= lines in a BUNDLE group?

 

Paul has indicated that it should be allowed, if the Offerer e.g. “knows” that the environment where it is operating in supports BUNDLE.

 

Now, as that is very similar to my original BUNDLE proposal, I would like to hear what others (especially Cullen) thinks about it.

 

Regards,

 

Christer

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 1 comment |
headers
Christer Holmberg | 15 Jun 2013 10:58
Picon
Favicon

When commenting on BUNDLE-04

Hi,

 

When giving comments on BUNDLE-04, I would appreciate if you could separate your comments into different e-mails, e.g. one mail per main topic (SDP O/A procedures, ICE usage, SDP Attribute procedures, etc etc etc).

 

It will be much easier to follow the discussion, and we’ll avoid ultralong e-mails :)

 

It would also be good if you could indicate whether any given comment is editorial or technical.

 

Thanks!

 

Christer

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 0 comments |
headers
Christer Holmberg | 14 Jun 2013 23:18
Picon
Favicon

Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-04

Dear Bundle Fans,

 

I’ve submitted a new version (-04) of BUNDLE.

 

Compared with the previous version, there are some rather big editorial changes, especially in the SDP Offer/Answer sections, mostly based on the mail discussions.

 

I have not touched the “ICE Usage” section at all. That is one of the next things we need to deal with.

 

Regards,

 

Christer

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 0 comments |
headers
Ari Keränen | 14 Jun 2013 20:20
Picon
Favicon
Gravatar

MMUSIC WG June 17th virtual interim agenda

Hi all,

Given the guidance from the RTCWEB WG chairs that the "no-plan" 
discussion should essentially happen at the RTCWEB WG, the MMUSIC 
interim meeting on June 17th will be focused on Plan A and Plan B. The 
goal of the meeting is to clarify what are the two different plans, what 
are their key differences and merits, and how can we select one to move 
forward with.

Here's the draft agenda:

7:00 – 7:10 Agenda bash & Note takers
7:10 – 8:10 Plan A Presentation
  http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00
  (also http://tools.ietf.org/html/draft-roach-rtcweb-glareless-add-00)
8:10 – 9:10 Plan B Presentation
   http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00
9:10 – 9:50 Discussion on preferred approach
9:50 – 10:00 Wrap-Up & Next Steps

Note: All Times are Pacific Daylight Time (PDT)

The WebEx information for joining the meeting is available here:
http://www.ietf.org/mail-archive/web/mmusic/current/msg11488.html

Regards,
Ari & Flemming (MMUSIC co-chairs)
Permalink | Reply | 18 comments |
headers
Ari Keränen | 14 Jun 2013 16:44
Picon
Favicon
Gravatar

Minutes of the MMUSIC WG May 23rd virtual interim meeting

Hi all,

The draft minutes of the MMUSIC WG May 23rd virtual interim meeting have 
been posted at:

http://www.ietf.org/proceedings/interim/2013/05/23/mmusic/minutes/minutes-interim-2013-mmusic-2

Please review the minutes and let us know of any comments or corrections.

Thanks,
Ari & Flemming (MMUSIC co-chairs)
Permalink | Reply | 0 comments |
headers
Flemming Andreasen | 14 Jun 2013 00:16
Picon
Favicon

What should we do with the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) ?

Greetings MMUSIC

As noted previously (http://www.ietf.org/mail-archive/web/mmusic/current/msg09368.html), we currently have a milestone for " Considerations for using SDP offer/answer with middleboxes" and we have a WG draft for that in the form of

    http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes/

When we polled for interest in this work about 1 year ago (per the above thread), there was some indication of continued interest in the work, however there were also some (significant) concerns expressed with the draft itself (see e.g. most recent thread in http://www.ietf.org/mail-archive/web/mmusic/current/msg10163.html). These concerns have existed for well over a year and we have seen very little discussion or active work trying to resolve them.

In lieu of the above, the chairs would like to ask the WG participants to

1) Indicate if you are in favor of continuing this work.

2) If you are willing to actively contribute to the work by either
a) Sign on as co-author, drive the open issues to resolution, and update the document accordingly
b) Actively contribute to discussion and resolution of open issues in the draft.

Please note, that if you answer "yes" to 2a or 2b, then you should assume that you *will* get called upon to deliver on that.

Also please note, that if we do not get sufficient positive responses to both 1 and 2 above, then our plan is to remove the milestone and abandon the WG draft.

Thanks

-- Ari & Flemming (MMUSIC co-chairs)













_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 1 comment |

Gmane