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

[Paul Kyzivat <[e-mail]>]

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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP