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

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Wed, 3 May 2006 17:35:11 +0200

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.

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: Paul Kyzivat <[email-masked]>
Date: Wed, 03 May 2006 13:29:03 -0400

> 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