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 09:23:06 -0500

Paul,
I am at a loss to understand what the problem is here.  The "P" in P header is for "private".  The draft is not imposing any behavior on the internet.  It is enabling a private network to implement a particular billing policy.  The draft clearly states that the header is not for use in the internet.

The following text from RFC 3960 clearly supports the contention that the handling of early media is a matter of local policy: 

"Note that, while it is not desirable to standardize a common local policy to be followed by every SIP UA, a particular subset of more or less homogeneous SIP UAs could use the same local policy by convention.  Examples of such subsets of SIP UAs may be "all the PSTN/SIP gateways" or "every 3GPP IMS (Third Generation Partnership Project Internet Multimedia System) terminal".  However, defining the particular common policy that such groups of SIP devices may use is outside the scope of this document."

Richard

Paul Kyzivat wrote:
> GARCIN Sebastien RD-CORE-ISS wrote:
> > Paul,
> > 
> > In your example you indicate that Provider-B behaved in a 
> compliant manner.
> > Fine.
> > 
> > However if Provider-A does not trust the early media sent 
> by Provider-B is
> > will certainly not let it through there is nothing IETF can 
> do about this
> > (regardless of the outcome of this P-header).
> 
> > My advice to Provider-B here is to "gain trust with 
> Provider-A" so that it
> > can actually make its services work properly for its customers of
> > Provider-B. I don't think that Provider-B will be able to 
> impose whatsoever
> > by saying that it complies with RFC xxx.
> 
> The "trust" here seems to be tied to the billing model. 
> Apparently the 
> assumption here is that early media is permitted for certain network 
> provided features, but not for UA-UA communication. As a 
> result, "trust" 
> could only ever by present between entities that have a business 
> relationship for purposes of billing for telephony services.
> 
> That only seems to work for an analog of the existing walled garden.
> 
> SIP is designed to permit calls between parties that have no business 
> relationship other than both being connected to the internet.
> 
> If I want to call someone with a sip address on the internet, 
> am I going 
> to be prevented from making a successful call if the callee, or the 
> callee's provider, doesn't have a business relationship with 
> *my* provider?
> 
> It seems like the proposal here will abet a strategy that is 
> sip-based 
> but is in fact only interoperates with other sip nodes when 
> it suits the 
> operator's purposes.
> 
> 	Paul
> 
> 
> > sébastien

_______________________________________________
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 11:25:26 -0400

Ejzak, Richard P (Richard) wrote:
> Paul,
> I am at a loss to understand what the problem is here. 
> The "P" in P header is for "private". 
> The draft is not imposing any behavior on the internet. 
> It is enabling a private network to implement a particular billing policy. 
> The draft clearly states that the header is not for use in the internet.

In Aki's initial comments he cited 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.

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.

> The following text from RFC 3960 clearly supports the contention
> that the handling of early media is a matter of local policy: 
> 
> "Note that, while it is not desirable to standardize a common local
> policy to be followed by every SIP UA, a particular subset of more or
> less homogeneous SIP UAs could use the same local policy by convention. 
> Examples of such subsets of SIP UAs may be "all the PSTN/SIP gateways"
> or "every 3GPP IMS (Third Generation Partnership Project Internet
> Multimedia System) terminal".  However, defining the particular common
> policy that such groups of SIP devices may use is outside the scope of
> this document."

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.

	Paul

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 17 Apr 2006 12:56:39 -0400

I re-read the draft trying to figure out why the argument is about not
delivering early media to the UAC, as opposed to the UAC simply deciding
what to do based on it, and I think I see the problem.

Section 7.2 says "In addition, if the proxy controls the gating of early
media in both directions for the User Agent Client, it SHALL use the
contents of the P-Early-Media header to gate the early media according to
the definition of the direction parameter defined in clause 7."
That should be removed IMO, because there is no such "proxy" concept in the
IETF.  Nothing in the media path between UAC-UAS can block delivery of
media.  If TISPAN or 3G wants to define that it's up to them to do so in
their specs.

The draft should purely be about the P-header returned to a UAC, with which
the UAC can do what it wants.  E.g., pure voip UACs could ignore it, and
PSTN-GWs could use it for something specific to their local policies.

-hadriel

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, April 17, 2006 11:25 AM
> To: Ejzak, Richard P (Richard)
> Cc: Cullen Jennings; Jon Peterson; Gonzalo Camarillo; Mary Barnes;
> sipping; Aki Niemi
> Subject: Re: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t
> xt
> 
> 
>