Subject: RE: [Sipping] Re: psychic early media behavior

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 28 Jun 2006 03:10:23 -0500

Dean,
It still doesn't make sense since early media is not guaranteed in any standards track document.  It is recommended (not required) to work as you would prefer in an informational RFC 3960.  But now you are trying to force a standards track solution to identify behavior not recommended by an informational one.  

You are also mixing several things since whether or not media is authorized does not guarantee that the UAC follows the (informational) RFC 3960 recommendation to render early media in preference to local ringback and does not guarantee that early media will be rendered at all during forking.  So you want a standards track solution to identify the possibility that one mechanism may prevent early media when there are various other ways (allowed by both standards track and informational RFCs on the topic) in which early media may fail to be rendered.

Doesn't pass the smell test.  I must conclude that you are grasping at straws to kill this P header.  There is no technical or IETF procedural reason to do so.

Richard

Dean Willis wrote:
> Paul is, I believe, trying to find a way so that we are not 
> SURPRISED  
> when a call using the extension fails to receive early media in a  
> case where we would have expected it to work at a UA that does not  
> support the extension.
> 
> The only positive way we have of doing this, so far, is to use an  
> option tag for the extension in a Require: when the extension is  
> used. This assures that non-compliant UAs will reject the request,  
> which assures us that their users will not be surprised by  
> unanticipated behavior. Of course, the "network" would be 
> required to  
> provide conventional early-media support if the extension 
> were NOT used.
> 
> --
> dean
> 

_______________________________________________
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: [email-masked]
Date: Wed, 28 Jun 2006 10:42:55 -0400

From: "Ejzak, Richard P (Richard)" <[email-masked]>

   I must conclude that you are grasping at straws to kill this P
   header.  There is no technical or IETF procedural reason to do so.

As far as I can tell, Dean wants to kill this P header *as a P header*
because he doesn't think it's an add-on or overlay type of change, but
a fundamental one.  P headers are only for changes that can be safely
ignored by UAs that don't understand them, where UAs won't be
unexpectedly bitten if they ignore them.

The problem, I think, comes from peoples' expectations of early media.
As someone said long ago, the most reasonable thing to do with early
media would have been to outlaw it.  But once SIP was defined so as to
admit early media, people start to expect that early media will work.
It's a huge change to add a whole infrastructure to regulate whether
early media will be allowed or not, and to require UAs to know how to
deal with that infrastructure in order to tell whether their early
media will get through or not.

Er, rather, if you're on the IETF side it seems like a huge change,
because the only time you've ever thought about early media is when
reading RFC 3261, and it assumes that early media will be propagated.
So an IETF-head says "Whoa, you mean my UA has to cope with this P
header just to make sure its early media still gets through?"

If you're on the PSTN side, it's always been in the back of your mind
that early media is a complexly-regulated feature, and of course
there's got to be additional features to control it.  So a PSTN-head
says, "Ah!  Now my UA can finally connect to the policies and
procedures that it needs to ensure its early media gets through."

So it hinges on the psychological status quo ante.  On the IETF side,
early media has always worked, and UAs assume that it always works.
On the PSTN side, early media has always been carefully controlled,
and UAs have to work to get their early media through.  Whether this
header "can by default be ignored" depends on what you think is the
default behavior.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Jun 2006 13:48:48 -0400

I agree with Dale.

I think this comes down to a question of whether you believe early media 
is already so broken that it can never be relied upon, and so that 
anything else you do to it can't make it worse.

I guess Richard believes it is badly broken, and is trying to create a 
partial fix for the field of applicability of his draft. (Roughly, 
networks adhering to TISPAN specs.)

I am inclined to think that it is flawed, but still useful.

This seems like it might benefit by a bar BOF.

I'm really not trying to block TISPAN from getting the headers they need 
to do something special. But my understanding is that we should be 
ensuring that those things don't impede interop with the public 
internet. It seems like it should be possible to achieve both.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Jun 2006 13:48:48 -0400

I agree with Dale.

	Paul

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Wed, 28 Jun 2006 12:51:43 -0500

Paul,

There is problems with early media. Do you want me to give you a list of
vendors products? Starting with yours??

Martin 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, June 28, 2006 1:49 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] Re: psychic early media behavior

I agree with Dale.

	Paul

---

From: [email-masked]
Date: Wed, 28 Jun 2006 15:23:44 -0400

From: Paul Kyzivat <[email-masked]>

   I'm really not trying to block TISPAN from getting the headers they
   need to do something special. But my understanding is that we
   should be ensuring that those things don't impede interop with the
   public internet. It seems like it should be possible to achieve
   both.

The perfect solution from the interoperability standpoint is to use a
full-fleged header and an option tag, as you've proposed.  The trouble
with that is that the process for getting approval is a lot longer
than for introducing a P-* header, and I suspect TISPAN wants to get
to market.

On the other hand, as long as it's understood that the Foo-Bar-Baz
header will only be used in conjunction with the foo-bar-baz option
tag, the WG can let TISPAN (or anybody) define Foo-Bar-Baz, as
perforce any problems it exhibits will only affect people who want to
be in that sub-universe, and who will be tagging all their requests
accordingly.  So perhaps a full RFC could be produced in the length of
time it would take to produce a P-* header.

Dale

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 28 Jun 2006 15:01:25 -0500

We went down the road of parallel P-headers and standard's track
documents a few years back for identity.  You can trace back through old
email threads and see that the idea that we can do a P-header as a stop
gap solution and then go on to develop the full fledged solution wasn't
as effective as anticipated (i.e., the point at which the P-header is no
longer used and replaced with the standard's track header isn't
visible).

As far as timing, as I recall we have had past p-header proposals more
recently  that have been considered to require more general solutions
and have produced the standard's track document fairly quickly (e.g.,
draft-ietf-sip-answermode-01).  

It was suggested that a "bar BoF" should be held to discuss the issue. I
absolutely agree that either a "bar BoF" or adhoc is definitely needed,
as it's clear that the discussion will take far more than a typical
SIPPING WG slot. 

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 28, 2006 2:24 PM
To: [email-masked]
Subject: Re: [Sipping] Re: psychic early media behavior

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Jun 2006 17:53:33 -0400

I'm not denying there are problems. If the issue is poor implementation 
of well defined specs by particular products, then by all means raise 
the issue through vendor channels. (Or post your complaints in public if 
you think that will be more effective.)

If the issues are because the specs are unimplementable, then other 
solutions are called for. Fixing it in TISPAN while leaving it unfixed 
in the sip specs is one possibility. Fixing it in the public specs, or 
even giving up early media entirely may be another.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Jun 2006 22:12:15 -0500

> unexpectedly bitten if they ignore them.

Thanks, Dale. That very nicely explains what I've been trying to say.

P-headers are there to provide optional added behavior, not to  
provide normal behavior in an abnormal network.

I'm by no means willing to accept that the PSTN community's dark  
vision of a locked-down dysfunctional Mother-May-I "Internet Lite"  
where only the access network provider can deliver services is the  
default condition. If I knew then what I know now, I'd have been  
saying "No, hell no, and what part of no did you not understand?"  
years ago.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Jun 2006 22:22:00 -0500

> draft-ietf-sip-answermode-01).

I'd support a standards-track with option-tag solution (in SIP), and  
agree that expediting it would be worthwhile.  I'd want a reasonably  
well-defined set of requirements with rough WG consensus from  
SIPPING. If that set of requirements could be produced fairly  
quickly, I don't anticipate that a standards-track solution should  
take more than a few weeks longer than a P-header, primarily in the  
IESG review cycle. Certainly there's no advantage to a P-header in  
the RFC Editor queue -- rather, WG documents supposedly get a higher  
priority. Net, we could actually deliver a standards-track RFC number  
faster.

--
dean

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 29 Jun 2006 05:00:47 -0500

Mary,

I agree. This issue is even bigger than what even is being asked for. I
can provide VGs to illustrate, to facilitate the Bar BOF.

Cheers,

Martin 

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Wednesday, June 28, 2006 4:01 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] Re: psychic early media behavior

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 28, 2006 2:24 PM
To: [email-masked]
Subject: Re: [Sipping] Re: psychic early media behavior

Dale