Subject: RE: [MMUSIC] FW: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 Sep 2006 08:22:58 +0100

Hadriel,

See below.

John 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 05 September 2006 21:22
> To: Elwell, John; [email-masked]
> Subject: RE: [MMUSIC] FW: I-D 
> ACTION:draft-kaplan-mmusic-best-effort-srtp-00.txt
> 
> 
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]]
> >
> > [JRE] The problem is an auto-answer device will probably 
> not send 18x., or
> > will send 18x immediately followed by 2xx.
> 
> But that's a good thing, isn't it?  If it's an auto-answer, 
> it sends 200ok
> right away.  There is no clipping/early-media problem.
[JRE] No early media, but there can be clipping. The UAS starts sending RTP
the same time as it sends the 200 - RTP will get there first.

> 
> 
> > > The problem with this is we're trying to make it so that the
> > > offer works
> > > seamlessly with as large a population of legacy answering 
> UAs (i.e.,
> > > RTP-only) as possible.  If you think offering two m= 
> lines will work
> > > successfully with legacy UA's, then you don't need a draft to
> > > do that AFAIK.
> > > You're simply offering two streams.  The problem I've seen is
> > > legacy UAs
> > > will reject the whole offer (e.g., send a 488), not just the
> > > unsupported
> > > streams.
> > [JRE] Such legacy UAs would not be SDP-compliant. I guess 
> it depends how
> > common such devices are in practice.
> 
> I don't believe they're non-compliant, and we've been told they're not
> uncommon. (probably more common than srtp-capable devices ;)  
> 
> I think 3261 regarding 488 responses allows them to reject 
> the offer of
> unsupported media capabilities.  While 3264 certainly says 
> how to handle
> rejecting specific streams and not others, there's nothing to 
> say you must
> accept an offer if you can support only a subset of the 
> streams; so I guess
> people took the easy way out.
[JRE]So presumably the same would apply if somebody offered audio + video
(wanting best effort) and the answerer does not support video. I would
arguing that sending a 488 is bad in this sort of situation.

> -hadriel

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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 6 Sep 2006 10:54:15 -0400

Hi John,
Comments inline...

> the same time as it sends the 200 - RTP will get there first.

Yup - but that's the same time as I was saying for a 18x response as well -
i.e., the difference between signaling vs. media one-way delay.  So not a
long time. 

No matter what that problem exists if the offerer offers both rtp+srtp and
cannot distinguish the difference by looking at media alone.  It is
unfortunate SRTP did not define a srtp flag/bit in the SRTP header.  As it
stands, the need to distinguish pre-answer RTP vs. SRTP is an issue we
decided not to tackle in this draft and leave to future drafts to handle.
(If the UAC can distinguish, it is free to render the media)

There have been several proposals of how to do it.  One is to use unique UDP
ports (essentially your proposal as well I think).  The problem with it is
it uses more UDP ports. ;)  It means more ICE checks, more TURN allocations,
and the odds are you'll find problems with using more udp ports through
firewalls/SBCs.  But it's really a discussion orthogonal to this draft, no?

> arguing that sending a 488 is bad in this sort of situation.

Yup, although my guess is UA's handle rejecting unsupported media-types
(e.g., video) more seamlessly than unsupported transport profiles of
supported media-types.  For example, an audio-only device rejecting just the
video stream, but rejecting the whole offer if it was for audio with SAVP.
But that's just an unsubstantiated guess on my part, and not really
important for this discussion.  The point is UA's do reject offers, and our
goal is to minimize that as much as reasonably possible, to help srtp get
over the adoption hurdle.  I don't think failing offers due to audio+video
is a hurdle for srtp.

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Fri, 22 Sep 2006 14:47:56 -0400

"Elwell, John" <[email-masked]> writes:
>> > [JRE] Such legacy UAs would not be SDP-compliant. I guess it depends
>> > how common such devices are in practice.
>> 
>> I think 3261 regarding 488 responses allows them to reject the offer of
>> unsupported media capabilities.  While 3264 certainly says how to handle
>> rejecting specific streams and not others, there's nothing to say you
>> must accept an offer if you can support only a subset of the streams; so
>> I guess people took the easy way out.
>

Sure, and you'd be right - it's bad.  But unfortunately far from uncommon,
and we're not talking minor players - we're talking major gateway hardware
providers.  You can get 488, 400, all sorts of other errors.  Most audio
SIP hardware that doesn't return an error won't even look past the first m=
stream at all, and will silently strip following m= lines.  For added fun,
they think it's interesting to accept payloads you didn't offer.

You can count on your pinkies how many properly reject media streams they
don't understand.  (Ok, slight exaggeration.)

And don't even start to suggest support for grouping,
multipart-alternative, etc.

-- 
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)