[AVT] Final minutes

["Tom-PT Taylor" <[e-mail]>]

These are the draft minutes I sent out earlier, updated with corrections 
from Colin and Steve.

The Audio-Video Transport (AVT) Working Group met twice. The originally
scheduled meeting was on Tuesday morning, Nov. 7. An additional meeting
was necessary to complete the agenda and specifically to consider
proposals for transport of keying along the media path. It was held on
Thursday afternoon, Nov. 9, from 3:10 to 4:10 pm.

Chairs: Colin Perkins <[e-mail]>, Roni Even 
<[e-mail]>, Tom Taylor <[e-mail]>
Tom Taylor reporting

1. Agenda, IPR notice, and status
   (Colin Perkins)
=================================
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-0.pdf

Colin announced that the following presentations would be added:

(1) RTP over DCCP (draft-ietf-dccp-rtp-01.txt), Colin Perkins,
immediately following WG status. This is shown on the published agenda
charts.

(2) Steve Casner on RTP design principles, immediately before
presentation of draft-ietf-avt-rtp-and-rtcp-mux-00.txt.

The IPR Notice was duly displayed and read out.

A number of RFCs have been published since the last meeting, with a fair
number in queue now. Four documents are currently in IESG review.
draft-ietf-avt-ulp-19.txt just went to WG LC.

As mentioned at the last meeting, the WG will be forming a payload
format directorate. This people will be called upon in rotation to
provide expert review to AVT Internet Drafts. Ross Finlayson volunteered
already. A number of others will be contacted shortly.

2. RTP and the Datagram Congestion Control Protocol (DCCP)
   (Colin Perkins)
================================
draft-ietf-dccp-rtp-01.txt
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-1.pdf

Colin started with brief description of DCCP. DCCP provides
connection-oriented, unicast, congestion-controlled, unreliable transport.

The draft defines RTP framing over DCCP along with the associated
signalling.

The framing of RTP and RTCP in DCCP is straightforward. The interesting
part is congestion control. There is additional complexity if
transcoding is involved. There are one or two other tricky points, but
the task was not too difficult otherwise.

Some additional SDP is needed, since the protocol is
connection-oriented. Most of this is defined by comedia (RFC 4145), but
a new attribute is needed for the DCCP service code.

Jonathan Rosenburg asked: how do you fall back to non-DCCP operation?
This is an issue for offer/answer signalling. The current suggestion is
to have multiple m= lines with alternative transports. This can be
modified when MMUSIC moves along on profile negotiation.

Steve Casner asked: we should be careful about optimization until we
have experience, but where does Colin see the possibility of
optimization? Colin thought the first possibility is obvious: multiplex
RTP and RTCP, since DCCP is connection-oriented. Colin doesn't see value
in sequence number compression because of potential problems at gateways.

Colin asks that the WG review the draft to make sure it makes sense from
the RTP/RTCP point of view. (Reviewers should look at version -02, which
will be submitted shortly after the meeting.) However, comments should
be submitted to the DCCP list ([e-mail]).

3. RTCP for Source-specific multicast
   (Joerg Ott <[e-mail]>)
================================
draft-ietf-avt-rtcpssm-12.txt
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-9.pdf

Editorial changes were made in the latest version based on reviews.

There was one important technical change, to SSRC collision behaviour.
The authors also added a mechanism for out-of-band SSRC announcement.
After expanding on the latter, Joerg asked whether the ability to signal
the SSRC out-of-band (e.g. via SDP) is of more general interest.

Steve Casner suggested that they could run into conflict on the role
definition (sender) contained in their proposed signalling. There was
some discussion over whether the "a=source-filter:" attribute should be 
at session or media level.

Francois Audet wondered whether there are other cases such as MIKEY
where similar semantics are being propagated. Joerg pointed out that
there was no interaction/negotiation in that case. Francois clarified
that his concern was over potential interaction between the mechanisms.
Joerg agreed that it was possible particular items would need to be
allocated to one or the other mechanism.

Allan Johnston cited a different case with similar considerations.

Hari Desineni suggested that the role seems to be redundant, and that 
parameters specific to the sender can be in a new attribute.

Brian Stucker pointed out that CNAME could be used to perform 
correlation between flows when needed.

Colin asked whether the draft needs a statement on offer-answer.

Jonathan Lennox indicated a need to consider multiple camera angles. Is
there an interaction with the RTCP retransmission draft? The
rtcp-unicast attribute is session level, would it make sense to describe
at stream level? There could be a lot of issues here.

Joerg wondered if offer-answer should be discussed, but in a separate draft.

Dave Oran remarked that multiple streams imply multiple m-lines. He was
corrected; this isn't always so with multicast. In any event, we have to 
straighten out the semantics of labels [There's that word again! What 
should it really be?]. He supports their use only for announcements, not 
offer-answer, in this draft.

4. RTP Payload Format for SVC (Scalable Video Coding)
(Stephan Wenger <[e-mail]> )
================================
draft-wenger-avt-rtp-svc-03.txt
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-8.pdf

Stephan summarized the changes in the draft since the Montreal meeting.
Some were editorial, but there was one major technical change: the 
introduction of SSRC multiplexing.
A Nokia IPR notice has been filed for this draft.
It will be resubmitted as a WG draft as agreed in Montreal.

SSRC multiplexing
-----------------

The problem being addressed is a case where H.264 video is being sent by 
layered multicast to a set of signalling-aware middleboxes (such as 
wireless base stations) where the streams must be aggregated and sent 
onward to a single transport address at the user device. Aggregation 
involves the selection of which layers to transmit if the onward link 
does not offer enough bandwidth to transmit all of them.

One solution would be to have the middleboxes perform as RTP mixers, but 
this would require them to be in the SRTP security context. To avoid 
that, the proposal is to use the SSRC as a layer identifier. This can be 
done by announcing the SSRCs and their associated layers in advance in 
signalling. That has the useful consequence that receivers can avoid 
collisions with the announced SSRCs, as in the source-specific multicast 
draft. Alternatively, the media sender can associate SSRCs with priority 
values, avoiding the need to include this information in explicit 
signalling. Specifically, higher SSRCs would denote layers of greater 
importance. A strategy would be needed to cope with SSRC collisions. 
[The proposal on the list was to assign a range of SSRC values to each 
layer, so the sender would have room to choose a new one in case of 
collision.]

Stephan finished some questions for discussion, beginning with the basic 
premise of the exercise and then looking for views on the right way 
forward.

Comments from the floor
-----------------------

Steve Casner, reflecting on the basic premise: the draft authors don't 
trust the MANE to have keys, but need it to perform services. Is the 
trust model consistent?

Jonathan Lennox: Are the authors assuming that RTCP is unencrypted? 
Reply: yes. Are they also assuming that it is unauthenticated? Reply: 
thinking about it -- this may be so.

Hari: does the RTCP header have to manipulated? Reply: not in general. A 
MANE does not tamper with RTCP.

Dave Oran: did the authors consider using header extension rather than 
ordinals? Reply: no. There was the usual worry about
overhead. But it is a valid approach. Dave worried about complexity and
restrictions involved in manipulating SSRC numbering subspaces, and 
suggested that the authors could well find that the alternative pays.

Jonathan Lennox: are the authors are assuming not only a single sender, 
but also a single source? Reply: yes. Jonathan asked if they had thought
about interaction with RTCP retransmission.

Steve Casner: the draft should consider sender SSRC assignments as 
fixed. Either have a means to avoid collision by other means or don't 
use SSRC overloading at all. Stephan protested that the sender knows how 
many layers it has in advance, so it can divide up the SSRC numbering 
space accordingly. Steve still considered it better to put the onus on 
the receiver to resolve collisions. Colin Perkins pointed out that 
dynamic adjustment at the sender gives a high probability of collision. 
8000 receivers imply a 50% probability of collision, not a large number 
for IPTV applications.

Dave Oran asked if it would work to define a rule that receivers lose in 
collision, as a global rule independent of payload type.

Stephan replied that header extension would be considered.

Colin urged: SSRC is there for the purpose, use it.

Steve Casner said that the rule that when a collision occurs, the 
receiver MAY
choose to keep packets from the new source rather than the existing
source has already been relaxed in RFC 3550.



5. Signalling Layered and Multidescription Media in SDP
   (Thomas Schierl <[e-mail]> )
================================
draft-schierl-mmusic-layered-codec-01.txt
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-2.pdf

The draft contains a number of technical changes from the -00 version, 
as shown on the first chart. The title has changed to reflect this.

Thomas reviewed the details of the proposed new signalling for media 
dependency. This signalling builds on the media stream grouping 
mechanism defined in RFC 3388. The present draft introduces the decoding 
dependency group: 'DDP'. This is complemented by a new media-level 
attribute 'a=depend:' identifying the type of dependency: 'lay' for 
layered coding, 'mdc' for multi-description coding, with a list of the 
streams forming the operating point as additional parameters of these 
attributes.

We decided at IETF 66 that SSRC multiplexing is an acceptable approach 
for transport of interdependent streams. A new media level attribute 
'a=ssrcmux:' has been introduced to signal this usage. The draft 
proposes implicit association of SSRC values to the individual streams, 
with higher values assigned to streams of higher importance, in the 
specific case where the relationship between the streams is strictly 
hierarchical. (This implicit signalling was one of the two approaches 
presented by Stephan when discussing the SVC draft.) Implicit 
association is signalled with another value of the 'a=depend:' 
attribute, 'a=depend:lay-ssrc'.

The draft specifies a requirement that the session description provide 
the means for an implementation that does not understand the new 
attributes to pick out a valid subset of the media streams that it can 
receive and decode successfully. This is needed, for example, to support 
offer/answer. The draft specifically states that this should be in the 
form of a separate media description that may point to the same 
transport address but may otherwise differ in detail.

Thomas presented some questions for discussion:
1) Which draft should hold SSRC multiplexing, this draft, the SVC draft 
or another one?
2) Use implicit or explicit assignment of SSRC to stream?
3) If SSRC multiplexing stays in this draft, should it be generalized to 
a mechanism that applies for non-RTP transport as well?

Colin Perkins saw no point in generalizing beyond SSRC.

Stephan Wenger made the distinction between payload-specific properties 
and considerations that apply to a variety of payload types. He sees 
value in documentation of SSRC multiplexing separately from the SVC 
payload type.

Hari Desineni noted the limit on number of SSRCs in receiver report packets.

Jonathan Lennox preferred that signalling for implicit multiplexing be 
dealt with in a separate document.

6. RTP Payload format for DV (IEC 61834) Video
   (Kazuhiro Mishima <[e-mail]> )
================================
draft-kobayashi-avt-rfc3189-bis-00.txt
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-3.pdf

This draft deals with a new SMPTE 370M format. This is a HD (High 
Definition) professional encoding format. The new format differs from 
consumer HD VCR, which is covered by RFC 2250.

The major changes from RFC 3189 were to add the new SMPTE 370M format 
and provide the associated media type registration. The draft also 
removes support for the SMPTE 306M format, which is already covered by 
SMPTE 314M.

The security considerations were improved to cover prevention of the 
unexpected source DOS attack using information from the latest IGMP 
specification (IGMPv3, MLDv2).

A number of implementations of RFC 3189 were listed.

Steve Casner asked if the listed implementations are using merged or 
separate audio and video. He and the presenter agreed to discuss this 
offline.

7. IEEE 802 and QoS: RTP Interactions?
   (Michael Johas Teener <[e-mail]> )
================================
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-4.pdf

Background: the IEEE is trying to merge firewire and 802 transport. The 
work is being done by the “IEEE 802.1 Audio Video Bridging Task Group”. 
A detailed presentation of this work was made to TSVArea. The charts for 
that presentation are available at 
http://www3.ietf.org/proceedings/06nov/slides/tsvarea-2.pdf

The Task Group has four projects:

-- Precise time synchronization and clocking serving (802.1AS)

-- Registration and reservation for streams (801.Qat)

-- Queuing and fwding rules for streams (802.1Qav)

-- Establishment of interconnected networks of cooperating devices
(802.1ABaw(?)) based on 802.1AB (Logical Link Discovery Protocol).

They have the feeling that RTP will be the main customer of the AVB work.

Steve Casner pointed a need to be able to signal the new capabilities.

Hadriel Kaplan noted a process issue to be worked out, for IETF people 
to see IEEE drafts. The answer is that interested persons should contact 
Michael Teener directly for access.

Stephan Wenger saw a problem of usage to be solved, spanning the gap 
between Layer 2 and Layer 7. Hacks are there now.

Steve Casner responded that we would need the Layer 4 protocol above IP 
to synchronize the end points. There is a pile of work to be done.

8. Some RTP design principles
    (Steve Casner <[e-mail]> )
===================================

Steve was invited to speak at this point because what he had to say 
relates to a number of succeeding papers on the agenda.

First chart: why is RTCP needed?
RFC 3550 says that the primary purpose is to provide feedback on the 
quality of data distribution. This is related to the congestion and flow 
control functions of other transport protocols.

In addition, a growing number of other uses exist:
- RTCP-XR as a vital means of monitoring the quality of VOIP sessions;
- CNAME-SSRC mapping, counting participants, dynamic timers,
lip sync for multiple media, SDES
- more recently, feedback for retransmission, codec control.

Colin Perkins remarked: it has all been implemented, for some 
applications at least.

Steve Casner continued: in designing protocols, we have to keep things 
generally applicable, because we don't know how new features may be 
used. We need to separate control and data information because they may 
have different consumers.
As one example, for multicast, third-party monitors may observe the RTCP 
without processing the media. In addition, the network treatment of 
control and media flows may be different.

There is an integrated layer processing argument for reducing the number 
of multiplexing points. [D. D. Clark and D. L. Tennenhouse. 
Architectural considerations for a new generation of protocols. In Proc. 
ACM SIGCOMM '90, pages 200--208, Sept. 1990.] Recognizing other 
constraints (NATs), Colin has proposed RTP and RTCP multiplexing.

Other rules governing RTP and RTCP usage have been changed, 
demonstrating the possibility for some flexibility going forward:
- RTCP timing rules relaxed for feedback
- relaxed RTP/RTCP odd/even port rule
- added SSRC collision rules for address changes.

Principles to keep in mind:
- information in the data header should only be there to support 
processing of the data in that packet
- security setup affects the channel, but not the media.

Francois Audet: ??
Stephan Wenger: ??

9. Multiplexing RTP and RTCP on a Single Port
    (Colin Perkins <[e-mail]> )
===================================
draft-ietf-avt-rtp-and-rtcp-mux-01.txt
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-5.pdf

Colin made two points:
- use of separate ports has advantages and disadvantages
- can multiplex RTP and RTCP if care is taken with payload type assignments.

Jonathan Lennox asked: will we assume RTCP packets start with SR or RR?
Colin replied that it is safer to avoid assumptions.

Geoff Devine: putting RTP and RTCP in the same stream will completely 
screw up cable and WiMax resource allocation.

When to use? Colin suggested a restriction to unicast sessions.

He proposed to signal multiplexing using 'a=rtcp:' to indicate the same 
port number as on the m= line, falling back to normal odd/even rules if 
the SDP answer does not contain 'a=rtcp:'.

In the case of SIP forking, some replies may show support, some not.

Comment: signalling can't fall back if you are using NAT. Colin agreed 
this will mean problems.

Henning Schulzrinne: SIP forking shouldn't be a problem -- extra streams 
should be CANCELled/BYEd.

Hadriel Kaplan: if there is an ALG in the path, it may change m= line 
but not understand 'a=rtcp:'. You will end up with a changed port on m= 
line. Colin agreed: no matter what, you can end up with a broken case.

Jonathan Rosenberg suggested a way around this: use a vseparate 
attribute to indicate multiplexing. If this attribute is received and
understood, ignore 'a=rtcp:'. The implication is that the 'a=rtcp:' port 
designation is the fallback. Colin agreed with this suggestion.

Colin went on to suggest port multiplexing would be disallowed for 
any-source multicast (ASM), but allowed for source-specific multicast 
(SSM). In the case of ASM, NAT is less often a problem in practice and 
there is more likely to be third-party monitoring of RTCP.

Colin's next-to-final chart raised the key questions. Do we actually 
want to do this? It breaks the architecture, but has positives
- removes one argument against use of RTCP.

We do need an on-path logically separate control channel. This is 
preferable to putting control messages into header extensions or shims. 
Where ports are restricted, the choice comes down to multiplexing RTCP 
or running a separate control protocol on the same port like STUN.

Jonathan Rosenberg commented that this was an interesting, complicated 
architectural question. We can get RTCP through NAT already with ICE. 
The latency issue has been fixed. There is a slight decrease in latency 
doing RTCP multiplexing. The key benefit, however, is that it doubles 
the capacity
of the TURN server. It is not an obvious choice whether or not to permit 
RTP/RTCP multiplexing.

Hadriel Kaplan agreed that the major benefit is to the TURN server. 
Multiplexing does avoid effort in some configurations.

Stephan Wenger noted that port reduction has implications beyond the NAT 
problem.

Eric Rescorla noted a fate sharing advantage.

Phil Zimmerman agreed that it does reduce NAT bindings by a factor of 2. 
It also reduces ICE complication. Jonathan Rosenberg demurred, but Phil 
insisted that it was definitely helpful.

Steve Casner observed that it is important to support separate 
transmission of RTP and RTCP, and this will be the usual way to do it. 
Hence we should not simplify ICE specifically on the assumption of 
RTP/RTCP multiplexing.

Colin summarized: There is value here. He will change the details of 
negotiation as indicated in the above discussion.

Jonathan Rosenberg agreed: do it. We should also address the general 
question of the role of on-path signalling. We need an architectrural 
discussion of where you should do what.

Cullen Jennings responded to this last: RAI is discussing these topics, 
and is going to figure out how to make it happen, but we need people to 
stimulate the conversation.

10. Changes in ZRTP
    (Phil Zimmerman <[e-mail]> )
===================================
draft-zimmermann-avt-zrtp-02.txt
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-10.pdf.

Phil described a number of technical changes in the latest draft. Some 
of these were made in recognition of new requirements.

He reported that a patent filing had been made relating to the work. The 
basic intent of the patent was defensive. He also indicated (in later 
discussion) that the patent would be used to enforce details of the 
implementation viewed as important to the fulfillment of its overall 
aim. This aim was to provide end-to-end security for communications 
without any requirement to trust the intervening networks.

In passing, Phil noted new SDP attributes required for ZRTP discovery, 
initialization and authentication. These were the subject of a separate 
MMUSIC discussion.

Eric Rescorla asked for clarification on when the shared secret [? - 
notes say SS] stream is brought up.

Phil described the procedures introduced for sharing the results of the 
Diffie-Helman procedure over multiple streams.

He then went on to describe the disclosure flag. An implementation has 
to indicate to the remote party if this end has disclosed the session
key to another party. Hadriel Kaplan asked if this is signalled in ZRTP 
or SDP. The answer was ZRTP. Hadriel had further questions about 
signalling, but these were ruled out of scope. [One Chair at least was 
becoming impatient with the extent to which discussion of IPR and 
political aspects at this point was replacing discussion of technical 
issues that needed to be addressed.]

Phil indicated that one can't have ZRTP intermediaries, since they look 
like man-in-the-middle (MITM) attackers. But an user could engage a ZRTP 
end point to act on the user's behalf and forward the media to the 
user's device. Jonathan Lennox asked if that meant ruling out the use of 
ZRTP with a conference bridge. Phil replied that he recognizes that the 
security characteristics will be different in a conference.

Magnus Westerlund pointed out that there was an architectural issue to 
be addressed: the best way of getting security information between end 
points. Phil
indicated that he did not want to discuss this now, but rather, wait for 
list discussion to settle down.

===============================================================================

At this point the meeting ran out of time. A second session was 
scheduled for Thursday afternoon, to address the remaining presentations 
and the architectural issues they entailed.

================================================================================

Second session
Thursday 15:10 to 16:30

Chairs: Colin Perkins, Roni Even, Tom Taylor

1. Agenda and summary of issues
   (Tom Taylor <[e-mail]> )
===================================
Charts available at http://www3.ietf.org/proceedings/06nov/slides/avt-12.pdf

The agenda was agreed: VoIP shim and DTLS-SRTP, which were leftovers 
from the earlier agenda, and ZRTP again with focus on the transport 
issues that have been the subject of discussion on the list. The focus 
of the meeting was to be on transport issues, not security per se.

Tom summarized the issues the Chairs saw in each presentation (see charts).

The speakers were requested to address these issues in their presentation.

2. VoIP Shim for RTP Payload Formats
   (Ingemar Johansson <[e-mail]> )
===================================
draft-johansson-avt-rtp-shim-01.txt
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-7.pdf

The proposal relates to multimedia telephony service (3GPP).

EDGE Layer 2 has increasing probability of packet loss with larger packet
size. (Could be improved with tweaking.) There is an issue of 
performance at the cell edge.

Depending on the radio technology in use, there is a requirement for 
adaptation at the cell edge, to reduce the packet rate quickly as 
transmission becomes weaker.

Statement: RTCP is either in use or not, implying (if it is) continuing 
consumption of bandwidth and battery even when specific signalling need 
not be present.

Ingemar's argument is that bandwidth consumption by RTCP can have 
significant effect on the performance being measured.

Alternatives to consider: various modifications to RTCP. Possibility of 
compression.

Joerg Ott: ??

Stephan Wenger: some of the items in the draft relate only to AMR. The draft
actually covers three different topics.

Flemming Andreasen: the extension involves bi-directional 
communications.  (Agreed.) How are parties distinguished in a 
multi-party session?

3. Datagram Transport Layer Security (DTLS) Extension to Establish Keys
for Secure Real-time Transport Protocol (SRTP)
    (David McGrew <[e-mail]> )
===================================
draft-mcgrew-tls-srtp-00.txt
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-6.pdf

DTLS is TLS reworked to operate over UDP.

The first chart summarizes the procedure.

Pre-setup: SDP signalling is used to indicate willingness to use DTLS 
and provide a fingerprint.

Key exchange occurs in the media channel. This allows reuse of DTLS key 
establishment procedures.

An extension to DTLS is used to negotiate SRTP protection profiles. The 
DTLS master key is used to generate SRTP keys.

The next chart presents the TLS handshake extension needed to support 
SRTP. The chart following shows the message flow, including early media 
to show how that would work. Subsequent charts showed the various 
possibilities for transport of the TLS handshake and indicated that the 
method met all the requirements listed in the rtpsec discussion in Montreal.

Roni Even asked how resynchronizing is done in mid-session keying. Since 
there are just two possibilities for any given packet, David suggested 
trial and error -- try the old key, if it doesn't work, try the new one.

Flemming Andreasen asked how they associated SSRCs with the correct 
security framework. David provided further clarifications.

Setup takes about 2 1/2 round-trip times (varies).

Phil Zimmerman asked how initial security is provided?  David suggested 
two options.

At this point, discussion was cut off, because these questions dealt 
with security rather than transport issues, and should therefore be 
dealt with in rtpsec.


4. ZRTP Transport Requirements
    (Phil Zimmerman <[e-mail]> )
===================================
draft-zimmermann-avt-zrtp-02.txt
Charts at http://www3.ietf.org/proceedings/06nov/slides/avt-13.pdf

Phil indicated that ZRTP involves two message types:
  - discovery -- need to indicate support for ZRTP while doing no harm
  - key agreement messages -- sent only between ZRTP endpoints.

Flemming Andreasen asked why one would not just signal the keying 
information. Phil pointed out that the signalling might not necessarily 
be SIP. His team wants to create a bump in the wire.

Dave Oran asked how a bump in the wire knows that it is receiving RTP 
packets. With further discussion, this requirement turned out to be 
'nice-to-have'.

Further requirements:
- both types of message should be able to traverse the maximum number of 
types of intermediate boxes
- message transport should work for unidirectional or inactive data streams
- there should be no need for extensions to signalling protocols
- discovery messages must be harmless to non-ZRTP end points
- discovery msgs need a lot of retransmission (empirical observation)
(may be able to use ICE approach).

To ensure correlation, the key agreement messages should be transmitted 
on same port as the media. Need to make it fast.

Stephan Wenger expressed doubt that key agreement could be independent 
of signalling.

Joerg Ott remarked that the requirements just described make a perfect 
case for RTCP.

Rohan Mahy suggested that it would help if Phil could distinguish 
between protocol requirements and implementation requirements. Phil 
responded that this distinction is difficult to make.

Phil summed up: it seems to be a question of RTP vs. RTCP for the key 
agreement messages. They are managing now with header extensions, but 
are willing to look at RTCP.

5. Open discussion
===================================

Colin Perkins: the last two presentations are clearly trying to carry 
similar information. It would be good if they could use the same mechanism.

Eric Rescorla: with DTLS, the two ends know both can do it. This differs 
from ZRTP.

Phil Zimmerman: unhappy with the view that signalling is essential.
Colin Perkins said he would probably run into trouble without it.

Flemming Andreasen: shim is really the same problem.

Hari Desineni: in-band is not the answer. They need light-weight RTCP.

Stephan Wenger: there is value in an additional RTP profile allowing 
shimming and light-weight header extension. Shim is really an extension 
of the CCM draft. It has a very limited use case: point-to-point 
bidirectional voice using AMR. Regarding encryption: he is hesitant to 
use RTP packets for control. If you
do, you have to set up a separate redundant channel for intermediate boxes.
He wants a key mechanism that works and respects the architecture.

Roni Even: DTLS can look at signalling possibilities.

Steve Casner: shim is solving a very specific problem. Redefine the AMR 
payload to make it work. Correlation works just as well with two ports 
of known relationship as one port. But we had to give up the even-odd 
rule because of NATs.

Ingemar Johansson: it would be be good to use RTCP to send only the 
information you need.

Flemming Andreasen: fully against use of RTP to signal. There are 
problems of directionality and fuzzy semantics. Try to keep it in RTCP.

Hari Desineni: RTCP has become quite usable.

Colin Perkins: has made it obvious that he is against multiplexing 
control into the same packets as voice. Comments have been made about 
the size and timing/persistence of RTCP. We have already made a number 
of changes, particularly with AVPF. It would be reasonable to allow
momentary changes in rate. For RTCP packet size, the obvious fix is to 
relax the rule on compounding RTCP packets. This is not a change he'd 
much like, but not terribly evil.

Steve Casner: we could reconsider the requirements for RR, SR. The rules 
for timing were for multicast sessions. We may be able to adjust them 
for specific circumstances. We might be able to create compression for 
specific sequences in compound packets.

Stephan Wenger: this isn't a final solution. There is still an order of 
magnitude difference in bit rate between RTP and RTCP. And once RTP and 
RTCP are mixed on same port the overhead goes up.

Hari Desineni: likes idea of just sending the feedback packet.

Cullen Jennings summed up. There is a fair amount of consensus on ways 
DTLS and ZRTP should NOT work. We could do some experimenting. Beyond 
that, there is no strong consensus here. Take it offline.



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt