[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   SIPPING
   Internet Draft                                         S. Parameswar
   Document: draft-parameswar-sipping-norefersub-00.txt
   Expires: April 2003                                     October 2002


                  Suppressing Refer Implicit Subscription


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.



Abstract

   The recipient of the REFER method [1] creates an implicit
   subscription to the 'refer' event. This subscription causes the REFER
   recipient to send NOTIFY messages to the sender informing him of the
   progress of the REFER. This memo provides for the requirements and
   one potential mechanism to suppress the creation of this implicit
   subscription, via an option tag - 'norefersub'. This gives the agent
   sending the REFER control over the creation of the subscription,
   while being backwards compatible with [1].


Conventions used in this document


   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.




Parameswar               Expires - April 2003                 [Page 1]

               Suppressing Refer Implicit Subscription   October 2002


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [2].

   This document uses the terms "referor" for the UA that sends the
   REFER method, and "referee" for the receiving agent.

Table of Contents

   1. Introduction...................................................2
      1.1 Implicit subscription in REFER.............................2
   2. Suppressing Implicit subscriptions.............................3
      2.1 Requirements for suppression of Implicit subscriptions.....4
   3. Potential mechanisms...........................................4
      3.1 Immediate Un-subscription..................................4
      3.2 New Option Tag.............................................5
   4. Usage of the 'norefersub' tag..................................6
      4.1 UAS (referee) behavior.....................................6
      4.2 UAC (referor) behavior.....................................7
   5. IANA Registration of the 'norefersub' Option Tag...............7
   Security Considerations...........................................8
   References........................................................8
   Acknowledgments...................................................8
   Author's Addresses................................................8


1. Introduction

   RFC 3265 [2] allows for non-SUBSCRIBE mechanisms to create
   subscriptions, these are popularly called Implicit subscriptions.
   This mechanism is used in [1] to create an implicit subscription when
   a REFER method is received by a UA. The UA responds with an immediate
   NOTIFY, and may send further NOTIFYs describing the progress till the
   subscription expires.

   The referor has no control over the creation of the subscription.
   There has also been some acknowledgement that the implicit
   subscription mechanism is not desirable. This memo defines a
   mechanism to allow the referor control over the creation of the
   implicit subscription caused by sending the REFER to the referee.

1.1 Implicit subscription in REFER

   Figure 1 below, shows a typical scenario. The REFER (F1) from the
   referor causes an implicit subscription to be created at the referee.
   The immediate NOTIFY (F3) is required as stated in RFC 3265[2] and
   provides the state of the subscription and the status associated with
   the event. This is followed by one or more NOTIFY messages describing



Parameswar               Expires - April 2003                 [Page 2]

               Suppressing Refer Implicit Subscription   October 2002


   the progresss, till the expiry of the subscription - as indicated by
   the Subscription-State header in the final NOTIFY.


   |  F1 REFER             |
   |---------------------->| Implicit Subscription
   |                       |
   |  F2 202 Accepted      |
   |<----------------------|
   |                       |
   |  F3 NOTIFY            |
   |<----------------------| Immediate NOTIFY
   |                       |
   |  F4 200 OK            |
   |---------------------->|
   |                       |--------->
   |                       |(whatever)
   |                       |<--------
   |  F5 NOTIFY            |
   |<----------------------| One or more NOTIFYs
   |                       |
   |  F6 200 OK            |                 |
   |<----------------------|

   Figure 1. Implicit subscription caused by REFER

2. Suppressing Implicit subscriptions

   As can be seen from Figure 1, the referor is neither in control of
   the creation of the implicit subscripton on its behalf, nor of the
   number and rate of NOTIFYs. The matter of rate and number of NOTIFYs
   may be handled by subscription filters carried in the payload of the
   REFER method. It must be noted that this topic of subscription
   filters is a subject of ongoing work. In the case of implicit
   subscription as it stands today, the referee is in complete control.

   In addition to the referor control of subscription, there are also
   some applications that may not need an implicit subscription to be
   created, either because the referor does not care or the Refer-To
   resource does not lend itself to providing a notion of success or
   failure. An example is discussed below to provide a use case:

   Web-push: The REFER method may be used to push web pages for example
   the Refer-To header may carry the address http://www.example.com. In
   this case the referee may not wish to browse the pushed page
   immediately and a NOTIFY may be delayed or not forthcoming.

   Attended Transfers: This is a weaker example -                                                - but when applied to an
   enterprise setting where all parties are served off the same


Parameswar               Expires - April 2003                 [Page 3]

               Suppressing Refer Implicit Subscription   October 2002


   proxy/registrar, the need to suppress implicit subscription exists.
   In an attended transfer scenario the transferor [4] first informs the
   transfer target of the impending transfer prior to completing the
   action. In such cases the transferor is reasonably sure that the
   REFER will succeed (transfer target contacted and ready, etc.) and
   the notification may not be required.

   It must also be noted that control of implicit subscriptions provides
   the opportunity to provide differentiated services. For example, a
   service provider may offer Basic Transfer and Enhanced Transfer with
   Status Notification.

2.1 Requirements for suppression of Implicit subscriptions

   This section looks at the requirements for the suppression of
   implicit subscriptions caused by REFER. These formally address the
   requirements that were laid out in Section 2 in an anecdotal fashion.

   1. Referor-control-req: The referor (party initiating the REFER
   method) MUST be able to control creation of the implicit
   subscription. This provides the referor the ability to create or
   suppress the implicit subscription.

   2. Session-integrity-req: In the case where the referee (party
   receiving the REFER method) chooses to, or does not support the
   suppression of implicit subscription, the session MUST not be
   affected. This allows the referor to retry the REFER based on the
   ability or choice of the referee.

   3. Backwards-compatability-req: Any mechanism that provides for
   suppression of implicit subscriptions MUST be backwardly compatible.

   4. Simplicity-req: The mechanism MUST be easy to implement. As such
   mechanisms that use existing SIP functionality are preferred.

   5. Congestion-limitation-req: Any mechanism that provides for
   suppression of implicit subscriptions SHOULD NOT create additional
   signaling burden on the network.

3. Potential mechanisms

   This section details a couple of potential mechanisms to suppress
   implicit subscriptions. Each of these mechanisms are discussed in
   light of the requirements in Section 2.1.

3.1 Immediate Un-subscription





Parameswar               Expires - April 2003                 [Page 4]

               Suppressing Refer Implicit Subscription   October 2002


   This section takes a look at immediately un-subscribing, following
   the first NOTIFY as an alternate to suppressing the implicit
   subscription mechanism.

   This is depicted in Figure 2. The REFER (F1) from the referor creates
   an implicit subscription. This causes the referee to generate an
   immediate NOTIFY (F3) after sending an acknowledgement to the REFER
   (F2). The referor not wanting further notification simply sends a 481
   "Subscription terminated" (F4) as per Section 3.2.2. 'Notifier NOTIFY
   Behavior' of RFC 3265[2]. The 481 terminates the subscription and the
   referee will send no further NOTIFYs.

   However this does not create full control over the implicit
   subscription and is a waste of bandwidth - which is important in
   bandwidth-constrained environments such as wireless, low-speed dialup
   etc.

   |  F1 REFER             |
   |---------------------->| Implicit Subscription
   |                       |
   |  F2 202 Accepted      |
   |<----------------------|
   |                       |
   |  F3 NOTIFY            |
   |<----------------------| Immediate NOTIFY
   |                       |
   |  F4 481 Sub Terminated|
   |---------------------->|
   |                       |--------->
   |                       |(whatever)
   |                       |<--------

   Figure 2. Un-subscribing after immediate NOTIFY

   This option does not meet all the requirements laid out in Section
   2.1. The fact that the referor receives a NOTIFY and has to send a
   481 violates the Referor-control-req and Congestion-limitation-req.

3.2 New Option Tag

   Given the discussion above - the author feels that there is definite
   value to being able to suppress implicit subscription in the case of
   the REFER message. This takes the form of a new option-tag
   "norefersub". In the simplest case the option-tag is sent in a
   Require header from the referor to the referee in a REFER message.

   Example usage:

         Required: norefersub


Parameswar               Expires - April 2003                 [Page 5]

               Suppressing Refer Implicit Subscription   October 2002


         Supported: norefersub
         Unsupported: norefersub

   This option-tag may be applied as described in [3]. This memo
   discusses its use in the REFER method and 2xx messages that
   acknowledge the REFER method.

   This mechanism meets all the requirements laid out in Section 2.1.
   The use of this mechanism is backwards compatible; in the absence of
   this option-tag the original REFER behavior will result i.e. the
   implicit subscription is created. This mechanism does not result in
   additional signaling burden on the network.

4. Usage of the 'norefersub' tag

   A simple example of the use of the 'norefersub' tag is shown in
   Figure 3. The REFER (F1) carries this tag in the Require header, this
   causes the suppression of the implicit subscription.

   |  F1 REFER             | Require: norefersub
   |---------------------->|
   |                       |
   |  F2 202 Accepted      |
   |<----------------------| Implicit subscription is suppressed.
   |                       |
   |                       |--------->
   |                       |(whatever)
   |                       |<--------

   Figure 3. Using the option-tag 'norefersub'

         Message One (F1)
          REFER sip:b@agentland SIP/2.0
          Via: SIP/2.0/UDP agenta.agentland;branch=z9hG4bK2293940223
          To: <sip:b@agentland>
          From: <sip:a@agentland>;tag=193402342
          Call-ID: 898234234@agenta.agentland
          CSeq: 93809823 REFER
          Max-Forwards: 70
          Refer-To: (whatever URI)
          Require: norefersub
          Contact: sip:a@agentland
          Content-Length: 0

4.1 UAS (referee) behavior

   The UAS MUST suppress implicit subscriptions if the REFER request
   contained a Require header field with the option tag 'norefersub'.



Parameswar               Expires - April 2003                 [Page 6]

               Suppressing Refer Implicit Subscription   October 2002


   If the UAS is unwilling to do so, it MUST reject the REFER request
   with a 420 (Bad Extension) and include an Unsupported header field
   containing the option tag 'norefersub'.

   If the REFER contained a Supported header with the option tag
   'norefersub', the UAS (referee) MAY decide to suppress the implicit
   subscription. In this case the UAS will send the option tag
   'norefersub' in a Require header of the 2xx response to the REFER.
   This indicates to the referor that no NOTIFYs are to be expected for
   this REFER. However in this case if the 2xx does not contain the
   Require header with the 'norefersub' option-tag, the referor MUST be
   prepared to receive the NOTIFY messages from the UAS.


4.2 UAC (referor) behavior

   When the UAC (referor) creates a new REFER request, it can insist on
   suppressing implicit subscription for that request.  To do that, it
   inserts a Require header field with the option tag 'norefersub' into
   the REFER request.

   If the UAC wishes to leave the decision to create or suppress
   implicit subscription to event 'refer' in the hands of the UAS
   (referee) - it SHOULD include the Supported header with the option
   tag 'norefersub' in the REFER method. The presence of the option tag
   in the Require header of the 2xx response, indicates whether the UAS
   has decided to create or suppress the implicit subscription. If the
   option tag is present in the Require header then the UAC MUST not
   wait for the NOTIFY, and in the absence of this option-tag it MUST be
   prepared to receive the NOTIFY message for event 'refer'.


5. IANA Registration of the 'norefersub' Option Tag

      This memo registers a single option tag, 'norefersub'.  The
   required information for this registration, as specified in RFC 3261,
   is:

         Name: norefersub

         Description: This option tag is for suppression of implicit
            subscriptions to event 'refer', caused by the reception of a
            REFER method.  When present in a Supported header, it
            indicates that the UA can support/handle such suppression.
            When present in a Require header in a REFER request, it
            indicates that the UAS MUST suppress the implicit
            subscription.
            When present in a Require header in a 2xx
            Response to the REFER, it indicates that the implicit


Parameswar               Expires - April 2003                 [Page 7]

               Suppressing Refer Implicit Subscription   October 2002


            subscription has been suppressed.

Security Considerations

   One of the advantages to implicit subscription is the case of forked
   REFERs -          - of course, a REFER sent within the scope of an existing
   dialog will not fork. A REFER sent outside the context of a dialog
   MAY fork and the receipt of multiple NOTIFYs alerts the referor to
   this fact.

   The use of implicit subscription suppression is advocated in those
   cases where the referor does not care about forked REFERs or the
   service being invoked via the REFER does not lend itself to sending
   back NOTIFYs.


References


   1  Sparks, R., " The SIP Refer Method", Work In Progress, June 2002.

   2  Roach, A., " Session Initiation Protocol (SIP)-Specific Event
      Notification", RFC 3265, June 2002

   3  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
      Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
      Session Initiation Protocol", RFC 3261, June 2002.

   4 Sparks, R., " SIP Call Control - Transfer", Work In Progress, July
      2001.



Acknowledgments

   Author gratefully acknowledges comments and support from Robert
   Sparks.


Author's Addresses

   Sriram Parameswar
   Phone: 214-929-1608
   Email: sriramkp@attbi.com







Parameswar               Expires - April 2003                 [Page 8]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/