Subject: [SIP] I-D ACTION:draft-ietf-sip-service-examples-01.txt

From: [email-masked]
Date: Mon, 05 Mar 2001 06:46:14 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: SIP Service Examples
	Author(s)	: A. Johnston, R. Sparks, C. Cunningham, 
                          S. Donovan, K. Summers
	Filename	: draft-ietf-sip-service-examples-01.txt
	Pages		: 96
	Date		: 02-Mar-01
	
This informational document gives examples of SIP (Session Initiation
Protocol) services.  This covers most features offered in so-called
Centrex offerings from local exchange carriers and PBX (Private
Branch Exchange) features.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-service-examples-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-service-examples-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-service-examples-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Henry Chen <[email-masked]>
Date: Tue, 06 Mar 2001 10:36:29 -0600

Hi Alan:

    I have a question about the session replacement in 2.2 "Music on Hold/Call Park" of SIP
Service Examples.

    How does A associates the incoming INVITE request from B (F14) with the existing Music
on Hole session and replace it?
    Even though B knows the Call-Id of the Music on Hole session between A and Music
Server, the F14 INVITE does not have
    any information about the session to be replaced.

    Thanks,

Henry

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Alan Johnston <[email-masked]>
Date: Thu, 08 Mar 2001 17:10:08 -0600

Henry,

Thanks for your comments on the draft.  You are correct.  Without a header such as Replaces in
that INVITE, A does not have a way of making that association.  This flow, along with the
Attended Transfer flow in 2.5, I believe, requires the Replaces header (or a similar header) in
order for it to work correctly.

The other changes to this new draft are:

   - Modified all REFER flows to include 202 Accepted and NOTIFY
     result message.

   - Removed "Telephony" from title of document.

   - Added note on 2.9 on use of REFER to exit 3-way conference.

   - Modified Music on Hold/Call Park flow (2.2).

   - Modified order of messages in transfers (2.4 and 2.5) to more
     closely resemble PSTN experience.

   - Added Call Pickup flow (2.13).

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

---

From: Henry Chen <[email-masked]>
Date: Fri, 09 Mar 2001 11:49:55 -0600

Hi Alan;

    Thanks for your answer.
    There is an issue with the 2.2 Call Park by the call flows you suggested in the draft.
    When user parks call at B, he or she will picks up the call some where else usually, say at C.
    The call flows work logically, but not practically since you will not expect user types in the
whole
    callid and To/From tags on device C to pick up and replace the call.
    Is it a reasonable argument?

    Thanks,

Henry

---

From: Alan Johnston <[email-masked]>
Date: Fri, 09 Mar 2001 16:06:11 -0600

Henry,

See my comments below.

Alan.

>     Is it a reasonable argument?

You are right in that these SIP flows are not necessarily a complete service flow.  Some non-SIP means
must be used to communicate some identifying information (such as the Call-ID, To, and From) from B
who knows it, to C who is then able to pickup the call.  However, I don't think SIP is the right
protocol for this application, unless you can think of a clever way...

This is true for Call Park/Pickup on PBXs today.  In order to pick up a parked call, one typically
needs to know what number the call has been parked at.  This number can be passed via overhead paging
("Sales, pick up line 23, please."), instant messaging, email, a web page, or some other scheme.

This example should probably have a note explaining this point.

---

From: Henry Chen <[email-masked]>
Date: Fri, 09 Mar 2001 17:04:25 -0600

Alan:

    Understand what you said. Please check below.

    thanks,

Henry

    Just give a try:
    - By some way, the user on receives Call Park Id (may only have 3 digits) for the call he or she
parked,
    - The user on C call Park Server with the Park Id some where , possible in the user part of
Request-URI,
    - Park Server refer the user on C to A and replace the call from C to park Server,
    - Park Server cancel the call from A.

> protocol for this application, unless you can think of a clever way...

    Just give a try (I do not think it carefully):
    - By some way (possible Notification), the user on B receives Call Park Id (may only have 3 digits)
for the call he or she parked,
    - The user on C call Park Server with the Park Id some where , possible in the user part of
Request-URI,
    - Park Server refer the user on C to A and replace the call from C to park Server,
    - Park Server cancel the call from A.

    And this is a case for the services need helps from network devices.

---

From: Ovidiu Sas <[email-masked]>
Date: Mon, 26 Mar 2001 12:34:45 -0500 (EST)

The "181 Call Is Being Forwarded" provisional response is not showed
in 2.6, 2.7 and 2.8 call forwarding diagrams.
  The rfc2543 statues that "A proxy server MAY use this status code".
To provide this informations to caller it's not mandatory, but ...

     Ovidiu

PS: In PSTN world this information can be provided via a CPG message.