Network Working Group A. Tveretin
Intended status: Standards Track February 5, 2015
Expires: August 9, 2015

Remote Call Control and Call Pick-up in SIP


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

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 August 9, 2015.

Copyright Notice

Copyright (c) 2015 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 ( 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.

Table of Contents

1. 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]

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

3. Terms Used In This Specification

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

4. Dialog Subscription (revised)

4.1. Event package name

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

4.2. SUBSCRIBE Request Bodies

SUBSCRIBE request body is empty.

4.3. Subscription Duration

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

4.5. Notifier processing of SUBSCRIBE Requests

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

4.6. Notifier generation of NOTIFY Requests

The CntrldP 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 CntrldP MAY strip SIP header fields and SIP bodies that do not indicate state of calls, including information hidden from CntrlgP for privacy reasons.

Messages are packed unencrypted.

4.7. Subscriber processing of NOTIFY Requests

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

4.8. Handling of Forked Requests

See [RFC6665].

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

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

5. New Methods

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

To generate a request, UAC supplies necessary header fields and a body. Header field are those mandated by SIP (From, To, Call-Id, Contact, Via) and those convey additional information (Referred-By, Subject, Target-Dialog)

This specification considers ANSWER, PICKUP, REJECT requests as out-of dialog; thus, they MUST NOT contain To-tag, but they SHOULD contain Target-Dialog to refer to an existing dialog between Cntrlg and Cntrld.

Body of these requests is "text/csv"; other types are for further study.

Request MAY fail because of e.g. race condition. Cntrld reports actual state by exisiting subscriptions (or equivalent monitoring); cntrlg 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.

5.1. ANSWER Method Definition

The ANSWER method has semantics of answering the call, or otherwise establishing a dialog. Specifically,

Early-dialog at UAS side is answered (200 response). This may include automatical reception of files and faxes, answering a voice call with loadspeaker, etc.

A subscription at subscriber side is renewed.

For established dialogs, this method fails.

The request body consists of fields: call-id, from-tag, to-tag. It MAY contain extra text for the third party.

5.2. PICKUP Method Definition

The PICKUP method has semantics of forwarding the call to Cntrlg, or to another party. Unlike forwarding proper, it is initiated by Cntrlg as forwarded-to, rather than the forwarder.

The request body consists of fields: call-id, from-tag, to-tag, reason. It MAY contain extra text for the third party. Reason consists of SIP code and space-separated optional reason text.

While processing this request, UAS forwards the affected early-dialog by sending 302 (or 3xx for that reason) with Reason: given.

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.

5.3. REJECT Method Definition

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

Early-dialog at UAS side is rejected by a 4xx-5xx response, using the reason code of the 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.

A subscription time is reduced to zero by either party.

6. IANA Considerations

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

7. Security Considerations

All information related to calls (including the fact of the call) is sensitive. An appropriate authorization of Cntrlg by Cntrld is REQUIRED.

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

8. Example

For scenario:
From: Alice <>;tag=tag1
To: Bob <>
Subject: Hello
Content-Type: application/sdp
Contact: <sip:>
/*More header skipped*/

Now consider Carol intercepting this call. First, any further information is requested:
From: Carol <>;tag=tag3
To: Bob <>
Event: dialog
Accept-types: message/sip, application/sdp
/*More header skipped*/

Bob responds, and sends a notification:
NOTIFY sip: SIP/2.0
From: Bob <>;tag=tag4
To: Carol <>;tag=tag3
Event: dialog
Content-Type: message/sip

Now Carol chooses to answer this call. She sends a PICKUP:
PICKUP sip: SIP/2.0
From: Carol <>;tag=tag83
To: Bob <>
Content-Type: text/csv
/*skipped*/;tag1;tag2;500 Picked Up

Now Bob responds to Alice:
SIP/2.0 302 Picked Up
From: Alice <>;tag=tag1
To: Bob <>;tag=tag2
Reason: SIP;code=500;text=Picked up!
Content-Length: 0

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

9. Normative References

[H.450.5] ITU-T, "Call Park and Call Pickup Supplementary Services for H.323.", , 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC3261] 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.
[RFC4235] Rosenberg, J., Schulzrinne, H. and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.

Author's Address

Anton Tveretin ul.Dzerzhinskogo, d. 13/1, kv.34 Surgut, HMAO-Yugra 628416 RU Phone: +79224149328 EMail: URI: