Subject: [Sipping] draft-stucker-sipping-early-media-coping-03

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 18:25:22 -0500

I read this draft, and am pretty confused about what problem its 
solving. I was looking for something that pointed out concrete issues 
with the existing mechanisms but didnt see that.

It seems its worried about classifying types of media streams in terms 
of importance so a UA knows whether to render them or not. What I 
totally fail to understand is how a gateway, which is really our primary 
use case for this mess, knows how to classify the media stream. It 
won't. For things that can classify (maybe a SIP-based prepaid server or 
something), they'll just mark everything as critical and we're right 
back to the issue that I think maybe you're trying to solve.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 2 Nov 2006 14:24:23 -0600

Jonathan,

Take a look at the sections describing the bad behavior of
intermediaries and the (from the perspective of the early media
generator) unpredictable behavior of the originating client as to how
their media will be treated.

I do not agree that gateway is our primary use case. It is a use case,
there are others as well. Just because we can interwork SIP with a brick
doesn't mean that all the other possible interworking use cases for
other UA's must be brick-like as well. Besides, the number of dumb
gateways should be decreasing over time in the long run, not increasing.

The draft is really discussing three things:

1. The problem with SIP wrt the required behavior of an SDP offerer. The
current mechanism is crazy. It's analogous to requiring that because you
invited your neighbor over for dinner you have to feed anyone that shows
up at your house. Further, they don't have to identify themselves upon
entry, and they can eat as much as they like.

2. The problem with SIP wrt what an early media generator as to what
they can expect from the SDP offerer. Client/proxy implementations
trying to deal with problem #1 (ie. preventing entry of the mob into
your home) also have bad effects. They may be let into the house, or
ignored, or let in and then kicked back out, etc. From their perspective
it can be random as to what happens. They may get treated differently at
different times with no indication of what's going on. Further, some of
the coping mechanisms in place potentially break other things (like
SRTP) or complicate them.

3. The stubs of a few things that might be able to help make items 1 and
2 work better. These are mostly intended as discussion starters and need
more feedback and review to see if they can be refined further or if
another mechanism should be introduced to solve the problem.

The intended (eventual) output of this draft is either one of two things
(may be a combination as well, I'm not sure):

1. A set of procedures that fixes early media in SIP where possible.
Help the SDP offeror understand who is knocking at the door so they can
let in the people they wanted to let in, and keep out or delay the
people they don't.

2. A document that explains why early media is fundamentally broken,
that we've tried everything, and short of major revisions to SIP it will
never work right, what implementations can do to deal with the
reprocussions, and to discourage egregiously bad behavior that is likely
to break other things in SIP. SIP is complex, and not all of the
interactions with various mechanisms and early media are obvious to the
reader. Having a document to reference that more explicitly says "you
shouldn't do this because you're going to break that" is valuable in and
of itself even if there's no change to the protocol.

Regards,
Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, November 01, 2006 5:25 PM
> To: IETF Sipping List
> Subject: [Sipping] draft-stucker-sipping-early-media-coping-03
> 
> I read this draft, and am pretty confused about what problem 
> its solving. I was looking for something that pointed out 
> concrete issues with the existing mechanisms but didnt see that.
> 
> It seems its worried about classifying types of media streams 
> in terms of importance so a UA knows whether to render them 
> or not. What I totally fail to understand is how a gateway, 
> which is really our primary use case for this mess, knows how 
> to classify the media stream. It won't. For things that can 
> classify (maybe a SIP-based prepaid server or something), 
> they'll just mark everything as critical and we're right back 
> to the issue that I think maybe you're trying to solve.
> 
> -Jonathan R.
> 
> 
> 
> -- 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Nov 2006 14:56:28 -0800

Brian Stucker wrote: 
...
> The intended (eventual) output of this draft is either one of 
> two things (may be a combination as well, I'm not sure):
> 
> Help the SDP offeror understand who is knocking at the door 
> so they can let in the people they wanted to let in, and keep 
> out or delay the people they don't.

ICE seems useful for that -- the offerer can avoid playing out
any RTP packets until either (a) an SDP answer is received, and 
the RTP media is arriving from the transport address in the SDP
answer, or (b) the offerer receives a STUN Binding Request, with
the STUN username in its offer.  This is very similar to the 
technique in draft-wing-session-auth-00.txt (which is now 
expired and available from 
http://tools.ietf.org/internet-drafts/draft-wing-session-auth-00.txt)

-d

>    that we've tried everything, and short of major revisions to SIP
>    it will never work right, what implementations can do to deal
>    with the reprocussions, and to discourage egregiously bad
>    behavior that is likely to break other things in SIP. SIP is
>    complex, and not all of the interactions with various mechanisms
>    and early media are obvious to the reader.  Having a document to
>    reference that more explicitly says "you shouldn't do this
>    because you're going to break that" is valuable in and of itself
>    even if there's no change to the protocol.
>
> 
> Regards,
> Brian
> 
> 
>