Dear Sathish, all implementations i have seen so far use activation code (*xx) sent in an INVITE; no SUBSCRIBE is used for activating features, even though i think this would be the right way to do it.
One could handle the call-forwarding or any other feature locally on the CPE, but in this case you would have to face several issues; what happens in case the CPE is not reachable and the phone activated the call-fowarding previously? What about billing of the call-fowarding? What i mean is that there are several pro/con in having a distributed solution for handling features like this. Said that, i would like to make a question regarding advanced features and ISDN phone attached to a CPE. How should the CPE behave on the SIP side, once the ISDN user wants to activate features like CFWD, CW... that are supposed to be handled by the SoftSwitch? In case of ISDN it would be wrong, i think, to send an INVITE with *xx, since first of all the user can activate any feature by using the display menu being still on-hook. Then, what abuot the answer from the SoftSwitch? Usually it comes in the RTP, the user listens to the message and understands whether the activation has been successful achieved. In case of an ISDN phone, being on-hook, the CPE should inspect the RTP and give back to the phone the right answer!? Well, in my opinion, using SUBSCRIBE messages would solve this problem, in conjunction with the NOTIFY of course. Sathish, i was looking for the same event package to be used in SUBSCRIBE messages, but i didn't find any. Regards Marco --- "Agrawal, Vishal" <[EMAIL PROTECTED]> wrote: > 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] > [mailto:[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 towards > the 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 phone > number. > > 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 > === message truncated === ___________________________________________________________ Win a BlackBerry device from O2 with Yahoo!. Enter now. http://www.yahoo.co.uk/blackberry _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
