Internet DRAFT - draft-tveretin-dispatch-remote

draft-tveretin-dispatch-remote







Network Working Group                                        A. Tveretin
Internet-Draft                                            April 10, 2017
Intended status: Standards Track
Expires: October 12, 2017


              Remote Call Control and Call Pick-up in SIP
                 draft-tveretin-dispatch-remote-03.txt

Abstract

   This memo defines a mechanism by which a SIP user agent could inspect
   calls at another user agent, and control a call, including picking up
   for itself.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on October 12, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Tveretin                Expires October 12, 2017                [Page 1]

Internet-Draft                 rcc&pick-up                    April 2017


Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Usage Scenario  . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Implementation Basics . . . . . . . . . . . . . . . . . . . .   2
   4.  Terms Used In This Specification  . . . . . . . . . . . . . .   3
   5.  Dialog Subscription (revised) . . . . . . . . . . . . . . . .   3
     5.1.  Event package name  . . . . . . . . . . . . . . . . . . .   3
     5.2.  SUBSCRIBE Request Bodies  . . . . . . . . . . . . . . . .   3
     5.3.  Subscription Duration . . . . . . . . . . . . . . . . . .   3
     5.4.  NOTIFY Request Bodies . . . . . . . . . . . . . . . . . .   3
     5.5.  Notifier processing of SUBSCRIBE Requests . . . . . . . .   3
     5.6.  Notifier generation of NOTIFY Requests  . . . . . . . . .   3
     5.7.  Subscriber processing of NOTIFY Requests  . . . . . . . .   4
     5.8.  Handling of Forked Requests . . . . . . . . . . . . . . .   4
     5.9.  Rate of Notifications . . . . . . . . . . . . . . . . . .   4
     5.10. State Aggregation . . . . . . . . . . . . . . . . . . . .   4
   6.  New Methods . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  ANSWER Method Definition  . . . . . . . . . . . . . . . .   5
     6.2.  PICKUP Method Definition  . . . . . . . . . . . . . . . .   6
     6.3.  REJECT Method Definition  . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Comparison message flows with RFC 3891 . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Requirements notation

   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 [RFC2119].

2.  Usage Scenario

   Alice calls Bob. Bob hears the call from B1 device (e.g. fixed).
   However, Bob wants to answer (or reject) that call from another
   device B2 (e.g. mobile).

   For more precise definition of this service, see [H.450.5]

3.  Implementation Basics

   First, B2 MUST identify the call umambigously.  The only way for this
   is to use dialog-id [RFC3261].  Thus, B2 must ask B1 somehow for the
   dialog-id in question.  An [RFC4235] solution exists, but only some




Tveretin                Expires October 12, 2017                [Page 2]

Internet-Draft                 rcc&pick-up                    April 2017


   information will be supplied.  Thus, an alternative is suggested: use
   message/sip media type for dialog information.

   Note: this does not affect existing implementations and
   interoperability.

   Any given UA at any given time may hold multiple dialogs.  After the
   affected dialog is chosen, B2 orders B1 to handle it (answer, reject,
   pick up [forward to B2], or forward somewhere else.

4.  Terms Used In This Specification

   Affected dialog (AfD): a SIP dialog whose state changed by remote
   call control; Controlling party (Ctg): an entity requesting call
   monitoring, or issuing remote call control commands (Note: this
   definition does not require to use SIP).  Controlled party (Ctd): an
   entity to which remote call control commands are directed.  It is
   also a party of Affected dialog.

5.  Dialog Subscription (revised)

5.1.  Event package name

   This specification reuses the dialog event package, which is defined
   in [RFC4235]

5.2.  SUBSCRIBE Request Bodies

   SUBSCRIBE request body is empty.

5.3.  Subscription Duration

5.4.  NOTIFY Request Bodies

   NOTIFY request body comforming to this specification is a valid SIP
   message (request or response).  It has "message/sip" MIME type.  This
   specification also allows multipart bodies.

5.5.  Notifier processing of SUBSCRIBE Requests

   As per [RFC6665].  However, consider security implications.

5.6.  Notifier generation of NOTIFY Requests

   The Ctd will relay SIP messages, both incoming and outgoing, that
   alter state of any dialog.  It MUST NOT relay any messages (e.g.
   MESSAGE, OPTIONS, ANSWER, PICKUP, REJECT requests and responses) that
   do not imply any kind of dialog state change themselves.  The Ctd MAY



Tveretin                Expires October 12, 2017                [Page 3]

Internet-Draft                 rcc&pick-up                    April 2017


   strip SIP header fields and SIP bodies that do not indicate state of
   calls, including information hidden from Ctd for privacy reasons.
   However, this memo does not suggest any.

   Messages are packed unencrypted.

   In addition, Ctd will add the 'direction' parameter to the Event
   header field.  The value is a token indicating the direction of the
   call (not dialog).  Currently, predefined values are: incoming,
   outgoing, transit, external, internal, 3pcc, unknown, none.  FFS:
   should this form an IANA registry?

5.7.  Subscriber processing of NOTIFY Requests

   Cntrlg discriminates incoming and outgoing (from Ctd perspective)
   messages by comparing known AoR with From-URI and To-URI.  Then Ctg
   uses this information to track the state of dialogs.  It MAY also
   alter call state by sending appropriate requests.

5.8.  Handling of Forked Requests

   See [RFC6665].

5.9.  Rate of Notifications

   Remote call control is done in near real time.  So no trottling is
   allowed.  Nor it is allowed to suppress notifications, which may
   bring devices out-of-sync.

5.10.  State Aggregation

   This specification covers state changes presumable triggered by user.
   As such, they are assumed to be rare.

   It is still possible to combine several messages (using multipart/
   mixed) into a single NOTIFY request.  In that case, they retain
   relative order.

6.  New Methods

   This document introduces new methods, namely ANSWER, PICKUP, and
   REJECT, into SIP.  Existing methods considered unsuitable for the
   task.








Tveretin                Expires October 12, 2017                [Page 4]

Internet-Draft                 rcc&pick-up                    April 2017


6.1.  ANSWER Method Definition

   The ANSWER method has semantics of answering the call, or otherwise
   establishing a dialog.  Ctg provides instructions for this, via
   request-body.

   Structure: header field are those mandated by SIP (From, To, Call-Id,
   Contact, Via)

   To-tag: this MUST NOT be present, as the request is out-of-dialog.

   Answer-Mode, Priv-Answer-Mode: as by [RFC5373].  "Auto" implies
   automatic reception of faxes, files, or voice mail (or video mail)
   etc.  "Manual" implies using a loudspeaker for the call.  This
   distinction has less sense for faxes.  Exactly one of them is
   REQUIRED.

   Replaces: header field is REQUIRED, it indicates the AFD.

   Target-Dialog: SHOULD refer to an existing dialog between Ctg and
   Ctd, if any.

   Referred-By: OPTIONALLY reveals the Ctg to the caller.  If present,
   it is relayed in the 200 or equivalent response.

   Subject: is not relayed, but could be used by Ctd for logging.

   The request body is a URI.  It is used by the Ctd to answer
   anonymously or not.  Thus, the body becomes To-URI of the response.

   Detailed execution:

   Early-dialog at UAS side is answered (200 response).

   A subscription at subscriber side is renewed.

   A subscription at notifier side is renewed.  Note that the NOTIFY
   request act as a "response" for the purpose of this section.

   For established dialogs, this method fails.

   Request MAY fail because of e.g. race condition.  Ctd reports actual
   state by exisiting subscriptions (or equivalent monitoring); Ctg MUST
   NOT rely on responses to track outcome of call control.  For this
   reason, responses are defined to contain only minimum required
   information, and in particular, no body.





Tveretin                Expires October 12, 2017                [Page 5]

Internet-Draft                 rcc&pick-up                    April 2017


6.2.  PICKUP Method Definition

   The PICKUP method has semantics of forwarding the call to Ctg, or to
   another party.  Unlike forwarding proper, it is initiated by Ctg as
   forwarded-to, rather than the forwarder.  Ctd also relays any extra
   information (Referred-By:, Contact:, Reason: header fields, or the
   request body) to its peer.

   Structure: header field are those mandated by SIP (From, To, Call-Id,
   Contact, Via)

   To-tag: this MUST NOT be present, as the request is out-of-dialog.

   Replaces: header field is REQUIRED, it indicates the AFD.

   Target-Dialog: SHOULD refer to an existing dialog between Ctg and
   Ctd, if any.

   Reason: SHOULD be present.  This information is exposed to the
   caller.

   Referred-By: OPTIONALLY reveals the Ctg to the caller.  If present,
   it is relayed to the caller.

   Refer-To: may reference the Ctg (this is the default), or the call
   may be forwarded to other entity.  This header field is OPTIONAL.

   Subject: is not relayed, but could be used by Ctd for logging.

   The request body is relayed just as the Referred-By: header field.

   Detailed execution:

   UAS forwards the affected early-dialog by sending 302 (or 3xx for
   that reason).

   UAC forwards the affected early-dialog by cancelling it (i.e. sending
   the CANCEL request) and making another call.

   An established dialog is transferred.

   Similar behaviour is expected for subscriptions at subscriber side.

6.3.  REJECT Method Definition

   The REJECT method has semantics of tearing down a dialog, including
   rejection of an incoming call (early dialog).




Tveretin                Expires October 12, 2017                [Page 6]

Internet-Draft                 rcc&pick-up                    April 2017


   Structure: header field are those mandated by SIP (From, To, Call-Id,
   Contact, Via)

   To-tag: this MUST NOT be present, as the request is out-of-dialog.

   Replaces: header field is REQUIRED, it indicates the AFD.

   Target-Dialog: SHOULD refer to an existing dialog between Ctg and
   Ctd, if any.

   Reason: SHOULD be present.  This information is exposed to the
   caller.

   Referred-By: OPTIONALLY reveals the Ctg to the caller.  If present,
   it is relayed to the caller.

   Subject: is not relayed, but could be used by Ctd for logging.

   The request body is relayed just as the Referred-By: header field.
   It MAY be used as a detailed error message.

   Detailed execution:

   Early-dialog at UAS side is rejected by a 4xx-5xx response, using the
   reason code of the REJECT request.

   Early-dialog at UAC side is cancelled with a CANCEL request, using
   the reason code of the REJECT request.

   An established dialog is terminated with a BYE request, using the
   reason code of the REJECT request.

   A subscription is terminated (by reducing time to to zero) by either
   subscriber or notifier.

7.  IANA Considerations

   This memo introduces 3 new methods for SIP.  Namely, ANSWER PICKUP
   REJECT For details, please refer to this specification, RFC xxxx

8.  Security Considerations

   All information related to calls (including the fact of the call) is
   sensitive.  An appropriate authorization of Ctg by Ctd is REQUIRED.
   In particular, Target-Dialog MUST NOT be used (nor expected to)
   instead of actual authentication.





Tveretin                Expires October 12, 2017                [Page 7]

Internet-Draft                 rcc&pick-up                    April 2017


   This memo assumes that Ctg and Ctd belong to the same person or
   entity.  This, they can have any shared secret (even symmetric
   cryptography key).  In practice, end-to-end information flow may be
   hindered by network, especially if interworking is involved.  It is
   RECOMMENDED that remote control is not used in doubtful cases.

   Another issue is the implementation of the ANSWER method.  It may be
   unexpected even by authorized Ctg, e.g. receiving a fax or turning on
   a loudspeaker.  All behaviour MUST be documented well, including
   warnings when needed.

9.  Example

   For scenario:
   INVITE sip:bob@biloxi.com SIP/2.0
   From: Alice <alice@atlanta.com>;tag=tag1
   To: Bob <bob@biloxi.com>
   Subject: Hello
   Content-Type: application/sdp
   Contact: <sip:192.168.2.101>
   Call-Id: 15@atlanta.com
   /*More header skipped*/
   SDP...

   Now consider Carol intercepting this call.
   First, any further information is requested:
   SUBSCRIBE bob@biloxi.com SIP/2.0
   From: Carol <carol@cover.com>;tag=tag3
   To: Bob <bob@biloxi.com>
   Event: dialog
   Accept-types: message/sip, application/sdp
   Expire:
   /*More header skipped*/


   Bob responds, and sends a notification:
   NOTIFY sip:192.168.2.301 SIP/2.0
   From: Bob <bob@biloxi.com>;tag=tag4
   To: Carol <carol@cover.com>;tag=tag3
   Event: dialog
   Content-Type: message/sip
   /*more...*/

   Now Carol chooses to answer this call. She sends a PICKUP:
   PICKUP sip:192.168.2.201 SIP/2.0
   From: Carol <carol@cover.com>;tag=tag83
   To: Bob <bob@biloxi.com>
   Refer-To: Carol@cover.com



Tveretin                Expires October 12, 2017                [Page 8]

Internet-Draft                 rcc&pick-up                    April 2017


   Referred-By: Carol@cover.com
   Replaces: 15@atlanta.com;local-tag=tag2;remote-tag=tag1
   Target-Dialog: ...;local-tag=tag3;remote-tag=tag4
   Reason: SIP;cause=500;text=Picked-Up
   Content-Length: 0
   /*skipped*/

   Now Bob responds to Alice:
   SIP/2.0 302 Picked Up
   From: Alice <alice@atlanta.com>;tag=tag1
   To: Bob <bob@biloxi.com>;tag=tag2
   History-Info: <sip:bob@biloxi.com?reason=sip%3bcause%3d500>;index=1
   Contact: Carol@cover.com
   Content-Length: 0

   The success of this operation is also reported to by with 200 PICKUP
    and NOTIFY messages.

10.  Normative References

   [H.450.5]  ITU-T, "Call Park and Call Pickup Supplementary Services
              for H.323.", 1999, <Rec. H.450.5>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC4235]  Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An
              INVITE-Initiated Dialog Event Package for the Session
              Initiation Protocol (SIP)", RFC 4235,
              DOI 10.17487/RFC4235, November 2005,
              <http://www.rfc-editor.org/info/rfc4235>.

   [RFC5373]  Willis, D., Ed. and A. Allen, "Requesting Answering Modes
              for the Session Initiation Protocol (SIP)", RFC 5373,
              DOI 10.17487/RFC5373, November 2008,
              <http://www.rfc-editor.org/info/rfc5373>.

   [RFC6665]  Roach, A., "SIP-Specific Event Notification", RFC 6665,
              DOI 10.17487/RFC6665, July 2012,
              <http://www.rfc-editor.org/info/rfc6665>.



Tveretin                Expires October 12, 2017                [Page 9]

Internet-Draft                 rcc&pick-up                    April 2017


Appendix A.  Comparison message flows with RFC 3891

   RFC 3891 gives an impression that it is minimal message flow for a
   call pick-up or equivalent.  The fact is this RFC assumes the same
   number of SIP messages.

   Incoming call:
   A->B: INVITE
   B->A: 180
   C->B: SUBSCRIBE
   B->C: 200 SUBSCRIBE
   B->C: NOTIFY
   C->B: 200 NOTIFY
   RFC 3891:
   C->A: INVITE/Replaces
   A->B: CANCEL
   A->C: 200 INVITE
   B->A: 200 CANCEL
   B->A: 451 INVITE
   A->B: ACK
   C->A: ACK
   B->C: NOTIFY
   C->B: 200 NOTIFY
   This memo:
   C->B: PICKUP
   B->C: 200 PICKUP
   B->A: 302 INVITE
   A->B: ACK
   B->C: NOTIFY
   C->B: 200 NOTIFY
   A->C: INVITE/History-Info
   C->A: 200 INVITE
   A->C: ACK

   An alternative, draft-, is almost the same as this RFC, except PICKUP
   is substituted for REFER/Replaces.

Author's Address

   Anton Tveretin
   ul.Dzerzhinskogo, d. 13/1, kv.34
   Surgut, HMAO-Yugra  628416
   RU

   Phone: +79224149328
   Email: tveretinas@yandex.ru
   URI:   http://www.fit-rulez.narod.ru




Tveretin                Expires October 12, 2017               [Page 10]