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

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Thu, 4 May 2006 08:36:50 +0200

If I follow your definition P-headers should never be used by 3GPP,
Cablecom, ETSI TISPAN...

My earlier comment hasn't received an answer yet. If one considers your
example with Provider A and Provider B, the same problem you describe will
occur even if Provider A and Provider B do not use this P-header. Provider A
can already block media (early or even confirmed) from Provider B by putting
a FW if does trust the media...

sébastien

-----Message d'origine-----
De : Paul Kyzivat [mailto:[email-masked]] 
Envoyé : mercredi 3 mai 2006 19:29
À : GARCIN Sebastien RD-CORE-ISS
Cc : Aki Niemi; Sipping; ext Dean Willis
Objet : Re: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.txt

GARCIN Sebastien RD-CORE-ISS wrote:
> Paul,
> 
> "Frankly, I wouldn't care if the applicability was really for a truly 
> closed garden, that would never interoperate with anything else based 
> on sip standards. But I don't for a moment believe that is the case or the
intent.
> "
> 
> Could you please explain what you mean here ? What's a "truly closed
garden"
> ? What criteria do you use to say this "P-header" is for "truly closed 
> garden" whereas this P-header isn't.

I mean I wouldn't have a problem with this P-header if the networks it is
used in never interoperate via SIP with anything outside the field of
applicability. For instance a private military communications network that
doesn't interop with the public network.

I suppose a sip based public telephony service would also qualify if it only
interoperates via PSTN protocols with those e.164 numbers it doesn't host.

But a sip based public telephony service that can interop via sip with
providers don't support this header presents a problem

I am hopeful that all the sip based islands in the e.164 sea will be able to
interconnect via sip, not just PSTN. I see this draft as putting that at
risk.

	Paul

> This is very confusing.
> 
> 
> 
> -----Message d'origine-----
> De : Paul Kyzivat [mailto:[email-masked]] Envoyé : mercredi 3 mai 
> 2006 15:33 À : Aki Niemi Cc : 'Sipping'; ext Dean Willis Objet : Re: 
> [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t xt
> 
> Snipping to just the key points...
> 
> Aki Niemi wrote:
> 
> 
>>Overall, I counted 80 messages on this thread landing in my inbox.
>>That's a lot. If anything, this further solidifies my belief that the 
>>SIP change process of RFC 3427 is not working. We're getting wrapped 
>>around the axle on discussing whether or not a proposal is evil or has 
>>the "wrong" business model attached to it -- not whether it works as 
>>intended. Honestly, I don't see these discussions on P-headers 
>>generally very beneficial to have here. I tend to think that the 
>>markets will take care of proposals attached with bad business models 
>>eventually anyway and we need not bother.
>>
>>That said, I still don't buy the argument that this header field 
>>changes behavior of nodes in a *significant* way. If it did, I can't 
>>imagine why blocking early media in terms of authorization of early 
>>media is then mentioned in RFC3959, which is after all standards track.
> 
> 
> I can't find a reference to blocking early media in RFC3959, I suppose 
> you meant RFC3960. I don't know why it meantions media authorization - 
> maybe Gonzalo or Henning can explain.
> 
> 
>>>4) This is where most of the argument is. Several folks have argued 
>>>that we're changing the behavior of SIP entities in a 
>>>non-interoperable way, and given the lack of an OPTION tag, can't 
>>>negotiate or even detect a requirement for the non-interoperable 
>>>behavior. This makes me very, very nervous. SIP is already complex 
>>>enough -- deliberately introducing multiple-personality-disorder 
>>>would not
> 
> make it any better.
> 
>>I don't believe this non-interoperablility argument, not at least when 
>>this is still on paper. Would an option-tag make the problem go away?
>>Hardly. I think the problem is we're measuring a P-header by the same 
>>standards we have for real headers.
> 
> 
> I continue to have difficulty deciding how RFC 3427 should be applied, 
> especially condition 4. I would be happy to have more guidance on this.
> 
> We start down the road of measuring P-headers the same as real headers 
> when it appears that the proposal has violated this condition.
> 
> Frankly, I wouldn't care if the applicability was really for a truly 
> closed garden, that would never interoperate with anything else based 
> on sip standards. But I don't for a moment believe that is the case or the
intent.
> 
> Re an options tag: I didn't specifically propose one. What I did 
> suggest was that the media authorization be done in such a way that 
> both ends know if early media will be permitted or not. I'm not 
> convinced that option tags are the way to achieve that. But if 
> achieved, what it would do is provide both ends with the opportunity to
avoid doing things that aren't going to work.
> It doesn't solve the problem in cases where there is no alternative to 
> early media, but it at least mitigates the problem.
> 
> 
>>Is there rather something that could be put into the applicability 
>>statement to make these concerns go away, like to write down exactly 
>>the cases when interop problems are expected to happen? So that 
>>implementors and deployers can take notice.
> 
> 
> There are practical problems with this. Suppose user A is connected 
> through a service provider that is using the mechanisms of 
> draft-ejzak-sipping-p-em-auth-00 to block early media from 
> unauthorized sources. User B gets service from a "rogue" service 
> provider that isn't part of the oligarchy that A's provider belongs 
> to. But both providers are connected to the internet, and do interconnect
via basic SIP routing rules.
> But because B's provider isn't part of the club, A's provider doesn't 
> "trust" it, and so does not authorize early media.
> 
> B has configured his service to forward calls to his cell phone number 
> on the PSTN when no sip device is registered. But B also forgot to pay 
> his cellphone bill, and his service has been terminated.
> 
> Then A calls B. The call goes to B's provider. Nothing is registered, 
> so B sends the call to its PSTN gateway, toward B's cell phone number. 
> The cell phone provider plays a disconnected message in the media 
> stream without answering the call. The gateway in B's network sends 
> this media as early media towards A. But A's provider has blocked 
> early media. So A hears nothing, and eventually the call drops.
> 
> Later A talks to B and says: I've been calling you and calling you 
> without success. There must be something wrong because I just get 
> silence and a disconnect.
> 
> 	Paul
> 
> _______________________________________________
> 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: "Spencer Dawkins" <[email-masked]>
Date: Thu, 4 May 2006 06:02:46 -0500

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>

"If I follow your definition P-headers should never be used by 3GPP,
Cablecom, ETSI TISPAN"

If I'm following the discussion correctly, it's not that P-headers shouldn't 
be used within a network (or even class of network), but that P-headers 
shouldn't be used when leaving that network. The issue isn't using P-headers 
in 3GPP, it's using P-headers on a call from 3GPP to TISPAN, or to any 
network that doesn't clearly understand P-headers, when not understanding 
affects the experience of the participants at each end.

If I have missed the point, someone please explain more clearly.

Thanks,

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 May 2006 18:10:06 -0400

Catching up on loose ends...

> a FW if does trust the media...

I suppose the provider can do that. And it can request the UA to explode 
and kill a user it doesn't trust. Maybe we should add something to sip 
to request that.

If the sip signaling goes e2e and negotiates the media, it seems wrong 
to me to require something else in sip to make the media (early or late) 
*work*.

The above-board way to do this would be to cause the sip request to fail 
if it requests something (e.g. early media) that the provider isn't 
willing to provide. That sounds a lot like the policy framework.

	Paul