Subject: [sipcore] Question regarding use of single NOTIFY by RFC3515

From: <[email-masked]>
Date: Tue, 12 Nov 2013 18:46:59 +0000

Hi folks,

I have a question because IMO there is a kind of gap in RFC 3515 for the following particular use case:
RFC3515 makes the NOTIFY as mandatory to execute a REFER transaction (because of the implicit subscription).
To end this subscription it is expected to receive a NOTIFY with “Subscription-State: terminated” with a reason of "noresource".
The NOTIFY contains a body of type message/sipfrag and the status of the referred action (eg. 100 Trying, 200 OK…)
And in the meantime, agents accepting REFER and not wishing to hold subscription state can terminate the subscription with the initial NOTIFY. 
So finally, if an agent wants to end the subscription with this initial/final NOTIFY it should send a NOTIFY with a subscription-state “terminated”, a reason “noresource” and a 100 TRYING body. 

Could you confirm this analysis because it sound inconsistent to have a “final” NOTIFY with a 100 Trying body?

In the standard there is neither an example of a NOTIFY (100 TRYING) with a subscription-state “terminated” and a reason “noresource”, nor it is stated that it is forbidden…

Here are some extracts from RFC3515:

In 2.4.4
"The creation of a subscription as defined by [2] always results in an immediate NOTIFY."
[…]
“Note that agents accepting REFER and not wishing to hold subscription state can terminate the subscription with this initial NOTIFY.”

In 2.4.5
“If a NOTIFY is generated when the subscription state is pending, its body should consist only of a status line containing a response code of 100.”

In 2.4.7
“Each NOTIFY must contain a Subscription-State header field as defined in [2].  The final NOTIFY sent in response to a REFER MUST indicate the subscription has been "terminated" with a reason of "noresource". (The resource being subscribed to is the state of the referenced request).”

In 3.4
“As described in Section 2.4.7, the agent accepting the REFER will terminate the subscription when it reports the final result of the reference, indicating that termination in the Subscription-State header field.”

If you can give me your opinion.

Best Regards,
Marianne Mohali

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 12 Nov 2013 14:25:01 -0600

> Could you confirm this analysis because it sound inconsistent to have a “final” NOTIFY with a 100 Trying body?
This is a reasonable body to send.

The point is saying the best you can about the referred action when you 
have to say something.
The primary thing you want to do is avoid saying "this failed".

Since you aren't going to tell the other end whether the referenced 
action succeeded or not (or if you even are really going to try, though
you've said some of that by accepting the REFER), you might as well send 
a 200 OK in the sipfrag. You're already cutting off the opportunity
to do anything to recover if it fails.

But a 100 Trying is in the spirit and letter of the text.
I have no idea how well it would be received by the current 
implementation base.

RjS

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 13 Nov 2013 16:22:10 -0500 (EST)

> From: <[email-masked]>
> 

> To end this subscription it is expected to receive a NOTIFY with
> "Subscription-State: terminated" with a reason of "noresource".

> The NOTIFY contains a body of type message/sipfrag and the status of
> the referred action (eg. 100 Trying, 200 OK...)

> And in the meantime, agents accepting REFER and not wishing to hold
> subscription state can terminate the subscription with the initial
> NOTIFY. 

I suppose that the agent could do that, but it seems to me that is not
strictly conformant to RFC 3515.  The subscription is supposed to
continue until it delivers the final response to the generated INVITE.

> So finally, if an agent wants to end the subscription with this
> initial/final NOTIFY it should send a NOTIFY with a
> subscription-state "terminated", a reason "noresource" and a 100
> TRYING body. 

That probably would work in practice, but if a transferor (the sender
of the REFER) is designed to take some action based on receiving the
NOTIFY containing the final response to the generated INVITE, then if
the agent does not report that final response, the transferor might
not behave in the best manner.

Dale

---

From: <[email-masked]>
Date: Thu, 14 Nov 2013 17:28:08 +0000

Thank you Dale and Robert,

You confirm my feeling and understanding of RFC3515 which is to distinguish the notification process status (related to the subscription) and the Transfer progress status (related to SIP responses).

Obviously we are not in flavor of this behavior as we prefer to have a full feedback on REFER request but we meet an AS vendor doing this early ending and I would like to be sure of my understanding of their implementation.

Marianne

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dale R. Worley
Envoyé : mercredi 13 novembre 2013 22:22
À : [email-masked]
Objet : Re: [sipcore] Question regarding use of single NOTIFY by RFC3515

> subscription state can terminate the subscription with the initial 

I suppose that the agent could do that, but it seems to me that is not strictly conformant to RFC 3515.  The subscription is supposed to continue until it delivers the final response to the generated INVITE.

> initial/final NOTIFY it should send a NOTIFY with a subscription-state 
> "terminated", a reason "noresource" and a 100 TRYING body.

That probably would work in practice, but if a transferor (the sender of the REFER) is designed to take some action based on receiving the NOTIFY containing the final response to the generated INVITE, then if the agent does not report that final response, the transferor might not behave in the best manner.

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

---

From: Brett Tate <[email-masked]>
Date: Thu, 14 Nov 2013 17:40:07 +0000

> I suppose that the agent could do that, but it seems 
> to me that is not strictly conformant to RFC 3515.  
> The subscription is supposed to continue until it 
> delivers the final response to the generated INVITE.

RFC 3515 section 2.4.5 describes the behavior as "minimal, but complete".

"A minimal, but complete, implementation can respond with a single
 NOTIFY containing either the body:

      SIP/2.0 100 Trying

   if the subscription is pending, the body:

      SIP/2.0 200 OK

   if the reference was successful, the body:

      SIP/2.0 503 Service Unavailable

   if the reference failed, or the body:

      SIP/2.0 603 Declined"

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 14 Nov 2013 14:12:14 -0500 (EST)

> From: Brett Tate <[email-masked]>
> 
[adding the remainder of the sentence in RFC 3515:]
   if the REFER request was accepted before approval to follow the
   reference could be obtained and that approval was subsequently denied
   (see Section 2.4.7).

I hadn't remembered that section.

In the ordinary cases, the choice described in 2.4.5 would be between
the second and the third example responses, because the subscription
would never be pending (the UA would grant it without user approval)
and user approval of following the REFER would also not be needed.

Which means that section 2.4.5 essentially says that a minimal but
complete implementation would provide one NOTIFY, containing either a
sipfrag with a success response code or a sipfrag with a failure
response code.  This leads back to the idea that the subscription must
continue until it can report either success or failure.

Normally a prompt NOTIFY is required upon establishment of a
subscription, but I suppose that is only if it is established via a
SUBSCRIBE.  Looking at RFC 6665 section 4.2 more or less supports
that.

Dale

---

From: Brett Tate <[email-masked]>
Date: Thu, 14 Nov 2013 20:11:26 +0000

Hi Dale,

It sounds like we disagree about RFC 3515 allowing a single NOTIFY to both terminate the subscription and communicate a 100 Trying body.  In my opinion, the 100 Trying body sounds appropriate for the following NOTIFY since all of the other response codes would be misleading concerning the "status of the referred action".

Section 2.4.4:

"Note that agents accepting REFER and not wishing to hold
 subscription state can terminate the subscription with this initial
 NOTIFY."

Similarly, we disagree about how to interpret section 2.4.5's "if the subscription is pending".  My interpretation is that it indicates that the NOTIFY has not been sent instead of that the NOTIFY's Subscription-State header would indicate "pending".  As the section 4 examples indicate, the 100 Trying is not limited to Subscription-State "pending".

Thanks,
Brett

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 15 Nov 2013 14:23:09 -0500 (EST)

>  subscription state can terminate the subscription with this initial

That sentence settles what I see as the main question:  The receiver
of the REFER is allowed to send one NOTIFY, promptly, that terminates
the "refer" subscription.  I had not known that that was allowed under
a strict reading of the RFC.  I had assumed that the notifier was
required to maintain the subscription until the reference succeeded or
failed.

There is a secondary question of whether the notifier is required to
send a NOTIFY immediately.  The procedures in 3265 only describe that
when a SUBSCRIBE is received, a NOTIFY must be sent promptly.  In RFC
3515 section 2.4.4 is:

   The creation of a subscription as defined by [2] always results in an
   immediate NOTIFY.  Analogous to the case for SUBSCRIBE described in
   that document, the agent that issued the REFER MUST be prepared to
   receive a NOTIFY before the REFER transaction completes.

Unfortunately, the wording of the first sentence can be interpreted as
the "creation of a subscription as defined by RFC 3265", that is, by
means of SUBSCRIBE, "always results in an immediate NOTIFY" -- which
doesn't speak to our question.  But later text:

   The duration
   of the subscription is chosen by the agent accepting the REFER and is
   communicated to the agent sending the REFER in the subscription's
   initial NOTIFY (using the Subscription-State expires header
   parameter).

presupposes that there will be a prompt NOTIFY, so it seems that RFC
3515 prescribes that the notifier will send a NOTIFY promptly after
reveiving a REFER.

It's clear from the discussion in RFC 3515 that a body of "100 Trying"
is the correct body to use if the notifier has not yet received a
response to the generated INVITE (perhaps not even having sent it yet).

> It sounds like we disagree about RFC 3515 allowing a single NOTIFY
> to both terminate the subscription and communicate a 100 Trying
> body.

Once it's agreed that the notifier can send a NOTIFY promptly that
terminates the subscription, it's clear that "100 Trying" is the
body to use (unless another response has been received).

> Similarly, we disagree about how to interpret section 2.4.5's "if
> the subscription is pending".  My interpretation is that it
> indicates that the NOTIFY has not been sent instead of that the
---------------------^
I think you mean "INVITE" here.
> NOTIFY's Subscription-State header would indicate "pending".  As the
> section 4 examples indicate, the 100 Trying is not limited to
> Subscription-State "pending".

To recap, the text in question starts:

   A minimal, but complete, implementation can respond with a single
   NOTIFY containing either the body:

      SIP/2.0 100 Trying

   if the subscription is pending, [additional cases follow]

It's a good question.  Given that "pending" is a technical term
regarding subscriptions, I believe that the intention of this clause
is that if the subscription is pending (that is, if the user needs to
approve and has not yet), then "100 Trying" should be used as a
"neutral" body value.  And that's what the preceding paragraph says:

   If a NOTIFY is generated when the subscription state is pending, its
   body should consist only of a status line containing a response code
   of 100.

What you're raising is a case that isn't handled in the text in
question.  What is really wanted is for it to state "the body 'SIP/2.0
100 Trying' if the reference is pending".

Dale