Subject: Re: [sipcore] sipcore Digest, Vol 65, Issue 6

From: "Gottfried, Hal F" <[email-masked]>
Date: Tue, 12 Aug 2014 09:05:05 -0400

Unsubscribe

Regards:

Hal F. Gottfried / Sr Consultant, Contact Center Consulting & Services
Verizon Advanced Services - Consulting & Integration Services (ASCIS)
Mobile: 913-217-0994

-----Original Message-----
From: [email-masked] [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, August 12, 2014 08:53 AM Eastern Standard Time
To: [email-masked]
Subject: sipcore Digest, Vol 65, Issue 6

Send sipcore mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/sipcore
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of sipcore digest..."

Today's Topics:

   1. Re: Fwd: New Version Notification for
      draft-sparks-sipcore-refer-clarifications-03.txt (Andrew Allen)

----------------------------------------------------------------------

Message: 1
Date: Tue, 12 Aug 2014 12:52:57 +0000
From: Andrew Allen <[email-masked]>
To: Ivo Sedlacek <[email-masked]>, Robert Sparks
        <[email-masked]>, Adam Roach <[email-masked]>,
        "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] Fwd: New Version Notification for
        draft-sparks-sipcore-refer-clarifications-03.txt
Message-ID:
        <[email-masked]>
Content-Type: text/plain; charset="utf-8"

What reason would a UAC have such a restriction for some and not others?

Why would it be advantageous to  decrease interoperability in such situations?

Whether the REFER request is sent within or outside the dialog should be a UAC decision (if its RFC 3515 only compliant) and outside the dialog if is also RFC 6665 compliant.

Andrew

From: Ivo Sedlacek [mailto:[email-masked]]
Sent: Tuesday, August 12, 2014 3:24 AM
To: Robert Sparks; Andrew Allen; Adam Roach; [email-masked]
Subject: RE: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

Hello,

There still seems to be misunderstanding. Let me state my issue in a different and more general way:

If:
- a UE supports receiving and accepting of out-of-dialog REFER request related to dialogs created by some (but not all) INVITE requests; and
- for a particular INVITE request, the UA rejects any out-of-dialog REFERs related to dialogs created by the particular INVITE request;
should the UE be still mandated to put GRUU in the Contact of the particular INVITE request? If so, what will the GRUU be used for?

Please note that the question above focuses solely on out-of-dialog REFERs.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
From: Robert Sparks [mailto:[email-masked]]
Sent: 7. srpna 2014 19:55
To: Ivo Sedlacek; Andrew Allen; Adam Roach; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

I've spent quite some time trying to understand the push for the proposal below, and I really think there's confusion, so I'm going to try to step up a level and see if we can make progress there.

A UA such as your proposed exception clause describes is simply not a compliant 6665 implementation which is what this clarification document is about.
If it accepts in-dialog subscription creating REFERs it is following 3265, not 6665 - further it is violating a 6665 requirement.
If it accepts no REFERs whatsoever, then it's not affected by this document.

If the point of the wordsmithing is to make legacy implementations compliant with 6665, there's no way to succeed - they simply aren't.

If that's not the point of the wordsmithing, what is?

At the moment, I think what I sent below is still the right path forward.

RjS

On 8/1/14, 1:44 AM, Ivo Sedlacek wrote:
Any comments on the proposal below?

Kind regards

Ivo Sedlacek

   If a REFER request is accepted (that is, a 2xx class response is
   returned), the recipient MUST create a subscription and send
   notifications of the status of the refer as described in Section
   2.4.4.From: sipcore [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 31. ?ervence 2014 9:26
To: Robert Sparks; Andrew Allen; Adam Roach; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

Hello,

According to the draft, the purpose of GRUU in Contact of INVITE request to "
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA."

If a UA rejects any out-of-dialog REFER requests corresponding to any dialogs related to an INVITE request, then setting up GRUU in Contact of INVITE does not provide any purpose.

This is true __regardless__ whether the UA supports and use the draft-sparks-sipcore-refer-explicitsub.
See attached mail giving an example of UA having two types of sessions, Type_A transferrable by REFER, and Type_B not transferrable by REFER.
Given that different standardization organization has defined so many enablers which can run on a single UA, I find it weird that one can guarantee that the above cannot occur.

Thus, I hesitate to mandate an unnecessary requirement influencing possible existing UA implementations and I prefer to be explicit on the exception for usage of GRUU in Contact of INVITE request:

   A UA that will accept a REFER request needs to include

   a GRUU in the Contact header field of all INVITE requests.  This

   ensures that out-of-dialog REFER requests corresponding to any

   resulting INVITE dialogs arrive at this UA. >>>UAs that will not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE request

   are exempted from including a GRUU in the Contact header field of the INVITE request.<<<

Kind regards

Ivo Sedlacek

From: Robert Sparks [mailto:[email-masked]]
Sent: 30. ?ervence 2014 18:54
To: Andrew Allen; Adam Roach; Ivo Sedlacek; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

On 7/30/14, 10:33 AM, Andrew Allen wrote:
I have a general concern with the direction this is now going.
I don't think you have the backwards-compatibility concern quite right, but I agree that the current wording isn't there yet.

Are we now saying here that it?s OK for a UA that supports receiving REFER to arbitrarily reject any REFER that would create a subscription (i.e be incompatible with RFC 3515 UACs by basically not supporting RFC 3515 UAS compliant behavior)?
No, _this_ document is not defining new behavior. It's only clarifying what's already defined.

According to RFC 3515

2.4.4 Using SIP Events to Report the Results of the Reference

                The NOTIFY mechanism defined in [2] MUST be used to inform the agent sending the REFER of the status of the reference.

Therefore the ability to create an implicit subscription when accepting
FWIW, Accepting is the key word here.
a REFER is mandatory behavior in RFC 3515 and is expected to be supported by all RFC 3515 UACs

I think before agreeing any wording here we should have a general discussion on the principle of whether these extensions that allow UACs to request that no implicit subscription can be effectively required by REFER UAS to be supported at the UAC.
This, and what you have below, is a discussion we definitely need to have as part of the extension document.
It is not necessary to wait for that discussion to complete the clarifications document that talks about what the specs say _now_.

My discomfort with the current text is that we've made it complex to make it so that we don't have to update the document once the proposed extensions exist.
There are NO currently standardized cases where the exemption in the current text would be invoked, and I don't think people are trying to argue there are - I'm hearing that to get there, they expect to invoke the yet-to-be-defined extension.

So, lets go back to the slightly longer sentence that led to this:

A UA that will accept a subscription-creating REFER request needs to include
a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER requests
related to any dialog created by the INVITE arrive at this UA.

In an attempt to be future-proof, that's introducing the potential for confusion about what the current standards define.
Let's remove that confusion.
Here's a proposed replacement, taking Adam's sentence simplification into account:

   A UA that will accept a REFER request needs to include
   a GRUU in the Contact header field of all INVITE requests.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA. Future extensions
   [draft-sparks-sipcore-refer-explicitsub] might relax this requirement
   by defining a REFER request that cannot create an implicit subscription.

Unless I hear objection soon, I'll rev the draft with that content.

If so then I think we will need a new sip options tag (e.g REFER-NOSUB) to be used in place of the REFER options tag so that a RFC 3515 compliant UA that expects a NOTIFY to be sent upon receipt of a REFER and that includes an Accept-Contact request to reach a UA that supports REFER doesn?t end up at a UAS that doesn?t  support compliant RFC 3515 behavior and ends up having its REFER requests rejected.

My own view is that we should keep with the principle of backward compatibility and that even when these no automatic subscription extensions are supported that full support for RFC 3515 behavior is continued.

Andrew

From: sipcore [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, July 29, 2014 11:19 AM
To: Ivo Sedlacek; Robert Sparks; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

On 7/29/14 09:52, Ivo Sedlacek wrote:

Thus, the text should state:

   In general, UAs that support receiving >>and accepting an out-of-dialog<< REFER request >>corresponding to a dialog established by an INVITE request<< need to include
   a GRUU in the Contact header field of >>the<< INVITE request.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs are routed to the correct user agent.  UAs
   that will never create a implicit subscription in response to a REFER
   (that is, those that will reject any REFER that might result in an
   implicit subscription) are exempted from this behavior.

I helped with the phrasing here, and one of the goals here was to make the first sentence cover the vast majority of the cases (hence "in general"), with the exceptional cases described later. The problem was that the overall concept was getting lost in a maze of twisty clauses: the clarification had become worse than the source text; it was actually more confusing.

Your proposal returns it to this very confusing state, and is way, way out into the realm of exceptional cases.

So I'll counterpropose:

   In general, UAs that support receiving REFER requests need to include

   a GRUU in the Contact header field of all INVITE requests.  This

   ensures that out-of-dialog REFER requests corresponding to any

   resulting INVITE dialogs are routed to the correct user agent.  UAs

   that will not create a implicit subscription in response to a REFER

   for the resulting dialog(s) -- that is, those that will reject a

   corresponding REFER that might result in an implicit subscription --

   are exempted from this behavior.

/a

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/sipcore/attachments/20140812/84659a10/attachment.html>

------------------------------

Subject: Digest Footer

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

------------------------------

End of sipcore Digest, Vol 65, Issue 6
**************************************