Hi, I agree with Agrawal, you can still dial some special number to activate feature.
Using SUBSCRIBE to activate service is a little misleading, because activation means let the server know that sth should be done, while SUBSCRIBE means the UA want to know sth from the notifier. Also, SUBSCRIBE/NOTIFIY will establish a dialog which add more overhead. Peili ----- Original Message ----- From: "Agrawal, Vishal" <[EMAIL PROTECTED]> Date: Monday, March 27, 2006 7:41 am Subject: Re: [Sip-implementors] Query on Subscribe for Call forward feature > In a PBX environment it'll be better that phone sends the star > code in > an INVITE especially for features like pickup. > > For the forwarding why wouldn't you use the local forwarding on the > phone itself? > > Vishal > > -----Original Message----- > From: [EMAIL PROTECTED] > [EMAIL PROTECTED] On Behalf Of Sathish > Chandrasekaran > Sent: Monday, March 27, 2006 5:42 AM > To: Aswin Bhupalam; [email protected] > Subject: Re: [Sip-implementors] Query on Subscribe for Call forward > feature > > Aswin, > One thing I want to clarify is , Iam not looking at the call > flows. > I need details about - how the feature enabling in POTS phone > will be > translated to SIP message ?. > If the feature enabling is done thro' SUBSCRIBE message , what > will be > event package name for call transfer /call forward . ? > > If not thro' SUBSCRIBE what will be the message used to enable a > feature like call transfer /call forward.? > > Thanks, > sathish > > > Aswin Bhupalam <[EMAIL PROTECTED]> wrote: > Sathish, > Find attached sipping services draft. Hope this helps. > > Regards, > Aswin Bhupalam. > > ----- Original Message ----- > From: "Sathish Chandrasekaran" > To: > Sent: Monday, March 27, 2006 2:52 PM > Subject: [Sip-implementors] Query on Subscribe for Call forward > feature > > > All, > > I have query on "SUBSCRIBE" regarding call features like Call > forward unconditional. > > Say for example , > > Scenario is > > - POTS phone connected to CPE( which Sends out as SIP message > towardsthe SIP Server ) > > > > For example : > > -If the end user needs to activate call forward busy / unconditional > from POTS phone.he will be just dialing *xx followed by respective > phonenumber. > > 1) what would be the SIP message needs to sends out to server for > intimating server to enable the feature ? > > I feel it would be the "SUBSCRIBE" Message .If this is Ok , > then what would be the package name ? > > Can any body give me a pointer to solve this ? > > Thanks , > > sathish > > > > > > > > > > > > --------------------------------- > > Jiyo cricket on Yahoo! India cricket > > Yahoo! Messenger Mobile Stay in touch with your buddies all the > time.> _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > SIPPING Working Group A. Johnston > Internet-Draft MCI > Expires: January 18, 2006 R. Sparks > C. Cunningham > S. Donovan > Estacado Systems > K. Summers > Sonus > July 17, 2005 > > > Session Initiation Protocol Service Examples > draft-ietf-sipping-service-examples-09 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > 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. > > This Internet-Draft will expire on January 18, 2006. > > Copyright Notice > > Copyright (C) The Internet Society (2005). > > Abstract > > This document gives examples of Session Initiation Protocol (SIP) > services. This covers most features offered in so-called IP Centrex > offerings from local exchange carriers and PBX (Private Branch > > > > Johnston, et al. Expires January 18, 2006 [Page 1] > > Internet-Draft SIP Service Examples July 2005 > > > Exchange) features. Most of the services shown in this document are > implemented in the SIP User Agents, although some require the > assistance of a SIP Proxy. Some require some extensions to SIP > including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces > and Join headers. These features are not intended to be an > exhaustive set, but rather show implementations of common features > likely to be implemented on SIP IP telephones in a business > environment. > > Table of Contents > > 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Service Examples . . . . . . . . . . . . . . . . . . . . . . 4 > 2.1 Call Hold . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.2 Consultation Hold . . . . . . . . . . . . . . . . . . . . 17 > 2.3 Music On Hold . . . . . . . . . . . . . . . . . . . . . . 34 > 2.4 Transfer - Unattended . . . . . . . . . . . . . . . . . . 42 > 2.5 Transfer - Attended . . . . . . . . . . . . . . . . . . . 49 > 2.6 Transfer - Instant Messaging . . . . . . . . . . . . . . . 61 > 2.7 Call Forwarding Unconditional . . . . . . . . . . . . . . 67 > 2.8 Call Forwarding - Busy . . . . . . . . . . . . . . . . . . 73 > 2.9 Call Forwarding - No Answer . . . . . . . . . . . . . . . 80 > 2.10 3-way Conference - Third Party is Added . . . . . . . . 88 > 2.11 3-way Conference - Third Party Joins . . . . . . . . . . 94 > 2.12 Single Line Extension . . . . . . . . . . . . . . . . . 99 > 2.13 Find-Me . . . . . . . . . . . . . . . . . . . . . . . . 117 > 2.14 Call Management (Incoming Call Screening) . . . . . . . 128 > 2.15 Call Management (Outgoing Call Screening) . . . . . . . 135 > 2.16 Call Park . . . . . . . . . . . . . . . . . . . . . . . 138 > 2.17 Call Pickup . . . . . . . . . . . . . . . . . . . . . . 148 > 2.18 Automatic Redial . . . . . . . . . . . . . . . . . . . . 156 > 2.19 Click to Dial . . . . . . . . . . . . . . . . . . . . . 161 > 3. Security Considerations . . . . . . . . . . . . . . . . . . 165 > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 165 > 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 165 > 6. Document History . . . . . . . . . . . . . . . . . . . . . . 166 > 6.1 Changes since -07 . . . . . . . . . . . . . . . . . . . . 166 > 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 > 7.1 Normative References . . . . . . . . . . . . . . . . . . . 166 > 7.2 Informative References . . . . . . . . . . . . . . . . . . 167 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 168 > Intellectual Property and Copyright Statements . . . . . . . 169 > > > > > > > > > > Johnston, et al. Expires January 18, 2006 [Page 2] > > Internet-Draft SIP Service Examples July 2005 > > > 1. Overview > > This document provides example call flows detailing a SIP > implementation of the following traditional telephony services: > > Call Hold Music on Hold > Unattended Transfer Consultation Hold > Unconditional Call Forwarding Attended Transfer > No Answer Call Forwarding Busy Call Forwarding > Single-Line Extension 3-way Call > Incoming Call Screening Find-Me > Call Pickup Call Park > Outgoing Call Screening Automatic Redial > Click to Dial > > The call flows shown in this document were developed in the design of > a SIP IP communications network. They represent an example set of > so-called IP Centrex services or PBX services. > > It is the hope of the authors that this document will be useful for > SIP implementers, designers, and protocol researchers alike and will > help further the goal of a standard implementation of RFC 3261 [2] > > These flows represent carefully checked and working group reviewed > scenarios of SIP service examples as a companion to the > specifications. > > These call flows are based on the current version 2.0 of SIP in RFC > 3261 [2] with SDP usage described in RFC 3264 [5] Other RFCs also > comprise the SIP standard and are used and references in these call > flows. > > The SIP specification and the other referenced documents are > definitive as far as protocol issues are concerned. Also, these > flows do not represent the only way to implement these services - > other approaches such as 3pcc (Third Party Call Control) [17] or > Back-to-Back User Agents (B2BUA) may be more appropriate in some > circumstances. The peer-to-peer design and principles of these > service examples are described in the Multiparty Framework document > [12]. > > These flows assume the functionality described in the SIP Call Flow > Examples document [16], which explores basic SIP behavior. Some of > the scenarios described herein make use of the SIP method extension > REFER [3] and the SIP header extension Replaces [4], the SIP header > extension Join [9], and some of the concepts in the 3pcc (third party > call control) [17] document. The SIP Events document [6] describes > the use of SUBSCRIBE and NOTIFY while the SIP Dialog Event Package > > > > Johnston, et al. Expires January 18, 2006 [Page 3] > > Internet-Draft SIP Service Examples July 2005 > > > [8] document describes the dialog event package. Some examples make > use the GRUU (Globally Routable User Agent URI) [20] extension. > > These flows were prepared assuming a network of proxies, registrars, > PSTN gateways, and other SIP servers. The use of Secure SIP URIs > (sips) is shown throughout this document with assumed certificate > validation for security. However, other security approaches such as > Digest challenges can be used. > > Each call flow is presented with a textual description of the > scenario, a message flow diagram showing the messages exchanged > between separate network elements, and the detailed contents of each > message shown in the diagram. > > 1.1 Legend for Message Flows > > Dashed lines (---) represent control messages that are mandatory to > the call scenario. These control messages can be SIP signaling. > > Double dashed lines (===) represent media paths between network > elements. > > Messages with parenthesis around name represent optional control > messages. > > Messages are identified in the Figures as F1, F2, etc. This > references the message details in the table that follows the Figure. > Comments in the message details are shown in the following form: > > /* Comments. */ > > 2. Service Examples > > > > > > > > > > > > > > > > > > > > Johnston, et al. Expires January 18, 2006 [Page 4] > > Internet-Draft SIP Service Examples July 2005 > > > 2.1 Call Hold > > Alice Proxy Bob > | | | > | INVITE F1 | | > |--------------->| | > | | INVITE F2 | > |(100 Trying) F3 |------------->| > |<---------------| | > | |180 Ringing F4| > | 180 Ringing F5 |<-------------| > |<---------------| | > | | 200 OK F6 | > | 200 OK F7 |<-------------| > |<---------------| | > | ACK F8 | | > |--------------->| ACK F9 | > | |------------->| > | Both way RTP Established | > |<=============================>| > | |INVITE(hold) F10 > |INVITE(hold) F11|<-------------| > |<---------------| | > | 200 OK F12 | | > |--------------->| 200 OK F13 | > | |------------->| > | | ACK F14 | > | ACK F15 |<-------------| > |<---------------| | > | No RTP Sent! | > | | INVITE F16 | > | INVITE F17 |<-------------| > |<---------------| | > | 200 OK F18 | | > |--------------->| 200 OK F19 | > | |------------->| > | | ACK F20 | > | ACK F21 |<-------------| > |<---------------| | > | Both way RTP Established | > |<=============================>| > | BYE F22 | | > |--------------->| BYE F23 | > | |------------->| > | | 200 OK F24 | > | 200 OK F25 |<-------------| > |<---------------| | > | | | > > > > Johnston, et al. Expires January 18, 2006 [Page 5] > > Internet-Draft SIP Service Examples July 2005 > > > In this scenario, Alice calls Bob, then Bob places the call on hold. > Bob then takes call off hold. Alice hangs up call. Note that hold > is unidirectional in nature. However, a UA that places the other > party on hold will generally also stop sending media, resulting in no > media exchange between the UAs. Older UAs may set the connection > address to 0.0.0.0 when initiating hold. However, this behavior has > been deprecated in favor of using the a=sendonly SDP attribute. > > Message Details > > > F1 INVITE Alice -> Proxy 1 > > INVITE sips:[EMAIL PROTECTED] SIP/2.0 > Via: SIP/2.0/TLS client.atlanta.example.com:5061;branch=z9hG4bK74bf9 > Max-Forwards: 70 > From: Alice ;tag=1234567 > To: Bob > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY > Supported: replaces > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com > s=Session SDP > c=IN IP4 client.atlanta.example.com > t=3034423619 0 > m=audio 49170 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > > > F2 INVITE Proxy 1 -> Bob > > INVITE sips:[EMAIL PROTECTED] SIP/2.0 > Via: SIP/2.0/TLS ss1.example.com:5061;branch=z9hG4bK83749.1 > Via: SIP/2.0/TLS client.atlanta.example.com:5061;branch=z9hG4bK74bf9 > ;received=192.0.2.103 > Record-Route: > Max-Forwards: 69 > From: Alice ;tag=1234567 > To: Bob > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: > > > > Johnston, et al. Expires January 18, 2006 [Page 6] > > Internet-Draft SIP Service Examples July 2005 > > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY > Supported: replaces > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com > s=Session SDP > c=IN IP4 client.atlanta.example.com > t=3034423619 0 > m=audio 49170 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > > > F3 (100 Trying) Proxy 1 -> Alice > > SIP/2.0 100 Trying > Via: SIP/2.0/TLS client.atlanta.example.com:5061;branch=z9hG4bK74bf9 > ;received=192.0.2.103 > From: Alice ;tag=1234567 > To: Bob > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Content-Length: 0 > > > F4 180 Ringing Bob -> Proxy 1 > > SIP/2.0 180 Ringing > Via: SIP/2.0/TLS ss1.example.com:5061;branch=z9hG4bK83749.1 > ;received=192.0.2.54 > Via: SIP/2.0/TLS client.atlanta.example.com:5061;branch=z9hG4bK74bf9 > ;received=192.0.2.103 > Record-Route: > From: Alice ;tag=1234567 > To: Bob ;tag=314159 > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: > Content Length:0 > > > F5 180 Ringing Proxy 1 -> Alice > > SIP/2.0 180 Ringing > Via: SIP/2.0/TLS client.atlanta.example.com:5061;branch=z9hG4bK74bf9 > ;received=192.0.2.103 > Record-Route: > > > > Johnston, et al. Expires January 18, 2006 [Page 7] > > Internet-Draft SIP Service Examples July 2005 > > > From: Alice ;tag=1234567 > To: Bob ;tag=314159 > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: > Content Length: 0 > > > F6 200 OK Bob -> Proxy 1 > > SIP/2.0 200 OK > Via: SIP/2.0/TLS ss1.example.com:5061;branch=z9hG4bK83749.1 > ;received=192.0.2.54 > Via: SIP/2.0/TLS client.atlanta.example.com:5061;branch=z9hG4bK74bf9 > ;received=192.0.2.103 > Record-Route: > From: Alice ;tag=1234567 > To: Bob ;tag=314159 > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY > Supported: replaces > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com > s=Session SDP > c=IN IP4 client.biloxi.example.com > t=3034423619 0 > m=audio 3456 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > > > F7 200 OK Proxy 1 -> Alice > > SIP/2.0 200 OK > Via: SIP/2.0/TLS client.atlanta.example.com:5061;branch=z9hG4bK74bf9 > ;received=192.0.2.103 > Record-Route: > From: Alice ;tag=1234567 > To: Bob ;tag=314159 > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY > Supported: replaces > > > > Johnston, et al. Expires January 18, 2006 [Page 8] > > Internet-Draft SIP Service Examples July 2005 > > > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com > s=Session SDP > c=IN IP4 client.biloxi.example.com > t=3034423619 0 > m=audio 3456 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > > > F8 ACK Alice -> Proxy 1 > > ACK sips:[EMAIL PROTECTED] SIP/2.0 > Via: SIP/2.0/TLS client.atlanta.example.com:5061;branch=z9hG4bK74bf92 > Route: > Max-Forwards: 70 > From: Alice ;tag=1234567 > To: Bob ;tag=314159 > Call-ID: [EMAIL PROTECTED] > CSeq: 1 ACK > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY > Supported: replaces > Content-Length: 0 > > > F9 ACK Proxy 1 -> Bob > > ACK sips:[EMAIL PROTECTED] SIP/2.0 > Via: SIP/2.0/TLS ss1.example.com:5061;branch=z9hG4bK837492.1 > Via: SIP/2.0/TLS client.atlanta.example.com:5061;branch=z9hG4bK74bf92 > ;received=192.0.2.103 > Max-Forwards: 69 > From: Alice ;tag=1234567 > To: Bob ;tag=314159 > Call-ID: [EMAIL PROTECTED] > CSeq: 1 ACK > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY > Supported: replaces > Content-Length: 0 > > > /* Bob places Alice on hold. Note that the version is > incremented in the o= field of the SDP */ > > F10 INVITE Bob -> Proxy 1 > > > > > Johnston, et al. Expires January 18, 2006 [Page 9] > > Internet-Draft SIP Service Examples July 2005 > > > INVITE sips:[EMAIL PROTECTED] SIP/2.0 > Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7 > Route: > Max-Forwards: 70 > From: Bob ;tag=314159 > To: Alice ;tag=1234567 > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY > Supported: replaces > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com > s=Session SDP > c=IN IP4 client.biloxi.example.com > t=3034423619 0 > m=audio 3456 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=sendonly > > > F11 INVITE Proxy 1 -> Alice > > INVITE sips:[EMAIL PROTECTED] SIP/2.0 > > Via: SIP/2.0/TLS ss1.example.com:5061;branch=z9hG4bK83749.1 > Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7 > ;received=192.0.2.105 > Record-Route: > Max-Forwards: 69 > From: Bob ;tag=314159 > To: Alice ;tag=1234567 > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY > Supported: replaces > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com > s=Session SDP > c=IN IP4 client.biloxi.example.com > > === message truncated === > > > --------------------------------- > Jiyo cricket on Yahoo! India cricket > Yahoo! Messenger Mobile Stay in touch with your buddies all the time. > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
