Re: [dispatch] Revised version of draft-allen-dispatch-routing-out-of-dialog-request

Paul

Thanks for the review.

Responses inline

Andrew

-----Original Message-----
From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Wednesday, February 18, 2015 12:58 PM
To: dispatch@ietf.org
Subject: Re: [dispatch] Revised version of draft-allen-dispatch-routing-out-of-dialog-request

Andrew,

This draft proposes new mechanism(s) intended to mitigate problems caused by certain types of B2BUA intermediaries.

My biggest problem with this draft is that it makes assumptions about how such intermediaries function. Those assumptions are not well specified.

The way sip deployments have evolved we now have a very complex ecosystem of components interconnected by SIP, with some of their behavior defined by the various ietf SIP standards, and some of it defined by 3gpp specifications, and some by a multitude of proprietary mechanisms. Most of this is dependent on "clever" manipulations by devices loosely described in ietf terms as B2BUAs, but that in practice take license with the few standards governing B2BUA, taking the view that they can break rules features when it suits them.

The result is a complex architecture that isn't written down anywhere I know of.

For awhile now we have been getting proposals for new features and extensions to existing features to fix things that have been broken by that architecture. (RFC6809 is one, your draft is another.) Each of these propose a "patch". But this seems to be just patching around the edges without any clear understanding of how many (if any) problems are being addressed.

I think you must be much more explicit about your assumptions. (E.g., I suspect you have 3gpp intermediaries in mind. Do those assumptions also apply to business systems such as Cisco deploys, that also employ B2BUA
intermediaries?) Those who aren't deeply steeped in 3gpp specs don't know what those intermediaries do.

[AA] The draft is not intended to solve all problems that SBCs or other intermediaries may cause. It is only intended to provide a tool to cause requests to be routed via certain nodes that may need to receive them when previously those nodes received them because of Record-Route and dialog reuse (which has now been deprecated by RFC 6665). I can add some specific examples of some of the behaviors in 3GPP land that have problems without dialog reuse.

Now for some more specific points:

* Are the intermediaries you are concerned with all B2BUAs? Or could proxies also have such needs?

[AA] Potentially proxies also might want to force related requests (such as REFER and SUBSCRIBE ) to also go by them - one reason might be charging. i.e. the request would not be charged for separately if it is related to an existing session.

* I'm confused when you talk about these B2BUAs "even terminating the dialog for some mid session requests", as if that was extraordinary. 
AFAIK a B2BUA by definition terminates *all* requests and dialogs that reach it. Else it isn't a UA. Of course it may, usually, originate a corresponding request or dialog on the other "side". (For some types of B2BUA it may be unusual when it processes an incoming request in some way other than originating a corresponding request.) If you have a different view of this, then I think we are not talking about a true B2BUA, but rather something that has no formal definition in SIP.

[AA] My bad terminology.  What I mean here is that the intermediary may act as a UAS for the request and not forward it on (e.g. service the REFER on behalf of the intended recipient such as perform the transfer). I will change this terminology in the next version.

* In section 2 you say:

    One way B2BUAs have have addressed this problem is by acting as two
    UAs back-to-back with the Contact URI being overwritten to be the URI
    of the B2BUA.  However this means that GRUU of the UA is overwritten
    by the B2BUA and the meaning of the Contact header field parameters
    becomes obscure.  Do the Contact header field parameters reflect the
    capabilities of the Contact address (i.e the B2BUA) or do they
    reflect the capabilities of the remote UA?  If they relect the
    capabilities of the B2BUA then the identfication of the capabilities
    of the remote UAS has been lost.  If they reflect the capabilities of
    the remote UA then they falsely identify that the B2BUA contact
    address has the capabilities of the remote UA.  While some have
    advocated that a B2BUA should only indicate the capabilities that it
    understands and supports in the Contact, in the opinion of the author
    this is not desirable behavior because the feature tags may indicate
    many kinds of capabilities which do not require the support of the
    intermediary.  ...

They may not require the active *support* of the intermediary. But they likely do still require that intermediaries don't impede them. And this does happen. Without rules on what intermediaries can do there is no way to know in a general way if an arbitrary feature will work in the presence of a particular intermediary.

[AA] If an intermediary does block a particular feature that it understands then it is appropriate for it to indicate that it does not allow that feature. However I would hope that most intermediaries don't block everything they don't understand as that destroys the creation of new features and services. The feature capability indicator is IMHO a better mechanism for an intermediary to indicate what features it supports / allows than monkeying with the Contact. The Contact conveys important end to end information and information that should be valid outside of that dialog or that session. Feature tags like sip.automata, sip.class, sip.duplex, sip.mobility, sip.description, sip.priority, sip.actor and sip.isfocus are characteristics of the remote UA and an intermediary has no business changing those. B2BUAs changing the contact potentially breaks all that.

ISTM that if an intermediary imposes itself as a B2BUA in a dialog, and makes any claim to being "transparent" (like a proxy), then it is obligated to do whatever is necessary to make itself transparent. In many/most cases that will likely involve introducing its own Contact addresses. If an incoming Contact address is a gruu, then the surrogate contact address used by the intermediary should also have the gruu property. Feature tags can be "forwarded" to the extent that the intermediary knows that its presence won't break them. (If it *really* thinks it can be transparent to features it knows nothing about, then it can simply forward on unknown ones.)

[AA] I disagree. I think its bad practice for intermediaries to change the contact address and lose the contact information of the remote UA. This information including the GRUU of the remote UA ought to be valid outside of this dialog or session. Having an intermediary mislead a UA into thinking that the intermediaries GRUU is the GRUU of the remote UA to me goes against the basic openness principle as well as meaning the UA can never learn the GRUU of the remote UA. 

This does impose a maintenance burden on those that deploy such intermediaries, to ensure that they support everything needed by their endpoints. But that is the unavoidable cost of using such things. (You can make your life easier by using proxies rather than B2BUAs.)

[AA] I don't like SBCs either but they do exist and we need to make sure that things work with them - at the very least things that used to work pre RFC 6665 without losing the benefits or fixes that RFC 6665 was intended to bring.

* next the draft says:

    ... In the opinion of the
    author the feature capability indicator mechanism defined in RFC 6809
    [2] is the appropriate means for an intermediary to indicate the
    capabilities that it supports and will allow.

While this is consistent with RFC 6809 I fail to see how it has anything to do with the the problem stated in *this* draft. Feature-Caps indicates features that are present somewhere along the path of the current dialog. It doesn't, by default, even indicate which intermediary provides the service. While some feature-tags may include a URI as part of their value, that URI doesn't necessarily refer to an entity that is on the path of the current dialog.

[AA] What I am arguing is that intermediaries shouldn't change the contact address and that there is another means to indicate what capabilities such as media capabilities that may be required to be supported by intermediaries for certain sessions to succeed.

* next:

    ... It also should be
    recognised that UAs may store Contact addresses especially if they
    are GRUUs for use later for originating sessions (e.g. stored in the
    address book) or for filtering incoming sessions (e.g. incoming
    sessions addressed to temporary GRUUs).  So if the Contact address is
    overwritten then this information is lost or not valid as a contact
    outside the lifetime of the current dialog.

Does anybody really put Contacts into address books? I'd be shocked if they were. I bet it is always To/From/P-A-ID that ends up in address books.

[AA] Since GRUU has not yet been widely deployed probably not currently. But if we get widespread deployment of GRUU then I think it is a perfectly reasonable thing to do to store the GRUUs in an address book. Currently we have different URIs for different devices: Mobile, Work, Home, Fax, IM client etc. In the future hopefully we can have a single URI for the user. Public GRUUs can then identify each device for the times a user wants to reach a user at a particular device. The "call me back in 5 minutes at this number" isn't very helpful when all the devices of the user share the same URI. Saving the Public GRUU is one way to reach the user at a particular device. Also temporary GRUUs can allow for a later call back but allow the user to decide if they want to accept an anonymous call back to the temporary GRUU they provided in an earlier anonymous call.i.e. they placed an anonymous call to an merchant and now the merchant is calling them back (however they already made the purchase from someone else so they don't want to accept the call anymore). If intermediaries overwrite the Contact Address then all these capabilities are lost.

* next:

    ... Additionally the
    mechanism defined in RFC 6665 [3] depends on the UA receiving a GRUU
    as the remote target in order to avoid dialog reuse, so overwriting
    the Contact Address breaks this mechanism.

So when a B2BUA replaces the Contact, the replacement should have the gruu property. Why is this a problem for RFC 6665 compatibility?

[AA] I suspect that the SBCs are not replacing a GRUU with another GRUU. Based on a comment from Hadriel on an earlier version of the draft most SBCs will likely replace the GRUU with a non GRUU especially now that dialog reuse is deprecated for the case when the UA has received a GRUU as the remote target. Without an alternative mechanism that makes it possible for intermediaries to indicate that REFER and SUBSCRIBE which previously visited them through dialog reuse are still to be routed via them, then intermediaries will continue to force dialog reuse by replacing GRUUs in the contact with non GRUUs (at least not with the gr parameter.

* IIUC, the intent is that when a UA is in a dialog, and wishes to send an out of dialog request that refers to that dialog, must take special steps to make that work: extract the special route from the dialog and incorporate it into the out of dialog request.

[AA] In the case of REFER and SUBSCRIBE with RFC 6665 it's no longer wishes to send out of dialog it is MUST send out of dialog if the remote target is a GRUU and a subscription could be created.

What criterion does the UA use to decide when to do this? Is it the presence of certain header fields in the request? (Replaces, Join, Target-Dialog). Is that well defined and exhaustive?

[AA] At least if it previously would have sent a REFER or SUBSCRIBE within the dialog. Probably a good idea to do this for all session related REFER requests.

What about cases where the client referencing an existing dialog already in that dialog? For instance, a client using the dialog event package to discover an existing dialog and then sending a request to replace it. 
IDoes that client need to know about the intermediaries? If so, how would it learn, and what if it doesn't?

[AA] My intention isn't to solve all problems caused by SBCs and other B2BUAs. The primary goal is to make the out of dialog REFER and SUBSCRIBE as required by RFC 6665 work (because they used to work in dialog). Other drafts could be written to solve other issues. I suppose the dialog events package could be extended to provide also the route set that established the dialog (which would the contain the OOD route indicator as well and then the request sent to replace it could be routed via those intermediaries.

Many clients, when sending out of dialog requests, already have a Route header to apply to that request. (E.g., via Service-Route.) How should the URIs of these interested intermediaries be sorted into that predefined route?

[AA] I agree any solutions draft will need to address this. Any intermediaries that need to be routed via are after the Service-Route  (ones in the Service-Route don't need to indicate OOD as they are already in the Route set. The Service Route ensures routing via intermediaries as far as the serving network of the UA the problem is intermediaries after the serving network of the UA.

	Thanks,
	Paul

On 2/17/15 10:39 PM, Andrew Allen wrote:
> I have submitted a revised version of draft-allen-dispatch-routing-out-of-dialog-request. This document discusses the problems for out of dialog requests that are related to another dialog, caused by B2BUA intermediaries that modify SIP parameters or terminate dialogs and proposes some possible solutions. This draft is related to the recent work on RFC 6665 that deprecates dialog reuse when creating subscriptions using SUBSCRIBE and REFER.
>
>
>
> I would like to request discussion time during Dispatch at IETF#92. Earlier list discussion indicated that either sipcore or STRAW would be the appropriate place to work on solutions to this issue.
>
>
>
> The draft can be found at:
>
>
>
> http://www.ietf.org/id/draft-allen-dispatch-routing-out-of-dialog-requ
> est-01.txt
>
> Please provide comments on the contents and on which WG would be an 
> appropriate for the work.
>
> Andrew
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch