Re: Martians
On Wed, 13 Mar 2013, Noel Chiappa wrote: Subject: Re: Martians Martian is nice expression. Weren't 'unusual' packets called 'Martians' at some early stage of Internet work? It certainly has history in the IETF as a term of art, I think that's it. Yes, attributed to Dave Mills, I believe, along with a number of other colorful expressions. -- Steve
Re: WG Review: Internet Wideband Audio Codec (codec)
On Tue, 5 Jan 2010, Phillip Hallam-Baker wrote: It seems to me that a group should be chartered with two sets of aims First to define a process for registering Internet audio CODECs for use on the Internet. This is slightly more complex than simply allocating an IANA code point as there are potentially parameters involved and these need to be exposed to the higher level protocol. When a code point is registered we need to have a document that defines the parameters, bit packing, packet segmentation and other issues, the set of applications for which it applies and the proprietary encumbrances that are known to affect it. Second, to register a set of base CODECs that have already established some form of support base. This is likely to mean rather more than simply providing a reference to an existing document that describes how to do everything but should not extend to performing 'research' into compression techniques. What you have described is exactly what AVT WG has done for the past decade plus. No need for a new WG to do that. (AVT does other things, too.) In the past, particularly when I was co-chair of AVT, there was significant pressure from IETF leadership against IETF (and AVT in particular) standarizing codecs out of concern that to do so would step on ITU toes. We made a carefully considered exception for iLBC because it had goals similar to those now being proposed. If the concern has now dissipated, that's fine with me. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: meeting attendance nomcom
On Fri, 9 Jan 2009, Eliot Lear wrote: I don't know about other companies, but mine has pretty tight travel restrictions right now. I do not yet know if I will make the San Francisco IETF or Stockholm. I suspect attendance at both will be way down, but it's a hunch. If others are in the same position, it will lead to a potential problem with the NOMCOM, which is that the pool of eligible volunteers may shrink to an unacceptably low number. It seems to me we already had problems getting a large enough pool in good times. If attendance is way down, then IETF will have a much bigger problem than finding NOMCOM volunteers. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: Pingsta Invitation
On Sat, 24 Mar 2007, Fred Baker wrote: Does anyone know who this is or what it is about? I don't know anything about Pingsta or its credibility. However, I am currently reading a boot titled Mavericks at Work which talks, in part, about open-source methods being applied to areas of business other than software development. Three companies, Your Encore, NineSigma, and InnoCentive, that serve as brokerages between people who need solutions and people who have ideas. The central notion is that a company's own RD team can't have anywhere near the breadth of the worldwide community of scientists, for example. The open question is to what extent that community is willing to participate, but the book implies that the three companies I mentioned are successful. It is likely that such an arrangement would be more appealing early in a career when becoming recognized and finding opportunities might be more valuable. Or, in the case of Your Encore, for scientists and engineers who have retired but still want an opportunity to apply their knowledge and intelligence. Pingsta might be an attempt to create a similar arrangement for internetworking. Whether is is honest, valuable, or potentially successful remains to be determined. -- Steve Begin forwarded message: From: Pingsta Registration [EMAIL PROTECTED] Date: March 24, 2007 8:31:52 AM GMT+01:00 To: Fred [EMAIL PROTECTED] Subject: Pingsta Invitation Fred, As an Internetwork expert, we would like to invite you to join Pingsta. Pingsta is a new experience in social networking that provides you with a platform to share your passion for internetworking, expand your industry network, and express yourself like never before. By actively contributing to Solvr - Pingsta's innovative user-generated internetwork intelligence repository - members extend their intellectual legacy and partake in Pingsta profit-sharing. Pingsta is exclusive to internetwork experts, membership is by invitation-only, and it only takes a minute to sign up. Here's your personalized invite-key: http://www.pingsta.com/[EMAIL PROTECTED]invitekey=eb108e15cd12c9b500695 Sincerely, The Pingsta team ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS pollution
On Wed, 11 Oct 2006, Keith Moore wrote: In the past month or so I've run across two separate ISPs that are apparently polluting the DNS by returning A records in cases where the authoritative server would either return NXDOMAIN or no answers. The A records generally point to an HTTP server that will display advertisements, but I've also seen more sinister things happen. Is there anything that IETF as an organization, or IETF participants, can do to discourage this? To me this is fraud and unfair trade practice in addition to being a security threat (as people give their passwords when trying to connect to the wrong site) and harmful to applications (either because they do connect to a protocol engine on the wrong server, or they try to connect to a nonexistent protocol engine on the wrong server and treat the connection refused or connection timed out condition as a temporary error). I've also seen this break applications that speak both IPv4 and IPv6 by failing to return the records. I agree. For me personally, this was not hypothetical. The Pine mail user agent that I use began to intermittently fail to connect to the IMAP server even when there was no evidence of problems with network connectivity. The problem turned out to be DNS fraud. I use ssh to connect over DSL service from Earthlink, and port forwarding to get to the IMAP server. That means Pine needs to connect to 127.0.0.1 on the forwarded port number. I don't know why, but Pine does a DNS lookup on 127.0.0.1. My problems arose when the Earthink DNS servers began returning A records for a host that, if accessed via http, provides a helpful message that the web site address I had entered could not be found. The DNS exchange, as displayed by ethereal: DNS Standard query A 127.0.0.1 DNS Standard query response A 209.86.66.92 A 209.86.66.93 A 209.86.66.94 A 209.86.66.95 A 209.86.66.90 A 209.86.66.91 This caused Pine to attempt an IMAP connection directly to that host rather than connecting to my intended IMAP server through the ssh port forwarding. Why the behavior was intermittent I have no idea, but the problem was baffling. I was able to figure out the answer because I am able to run tcpdump and interpret the results. Someone with less knowledge would just have to suffer. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS pollution
On Thu, 12 Oct 2006, Edward Lewis wrote: At 23:37 -0700 10/11/06, Stephen Casner wrote: connect to 127.0.0.1 on the forwarded port number. I don't know why, but Pine does a DNS lookup on 127.0.0.1. My problems arose when the Sounds like an application layer implementation defect. The problem could be solved by reporting the bug to the developers. I have now been informed that if I had enclosed the 127.0.0.1 in square brackets then Pine would not looked it up as a name. This potential for misinterpretation has probably not been seen as a problem because on many systems the DNS resolver will recognize the string as an address rather than a name and not do a forward lookup. The system on which this problem was observed was Windows-98. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 63 On-line Survey
On Thu, 18 Aug 2005, Brian E Carpenter wrote: Spencer Dawkins wrote: ... Would you prefer longer meetings or shorter meetings? Shorter meetings with more overlaps No change Longer meetings with fewer overlaps ... It was meant to refer to the Friday morning controversy- should we have more parallel sessions and end Thursday night, or fewer parallel sessions and end Friday night,or do what we do now. We didn't identify the ambiguity until too late. I thought the primary purpose of the survey was to find out whether people preferred the later schedule of hours during the day, and no evening sessions, as used in Paris, rather than to ask again about Friday. The question about hours was raised in the discussion on this list, and that prompted to say a survey would be taken. However, that question is not asked on the survey, unless the one quoted above is it. That would be even more ambiguous. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 63 On-line Survey
On Thu, 18 Aug 2005, Harald Tveit Alvestrand wrote: The question was Did you prefer the schedule change which had dinner following all sessions? - it only shows when you click Yes on the Did you attend Paris question. Forms that change their content based on the answers given look fancy, but they can be almighty confusing if you're trying to scan the questions before filling them in. I did not attend Paris, but I wanted to answer Yes to that question anyway. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RTP vs. MIME (Was Re: Ietf Digest, Vol 15, Issue 35)
I'll address just a few points: On Tue, 12 Jul 2005, Bruce Lilly wrote: The audio/amr format contains identical media data, but the RTP transport is defined to strip the initial magic number, which is redundant with fields in the RTP protocol headers. The wide band version of AMR, and the related EVRC formats are similar. Audio/amr explicitly specifies two separate media formats; if it were merely a matter of some RTP processing, such processing could have been specified separately from the format. As Colin explained, the two things specified are not separate media formats, they are: - a media format consisting of a sequence of frames - a means of processing those frames for transport in RTP They are specified separately in the RFC, but it makes sense to handle them together in one RFC, especially since many readers will be interested in both. The right way to think about this from the MIME perspective is that the document defines a media file format consisting of a concatenated sequence of frames with a magic number for identification as a header. Because the MIME type is applicable to multiple domains of use, it also indicates the selection of an RTP payload format using the same sequence of frames and loading them into packets. It's not about leakage, it hasn't been about leakage; that is a minor issue that has been turned into a strawman in order to demonstrate how easily it can be knocked down. In earlier discussions with Ned Freed and John Klensin, leakage of types from RTP applications to others was one of the primary concerns they expressed. RFC 2793 (the AVT 2793bis draft is unavailable) specifies: This is an example of a T140 RTP packet without redundancy. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC=0 |M| T140 PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp (1000Hz) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + T.140 encoded data + | | + +---+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] Published specification: ITU-T T.140 Recommendation. RFC 2793. First, the content excluding T.140 encoded data is not delimited as not part of the text content (vs. e.g. text/html, text/sgml, text/enriched, etc.). Second, unless it is absolutely guaranteed that neither octet of the sequence number, none of the 4 octets of the timestamp, and none of the 4 octets of the SSRC identifier can ever have values 0x00, 0x0A, or 0x0D, the format fails to comply with the text media type requirements, which prohibit those values. As Colin explained, the first twelve octets here are the RTP header, which is present in every RTP packet. It is comparable to a TCP header or a UDP header. RTP usually runs within UDP, and the concatenation of the UDP header and the RTP header provides a set of services that is similar to the set of services provided by the TCP header (not the same, of course, because the purpose is different). I don't think you are concerned, from a MIME perspective, that some of the octets of the TCP header carrying email may be 0x00, 0x0A or 0x0D. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Ietf Digest, Vol 15, Issue 17
On Tue, 5 Jul 2005, Bruce Lilly wrote: Date: 2005-07-05 11:18 From: Magnus Westerlund [EMAIL PROTECTED] Magnus, Comments in-line: [...] registered a large amount of names (70) makes it very hard to see that moving into separated registries will resolve any confusion. In addition it will require a huge work effort to move to the new registry. I have suggested grandfathering existing RTP-related registrations in a separate RTP registry. That would prevent further confusion and would give the RTP registry a separate sandbox with clean sand and new toys. Some small amount of copying work would be required, and of course registration procedures for both registries would require some minor tweaking. That's not it. Of course all the existing registrations would be copied. However, all of the many RTP-related RFCs that refer to MIME registrations would become obsolete and need to be revised. A fair number of those RFCs are referenced by other SDO's documents. As Colin mentioned, in December 1997, then-ADs Harald Alvestrand and Keith Moore strongly encouraged the AVT working group to convert from using its own name space for media payload formats to using the MIME media type registry. Some of the motivations for moving the RTP namespace into the MIME namespace were: - To avoid different names for the same media format, such as MIME's audio/basic and RTP's PCMU. More on this below. - To help populate the MIME audio and video spaces which were very sparse. The AVT working group did a lot of work between then and now to specify the mechanism for the registrations and to create registrations with what I believe was careful attention to detail. This process has imposed very little load on the MIME folks; in fact, it has received little notice until the recent consideration of two subtypes under the text major type. In my opinion, we should set a fairly high bar for the decision to change from the status quo and induce the overhead of obsoleting a large number of RFCs. To me the best way forward is that we clean up the registration procedures of the current media types registry. Because of widely-deployed mission-critical MIME applications, any such clean up cannot change the fundamental rules for text media types, as detailed earlier. We're not talking about mere entertainment applications, we're talking about email and things like Internet fax, voice messaging, and EDI. There is no proposal to change the way email, html, and fax use MIME types. Perhaps clean up is not the most appropriate term. I would say what's needed is to be more specific about the domains in which media types are used, without changing at all how they have been or will be used for email, etc. The issue I see is that with two separate registries one will not seriously consider the names in the other registry. Why should a MIME implementer need to consider RTP names or vice versa; e.g. text/plain or text/html vs. RTP? This question does not make any sense. Someone wanting to know more about text/plain would look up that media type. However, it would be good if someone who was thinking about sending snippets of audio captured from a GSM phone considering the registration of audio/GSM that is defined currently only for the transport via RTP. What I intended to stress was that having cross review between registries is a hard way of avoiding having two different formats register the same name but in different registries. As the name structure looks the same, it is very hard to determine to which registry such a name would belong. Thus one needs to look up both if checking. Why? An particular implementation is either handling RTP streams or MIME data, and would only need to be concerned with the appropriate registry. It seems to me that the main concern in this discussion is leakage. Leakage occurs precisely then implementors and users don't reference documentation. If we have different names for the same media format when carried in RTP and in email, this increases the likelihood that the name from one domain will be used incorrectly in the other. Sure, one could register the same name in both registries at the same time if both modes of use were being defined at once, but that is not always the case. I believe it is better to have an entry in one unified registry that says for subtype foo that this type is defined only for transport in RTP than to have separate registries with nothing for the name foo in the MIME registry. That is, negative information is better than no information. Not foolproof, but better. If there is a single registry: o each MIME and each RTP implementer will have to examine each entry and determine: * is this media type applicable to my work? - yes - no - unclear This is clearly more work for implementers if there is a combined registry. To the extent that implementers ask
Re: I-D ACTION:draft-iesg-media-type-00.txt
On Sat, 2 Jul 2005, Robert Elz wrote: | Thus we need to be able to register RTP payload formats also in | text top-level type. Now, I'm lost. You just finished explaining how the RTP media types are all different from all other media types, because they necessarily need to retain the RTP packet info (or I'd guess perhaps some of that, but it doesn't matter) as an essential part of a data. Now you seem to be saying that it is OK to multiplex a text/plain or a text/html into the same data stream. How? Those don't contain the RTP packet info, do they? No, there is no payload format specification for packetizing either text/plain or text/html in RTP, so neiher can be sent in RTP, let alone multiplexed. For those types (in text or in audio or video) that do have payload format specification, the answer to your question about how two streams within the same major type would be multiplexed is this: the RTP header contains a payload type field that identifies the type with a small number dynamically mapped to the type for the duration of the session. Someonecould write a simple specification for putting text/plain into RTP, but that proposal would not gain consensus in the AVT working group because RTP is not a reliable transport protocol. The text types that are defined include redundancy mechanisms that are appropriate for text when used in a streaming mode, such as conversational text. Or is this just because you have some text/x types already, and want to be able to add new ones to the same set? Yes, that is right. If you think about categories of streaming media, text is just as logical as audio and video. If that's it, would it be possible to rename the existing text/* (RTP) types into something else, like rtp-text/* so that the confusion goes away? That would be possible, but only with a lot of work and backwards compatibility problems. If the registrations remain in the MIME namespace, then that implies the definition of a new major type. There are righly tight constraints on doing that. Rather than define rtp-text, it has been proposed to separate all the RTP media types into their own space, where we could have audio, video and text to use without any MIME restrictions. While that might seem attractive in some circles for some reasons, it gets us back to the question from Colin to which you responded: | The question becomes: will the leakage go away if we separate the | registries? I didn't know that was the suggestion. I wouldn't suggest that. What I'd prefer would be for the specifications to indicate how to send media type X over RTP. That is, for data types where that makes sense. The data type should stand alone as something useful. That is exactly what we have done for all the data types where it made sense and there was motivation. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On Wed, 13 Apr 2005, Robert Elz wrote: Date:Tue, 12 Apr 2005 21:20:28 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | RFC 3555 allows media types to be defined for transport only via RTP. | The majority of these registrations are under the audio and video | top-level types, with a small number being under text. Is your | objection to any media type being defined only for transport via RTP, | or to text media types being defined only for transport via RTP? Not to either of those being attempted, but to the expectation that the only via RTP will, or can, ever be enforced. What that means is that the specifications only supply instructions about how to format and transmit the data via RTP, not any other method. Therefore... That is, to your earlier statement ... Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. You'd need to be able to show me how that can possibly be true, when I can trivially easily send e-mail with text/t140 in the Content-Type header. When you set out to do that, how are you going to figure out what some text/t140 content should be? Are you saying that you would use that Content-Type but just put US-ASCII into the body? You could also use Content-Type=audio/basic and put US-ASCII into the body, but it would probably not be very useful. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re:IETF62 Network and Terminal Room Information
I think my experience with the wireless network was on the lower end of the scale, perhaps in part due to the fact that I am using an older laptop and Cisco 340 card with 802.11b only. I also run FreeBSD, so that put me outside the norms. The wireless network worked great on Saturday and most of Sunday, but ran into trouble as the population grew. As a consequence, I spent some time working with the NOC folks after they invited assistance to investigate problem situations. They explained to me that the equipment used in this network has dumb access points hooked to centralized controllers. Those controllers implement or proxy the DHCP and ARP functions. Furthermore, DHCP, ARP and data packet forwarding are separate functional paths through the controller which can independently work better or worse. That can result in surprising behavior relative to a more traditional functional decomposition into separate boxes. For example, a number of times I got an address from DHCP, but could not ARP the first-hop router. Some of the improvements over the days came from turning off features such as one that tries to protect against address use by sources that had not obtained an address via DHCP. In the later days, I still had problems becomming disassociated, but always when associated I got DHCP, ARP and packet flow. I noticed that performance was always fine once the session was over and most people shut down their connections. One hypothesis was that limits were reached in various state tables in the controller. Only the vendor could know about those details for sure. But I draw the conclusion that this particular system may not be ready yet to scale to the density of radio participants at the IETF meeting. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MP3 audio streaming for IETF 62
On Sun, 6 Mar 2005, Joel Jaeggli wrote: IETF 62 inagurates a new streaming effort. Instead of covering only two rooms it is our intention to cover all eight. Instead of multicast video delivery, unicast audio-only. It is our hope that this new effort will provide more useful timely and accessible access to the proceedings of the IETF as they happen. So IETF multicast survived for exactly 13 years, beginning March 1992 in San Diego and succeeded in March 2005. It is too bad that inter-domain IP multicast didn't get off the runway, but at least it lives on within enterprises and academia. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF57 Wien WLAN readiness?
On Fri, 11 Jul 2003, Pekka Savola wrote: As a lot of folks are coming to IETF57 early, it would be interesting to know when: - the WLAN network is estimated to be operational - when/whether it is possible to come to the conf. center (i.e. as it isn't in a hotel, is it open for IETF'ers e.g. on Saturday already) A portion/extension of the WLAN is installed in the lobby and 1st floor of the Crowne Plaza hotel. I've been using it since yesterday. -- Steve
Re: Financial state of the IETF - to be presented Wednesday
After the last IETF meeting that was held in San Jose, a decree was issued that no future meetings be held in Silicon Valley because of unmanageably large attendance. Harald's slides say that part of the problem we now face is reduced revenue due to reduced attendance. The answer seems obvious to me. [Um, yes, I do live in Silicon Valley.] On a more serious note, IETF used to function with the same attendance numbers as now. Are the costs now out of line with what they were then? -- Steve
IETF 56 hotel code
At this moment, the Group/Convention Code that the Hilton San Francisco has in its computer is IET rather than IETF as specified on the IETF web page. I imagine that this may get fixed one way or the other at some point. -- Steve
Re: Clarification regarding RFC2507
On Mon, 6 Jan 2003, Ramana Divvi wrote: Hi In RFC2507( page : 22 ), it is given that compressed non-TCP headers contains one BYTE optional 'DATA' field. If any one knows , please tell me what is the main purpose of this one Byte DATA field. See Section 3.3.1 of RFC 2508. -- Steve
RE: Clarification regarding RTP
On Mon, 6 Jan 2003, Ramana Divvi wrote: I have very basic doubt ( please don't laugh at me). How will we know , UDP is carrying RTP payload?. Is there any reserved port numbers for this case? The UDP port numbers used with RTP are assigned dynamically. See Section 7 of RFC 1890, which is being revised in Section 8 of draft-ietf-avt-profile-new-12, for an explanation. If your question is in regard to RTP header compression, Section 3.1 of RFC 2508 explains that the compressor must decide heuristically whether a UDP stream carries RTP. In other cases, the UDP port numbers are learned from the signaling protocol that sets up the session between/among the endpoints. These questions regarding RTP would be more appropriately directed to the [EMAIL PROTECTED] mailing list of the Audio/Video Transport working group. Please be sure to read carefully the documents I have mentioned, and the references they point to where appropriate, before asking further questions. For example, your first question was answered in the document you were reading (RFC 2507). Section 5.3.2 says: Data field is explained in section 12, and Section 12 explains the use and gives a pointer to RFC 2508, same as I did in my first reply. -- Steve
Seeking input from G.726 ADPCM implementers
The IETF Audio/Video Transport working group is seeking input from any implementers of systems using the G.726 ADPCM audio encoding, in particular any that use the MIME audio subtypes G726-16, G726-24, G726-32, and G726-40 or the RTP static paylod type 2 for G726-32. This notice is being sent to multiple mailing lists to reach as many interested parties as possible; please reply only to [EMAIL PROTECTED] Background: The AVT working group is seeking to advance the Real-time Transport Protocol (RTP) and its associated Profile for A/V Conferences (RFCs 1889 and 1890, respectively) to Draft Standard status. Two drafts have been prepared to revise these RFCs for advancement: draft-ietf-avt-rtp-new-11.txt draft-ietf-avt-profile-new-12.txt These drafts have been tentatively approved for publication by the IESG. In addition, a new companion draft has been approved for publication as a Proposed Standard to specify MIME subtype registrations for all the encoding names defined in the RTP Profile: draft-ietf-avt-rtp-mime-06.txt Issue: The packetization of G.726 audio specified in the RTP Profile packs audio samples into octets beginning with the least-significant bit of the octet. This is at odds with the packetization of G.726 audio for ATM AAL2 transport specified in ITU-T Recommendation I.366.2 Annex E, which begins with the most-significant bit. Implementers of systems that operate with both transports or gateway between the two have requested that the RTP packetization be changed to match the I.366.2 packetization to avoid requiring two different DSP implementations and/or translation between packings. Both specifications have existed for some time: I.366.2 has been an approved standard since 1999, and the packing for the G726-32 rate has been part of the RTP Profile drafts since 1997. Therefore, implementations of both packings are likely to exist. Furthermore, since the RTP Profile did not include packetizations for rates other than 32K until 2001, some RTP implementations may have used the I.366.2 packings for those rates. As a consequence, there is no course of action that will make everyone happy. Proposal: After consultation with the IETF Transport Area Directors, it is proposed that the draft RTP Profile packetization be changed to be consistent with I.366.2 Annex E before it is published as an RFC. The MIME subtype registrations for G726-16, G726-24, G726-32, and G726-40 in draft-ietf-avt-rtp-mime-06, which refer to the specification of the packetizations in draft-ietf-avt-profile-new-12, would therefore apply to the changed packetization. In addition, RTP static payload type 2, which is bound to the G726-32 encoding and packetization by draft-ietf-avt-profile-new-12, would also change its meaning. Consequences: We have already heard from one vendor that has implemented the packetizations according to the current RTP Profile draft and therefore objects to the change. Any such systems already in the field would produce garbled audio when interoperated with RFC-compliant implementations, and not detect the error. This is a significant consideration, although draft specifications are not guaranteed to remain unchanged. We have also been informed that the format for G.726 audio in the Voice Profile for Internet Mail (RFC 2421/2) uses the same sample packing as currently specified in the RTP Profile draft. This is consistent with ITU-T Recommendation X.420 for X.400 mail. Since the VPIM systems use MIME type audio/32KADPCM rather than audio/G726-32, there would not be conflict in meaning if the latter were changed as proposed. However, voicemail systems that transmit messages over RTP would be forced to reformat the data. * We are seeking statements from interested parties both for and * * against this proposal, particularly with motivations. *
Another 10 year event
[I made this same comment to the IETF plenary last night, but I waited until the end of the program to get in line so that more significant topics could go first. However, the result of that strategy was that many people whom I think might have been interested to hear my comment had already left the room. So, I will bother the whole list now and apologize if you are not interested.] There has been a somewhat contentious discussion on this list recently regarding what has not been achieved in security during the last 10 years. This meeting of the IETF was also the 10th anniversary of the first audio multicast from the San Diego IETF meeting. Steve Deering and I were the primary organizers of that audiocast, with plenty of help from many others to set up DVMRP tunnels ranging from Australia to Sweden. There has been an audio + video multicast from every IETF meeting since then. For one of those meetings (I don't recall which), the cumulative number of distinct hosts tuning in to the multicast during the week was just slightly higher than the number of physical attendees. I thank those who have taken responsibility for the multicasts subseqent to the first several that I worked on, including the U of Oregon crew who have handled recent meetings. I am disappointed that, like security, IP multicast has not become universally deployed in those 10 years. Perhaps both problems are just hard. I think we are making headway now on security; I hope people have not given up on multicast. Not coincidentally, this meeting was the 10th anniversary of the Audio/Video Transport working group that I co-chair with Colin Perkins. I suppose there may be some others that have lasted longer, but it still seems like a long time. -- Steve
Re: [AVT] Last Call: RTP: A Transport Protocol for Real-TimeApplications to Draft Standard
This is a Last Call comment on: o RTP Profile for Audio and Video Conferences with Minimal Control draft-ietf-avt-profile-new-12.txt This document is intended to replace RFC1890, currently a Proposed Standard. It was recently discovered that RFC1890 contains an ambiguity that remains in draft-ietf-avt-profile-new-12.txt. The table in Section 4.1 of the draft that specifies the convention for the ordering of audio channels contains two possible orderings for four channels: channels description channel 1 2 3 4 5 6 __ 2 stereo l r 3 l r c 4 quadrophonic Fl Fr Rl Rr 4 l c r S 5 Fl Fr Fc Sl Sr 6 l lc c r rc S This is ambiguous because the ordering is selected implicity by the number of channels. It must be that nobody has used 4-channel audio with RTP since the issue has not arisen before. We propose to just eliminate the quadrophonic order for the revision of the profile and add the following note: Note: RFC 1890 defined two conventions for the ordering of four audio channels. Since the ordering is indicated implicitly by the number of channels, this was ambiguous. In this revision, the order described as quadrophonic has been eliminated to remove the ambiguity. This choice was based on the observation that quadrophonic consumer audio format did not become popular whereas surround-sound subsequently has. The channel-order parameter specified in RFC3190 could be used to define a quadrophonic convention in the future if needed. -- Steve
Re: Plenaries at IETF 53
On Fri, 18 Jan 2002, Dave Crocker wrote: There has been some suggestion about having a working meeting after the Sunday reception. I'm inclined to think that trying to have it afterwards (after socializing and alcohol) is problematic. Yes, but (as others have suggested) moving the social to Sunday night would not have that problem. Or just eliminate it. My perferred schedule modification: Sun: Reception + social Mon: Evening sessions Tue: Plenary Wed: Plenary Thu: Fine dinner after a hard week -- Steve
Re: RTP
On Sun, 7 Nov 1999, Mehmet Demir wrote: I am looking for information and source code ( if any) of Real-Time Transport Protocol. See www.cs.columbia.edu/~hgs/rtp/ -- Steve
