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

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Thu, 29 Jun 2006 08:35:52 +0200

The behavior of UA that do not support this P-header is not changed as far as I understand. 

This thread tends to confirm what Richard is saying in that some people are not happy with this P-header but have not proven it technicaly. 

sébastien

-----Message d'origine-----
De : Dean Willis [mailto:[email-masked]] 
Envoyé : jeudi 29 juin 2006 05:22
À : Mary Barnes
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Sipping] Re: psychic early media behavior

On Jun 28, 2006, at 3:01 PM, Mary Barnes wrote:
>
> 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).
>

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

_______________________________________________
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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 29 Jun 2006 16:02:30 +0200

Hi,

It's been a long discussion, but just a short question of clarification: HOW would the situation for those not undertstanding the P- header be worse??? A client not understanding the header would listen to early media - which may come, or which may not come (there is no requirement in SIP to always send early media). The header doesn't change that fact, does it?

Now, if we say that early media in SIP doesn't work in general, and/or there are bad implementations out there, what does this P- header have to do with that??? Is that a reason to reject the header?

And, if IETF wants to work on something "better", fine - let's do it. But, this header fulfills the requirements of TISPAN - where it is intended to be used.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 29. kesäkuuta 2006 16:54
To: Ejzak, Richard P (Richard)
Cc: [email-masked]; Mary Barnes; Gonzalo Camarillo (JO/LMF); 'Dean Willis'
Subject: Re: [Sipping] Re: psychic early media behavior

Ejzak, Richard P (Richard) wrote:
> The reason a standards track solution may delay this work significantly is that we still don't have a solution to the problem that Paul and Dean have morphed this into.  At least not one that looks anything like the current draft.  TISPAN only wants a way to signal early media authorization within a private network. 

Maybe I don't understand, but I think this amounts to a header used to prevent the use of early media in some cases where it would have worked had the UAC and UAS been left alone.

> Paul wants a general way to identify when early media is actually rendered to the end user.  There is no reason to believe that the P-header is even the beginnings of a solution to this problem.

While I would *like* that, I would be satisfied if the mechanism didn't make things worse for those unaware of this mechanism.

> I have heard vague suggestions of a solution around an early media 
> option tag in addition to the procedures in my draft, but that will do 
> nothing useful.  I don't think there is any way to include in the 
> initial INVITE request the precise conditions under which a UAS will 
> be allowed early media.  There are no limitations on what information 
> may factor into creating a local policy, and there is no way to 
> predict the early media outcome of forking.  Furthermore, the UAC has 
> no reason to REQUIRE the support of an early media authorization 
> mechanism by the UAS or proxies on the path, since that guarantees 
> nothing about the availability of early media.  Proxies on the path 
> likewise have no reason to REQUIRE support of an early media 
> authorization mechanism by the UAS.  At most they might be willing to 
> indicate that they are applying an unspecified early media policy.  
> Since this new option tag would only be used in the supported header 
> and not the required header in the INVITE
re!
>  quest, it provides no information that the header itself doesn't already provide.  It's the UAS that may have a desire to determine availability of early media.  

I just threw out that proposal to prove a point. I have no expectation that it really solves the problem.

> According to the procedures in the draft, any proxy on the path back to the UAC may modify a UAS authorization request before it finally reaches the UAC.  Providing an indication to the UAS that an authorization request has succeeded clearly requires a 2nd round of signaling.  What message is that going to go in?  There may be no further need for SDP offer/answer.  Do we then define another application of the UPDATE or INFO method?  When the UAC or one of its proxies picks only one stream to render during parallel forking, how does it know what information to signal to its UASs since it can't identify the dialog from information in the stream?  Will the UAC be required to inform the UAS precisely what is being rendered to its user?  

Is there a reason why it needs to be modified on the reverse path? If all the modifications were done on the forward path then the UAS and UAC would at least have a common understanding.

> A big problem that hasn't even been raised yet is that the P-header can only be trusted within the defined Trust Domain and is not applicable to the internet. 
> 
> I propose to separate these problems and work on them independently.  
> 
> Let the P-header go forward as is.
> 
> Then define (in a separate standards track draft) a new option tag "early-media-report" that allows a UAS to request the UAC to report which m-lines are being rendered, if known, and any changes to what is being rendered.  

That is worthy of consideration and discussion.

> That allows us to work on the problems independently.  The private header never needs to go outside the private network.  The standard extension makes no assumptions about authorization or rendering policies while reporting exactly what is known about which early media is being rendered.

We still need to resolve the issue of whether this header violates the rules for P-headers by altering standard behavior. This is a judgment call whether anything about early media counts here.

	Paul

> Richard
> Dean Willis wrote:
>> 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
>