http://blog.gmane.org/gmane.ietf.mmusic hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.mmusic/10693 <pre>Hi, Currently BUNDLE defines that the first offer is sent with separate port numbers (later, if the answerer has indicated support of BUNDLE, the offerer will send a second offer, with identical port numbers). Some people have indicated that the offerer shall be able to receive data already when the first offer has been sent. The question is on which port(s) it needs to be able to receive media. - Some have suggested the port of the first non-zero m- line within the offered bundle group. - Some have suggested ANY port The issue with assuming the first non-zero m- line is that the answerer in the answer may reject it (put the port to zero), or remove it from the bundle group (which people seem to want to allow). In both cases it would be strange to assume the first m- line. Now, in case e.g. ICE is used, the offerer will be able to send the second offer before any media is received to begin with. But, the offerer could still receive STUN connectivity checks on any of the ports, until</pre> Christer Holmberg 2013-05-20T11:43:30 http://comments.gmane.org/gmane.ietf.mmusic/10688 <pre>The rtsp-nat draft reflects analysis done in the rtsp-nat-evaluation draft, which just concluded a reissued WGLC. We previously had a 2 week WGLC on the rtsp-nat-14 draft, which resulted in a few updates. In lieu of this, we are announcing a 1 week Working Group Last Call for any final comments on draft-ietf-mmusic-rtsp-nat-15 as Proposed Standard. Please review and provide any comments you may have on the document by May 25, 2013. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks Flemming Draft Info: 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 : A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) Author(s) : Jeff Goldberg </pre> Flemming Andreasen 2013-05-17T14:04:05 http://comments.gmane.org/gmane.ietf.mmusic/10676 <pre>Here is what we are planning to send as a response to the 3GPP liaison request regarding 3D video work at MMUSIC (for details, see https://datatracker.ietf.org/liaison/1239/). Regards, Ari &amp; Flemming (MMUSIC co-chairs) --- Title: Reply to Liaison statement to IETF concerning 3D video formats signalling in SDP Source: IETF MMUSIC WG To: TSG-SA WG4 The MMUSIC Working Groups thanks SA4 for their information request around work related to SDP signaling of 3D video formats. At the present time, the MMUSIC WG does not have any active work in this area. For your information, the MMUSIC WG did previously (in 2012) consider work in this area based on the following 3 documents: http://datatracker.ietf.org/doc/draft-capelastegui-mmusic-3dv-sdp/ http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-sdp-parallax/ http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-sdp-3d-format/ The drafts were presented in a couple of meetings and discussed on the MMUSIC mailing list, however there was n</pre> Ari Keränen 2013-05-16T19:58:14 http://comments.gmane.org/gmane.ietf.mmusic/10651 <pre>The following errata report has been submitted for RFC6236, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6236&amp;eid=3620 -------------------------------------- Type: Editorial Reported by: Liangxing Wang &lt;liangxwa&lt; at &gt;cisco.com&gt; Section: 4.2.4 Original Text ------------- send [x=400:16:800],y=[320:16:640],sar=[1.0-1.3],par=[1.2-1.3]] Corrected Text -------------- send [x=[400:16:800],y=[320:16:640],sar=[1.0-1.3],par=[1.2-1.3]] Notes ----- Mismatching [] in original text. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6236 (draft-ietf-mmusic-image-attributes-11) </pre> RFC Errata System 2013-05-15T03:56:04 http://comments.gmane.org/gmane.ietf.mmusic/10643 <pre>The following errata report has been submitted for RFC5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5245&amp;eid=3619 -------------------------------------- Type: Technical Reported by: Ashish Kundu &lt;akundu&lt; at &gt;us.ibm.com&gt; Section: Section 4, 5 Original Text ------------- Missed candidate pair in ICE standard Corrected Text -------------- Scenario: X is caller, Z is callee. X is behind a non-full-cone (such as symmetric) NAT, Z is behind a full-cone NAT. ICE standard: Section 2.1 of RFC5245 describes the addresses that are collected as candidate addresses: (local address, server-reflexive address, TURN relay address). For X: (X:x, X1:x1, Yx:yx), and for Z: (Z:z, Z1:z1, Yz:yz). Missed candidate pair in ICE standard: 1. X:x sends a connection check message to the Z1:z1 (as part of the proce</pre> RFC Errata System 2013-05-14T04:21:07 http://comments.gmane.org/gmane.ietf.mmusic/10630 <pre>We've had a great deal of discussion about plan A and B and the various interactions of these proposals with bundling. But I still don't get a good sense that there is a working consensus on what an m-line actually represents. I think that we've each reached our own conclusions, but they definitely are not consistent. We need a well-understood semantic for m-lines if we have any chance of resolving these issues; Plan A/B being only the first RTCWEB problem to address. RFC 4566 is helpfully devoid of detail, so we are free to come up with any interpretation we choose. Here are the ones that I have seen: 1. an m-line represents a single RTP session (or at least the part of the session that touches the client) This appears to be consistent with the Plan B approach 2. an m-line represents the set of RTP streams that decode into a single rendering, including layers, simulcast and FEC 3. an m-line represents a single RTP stream; multiple m-lines might be required to obtain a single rendering if </pre> Martin Thomson 2013-05-13T18:42:32 http://comments.gmane.org/gmane.ietf.mmusic/10619 <pre>Hi, We seem to have an agreement that, when an SDP offer contains an m- line associated with a bundle group, it is ok to leave that m- line outside the bundle group in the SDP Answer. Now, there has been some discussions about "splitting" a BUNDLE, meaning that an m- line in an SDP Answer is added to a DIFFERENT bundle group than in the SDP Offer. Based on the discussions, it seems like people would be ok to NOT allow that. If the SDP Answerer wants to put an m- line in another bundle group, it needs to first reply to the SDP Offer, and then send a new SDP Offer itself, putting the m- line in the bundle group it wants. In short, is basically means: in an SDP Answer, an m- line must only be bundle grouped with the same m- lines (or, a subset of those) as in the associated SDP Offer. Regards, Christer _______________________________________________ mmusic mailing list mmusic&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mmusic </pre> Christer Holmberg 2013-05-13T11:58:28 http://comments.gmane.org/gmane.ietf.mmusic/10577 <pre>We previously had a 2 week WGLC on the rtsp-nat-evaluation draft which resulted in several updates to the draft. The resulting -06 has been out for review without any additional comments for quite some time now. Based on that, we are announcing a 1 week Working Group Last Call for draft-ietf-mmusic-rtsp-nat-evaluation-06 as Informational. Please review and provide any comments you may have on the document by May 16, 2013. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks Flemming Draft Info: 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 : The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) Author(s) : Magnus Wes</pre> Flemming Andreasen 2013-05-09T14:52:10 http://comments.gmane.org/gmane.ietf.mmusic/10574 <pre>Greetings This is to announce a virtual interim meeting for the MMUSIC Working Group to take place on Thursday, May 23rd, from 7:00 am - 10:00 am Pacific Time. The goal of this meeting is to come to a resolution on the so-called "Plan A" or "Plan B" approach related to SDP signaling needed by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or very few "m=" lines and to what extent is there sub-negotation and signaling at the SSRC level). A more detailed agenda and logistics will be sent out separately. For now, people should take a close look at the following two drafts: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks </pre> Flemming Andreasen 2013-05-09T01:57:36 http://comments.gmane.org/gmane.ietf.mmusic/10555 <pre> 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 : Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication Author(s) : Emil Ivov Hadriel Kaplan Dan Wing Filename : draft-ietf-mmusic-latching-01.txt Pages : 14 Date : 2013-05-07 Abstract: This document describes behavior of signalling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as</pre> internet-drafts< at >ietf.org 2013-05-07T18:29:05 http://comments.gmane.org/gmane.ietf.mmusic/10543 <pre>I have been working on an SDP Directorate review of a draft that defines some new SDP attributes. In the process of doing that I came across some things that I think ought to be improved in 4566bis: 1) The formal syntax for SDP in 4566 defines a generic syntax for attributes: attribute-fields = *(%x61 "=" attribute CRLF) attribute = (att-field ":" att-value) / att-field att-field = token att-value = byte-string This is fine. Elsewhere it defines a number of specific attributes: a=cat:&lt;category&gt; ... a=keywds:&lt;keywords&gt; .... These are defined with informal patterns such as above, along with text. There is no formal specification of the syntax of the values of these attributes. Then in the IANA considerations section these attributes are added to the IANA registry of SDP attributes. The main problem with the above is the lack of syntax for the values. With newer attributes in other drafts we have typically required ABNF. I</pre> Paul Kyzivat 2013-05-06T18:42:20 http://comments.gmane.org/gmane.ietf.mmusic/10538 <pre>Hi, I have been assigned to perform a SDP Directorate review of the document. The document does not define new SDP related procedures, but refers to the procedures in RFC 3611. As was mentioned by Dan, it is allowed to use the feature without signaling support in SDP. But, as that has been accepted already when RFC 3611 was made, it would be messy to change it for this specific XR usage. So, from an SDP directorate perspective, I think the draft is ready for publication. Regards, Christer _______________________________________________ mmusic mailing list mmusic&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mmusic </pre> Christer Holmberg 2013-05-06T10:32:22 http://comments.gmane.org/gmane.ietf.mmusic/10522 <pre>Hi, Assume the following case: 1. An SDP offer contains an m- line associated with a BUNDLE group 2. The answerer wants to accept the m- line, but wants to reject it being in the specific BUNDLE group. A few alternatives on how this could be achieved have been presented: Alt 1. The answerer accepts the m- line, but does not associate it with a BUNDLE group. Alt 2. The answerer accepts the m- line, associates it with a BUNDLE group, and then sends a new offer which removes the m- line from the BUNDLE group. Alt 3. The answerer rejects the m- line, and then sends a new offer which adds the m- line outside a BUNDLE group. In my opinion, Alt 1 does not work, at least not if the offer contains identical port values for the m- lines associated with the BUNDLE group. It would mean that the m- line is not added to a BUNDLE group, but still has the same port value (at least at the offerer side) as the m- lines in the BUNDLE group, which is not allowed. So, my suggestion would be t</pre> Christer Holmberg 2013-05-03T13:07:00 http://comments.gmane.org/gmane.ietf.mmusic/10521 <pre>Hi, In order to try to close issues on BUNDLE, based on the discussions we've had, I intend to update the BUNDLE draft based on the following assumptions: 1. We mandate usage of rtcp-mux when BUNDLE is used. 2. SDP m- lines with a zero port value MUST NOT be put inside a BUNDLE group (not in an offer, nor in an answer). There will be a note indicating that, due to this, the number of m- lines associated with a BUNDLE group may differ between the offer and the associated answer. There will also be a note indicating that this is due to RFC 5888, in case people later start to wonder where the "MUST NOT" comes from. Please indicate if you OBJECT to any of these assumptions. Regards, Christer _______________________________________________ mmusic mailing list mmusic&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mmusic </pre> Christer Holmberg 2013-05-03T12:53:03 http://comments.gmane.org/gmane.ietf.mmusic/10498 <pre> 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 : A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) Author(s) : Jeff Goldberg Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-15.txt Pages : 32 Date : 2013-05-02 Abstract: This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rts</pre> internet-drafts< at >ietf.org 2013-05-02T15:49:35 http://comments.gmane.org/gmane.ietf.mmusic/10493 <pre>Hi, One of the open issues is the usage of m- lines with port value zero within a BUNDLE group. As Paul has indicated, RFC 5888 does not currently allow it. One suggestion has been to update RFC 5888. But, before we go down that path, I think we need to see whether NOT allowing zero port m- lines in BUNDLE groups would work. So, how would it impact BUNDLE? Zero port value in answer: If an m- line in the offer contains a non-zero port value, but the associated m- line in the answer contains a zero port value (read: the answerer rejected the offered media associated with the m- line), the number of m- lines associated with the BUNDLE group would differ in the offer and answer. As the media is rejected, no matter whether it would be part of a BUNDLE group or not, I can't think of any issues. Zero port value in offer: If an m- line in the offer contains a zero port value, the associated m- line in the answer MUST also contain a zero port value. If the m- line has previously been part of a BUNDLE gro</pre> Christer Holmberg 2013-05-02T12:55:13 http://comments.gmane.org/gmane.ietf.mmusic/10484 <pre>RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which side is the DTLS server must be established via some out-of-band mechanism such as SDP." What is the specification on how to signal that in SDP? Specifically in case of 3pcc where both endpoints are SDP offerers which one should take the client and server roles for DTLS? Should we tie that role to ICE controlled/controlling roles or should we negotiate it in the SDP somehow? G. </pre> Gustavo García 2013-05-01T18:26:52 http://comments.gmane.org/gmane.ietf.mmusic/10474 <pre>Hi, As currently indicated in BUNDLE, and SDP offer for RTP must contain an rtcp-mux attribute, indicating support of RTP/RTCP multiplexing. However, it is currently optional to include it in the SDP answer. There has been some discussions on whether we should MANDATE the usage of rtcp-mux whenever BUNDLE is enabled. Would anyone OBJECT to that? Regards, Christer _______________________________________________ mmusic mailing list mmusic&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mmusic </pre> Christer Holmberg 2013-04-30T13:26:35 http://comments.gmane.org/gmane.ietf.mmusic/10472 <pre>Hi, Here is my review of the introduction and those sections related to RFCs that I have been part of writing as requested (5.3, 5.9, 6.2, 6.3, 8.3). I would have to note that although it is good to solicit reviews it would have been desirable to not CC the WG mailing list for each solicitation. 1) Section 1) However, in the RTCWeb WG, a requirement has arisen to multiplex several RTP Sessions over a single transport layer flow. I wished this was the part there was strong consensus because, the only solution on the table that tries to solve this issue is: https://datatracker.ietf.org/doc/draft-westerlund-avtcore-transport-multiplexing/ What so far been most discussed is having multiple media types in one RTP session. That also implies multiple SDP Media Descriptions (m= blocks) describing one RTP session. There are a very important distinction here. Something I will return to. 2) Section 3: The specific problem is that there are attribute combinations which make sense when specified o</pre> Magnus Westerlund 2013-04-30T09:44:40 http://comments.gmane.org/gmane.ietf.mmusic/10466 <pre>Moving this proposal over from the RTCWEB mailing list, updating and correcting it: I was working on an essay based on the assumption that a single video capture is carried over a single m= line (with the various component streams (simulcast, FEC, layered encoding, etc.) sent using different SSRCs)... But many existing systems don't work that way. It would be nice to correct that, but basing our solution on that assumption isn't the quick way to get products to market. ;-) So we can't assume a small number of m= lines, which implies that we can't safely require that each m= line has a disjoint set of payload types, which implies that we can't demultiplex based on PT. If multiplexing based on payload type is unworkable, how about the following technique. (Forgive me if someone else has already proposed it.) Each SSRC is demultiplexed based on an RTCP SDES item that specifies the mapping between the SSRC and the m= line via which it is presented to the application layer. When a media stream</pre> Dale R. Worley 2013-04-29T21:59:58 http://comments.gmane.org/gmane.ietf.mmusic/10453 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond1< at >hushmail.com 2013-04-27T17:37:17 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.mmusic