Subject: [MMUSIC] SDP Capability Negotiation Design Team: 12/12/06 Conference Call

From: Flemming Andreasen <[email-masked]>
Date: Mon, 11 Dec 2006 00:09:07 -0500

Greetings

The SDP Capability Negotiation Design Team will hold its first weekly 
conference call this Tueday, December 12, 2006 from 10-12 am Eastern 
(GMT-5). Dial-in information is below:

Meeting Access Phone Numbers:
Local San Jose & International : 408-902-7870
US Domestic Toll Free (Outside San Jose ONLY) : 866-902-7870 ***This 
number WILL NOT work from the 408 area code.***
MeetingID: 737227634

Please note that I have reserved a limited set of ports based on the 
participant feedback I have gotten so far. If you would like to attend 
the conference calls and have not told me yet, please do so as soon as 
possible.

Agenda for the first call:
1) Brief recap of where we are and what we want to do in terms of 
general problem scope
2) Discuss design team deliverables:
    a) Requirements
    b) Solution
3) Review current requirements
4) Discuss general direction for solution

To help with the deliverables, I have split my previous SDP capability 
negotation document 
(draft-andreasen-mmusic-sdp-capability-negotiation-01.txt) in two, 
namely a requirements document (including review of existing work), and 
a separate solutions document. The requirements document was just 
submitted today as 
draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt. Until it 
appears in the archives, you can get a copy from 
http://www.geocities.com/fandreasen/draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt. 
Note that the requirements have been updated based on the feedback 
received at the last IETF and I would like people to take a look at the 
update prior to the call and see if they find anything they disagree 
with and/or missing.

I'm also in the process of creating a new solution document based on the 
updated requirements and feedback from the last IETF. The structure is 
similar to that in 
draft-andreasen-mmusic-sdp-capability-negotiation-01.txt but with some 
updates and changes to accommodate the latest IETF feedback. In 
particular, the solution no longer uses the RFC 3407 (Simcap) syntax, 
but instead defines its own attributes with similar semantics. Other 
solutions are of course possible here and hence the objective of 
discussion item 4 is to see if the design team agrees with the current 
direction or not.

Thanks

-- Flemming

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Randell Jesup <[email-masked]>
Date: Wed, 13 Dec 2006 17:13:28 -0500

Flemming Andreasen <[email-masked]> writes:
>(draft-andreasen-mmusic-sdp-capability-negotiation-01.txt) in two, namely a
>requirements document (including review of existing work), and a separate
>solutions document. The requirements document was just submitted today as
>http://www.geocities.com/fandreasen/draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt. Note
>that the requirements have been updated based on the feedback received at
>the last IETF and I would like people to take a look at the update prior to
>the call and see if they find anything they disagree with and/or missing.

In 3.6 and 3.7 (Opportunistic encryption and best-effort encryption) it's
stated that it can't indicate "alternatives other than the inferred SRTP
(including vanilla RTP as an alternative to SRTP)".  That's incorrect; both
allow the answerer to ignore the inferred SRTP and use RTP/AVP (or
RTP/AVPF, depending on the offer).

Also, in the [BESRTP] drafts, discussion has centered on methods to
indicate SRTP and allow for things like early media.  One proposal for
[BESRTP] has been to use alternate payload values and signal that those
payload values use SRTP:

m=audio 3245 RTP/AVP 0 99
a=rtpmap:0 PCMU/8000
a=rtpmap:99 SAVP/8000/0
a=crypto (etc)

(among a few other variations using a= lines to map 99 to be payload 0 in
RTP/SAVP - I forget which ones seemed the most reasonable).  This preserves
the ability to process (usually unencrypted) early-media (and early
encrypted media if the crypto scheme used receive-keys instead of
send-keys, though that's frowned on).

In 3.8, Opportunistic with probing, an additional disadvantage is that
midboxes, etc may be unable to determine the encryption status of the
stream unless they're in the media path and understand the media-level
probe.  For example, boxes that monitor RTCP/RTCPXR stats.  That may not be
significant enough (or too obvious) to include, and this issue may be
shared by some of the other cases (if the monitor box doesn't understand
the SIP signalling).

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: "Victor Paulsamy" <[email-masked]>
Date: Fri, 15 Dec 2006 09:57:52 -0800

Hello,

The requirements document, at the end of page 3 and start of 4 reads as,

	 "Both the offer and the answer contain actual configurations - 
        potential configurations are not supported. The answer however
may 
        reduce the set of actual configurations from the offer."

Consider a case where the answerer lists up additional media formats
that are not part of the offer. Since these formats are not listed up in
the offer, none of these could be used in the session resulting from
this O/A exchange. Hence, these additional formats become potential
capabilities of the answerer that could be leveraged during a future
negotiation (if the offerer supports them, of course.)

--victor

-> -----Original Message-----
-> From: Flemming Andreasen [mailto:[email-masked]]
-> Sent: Sunday, December 10, 2006 9:09 PM
-> To: mmusic
-> Subject: [MMUSIC] SDP Capability Negotiation Design Team:
-> 12/12/06Conference Call
-> 
-> Greetings
-> 
-> The SDP Capability Negotiation Design Team will hold its first weekly
-> conference call this Tueday, December 12, 2006 from 10-12 am Eastern
-> (GMT-5). Dial-in information is below:
-> 
-> Meeting Access Phone Numbers:
-> Local San Jose & International : 408-902-7870
-> US Domestic Toll Free (Outside San Jose ONLY) : 866-902-7870 ***This
-> number WILL NOT work from the 408 area code.***
-> MeetingID: 737227634
-> 
-> Please note that I have reserved a limited set of ports based on the
-> participant feedback I have gotten so far. If you would like to
attend
-> the conference calls and have not told me yet, please do so as soon
as
-> possible.
-> 
-> Agenda for the first call:
-> 1) Brief recap of where we are and what we want to do in terms of
-> general problem scope
-> 2) Discuss design team deliverables:
->     a) Requirements
->     b) Solution
-> 3) Review current requirements
-> 4) Discuss general direction for solution
-> 
-> To help with the deliverables, I have split my previous SDP
capability
-> negotation document
-> (draft-andreasen-mmusic-sdp-capability-negotiation-01.txt) in two,
-> namely a requirements document (including review of existing work),
and
-> a separate solutions document. The requirements document was just
-> submitted today as
-> draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt. Until
it
-> appears in the archives, you can get a copy from
-> http://www.geocities.com/fandreasen/draft-andreasen-mmusic-sdp-
-> capability-negotiation-reqts-00.txt.
-> Note that the requirements have been updated based on the feedback
-> received at the last IETF and I would like people to take a look at
the
-> update prior to the call and see if they find anything they disagree
-> with and/or missing.
-> 
-> I'm also in the process of creating a new solution document based on
the
-> updated requirements and feedback from the last IETF. The structure
is
-> similar to that in
-> draft-andreasen-mmusic-sdp-capability-negotiation-01.txt but with
some
-> updates and changes to accommodate the latest IETF feedback. In
-> particular, the solution no longer uses the RFC 3407 (Simcap) syntax,
-> but instead defines its own attributes with similar semantics. Other
-> solutions are of course possible here and hence the objective of
-> discussion item 4 is to see if the design team agrees with the
current
-> direction or not.
-> 
-> Thanks
-> 
-> -- Flemming
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> _______________________________________________
-> mmusic mailing list
-> [email-masked]
-> https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 17 Dec 2006 20:41:00 -0500

>RTP/AVPF, depending on the offer).
However in that case case they are not alternatives to the offer, so I 
think the statements are correct as-is. Of course the proposal could be 
changed very easily to allow for other profiles.

>send-keys, though that's frowned on).
Right - I'll add that to the descriptionn. I think it was agreed in the 
MMUSIC meeting though that this part of the proposal was not part of the 
core of the proposal and should be split out into a separate draft - 
other proposals could use this mechanism as well (or an alternative such 
as the suggested use of ICE of instead).

>shared by some of the other cases (if the monitor box doesn't understand
Yeah - I think we have middlebox issues with most of the proposals and 
probably the best way to address that in practice is to follow the ICE 
model of providing an updated offer with the "real" offer , using only 
RFC 3264 mechanisms, once you've actually negotiated what it is you are 
going to do.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 17 Dec 2006 20:54:41 -0500

>negotiation (if the offerer supports them, of course.)
That's not entirely accurate. You are correct that the answer may 
include additional media formats in the answer, however by doing so, the 
answerer commits to using those media formats, albeit only in his 
receive direction. Thus they are not potential capabilities but rather 
actual configurations (of course, the offerer upon seeing this answer 
may decide he'd like to use one of those codecs bi-directionally, in 
which case a new offer/answer exchange would be needed, so from that 
point of view you could argue they are also potential configurations, 
but that's the point: RFC 3264 does not make a distinction between the 
two).

Thanks

-- Flemming

---

From: Randell Jesup <[email-masked]>
Date: Tue, 19 Dec 2006 18:10:03 -0500

Flemming Andreasen <[email-masked]> writes:
>other proposals could use this mechanism as well (or an alternative such as
>the suggested use of ICE of instead).

The idea is to have some way from the media stream to infer which 
type of response you've gotten - what the packets mean.  Without that
there's no way to decode media before completion of the exchange.
Early media is an issue, and is used.  Using the mechanism given above
for indicating this through the payload values has limits to extensibility.
For [BESRTP] this isn't an issue, but when you have a more combinatorial
general exchange it might be.

An alternative to avoid an excessive number of payloads (and a= lines)
might be something like:

	m=audio 3245 RTP/AVP 0 99
        a=rtpmap:0 PCMU/8000
        a=rtpmap:99 CAP/8000/0
        a=<capability stuff that defines what 99 really means (SAVP, etc)>

This would mean 0 is PCMU in RTP/AVP packets, and 99 is PCMU in whatever
the capability negotiation works out to.  This would mean that (unless
there was only a single alternative) that incoming payload 99 data would
probably have to be ignored until a 200 OK got through.  It would retain
the ability for AVP calls and non-capability endpoints to do early media,
and even for capability-aware endpoints, they (in theory) could send
payload 0 as early media, and when they see an ACK switch to 99.  But that
might be a stretch, even though it's a logical extension of how payload
types and offer/answer work (i.e. you're allowed to use any payload).

Without something in the payloads as differentiator, NOTHING can be done
with any incoming data until OK is received.

>model of providing an updated offer with the "real" offer , using only RFC
>3264 mechanisms, once you've actually negotiated what it is you are going
>to do.

That may be the case, though note that midboxes will still be in the dark
until the reinvite/etc occur and get successfully responded to.  Also
note that UAs will need to be careful to recognize that there was no change
from the previous agreement and not do anything like re-initialize codecs,
SRTP rollover counts, jitter buffers, etc.  (No change here, and normal for
reinvite if nothing changed, but in this case it will *look* like a very
different exchange, but it just happens to work out to the same end-values.)