Subject: Re: [sipcore] Confirming Consensus: WebSockets

From: Adam Roach <[email-masked]>
Date: Mon, 02 Apr 2012 10:52:57 -0500

[as a participant]

Hadriel:

I understand the practicalities you're trying to highlight, but I don't 
think it's reasonable to work around the not-formally-defined and 
constantly shifting behavior of arguably noncompliant intermediaries at 
this point. Maybe STRAW can take on an item to define out-of-dialog 
request routing behaviors, and discuss GRUU interaction; then we can 
talk in terms of intermediaries that implement those specific procedures.

For the time being, I think we need to work with the standardized tools 
that have been defined -- tools that work just fine in an actual 
standards-compliant network -- and let those entities that break proper 
routing deal with the consequences through whatever proprietary 
band-aids amuse them.

In this context, that would (IMHO) involve a discussion of the problems 
solved by GRUU, and a pointer to the document. I agree with Christer 
that -- like outbound -- we don't need to mandate GRUU; we simply need 
to describe what happens without it, and let implementors make their own 
evaluation about whether those properties warrant the additional 
implementation complexity.

/a

On 3/29/12 12:40 PM, Hadriel Kaplan wrote:
> On Mar 28, 2012, at 10:56 PM, Paul Kyzivat wrote:
>
>> Please correct me if I'm wrong, but I *think* what you are trying to say is that out of dialog requests to the contact address from a dialog will mostly never work, unless somebody puts the phone-number-style URI in the contact address, or if the contact is one that was substituted by the last SBC.
> I'm not quite sure what *you're* saying, so I can't tell if it's what I'm also trying to say. :)
>
>
>> I would think, *if they wanted to*, SBCs could make whatever substitution is necessary to make a gruu that they receive in a contact address be usable on the other side. This would be in their traditional role of fixing all the interop problems of the networks they connect.
>
> Sort of.  There are some folks in the IETF who don't want the SBCs to change them at all if they're GRUUs.  And there are also other SDOs/groups that seem to think they will be getting GRUUs, that they MUST get GRUUs, and that it will somehow make things magically work.
>
> -hadriel
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Victor Pascual Avila <[email-masked]>
Date: Mon, 2 Apr 2012 18:10:15 +0200

On Mon, Apr 2, 2012 at 5:52 PM, Adam Roach <[email-masked]> wrote:
> I agree with Christer that -- like outbound -- we don't need to mandate
> GRUU; we simply need to describe what happens without it, and let
> implementors make their own evaluation about whether those properties
> warrant the additional implementation complexity.

Agreed -- this is what we're actually planning to do for the next
revision of the document

-Victor

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Apr 2012 00:20:43 -0400

[as individual]

> I'm not quite sure what *you're* saying, so I can't tell if it's what I'm also trying to say. :)

OK, I'll try again, and at the same time back off from some assumptions 
I was making about what you were saying.

The point of a UA using a Gruu (a gruu (globally routable ua uri) 
assigned by a registrar according to 5627) as its contact address in a 
dialog is so that it knows that it can be reached out-of-dialog by any 
UA that receives its contact address.

When you disparage using Gruus in this way, without offering a reference 
to an alternative, I guess you are saying the UA should just use its 
own, non-gruu URI, and rely on "somebody else" to "make it better" in 
some unspecified, magic way. Is that right? How is the UA to know this 
will happen? How does it know that it will work in all the cases that 
matter to it?

> Sort of.  There are some folks in the IETF who don't want the SBCs to change them at all if they're GRUUs.

Yes. I think that if they are constructed to be globally routable then 
they should not need to be changed in any 3261 conforming network.

I guess I would not object if an SBC did something to a Gruu to make it 
work in an environment that was *not* conforming and where the Gruu 
would otherwise not work. I would also expect that network to *not* 
advertise itself as conforming to sip.

> And there are also other SDOs/groups that seem to think they will be getting GRUUs,
> that they MUST get GRUUs, and that it will somehow make things magically work.

Well, 3261 says that UAs MUST use a contact URI with global scope. 5627 
was created because many UAs were not following this because they had no 
access to such a URI.

The 3261 requirement is not to use a Gruu assigned by a registrar 
according to 5627. The UA can get one any way it wants. The registrar 
mechanism is just one way to achieve that.

But its pretty sad if an SBC goes out of its way to break a UA that is 
trying hard to do what it is required to do.

Now this doesn't mean I'm blaming *you*, or *Acme*, or any SBC vendor, 
for doing this. As you repeatedly stress, and I understand, you are just 
doing what your customers ask you to do. So its *them* that I blame for 
this.

If they are going to require non-conforming behavior, or "fix" 
conforming behavior to be non-conforming, they they should make it clear 
to *their* customers that they are operating a closed environment that 
is not sip-conforming.

	Thanks,
	Paul