Subject: [dispatch] (Fwd) New Version Notification for draft-tveretin-dispatch-remote-00.txt

From: "Anton Tveretin" <[email-masked]>
Date: Thu, 05 Feb 2015 15:29:02 +0500

Dear all,
A long-awaited I-D is finally posted!
I've spent 25 years to make a telephone a telephone, not this annoying box. ;)
Surely, there are still issues to discuss.
For instance, should Reason go to the body, or into header? Is NOTIFY an appropriate 
method there (or should be INFO)? There was a discussion for another I-D.
Regards,
Anton.

------- Forwarded message follows -------
From:	[email-masked]
To:	"Anton Tveretin" <[email-masked]>,
	Anton Tveretin <[email-masked]>
Subject:	New Version Notification for draft-tveretin-dispatch-remote-00.txt
Date sent:	Thu, 05 Feb 2015 00:35:57 -0800

A new version of I-D, draft-tveretin-dispatch-remote-00.txt
has been successfully submitted by Anton Tveretin and posted to the
IETF repository.

Name:		draft-tveretin-dispatch-remote
Revision:	00
Title:		Remote Call Control and Call Pick-up in SIP
Document date:	2015-02-05
Group:		Individual Submission
Pages:		8
URL:            http://www.ietf.org/internet-drafts/draft-tveretin-dispatch-remote-00.txt
Status:         https://datatracker.ietf.org/doc/draft-tveretin-dispatch-remote/
Htmlized:       http://tools.ietf.org/html/draft-tveretin-dispatch-remote-00

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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

------- End of forwarded message -------

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 08 Feb 2015 17:38:32 -0500

>    calls at another user agent, and control a call, including picking up

The facilities in this draft are interestingly different from those
provided by the REFER method.  REFER always commands the UAS to generate
a particular request, and if used with Target-Dialog, can command the
request to be made within a particular dialog.  E.g., this can be used
to terminate an existing dialog between the UAS and a third UA by
ordering a BYE to be sent.

Call pickup can be implemented using INVITE/Replaces.

But the facilities described in the draft generally command the UAS to
respond to a particular INVITE in early-dialog state with a particular
response:

200 - accept the call
4xx - refuse the call
302 - forward/transfer the call
(none) - stop alerting but keep the dialog in early state

Excepting for that last function (stop alerting), it seems like they
could be implemented by a version of REFER that specifies the response
code to be returned to an early dialog.  This would effectively fold
ANSWER, REJECT, and PICKUP into a variant of REFER.

   First, B2 MUST identify the call ambiguously.  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.

Can you expand on why the information provided by dialog events (RFC
4235) is insufficient?  I say this having worked on a system that has
for years used RFC 4235 to implement call pick-up, and the information
it provides has always been sufficient.

Dale