Subject: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Mar 2014 16:38:36 -0400

I read this draft as well as the referenced draft 
draft-kaplan-dispatch-gruu-problematic-00 (which somehow slipped by 
without my noticing.)

I am not very sympathetic.

This seems to be a problem that SBC products have made, and it ought to 
be one that they fix. AFAIK SBC vendors have typically advertised that 
they "fix" problems in integrating different sip implementations.

This is not new. IMS has had B2BUAs and access proxies for a long time. 
And at one point procedures were included for how they should handle gruus.

And in cases where user endpoints are specialized for non-standard 
environments it is also possible for those endpoints to obtain gruus in 
some non-standard way, rather than using standard registrar-provided gruus.

I'll also note that 3261 *required* that *all* contact addresses be 
globally routable, and GRUUs were introduced in the first place because 
that had been widely violated. I don't recall any alternatives to GRUU 
being proposed at the time.

I want to hear a very careful explanation of how attempts have been made 
to get gruus to work, and how it is impossible to do so. And I want to 
see a specific, workable, and deployable proposal for an alternative. 
(And it needs to deal with the issues around dialog sharing.)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Mar 2014 18:27:13 -0400

On Mar 12, 2014, at 4:38 PM, Paul Kyzivat <[email-masked]> wrote:

> I read this draft as well as the referenced draft draft-kaplan-dispatch-gruu-problematic-00 (which somehow slipped by without my noticing.)
> 
> This seems to be a problem that SBC products have made, and it ought to be one that they fix. AFAIK SBC vendors have typically advertised that they "fix" problems in integrating different sip implementations.

Hmmm... I could be tacky and put this URL here:

http://i.imgur.com/nZutGqn.jpg

...but I'll try to be good.

Instead I'll just point out that most of draft-kaplan-dispatch-gruu-problematic-00 is not due to problems caused by SBCs, or at least not *only* SBCs.

(I haven't read Andrew's draft yet though)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Mar 2014 18:43:53 -0400

> ...but I'll try to be good.

Thanks for being good!

> Instead I'll just point out that most of draft-kaplan-dispatch-gruu-problematic-00 is not due to problems caused by SBCs, or at least not *only* SBCs.

Then maybe you can resume the role of good guys who fix other people's 
problems. :-)

> (I haven't read Andrew's draft yet though)

Go for it. Its short.

Here is my problem: SIP was specified on the assumption of global 
routability of contacts. GRUUs were introduced to give UAs a alternative 
if they had no other way to get a globally routable contact.

We don't have another general alternative. Requiring that UAs assume 
that magic middle boxes are always deployed that can figure out how to 
fix everyting doesn't seem a good answer, since we have no definition of 
such boxes and no way to ensure they are present.

IMO it is the responsibility of middle boxes to ensure they don't break 
things. (Yes, I know that can be hard, since the full set of things they 
shouldn't break is undefined. But that is what you bite off when you 
deploy one.)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Mar 2014 19:37:51 -0400

On Mar 12, 2014, at 6:43 PM, Paul Kyzivat <[email-masked]> wrote:

> Then maybe you can resume the role of good guys who fix other people's problems. :-)

There is no problem I know of, so long as you do NOT use GRUUs, or ignore the 'gr' param and just behave like they're normal contact URIs.

"Fixing" GRUU isn't really possible - at least not in the sense of (1) being a GRUU and thus *globally routable*, and also of being able to give a received GRUU to someone else and have them be able to use it, anytime, anyplace.

It's not solvable because the problem is there is no URI you can create that is *truly* globally routable, in practice, in most networks. The reasons why are documented in draft-kaplan-dispatch-gruu-problematic-00.  Many of those reasons ultimately mean there can be no such thing as a globally-routable/de-referencable URI, for many domains.

>> (I haven't read Andrew's draft yet though)

Done. Yup, short. :)
It would be simpler to just use a Contact param that meant "use the received Record-Route list in this dialog to generate a Route set for a new out-of-dialog REFER, if you send such a REFER".  Or something like that.  Years back we toy'ed with the idea of embedding the Record-Route headers into the "gruu" contact, to try to make GRUU work, but it grows way too big.

> Here is my problem: SIP was specified on the assumption of global routability of contacts. GRUUs were introduced to give UAs a alternative if they had no other way to get a globally routable contact.

Why do they need one?  What's "broken" that has to be fixed?

The only problem I know of is that RFC 6665 demands GRUUs, and IMS has decided they need 6665 for some reason.

There's nothing wrong with 6665 - it just can't be used by many SIP domains, including IMS ones.  It's like writing an RFC and saying "to implement this RFC you MUST use IPV6".  That's cool and all... good luck with that.

> We don't have another general alternative. Requiring that UAs assume that magic middle boxes are always deployed that can figure out how to fix everyting doesn't seem a good answer, since we have no definition of such boxes and no way to ensure they are present.
> IMO it is the responsibility of middle boxes to ensure they don't break things. (Yes, I know that can be hard, since the full set of things they shouldn't break is undefined. But that is what you bite off when you deploy one.)

It's not only the middleboxes that break it.  If you deploy a SIP domain and don't accept SIP requests from any device anywhere on the Internet (for both IPv4 and IPv6), then you can't use GRUUs.  If you deploy a SIP domain and won't allow all your proxies or UAs to directly send SIP requests to any device anywhere on the Internet, then you can't accept GRUUs.

In practice, very few SIP domains accept SIP requests from any random device on the Internet, or allow all their proxies/UAs to send SIP requests directly to any random device on the Internet.  IMS domains don't.  Most Enterprise domains don't.  They're all incompatible with GRUUs.  They just don't realize it.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Mar 2014 11:01:08 -0400

> There is no problem I know of, so long as you do NOT use GRUUs, or ignore the 'gr' param and just behave like they're normal contact URIs.

So you are saying that take any old contact from an existing dialog, and 
use it as the Refer-To URI in an out of dialog request to anybody, and 
it will work fine?

> It's not solvable because the problem is there is no URI you can create that is *truly* globally routable, in practice, in most networks. The reasons why are documented in draft-kaplan-dispatch-gru…

In practice it is only important to be routable from places you want to 
be reached from. If other calls fail, and that is what you wanted to 
happen, then fine.

The problem is when call flows break even when all the participants are 
legitimate - when the providers are creating a walled garden that only 
works for the specific call flows they have anticipated and made 
specific provision for. That breaks innovation, and drives things like 
webrtc.

> It would be simpler to just use a Contact param that meant "use the received Record-Route list in this dialog to generate a Route set for a new out-of-dialog REFER, if you send such a REFER".  Or s…

It sounds like you want to be involved in the update to 3515!

> The only problem I know of is that RFC 6665 demands GRUUs, and IMS has decided they need 6665 for some reason.

You know the reason. First, it was updating 3265 to eliminate multiple 
dialog usages, as specified in rfc 5057. Do you have some other way to 
achieve that?

> There's nothing wrong with 6665 - it just can't be used by many SIP domains, including IMS ones.  It's like writing an RFC and saying "to implement this RFC you MUST use IPV6".  That's cool and all…

Did you object to 6665 when it was being reviewed?

> In practice, very few SIP domains accept SIP requests from any random device on the Internet, or allow all their proxies/UAs to send SIP requests directly to any random device on the Internet.  IMS…

That is unfortunate, and is indeed a problem. SIP was designed on the 
email model. But "market forces" don't like that model.

But as I said above, I don't think it is *the* problem in this case.

I realize there is *a* problem. Andrew's draft and yours about gruu 
indicate pain. I think it is reasonable to investigate that further. But 
it will take some work to tease out exactly what is causing the problem, 
and what makes sense as a solution. (Versus what implementers just don't 
want to do.) It seems to require formalizing behavior that is common in 
the field that is not written down in a way that allows it to be 
considered in our specifications.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Mar 2014 17:44:12 +0000

Hi,

>> In practice, very few SIP domains accept SIP requests from any random device on the Internet, or allow all their proxies/UAs to send SIP requests 
>> directly to any random device on the Internet.  IMS domains don't.  Most Enterprise domains don't.  They're all incompatible with GRUUs.  They just don't realize it.
>

E-mails aren't sent to a user device. They are sent to the receiver's mail server, from where the user device(s) fetch them (push or pull).

Also, one of the justifications for GRUU was to not only reach a specific user - but a specific user DEVICE (needed for call transfer). E-mails don't need to reach a specific user device - they can be "forked" to every user device running a mail program connected to the mail server.

I know this is not really related to the topic of this thread, but I don't think we should compare SIP with e-mail :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Mar 2014 13:52:53 -0400

> I know this is not really related to the topic of this thread, but I don't think we should compare SIP with e-mail :)

I meant it was like email in the sense that anyone can send to anyone. 
There aren't "peering relationships" that enforce an oligopoly.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Mar 2014 14:10:34 -0400

[splitting the email up because it's getting long...]

On Mar 13, 2014, at 11:01 AM, Paul Kyzivat <[email-masked]> wrote:

> So you are saying that take any old contact from an existing dialog, and use it as the Refer-To URI in an out of dialog request to anybody, and it will work fine?

No of course not - I didn't mean you couldn't manufacture a problematic scenario - I meant as far as I know, people aren't hitting this "problem" in practice, in the field.  We had some problems along these lines years ago, but we fixed it by using "global contacts" as indicated in my draft.  I haven't heard of any problems since then. (which isn't to say there aren't such problems - perhaps a LOT of people are having such problems - I just haven't heard of it personally)

> In practice it is only important to be routable from places you want to be reached from. If other calls fail, and that is what you wanted to happen, then fine.

Right, so that's the "problem" I'm saying I don't see happening.  Call transfers aren't failing due to legacy SIP contact usage, afaict.
It used to, but I haven't heard of problems since global contacts started getting used. (but again, that's just my experience and I could be way wrong on that)

> The problem is when call flows break even when all the participants are legitimate - when the providers are creating a walled garden that only works for the specific call flows they have anticipated and made specific provision for. That breaks innovation, and drives things like webrtc.

You realize the irony in that last statement right?  Webrtc is by-definition a walled-garden. :)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Mar 2014 14:49:40 -0400

[part 2...]

> It sounds like you want to be involved in the update to 3515!

Only if it contains: "...and here's how to send in-dialog REFER requests..."
;)

On a more serious note, it needs to not demand GRUUs be used.

> You know the reason. First, it was updating 3265 to eliminate multiple dialog usages, as specified in rfc 5057. Do you have some other way to achieve that?

Afaik, the only "problem" with multiple dialog usages is implementors get confused by it, or don't know about it to begin with. (and don't get me wrong - it *is* very confusing)

IMS has no substantive reason for eliminating them that I know of, nor to go to 6665... other than the RFC number for 6665 is higher than 3265.

Afaict, IMS networks can't truly use GRUUs safely, for most intents and purposes.

> Did you object to 6665 when it was being reviewed?

Nope. I don't even remember it much. I guess I wasn't paying much attention to it - I thought it was just cleaning up stuff, not fundamentally changing things. (my fault)

> That is unfortunate, and is indeed a problem. SIP was designed on the email model. But "market forces" don't like that model.

Yup.  We've been struggling with that in these WGs for over a decade.

> I realize there is *a* problem. Andrew's draft and yours about gruu indicate pain. I think it is reasonable to investigate that further. But it will take some work to tease out exactly what is causing the problem, and what makes sense as a solution. (Versus what implementers just don't want to do.) It seems to require formalizing behavior that is common in the field that is not written down in a way that allows it to be considered in our specifications.

It's a complicated issue.  IMS in particular makes it even more complicated, because as specified in the IMS docs the P-CSCF isn't truly a B2BUA in the way an SBC is, yet the access-controls and message routing rules/model are similar to SBCs.  So they're trying to have their cake and eat it too.

Regardless, no matter it being true "IMS" as specified, or a normal Service-provider network, or a access-controlled Enterprise, or whatever... I think the basic problem is all messages related to a dialog have to flow through specific hops; the same ones used for the dialog.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Mar 2014 19:32:39 +0000

Hi,

> It would be simpler to just use a Contact param that meant "use the received Record-Route list in this dialog to generate a Route set for a new 
> out-of-dialog REFER, if you send such a REFER".  Or something like that.  Years back we toy'ed with the idea of embedding the Record-Route 
> headers into the "gruu" contact, to try to make GRUU work, but it grows way too big.

Yes - we need to keep SIP messages short ;)

Anyway, 3261 already supports adding embedded headers to the contact. Whether entities would actually use them, especially for out-of-dialog requests, is another question...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Mar 2014 19:41:48 +0000

Hi,

>>> It would be simpler to just use a Contact param that meant "use the received Record-Route list in this dialog to generate a Route set for a new out-of-dialog 
>>> REFER, if you send such a REFER".  Or something like that.  Years back we toy'ed with the idea of embedding the Record-Route headers into the "gruu" contact, to try to make GRUU work, but it grows way too big.
>>

...which, as we discuused in London, means that the text needs to continue with "...by making sure no ref-subscription (well, at least not a ref-subscription within the same dialog) is created..."

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Mar 2014 16:59:13 -0400

> Yes - we need to keep SIP messages short ;)

Actually, we do need to.  Not in specs of course, but in deployment. :)

> Anyway, 3261 already supports adding embedded headers to the contact.

Of course - that's why we were considering using it.

> Whether entities would actually use them, especially for out-of-dialog requests, is another question...

Yeah the odds aren't great.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Mar 2014 14:36:11 -0400

> On a more serious note, it needs to not demand GRUUs be used.

Of the work currently contemplated, that is your leverage point to sell 
your position.

> Afaik, the only "problem" with multiple dialog usages is implementors get confused by it, or don't know about it to begin with. (and don't get me wrong - it *is* very confusing)

So where were you when RFC5057 was being discussed.

*I* was in favor of retaining multiple dialog usages, but AFAIK I was 
the *only* person who was. So I was overridden.

> IMS has no substantive reason for eliminating them that I know of, nor to go to 6665... other than the RFC number for 6665 is higher than 3265.

You heard Christer. They have a policy of updating to the latest updates 
to the drafts they reference. Also, they need the new H-I, and it 
references 6665.

> Afaict, IMS networks can't truly use GRUUs safely, for most intents and purposes.

As I said elsewhere, a number of years ago I worked on IMS revisions for 
GRUU. (Done for Cable Labs.) But I wasn't involved long enough to know 
if they were ever adopted. Were they? Or not?

> Nope. I don't even remember it much. I guess I wasn't paying much attention to it - I thought it was just cleaning up stuff, not fundamentally changing things. (my fault)

Then this is now sour grapes.

> Regardless, no matter it being true "IMS" as specified, or a normal Service-provider network, or a access-controlled Enterprise, or whatever... I think the basic problem is all messages related to…

They have to deal with the details. AFAIK you don't speak for them. I 
look to people like Christer, Andrew, and Gonzalo to bring up issues 
like this. And now is kind of late.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Mar 2014 14:39:02 -0400

> ...which, as we discuused in London, means that the text needs to continue with "...by making sure no ref-subscription (well, at least not a ref-subscription within the same dialog) is created..."

One of the possibilities mentioned (though not too seriously) was to 
revise 3515 to totally eliminate the implicit subscription to the refer 
event package - forcing it to be done explicitly if desired.

I can think of lots of reasons why that would be a bad idea. But there 
may be other possibilities. ISTM that the way norefersub was defined was 
less than successful.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Mar 2014 14:42:57 -0400

> Actually, we do need to.  Not in specs of course, but in deployment. :)

We haven't solved this with TCP. But maybe we are approaching a time 
when we have strong arguments for why people need to use TLS on all hops 
(without SIPS) to provide privacy, and then get large message support as 
a bonus.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Mar 2014 19:00:22 +0000

Hi,

> event package - forcing it to be done explicitly if desired.

I took it possibility seriously :)

> may be other possibilities. ISTM that the way norefersub was defined was

One suggestion (by myself) was to define a new option-tag, which in a Require header field would mean "must support AND must use", similar to 100rel.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Mar 2014 15:12:13 -0400

> It used to, but I haven't heard of problems since global contacts started getting used. (but again, that's just my experience and I could be way wrong on that)

So you say you haven't had a problem since you introduced a proprietary 
solution. And that was documented in an individual draft that expired 
years ago. (The draft was published on Oct 18, 2010, and afaict was 
discussed on the mailing list for two days and then never again until now.)

 From what I can see, the complete definition of "Global Contacts" is:

"which are Contact URIs having the properties of a GRUU, but not being a 
GRUU in syntax (i.e., without a 'gr' param, and not indicating an AoR)."

Note that the UA aren't required to use GRUUs constructed according to 
rfc5627. They can use anything with the required properties. The purpose 
of the "gr" parameter is to hint others that the uri has the gruu 
property, so they can avoid work-arounds such as sending requests 
in-dialog. I guess you wanted to preserve the work=arounds.

> You realize the irony in that last statement right?  Webrtc is by-definition a walled-garden. :)

It depends on your point of view. Certainly each web server that puts 
usages of webrtc into its web pages is a sort of walled garden. And that 
can indeed be a problem if I want to talk to a Facebook user, since I 
don't have a Facebook account.

OTOH, it is open in the sense that any browser can work with any of 
those web servers. It is a radically different model, so hard to compare.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Mar 2014 16:34:23 -0400

> So where were you when RFC5057 was being discussed.

I don't know - probably doing my day job instead of IETF stuff. :)

> You heard Christer. They have a policy of updating to the latest updates to the drafts they reference. Also, they need the new H-I, and it references 6665.

Uhhh, not that I see it doesn't. Why would it?

> As I said elsewhere, a number of years ago I worked on IMS revisions for GRUU. (Done for Cable Labs.) But I wasn't involved long enough to know if they were ever adopted. Were they? Or not?

Using GRUUs is in their specs. Whether it gets used in practice is a different question, with probably a mixed answer. (there's a lot in IMS specs that rarely sees deployment, or takes a veeery long time to, afaict)

> Then this is now sour grapes.

Oh no, not at all - RFFC 6665 is only a "Proposed Standard" after all, not an actual Internet Standard. ;)

> They have to deal with the details. AFAIK you don't speak for them. I look to people like Christer, Andrew, and Gonzalo to bring up issues like this. And now is kind of late.

I don't speak for anyone but myself in IETF mailing lists. Not for 3GPP, nor my employer. I didn't start this thread - you guys did. So I'm just giving my input, and it's not just about IMS networks. If you don't want public input, I don't think this mailing list is the right one for this thread. (or else I misunderstand the nature of IETF WG mailing lists)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Mar 2014 16:37:59 -0400

On Mar 14, 2014, at 2:39 PM, Paul Kyzivat <[email-masked]> wrote:

> One of the possibilities mentioned (though not too seriously) was to revise 3515 to totally eliminate the implicit subscription to the refer event package - forcing it to be done explicitly if desired.

I don't think that will help - because if the UA desires to do it explicitly, the SUBSCRIBE has to go to the same place/path the INVITE/REFER did too.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Mar 2014 20:57:37 +0000

Hi,

>>> ...which, as we discuused in London, means that the text needs to continue with "...by making sure no ref-subscription (well, at least not a ref->>>subscription within the same dialog) is created..."
>>
>> One of the possibilities mentioned (though not too seriously) was to revise 3515 to totally eliminate the implicit subscription to the refer event package - >> forcing it to be done explicitly if desired.
>

True. But, it would solve the case where the UA does NOT want a subscription, which I belive is the use-case that triggered the discussion in London :)

Regards,

Christer

---

From: Michael Hammer <[email-masked]>
Date: Fri, 14 Mar 2014 21:03:38 +0000

The real irony would be if the WebRTC servers interconnected to each other 
using a widely-available IMS and thereby become more open.

One walled-garden turning the other walled-garden inside out.  :)

________________________________
Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, March 14, 2014 3:12 PM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [dispatch] Comments on
draft-allen-dispatch-routing-out-of-dialog-request-00

On 3/13/14 2:10 PM, Hadriel Kaplan wrote:
>>> There is no problem I know of, so long as you do NOT use GRUUs, or
ignore the 'gr' param and just behave like they're normal contact URIs.
>> So you are saying that take any old contact from an existing dialog, and
use it as the Refer-To URI in an out of dialog request to anybody, and it
will work fine?
>
> No of course not - I didn't mean you couldn't manufacture a 
> problematic scenario - I meant as far as I know, people aren't hitting 
> this "problem" in practice, in the field.  We had some problems along 
> these lines years ago, but we fixed it by using "global contacts" as 
> indicated in my draft.  I haven't heard of any problems since then. 
> (which isn't to say there aren't such problems - perhaps a LOT of 
> people are having such problems - I just haven't heard of it 
> personally)
>
>
>>> "Fixing" GRUU isn't really possible - at least not in the sense of (1)
being a GRUU and thus *globally routable*, and also of being able to give a
received GRUU to someone else and have them be able to use it, anytime,
anyplace.
>>>
>>> It's not solvable because the problem is there is no URI you can create
that is *truly* globally routable, in practice, in most networks. The
reasons why are documented in draft-kaplan-dispatch-gruu-problematic-00.
Many of those reasons ultimately mean there can be no such thing as a
globally-routable/de-referencable URI, for many domains.
>> In practice it is only important to be routable from places you want to
be reached from. If other calls fail, and that is what you wanted to happen,
then fine.
>
> Right, so that's the "problem" I'm saying I don't see happening.  Call
transfers aren't failing due to legacy SIP contact usage, afaict.
> It used to, but I haven't heard of problems since global contacts 
> started getting used. (but again, that's just my experience and I 
> could be way wrong on that)

So you say you haven't had a problem since you introduced a proprietary
solution. And that was documented in an individual draft that expired years
ago. (The draft was published on Oct 18, 2010, and afaict was discussed on
the mailing list for two days and then never again until now.)

Note that the UA aren't required to use GRUUs constructed according to
rfc5627. They can use anything with the required properties. The purpose of
the "gr" parameter is to hint others that the uri has the gruu property, so
they can avoid work-arounds such as sending requests in-dialog. I guess you
wanted to preserve the work=arounds.

>> The problem is when call flows break even when all the participants are
legitimate - when the providers are creating a walled garden that only works
for the specific call flows they have anticipated and made specific
provision for. That breaks innovation, and drives things like webrtc.
> by-definition a walled-garden. :)

It depends on your point of view. Certainly each web server that puts usages
of webrtc into its web pages is a sort of walled garden. And that can indeed
be a problem if I want to talk to a Facebook user, since I don't have a
Facebook account.

OTOH, it is open in the sense that any browser can work with any of those
web servers. It is a radically different model, so hard to compare.

	Thanks,
	Paul

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Mar 2014 21:10:51 +0000

Hi,

What started this whole discussion was the submission of Andrew's draft, which is not about GRUUs as such, eventhough the draft does mention GRUUs getting overwritten. 

The main issue raised in the draft is SBCs re-writing the contact, but not other parameters (e.g Target-Dialog, Replaces, Refer-To URI, etc), and that out-of-dialog requested addressed using those other parameters won't reach the UA.

Regards,

Christer

________________________________________
From: dispatch [[email-masked]] on behalf of Hadriel Kaplan [[email-masked]]
Sent: Friday, 14 March 2014 10:34 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Mar 2014 21:12:06 +0000

>One walled-garden turning the other walled-garden inside out.  :)

Well, your dream is about to become true, as 3GPP is currently defining WebRTC access to IMS :)

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, March 14, 2014 3:12 PM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [dispatch] Comments on

        Thanks,
        Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Mar 2014 17:32:51 -0400

On Mar 14, 2014, at 3:12 PM, Paul Kyzivat <[email-masked]> wrote:

> So you say you haven't had a problem since you introduced a proprietary solution. And that was documented in an individual draft that expired years ago. (The draft was published on Oct 18, 2010, and afaict was discussed on the mailing list for two days and then never again until now.)

I think you're venting at the wrong target. I didn't raise this topic/thread, nor was I the one to start referencing my gruu-problematic draft. I'm not the one bringing this issue up in the first place.

Regarding the gruu-problematic draft, I didn't refresh it since 2010 because there didn't seem much interest - in fact, there was general anger vented against it if I recall right. I get enough of that from my other drafts, I didn't need another. :)

> Note that the UA aren't required to use GRUUs constructed according to rfc5627. They can use anything with the required properties. The purpose of the "gr" parameter is to hint others that the uri has the gruu property, so they can avoid work-arounds such as sending requests in-dialog. I guess you wanted to preserve the work=arounds.

No, we wanted to keep calls working.  We would have far preferred to have to do nothing new instead, and let things just work as advertised.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Mar 2014 20:49:51 -0400

> The main issue raised in the draft is SBCs re-writing the contact, but not other parameters (e.g Target-Dialog, Replaces, Refer-To URI, etc), and that out-of-dialog requested addressed using those…

<soapbox>

You make it sound like replacing the Contact is a bug or bad idea - it isn't, it's what an SBC *should* do. It's what P-CSCF's should have done from the beginning too, for that matter. It's what makes things actually *work*. If an SBC doesn't also replace the other headers, that's a bug/bad-idea.

But that wasn't what Andrew's draft said... or at least that's not how I read it.

His gripe with a B2BUA replacing the Contact is you lose what the far-end UAC's capabilities were.

But again, that too is not a bug/bad-idea, it's what a B2BUA *should* do.  Having a B2BUA blindly pass-along UAC capabilities without knowing if the B2BUA itself supports them is just asking for things to break badly. The downside is it means you have to either upgrade B2BUAs to support new features, or configure them to pass the feature caps that you know will work through them. That's the price you pay for using B2BUAs instead of real Proxies. (and let's not pretend a P-CSCF is a real Proxy)

It's a price many are willing to pay, to make phone calls actually work. And arguably it's what they should want to happen, because most operators of SIP domains want to test new features first, before it's used by endpoints, to make sure it will work between everyone and they don't get inundated with support calls for things not working. They don't want a change in UA behavior until they're sure they can handle it.

</soapbox>

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 15 Mar 2014 09:11:20 +0000

Hi,

> You make it sound like replacing the Contact is a bug or bad idea 

Not me - the draft. I probably agree with most things you say :)

I simply clarified what the draft talks about.

> - it isn't, it's what an SBC *should* do. It's what P-CSCF's should have done from the beginning too, for that matter. It's what makes things actually *work*. If an SBC doesn't also replace the other headers, that's a bug/bad-idea.

Exactly.

> His gripe with a B2BUA replacing the Contact is you lose what the far-end UAC's capabilities were.

That is another issue in the draft, yes.

The draft claims that it is problematic if the capabilities point to the UA, but the contact to the SBC, but the draft doesn't say why that is problematic.

Regards,

Christer

---

From: Shida Schubert <[email-masked]>
Date: Sun, 16 Mar 2014 14:44:04 -0700

All;

 Let me clarify one point as a co-author of H-Ibis. 

> You heard Christer. They have a policy of updating to the latest updates to the drafts they reference. Also, they need the new H-I, and it references 6665.

 H-I doesn't require RFC6665, it's the RFC6910 (BLISS-Call-Completion) that references 
RFC6665. At the point of publication it used to reference RFC3265 but as new shiny 
car replaced the old one, it was requested to reference the new guy. Thus an issue 
is arising at 3gpp. 

 Shida

---

From: Andrew Allen <[email-masked]>
Date: Sun, 16 Mar 2014 22:15:11 +0000

I agree with Shida. I mispoke at the microphone at IETF#89 mixing up one 3GPP IETF dependency with another. Apologies for that.

But the fact remains 3GPP is in reality forced to upgrade to the latest versions ultimately as other RFC dependencies will suck in the latest versions of updated documents.

Also 3GPP has a basic principle in the current release  under development to incorporate the bug fixes found in earlier releases. In my view RFC 6665 is a collection of fixes from RFC 3265. 

What we need is to ensure that RFC 6665 mechanisms stiill work even when SBCs are in the way.

Andrew

----- Original Message -----
From: Shida Schubert [mailto:[email-masked]]
Sent: Sunday, March 16, 2014 05:44 PM Eastern Standard Time
To: Paul Kyzivat <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00

All;

 Shida

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 16 Mar 2014 18:47:28 -0400

> What we need is to ensure that RFC 6665 mechanisms stiill work even when SBCs are in the way.

I think you mean B2BUAs in general.

But anyway it will work, afaict - the B2BUA will use its own Contact, which if not a GRUU would force the UA to assume it's talking to a pre-6665 device and revert to normal behavior.

-hadriel

---

From: Andrew Allen <[email-masked]>
Date: Mon, 17 Mar 2014 00:54:33 +0000

Which totally defeats the main reason for RFC 6665!

In addition as I state in my draft modifying the Contact header field means either the media feature tags of the remote UA are lost or the B2BUA is saying if you send a request to this address (including potentially after this session has ended) you can expect that this feature is supported.

Having B2BUAs only include feature tags they understand to my view means no innovation and no new services. B2BUAs have then become the switches of old needing all to be updated or reconfigured to support any new services.

Andrew 

----- Original Message -----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Sunday, March 16, 2014 06:47 PM Eastern Standard Time
To: Andrew Allen
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00

-hadriel

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 17 Mar 2014 08:18:17 +0100

> Having B2BUAs only include feature tags they understand to my view means no innovation and no new services. B2BUAs have then become the switches of old needing all to be updated or reconfigured to…
Yes, that's Asterisk in a nutshell. 

/O

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Mar 2014 10:16:10 -0400

> Which totally defeats the main reason for RFC 6665!

Which would be...? What great feature does IMS get from it, exactly?

> Having B2BUAs only include feature tags they understand to my view means no innovation and no new services. B2BUAs have then become the switches of old needing all to be updated or reconfigured to…

Yup, and that's exactly the right thing to happen.  It's what most IMS operators actually should *want* to happen as well.

See here:
http://www.ietf.org/mail-archive/web/dispatch/current/msg05432.html

It's really not a bad thing to want service stability.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Mar 2014 10:21:49 -0400

I actually agree with much of what you say!!!

> You make it sound like replacing the Contact is a bug or bad idea - it isn't, it's what an SBC *should* do. It's what P-CSCF's should have done from the beginning too, for that matter. It's what ma…

I agree. If it doesn't include its own contact, then as I understand 
things it shouldn't be considered a UA/B2BUA. Rather it is just a 
misbehaving proxy.

> But again, that too is not a bug/bad-idea, it's what a B2BUA *should* do.  Having a B2BUA blindly pass-along UAC capabilities without knowing if the B2BUA itself supports them is just asking for things to break badly.

I agree here too.

> The downside is it means you have to either upgrade B2BUAs to support new features, or configure them to pass the feature caps that you know will work through them. That's the price you pay for using B2BUAs instead of real Proxies. (and let's not pretend a P-CSCF is a real Proxy)

This is the motivation for the e2e principle, and one of the key things 
that made the Internet a success compared to many other networking 
approaches.

SIP *could* have been made to work without this. We could argue about 
why it didn't shake out that way. (But there really isn't any point in 
doing so.) We see the pain that results from abandoning the e2e principle.

Still, it would be ok if there was a commitment to updating all those 
B2BUAs when they are found to break things, to eliminate the breakage. 
That means properly replicating all the features, such as making GRUUs 
and out of dialog requests work. ISTM the problem is that such updating 
isn't happening. Instead, those deploying such intermediaries seem to 
expect the endpoints to work around their foibles.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 19 Mar 2014 17:43:06 -0400

I move that we move the consideration of
draft-allen-dispatch-routing-out-of-dialog-request-00 (and
draft-kaplan-dispatch-gruu-problematic-00 as well) to the Sipcore
working group.  This will allow us to move the surrounding discussion
to the Sipcore mailing list, which is the technically correct place to
have it (since this is all about *getting your request to where it is
going*).

We need to properly consider these drafts in relationship to the
practical problems that have been described.  It is clear that there
is not yet a consensus on solutions, or the essential nature of the
observed problems.  And at least in my mind, we haven't even clearly
identified the crucial specifics of typical failure cases -- the
discussion has been carried out at a level of generality that (IMHO)
may mask diversity in the nature of the failure cases.

"Pure SIP" usages as envisioned by the early RFCs differ significantly
from a large part of deployed usage.  A good solution to these
problems needs to be aware of this, and will accommodate both
correctly, as well as *ensuring that the two interoperate correctly*.

The proper nature of the outcome can only be determined by further
discussion.  The existing drafts may be turned into RFCs describing
new mechanisms.  Alternatively, they may be revised into some sort of
Best Current Practices, or Poor Practices to be Avoided.  Perhaps it
will be determined that present practices are sufficient.

All in favor?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Mar 2014 12:24:53 -0400

Speaking as sipcore co-chair:

I agree that the sipcore mailing list is the appropriate place to have 
this discussion. (The issue is clearly a fundamental issue with SIP.)

At this point it is indeed just *discussion*. There has been no decision 
that there is need to define a deliverable regarding this. Discussion 
might lead to such a decision. In all likelihood, if we were to decide 
to do that it would fall within the scope of sipcore. But we can defer 
that decision, and if there is question we can then defer to dispatch.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Mar 2014 19:04:17 +0000

Hi,

If the delivery would be an SBC BCP document, I guess it could also be done in STRAW.

But, for now I agree that the discussion should be taken to SIPCORE, and then we'll figure out what (if anything) needs to be done.

Regards,

Christer
________________________________________
From: dispatch [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Thursday, 20 March 2014 6:24 PM
To: [email-masked]
Subject: Re: [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-00

        Thanks,
        Paul