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

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 27 Jun 2006 18:47:29 -0500

Dean, Paul,
I am at loss to see how Paul's suggested use of an early-media option is going to help in cases like forking or alternate call progress rendering policies.  And it is not a TISPAN requirement to solve those cases, if they can be solved.  I would hate to see the draft held up for a solution to an unsolvable problem.  If an "untrusted" UAS application truly requires early media because it is prompting for input, there are several approaches to solve that problem.  It can probe for media by prompting for a response from the UAC user, or it can just answer the call!  I don't see any way of guaranteeing early media without probing the media stream.  It's certainly the case that even the UAC won't pick the winner in the forking early media lottery until after it receives an SDP answer and preconditions are satisfied.  And even then the UAC can't identify the winner!  

Even in the simpler case without forking, there is no standards track RFC specifying what to do about early media.  A UAC can render any media it chooses in any way it chooses before answer.  Are you suggesting that the entire UAC early media policy and the possibility of forking must be presented to each UAS so it can decide how to handle the situation?  I hope not.

Richard

Dean Willis wrote:
...
> On Jun 26, 2006, at 5:11 PM, Paul Kyzivat wrote:
...
> > The problem is this is that because it is a P-header, a UAS that  
> > expects to send or receive early media, and doesn't understand the  
> > header, is going to get bad results.
> >
> > This could be solved with a *standard* extension, using a 
> new Early- 
> > Media header and a new early-media option. Then if you include  
> > Require: early-media, and Proxy-Require:early-media, and an Early- 
> > Media:inactive header, you will know for certain that both parties  
> > understand the early media status - if the call completes. And of  
> > course on all the calls that don't complete you will know you  
> > aren't getting early media.
> 
> I fear Paul is correct. I fear Paul in general, but that's another  
> matter  -- whenever he comments on my drafts, I know I have 
> more work  
> to do!
> 
> This leaves us in an interesting predicament. It seems that if we  
> want to solve this problem, we need a standards-track extension.  
> Process-wise, we would need an agreed set of requirements that we  
> could pass over to SIP for them to execute on.
> 
> I don't quite think we have an agreed set of requirements, 
> although I  
> think we have the spirit of an agreement on those 
> requirements, or an  
> agreement "in principle".
> 
> Chairs, how shall we proceed?
> 
> --
> 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
> 

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 27 Jun 2006 20:16:29 -0500

On Jun 27, 2006, at 6:47 PM, Ejzak, Richard P (Richard) wrote:

> Dean, Paul,
> I am at loss to see how Paul's suggested use of an early-media  
> option is going to help in cases like forking or alternate call  
> progress rendering policies.  And it is not a TISPAN requirement to  
> solve those cases, if they can be solved.  I would hate to see the  
> draft held up for a solution to an unsolvable problem.  If an  
> "untrusted" UAS application truly requires early media because it  
> is prompting for input, there are several approaches to solve that  
> problem.  It can probe for media by prompting for a response from  
> the UAC user, or it can just answer the call!  I don't see any way  
> of guaranteeing early media without probing the media stream.  It's  
> certainly the case that even the UAC won't pick the winner in the  
> forking early media lottery until after it receives an SDP answer  
> and preconditions are satisfied.  And even then the UAC can't  
> identify the winner!
>
> Even in the simpler case without forking, there is no standards  
> track RFC specifying what to do about early media.  A UAC can  
> render any media it chooses in any way it chooses before answer.   
> Are you suggesting that the entire UAC early media policy and the  
> possibility of forking must be presented to each UAS so it can  
> decide how to handle the situation?  I hope not.

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