Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t xt

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 17 Apr 2006 14:06:17 -0500

Hi Paul,
Thank you for acknowledging that it is legitimate to apply local policy considerations to early media.  It is clear that you do not recommend it.

Richard

Paul Kyzivat wrote:
> Ejzak, Richard P (Richard) wrote:
> > Paul Kyzivat wrote:
> > 
> >>It is the redefining of behavior that is concerning me. If it 
> >>was just 
> >>affecting the billing policy then I don't think I would have any 
> >>concern. But it isn't just affecting billing policy. It is actually 
> >>redefining the policy for whether the early media is delivered.
> >  
> > And in the presence of parallel forking, also according to RFC 3960:
> > "It is difficult to decide which early media sessions carry more
> > important information from the caller's perspective.  In fact, in
> > some scenarios, the UA cannot even correlate media packets 
> with their
> > particular SIP early dialog.  Therefore, UACs typically pick one
> > early dialog randomly and mute the rest."
> > 
> > So there is no way that a UAS can know that its early media will get
> > through in a given situation anyway.  My draft DOES NOT CHANGE THIS.
> 
> Are you are saying that because parallel forking can result in a case 
> where early media is lost, it is ok to introduce additional 
> cases that 
> lose early media?
> 
> >>The passage you quote is from section 3.2 (Ringing Tone 
> Generation). 
> >>Earlier in that section is: "a UAC should develop its local policy 
> >>regarding local ringing generation".
> >>
> >>IMO the section you quote pertains to a policy for local ring tone 
> >>generation, not a policy for processing of early media.
> > 
> > Local ringing generation is described in 3.2 as being inextricably
> > linked with early media. 
> 
> Yes, but the converse is not true - early media is meaningful without 
> reference to ring tone generation.
> 
> > The example policy given after the text
> > you quote describes how one might decide to provide local ringing
> > depending on the presence of early media.  Since this is completely
> > up to local policy, then (as in the parallel forking example) it
> > is a completely legitimate local policy to generate local ringing
> > in place of early media.
> 
> Legitimate perhaps, but misguided. If a UA does this 
> routinely, even in 
> the absence of forking, then it will miss all the in-band 
> announcements 
> about sevice disconnect, etc. that are routinely provided by the PSTN.
> 
> The fact of the matter is, early media is important, and 
> losing it is a 
> problem. Efforts should be taken to avoid losing it.
> 
> IMO what you propose is a system where early media only works to/from 
> sources inside the walled garden, while early media to/from 
> outside the 
> garden walls is blocked.
> 
> 	Paul
> 
> > Richard
> > 
> 

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Apr 2006 15:22:10 -0400

> Thank you for acknowledging that it is legitimate to apply local policy considerations to early media.  It is clear that you do not recommend it.

I've been hoping some others would jump in here to give some other 
perspectives on this. I don't pretend to be the last word on this.

Do you acknowledge that a consequence of intended use of this p-header 
is that "trusted" sources of early media may have their early media 
delivered, while potential sources of early media *outside* of your 
trust domain will have their early media dropped - not delivered to the 
other UA?

The question comes down to whether that is a valid use of a P-header 
according to point 4 of RFC 3427:

    4.  The proposed header MUST be of a purely informational nature, and
        MUST NOT significantly change the behavior of SIP entities which
        support it.  Headers which merely provide additional information
        pertinent to a request or a response are acceptable.  If the
        headers redefine or contradict normative behavior defined in
        standards track SIP specifications, that is what is meant by
        significantly different behavior.

Will this P-header "significantly change the behavior of SIP entities 
which support it"? As best I can tell, that is the *intent* of this header.

	Paul