FIELD OF THE INVENTION
The present invention relates to third party call control using the session initiation protocol (sip). More particular, the present invention relates to sip (session initiation protocol) refer method notification content.
DESCRIPTION OF RELATED ART
The SIP REFER request defined in RFC3515, "The Session Initiation Protocol (SIP) Refer Method", R. Sparks, April 2003, is a way for a REFER-lssuer to request the REFER-Recipient to perform some SIP transaction to the REFER-ed User. The SIP REFER request creates an implicit subscription for the 'refer' event, and per this implicit subscription, the notifications are generated to the REFER-lssuer to report the progress of the REFER-ed SIP transaction by the REFER-Recipient. The following figure 1 shows the basic example flows of REFER mechanism.
The 'refer' event notifications must contain a body of type 'message/sipfrag', which contains parts of the SIP response that the REFER-Recipient has received for the REFER-ed SIP transaction. The REFER-Recipient decides which parts of the SIP response to be included in the notifications to well describe the status of the REFER-ed SIP transaction. In RFC 3515, the default is that the Request Line in the SIP response must be included while other headers in the SIP response can be optionally included.

Different REFER-lssuer might need different parts of the SIP response of the REFER-ed SIP transaction for different purposes. Also, different REFER-Recipient would want to include in the 'refer' event notification, the different parts of SIP response of the REFER-ed SIP transaction to protect REFER-Recipient's privacy.
For example, in case of call transfer in Figure 2 where User A transfers the call with User B to User C. For this. User A, REFER-lssuer, sends REFER requests to User B, REFER-Receiver, then the User B initiate a call with User C, REFER-ed User. In this case, the User B is another personnel just like User A. So, the contents of the 'refer' event notifications should be limited to those just enough to inform the User A of the progress of the REFER-ed SIP transaction between User B and User C. Because, revealing too much information to User A of the SIP transaction between User B and User C might cause privacy problems against both User B and User C.
Therefore, in this case just the Request Line of the SIP response for the REFER-ed SIP transaction would be enough as the contents of 'refer' event notifications.
In another example case of proxyed call as depicted in Figure 3, where a user generates a call through a call proxy, the caller issues REFER requests to the call proxy requesting to make a call to the callee, then the call proxy, working as B2BUA (Back to Back User Agent), generates a call to the REFER-ed callee.

Here, the caller is REFER-lssuer, the call proxy is REFER-Receiver, and the callee is REFER-ed User. In this case, the user who is REFER-lssuer actually owns the SIP call between calt proxy and callee, as well as that between caller and call proxy. So, compared to the previous case, there's no privacy issue of the REFER-Receiver, and the contents of the 'refer' event notifications to the user, REFER-lssuer, should contain enough information for the user, REFER-lssuer, to be able to generate future REFER requests to manage the REFER-ed SIP call between the call proxy and the callee (e.g., canceling the call). This would be the information to identify the dialog for the REFER-ed SIP call, which would be the call-id, local tag, and remote tag.
Another example would be a network entity doing call control activities. A call control network entity would invoke REFER requests for some SIP transactions and might need to have various SIP header information of the REFER-ed SIP transactions for future call control activities {e.g.. Supported, Require, Max-Forwards headers etc.). Such information should be returned by the REFER-Receiver, in the 'refer' event notifications.
Further, a Network Call Control Entity like a Third Party Call Controller (3PCC) for example, is used to initiate a call between two parties by Service Providers. The Service Providers are generally interested to monitor such calls and get information of the Call setup like the following;
• Supported: The list of Supported header values.

• Allow: The list of supported methods at the REFER-Target.
• Accept-Language, Accept-Encoding, Accept-Content etc.
• Dialog identifiers.
Using the SIP OPTIONS method is the current art which could have been used by the Third Party Call Controller to learn about the capabilities of the REFER-Target. A SIP OPTIONS response is highly unreliable as the SIP OPTIONS Request can fork when there are multiple instances registered for the same AOR, and a UA receiving the SIP OPTIONS Response cannot in anyway be sure that the INVITE will land at the same UA that responded to the OPTIONS request. This is basically due to the NICT (Non-INVITE Client Transaction) kind of handling at the Proxy for the NICT requests like OPTIONS. A forked OPTIONS will generate many SIP Responses to the proxy, but the Issuer of the OPTIONS request will receive only one 200 OK response to the OPTIONS request (Please see Fig. 4).
In Fig. 4, a Network server wants to know the capabilities of an Endpoint B, and sends an OPTIONS request out. As User B has two registered contacts the OPTIONS request forks and yields only one response to the Network Server. Therefore, the Networks Server does not know which Registered Contacts Capabilities are listed in the SIP OPTIONS response, and is not able to learn reliably the exact capabilities of the Registered contact with whom Sessions are to be established in the future.

The above-mentioned problems could be resolved if the REFER-lssuer is able to request the necessary parts of the REFER-ed SIP transaction's SIP response. However, as of the existing arts, there is no easy way for the REFER-lssuer to indicate which parts of the SIP response for the REFER-ed SIP transaction has to be returned in the 'refer' event notification, and how the REFER-Receiver to decide the contents of the 'refer' event notification:
The existing arts for REFER requests in RFC3515 just mandate to include the Request Line of the SIP response for the REFER-ed SIP transaction in 'refer' event notifications, and optionally allow to include other SIP header information.
One way of doing this would be for REFER-lssuer to SUBSCRIBE to the REFER-Recipient for the 'dialog' event per RFC4235, "An INVITE-lnitiated Dialog Event Package for the Session Initiation Protocol (SIP)", J. Rosenberg, et. al., November 2005. However, it might not always be possible to subscribe for the 'dialog' event, for several reasons: The 'dialog' event package is originally devised to monitor the status of all dialogs that a user agent is engaged in. So, it is highly probable that the REFER-lssuer may not have the credentials to see all the dialogs that are being established at the REFER-Recipient and not be authorized to subscribe the REFER-Recipient's 'dialog' event package. Even when authorized to subscribe, the 'dialog' event notification to the REFER-lssuer would contain much more information than needed, as the notification would contain the information on all dialogs at the REFER-Recipient rather than the specific dialog that the REFER-lssuer has interest in. Also, utilizing 'dialog' event

package would need additional event subscription than the 'refer' event, thus the network overhead involved in subscribing for the 'dialog' event might be more for the REFER-lssuer.
SUMMARY OF THE INVENTION
The SIP REFER method defined in RFC3515 creates an implicit subscription for the 'refer' event. The notifications that are generated due to this implicit subscription contain the 'message/sipfrag' body. There is no way for the REFER-lssuer to indicate which parts of the SIP response of the REFER-ed SIP transaction have to be returned in the 'refer' event notification. Different applications might be interested in seeing different parts of the SIP Response of the REFER-ed SIP transaction.
Accordingly the invention explains a method for requesting required SIP headers in a notification message created by SIP REFER method wherein the SIP REFER method indicates that a REFER-Recipient identified by a request URI contacting a third party using the contact information provided in a request.
This invention proposes system and methods to indicate in the REFER request, which parts of the SIP response of the REFER-ed SIP transaction are expected by the REFER-lssuer in the 'refer' event notification. Also, this invention proposes system and methods on how the REFER-Receiver to decide the contents of the 'refer' event notification per this request by REFER-lssuer as well as oer the REFER-Receiver's own nrivanv nnlir.v

I nese ana otner oDjects, Teatures and advantages or tne present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 depicts Message flow for REFER request.
Figure 2 depicts Message flow for call transfer.
Figure 3 depicts Message flow for proxyed call.
Figure 4 depicts an example of a forking SIP OPTIONS request.
Figure 5 depicts a Call flow depicting the usage of this invention for
CANCEL'ling a Call transfer.
Figure 6 depicts Existing art, where a PoC Client cannot CANCEL a call dunng
Call setup in Pre-established Mode in a standard way.
Figure 7 depicts A PoC User A successfully Cancelling a Call during Call setup
when using Pre-established mode.
Figure 8 depicts an example usage of the invention by a 3PCC Application
Server.
DETAILED DESCRIPTION OF THE INVENTION
The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be

embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail.
As described above, different applications utilize the REFER requests for different purposes and as such, would need different parts of SIP response of the REFER-ed SIP transactions as 'refer' event notifications.
In order for this, this invention proposes the system and methods where:
'1. the REFER-lssuer can explicitly request to the REFER-Receiver the information of the REFER-ed SIP transaction that the REFER-lssuer wants to receive in the 'refer' event notifications, then; 2. the REFER-Receiver can decide the contents of the 'refer' event notification per the REFER-lssuer's request as well as the REFER-Receiver's privacy policy.
A) REFER-lssuer Suggesting the Content of 'refer' Event Notifications
This invention proposes that the REFER-lssuer be able to explicitly request to the REFER-Receiver the information of the REFER-ed SIP transaction that the REFER-lssuer wants to receive in the 'refer' event notifications.

In order for this, this invention proposes that the REFER-lssuer can include the REFER-lssuer's suggestion for the contents of 'refer' event notifications either in the body of the REFER request or in the SIP header of the REFER request.
A-1) REFER-lssuer's content suggestion for 'refer' event notification in the body of the REFER request
In this approach, the body of the REFER request wii! typically contain the list of one or more SIP headers that the REFER-lssuer would wish to see in the body of the 'refer' event NOTIFY, apart from the Request Line of the SIP Response (Note that the Request Line of the SIP Response is default content for 'refer' event notification per RFC3515). Such body of the REFER request would be an XML description of the SIP headers. XML was chosen here as it can express exactly what headers and associated parameters the REFER-lssuer expects. The content type- for the XML description of the SIP headers could be "application/headers+xml". An example body of the REFER request would look like the following.
REFER sip:b@example.com SlP/2.0
Via: SIP/2.0/TCP issuer.example.com;branch=29hG4bK-a
From: ;tag=1 aasdad877xcv ^
To:
Call-ID: wwqekjasddadsa@issuer.example.com

Ubeq: ^J4 KbhbK
Max-Forwards: 70
Refer-To:
Require: tdiaiog, sipfragreq
Contact: sip:a@issuer.example.com
Content-Type: application/headers+xml
Content-Length: xxx

able 1. An example REFER message with a Body indicating the SIP Response headers expected.
The above example is REFER request that "sip:a@example.com" sends to "slp:b@example.com" to request "sip:b@example.com" invokes SIP INVITE to

"sip:c@example.com". The REFER-lssuer "sip:a@example.com" suggests in the body that the REFER-lssuer "sip:a@example.com" wishes to see in the 'refer' event notification "From" header with its tag, "To" header with its tag, "Catl-ld" header, "Max-Forwards" header, and "Supported" header.
The XML Schema for the above example "application/headers+xml" content is defined below:

A schema for representing SIP Response headers required by the
REFER-lssuer.

able 2. An XML schema for representing in REFER request body the SIP Response headers as required by the REFER-lssuer
The XML content above, mentions only the SIP headers required, apart from the SIP Response Status Line, which is mandatory as per SIP REFER RFC 3515. The headers requested is just an indication from the REFER-lssuer of the list of SIP Response headers expected, it is upto the REFER-Recepient to decide what it wants to return.
So a 2XX response to a REFER request does not necessarily mean that all the SIP response headers requested will be sent to the REFER-lssuer.
13

A-2) REFER-lssuer's content suggestion for 'refer' event notification in the SIP header of the REFER request (Alternate method)
As an alternate method to the above described mechanism, this Invention proposes that the REFER-lssuer can include the REFER-lssuer's suggestion for the contents of 'refer' event notifications in the SIP header of the REFER request. Instead of having a new content type for expressing the desired SIP Response headers in 'refer' event notifications, a new SIP Header could be used which can carry a comma separated list of headers expected by the REFER-lssuer. The new SIP header which will appear only in SIP REFER request could be called "Sipfrag-Req". A Require header field with the value "sipfragreq" should be included if the REFER-lssuer wants to make sure that the REFER-Recipient understands this option tag and the new SIP header. The new header should never be included along with a Refer-Sub header with a value of false, which indicates that the 'refer' event notifications would be suppressed.
For example;
Sipfrag-Req: From,To,Call-ld, Max-Forwards, Supported
REFER sip:b@example.com SIP/2.0
Via: SIP/2.0/TCP issuer.example.com;branch=z9hG4bK-a
From: ;tag=1aasdad877xcv

To:
Call-ID: wwqekjasddadsa@issuer.example.com
CSeq: 234 REFER
Max-Forwards; 70
Refer-To:
Require: tdialog, sipfragreq
Sipfrag-Req: From, To, Call-Id, Max-Fonwards, Supported
Contact: sip;a@issuer.example.com
Content-Length: 0
able 3. An example REFER message with a SIP headers Indicating the expected SIP Response headers information in the 'refer' event notifications.
In the above example, the REFER-lssuer conveys in the REFER request that the 'message/sipfrag' body of the resulting 'refer' event NOTIFY requests should carry the From, To, Call-Id, Max-Forwards and Supported header. {This is the same as the example REFER request in Table 1.)
B) Option Tag for Require and Supported Headers
This invention proposes a new Require/Supported header option tag called

"sipfragreq". This option tag is used to specify the User Agent's capabHity of the 'refer' event notification content suggestion as proposed by this invention.
When the "sipfragreq" option tag is used in a Require header field, it implies that the recipient needs to support the 'refer' event notification content suggestion that this invention proposes. When the "sipfragreq" option tag is used in a Supported header field, it implies that the sender of the message supports the 'refer' event notification content suggestion that this invention proposes.
The REFER-lssuer who wants explicit failure notification if the 'sipfragreq' option is not supported MAY include the "sipfragreq" option in a Require header field.
Example:
Require: sipfragreq
C) Processing at the REFER-Recipient of the REFER-lssuer's Content Suggestion for 'refer' Event Notifications
Upon receiving a REFER request with the REFER-lssuer's content suggestion for 'refer' event notifications as described above, a REFER-Recipient can do the following procedures:
1. If Require header field with the value of "sipfragreq" option tag is included in the received REFER request, the REFER-Receiver should

first check whether it supports this option tag. If supported it proceeds to the next step, otherwise it generates error response to the REFER-Issuer.
2. The REFER-Receiver checks v\/hether the REFER request can be accepted according to the REFER-Receiver's policy or some other local policy. If accepted it proceeds to the next step, otherwise it generates error response to the REFER-lssuer.
3. The REFER-Receiver extracts the list of the requested SIP Response headers to be returned in the "message/sipfrag" body of the 'refer' event NOITFY, from the 'refer" event notification content suggestion in the REFER request as proposed by this invention. Then, it stores those to be used when generating the 'refer' event NOTIFY request.
4. If there is Refer-Sub header with a value of 'false', the REFER-Receiver will not generate any 'refer' event notifications, hence no further processing related to the 'refer' event notification content suggestion per this invention will be carried out.
5. When SIP Responses are received by the REFER-Recipient on the SIP transaction triggered by the REFER request, the REFER-Recipient prepares a 'refer' event NOTIFY request with the "message/sipfrag" body according to RFC 3515. The content of the "message/sipfrag" body must include the Request Line of the SIP response of the REFER-ed SIP transaction. In addition, the content of the "message/sipfrag" body should also include the SIP Response headers as requested by the REFER-lssuer if those headers are

>
allowed to be distributed to the REFER-lssuer according to the REFER-Recipient's privacy policy or other local policy. After this, the REFER-Recipient sends the 'refer' event NOTIFY request to the REFER-lssuer.
Upon receiving the example REFER request in Table 1 or Table 3, the REFER-Recipient would process it as described per the above procedure and would generate the 'refer' event NOTIFY request as following Table 4. As the REFER-lssuer 'sip:a@example.com' requests to receive the SIP headers of From, To, Call-ID, Max-Forwards, and Supported headers of the REFER-ed SIP INVITE transaction in the example REFER request in Table 1 or Table 3, the REFER-Recipient 'sip.:b@example.com' includes in the 'refer' event NOTIFY requests to the REFER-lssuer, those requested SIP headers in the 180 SIP Response to the REFER-ed SIP INVITE request to the REFER-ed User 'sip:c@example.com'.
NOTIFY sip:a@example.com SIP/2.0
Via: SIP/2.0/TCP refer-recipient.example.com;branch=z9hG4bK9922ef992-
25 ;
From: ; tag=4992881234 To: ; tag=1aasdad877xcv Call-ID: wwqekjasddadsa@issuer.example.com CSeq: 385 NOTIFY Max-Forwards: 70 Event: refer

Subscription-State: active;expires=(vaiue longer than the Expire value of
the REFER-ed INVITE)
Contact:, sip:b@refer-recipient.example.com
Content-Type: message/sipfrag; version=2.0
Content-Length: xxx :
SiP/2.0 180 Ringing
From: ; tag=1928301774
To: ; tag=a6c85cf.
Call-ID: a84b4c76e66710@refer-recipient.example.com
Max-Fonwards: 60
Supported: tdialog, sipfragreq
able 4.: An example 'refer' event NOTIFY request with a Body indicating the SIP Response headers of the REFER-ed SIP transaction as requested by the REFER-lssuer.
D) Applications of the Invention
The following shows how the 'refer' event notification content suggestion mechanism as proposed by this invention resolve the limitations described in the above "Limitations of Related Art".
D-1) Call Transfer Case

In general case, as described above, the person who requests a call transfer by sending REFER request would be allowed to see just the Request Line of the SIP Response of the transferred call, mainly because to protect the privacy of the persons participating the transferred call.
But, if the call transfer issuer wants to remain to be able to control the transferred call (e.g., call operator), he/she would need more information than just the Request Line. This would be at least the Call-Id, local tag, and remote tag information of the transferred call, because with which the transferred call dialog can be identified and thus, with which the call transfer issuer would still be able to control the transferred call.
In order for this, the call transfer issuer could use the 'refer' event notification content suggestion mechanism as proposed by this invention, to request the REFER-Recipient to include those Call-Id, local tag, and remote tag information of the transferred call in the 'refer' event notifications.
The figure 5 and descriptions show the call flow for a call transfer that is being cancelled by the call transfer issuer, i.e., the REFER-lssuer.
The description of the Call flow in figure 1 is given below.
1. A call is established between User A and User B.

2. User A wants to transfer the call to User C, and sends a REFER request with Refer-To header having the SIP URI of User C and with 'method' parameter set to "INVITE". The Body of the REFER request indicates the SIP Response headers requested by User A from the REFER-ed INVITE transaction between User B and User C. (See Table 1 for an example REFER request with "application/headers+xml" body to indicate User A's content suggestion for 'refer' event notifications). Here, User A requests the "To, From, Call-Id" header information for 'refer' event notification.
3. A 202 Accepted SIP Response sent by User B for the REFER request.
4. A SIP INVITE request sent to User C, as a result of the REFER received by User B.
5. User C receives the INVITE and sends a 180 Ringing SIP Response back to User B.
6. User B generates a 'refer' event NOTIFY request with a "message/sipfrag" body as mentioned in RFC 3515. In addition, User B checks the SIP Response headers requested by User A in the REFER Request "apptication/headers+xml" body. If distributing the requested SIP Response headers to User A is allowed per User B's local privacy policy, then those will also be included in the "message/sipfrag" body of the 'refer' event NOTIFY request.
7. User B sends the 'refer' event NOTIFY request to User A, then gets 200 OK response from User A.

8. From the 'refer' event NOTIFY requests, User A gets learned about the dialog information of "To, From, Call-Id" header information.
9. User A decides to cancel the call transfer between User B and User C for some reason.
10. The User A generates a REFER request with method="CANCEL", and also includes a Target-Dialog header, per RFC4538 "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", J. Rosenberg, June 2006, to clearly identify the REFER-ed INVITE transaction between User B and User C to be CANCEUIed and to get an implicit authorization of this REFER request from User B. User A can set the value of Target-Dialog header per the REFER-ed SIP transaction information received from the previous 'refer' event notification.
11. User B sends a 202 Accepted response to the REFER with method="CANCEL" and the Target-Dialog header.
12. User B sends the CANCEL request to the matching theSIP dialog per the dialog identifiers given by the Target-Dialog header in the REFER request just received from User A.
13. User C sends 200 OK response for the SIP CANCEL request.
14. Subsequently, User C sends 487 Request Terminated response to User B, indicating the termination of the call as requested by the SIP CANCEL request.
15. User B generates ACK for the 487 Request Terminated response
16. User B generates a 'refer event NOTIFY request for the 487

Request terminated response, which including the SIP Response headers requested in the initial REFER request with method="INVITE".
D-2) Proxyed Call Management Case
A typical scenario of Proxyed Call Management occurs in the Push To Talk Over Cellular ( PoC ) technology defined by OMA (Open Mobile Alliance), with the concept of a Pre-established Session. A Participating PoC Function acts on behalf of PoC Client for Call Control, where the PoC Clients have already negotiated their capabilities with the Participating PoC Function. A Call is initiated using the SIP REFER method, by placing the URI of the Callee in the Refer-To SIP header.
One application of using the invention is to CANCEL a Call, during Call setup. The shortcoming observed in the current PoC specification is that, there is no standard way of CANCEL' ling a Call which is in Proceeding or in the Ringing state when Pre-established sessions are used (Please refer Fig. 6). Currently PoC specification proposes to release the Pre-established Session when the PoC User wants to CANCEL a call. But, with this invention, the Pre-established Session Call can be CANCELLed without releasing the Pre-established session.
Referring to figure 7
1.) A Pre-established Session is established between the PoC Cleint A and

:he PF (Participating PoC Function). This involves a INVITE/200 OK/ACK
exchange. 2.) The PoC User A initiates a Call using the SIP Refer method. The Content
Suggestion is included in the REFER SIP Message body per this
invention. In this case the PoC Client has requested for the From, To and
Callld Header. 3.) The PF sends an INVITE out to the SIP URI in the Refer-To Header. 4.) A NOTIFY is generated when the Callee responds with a 180 Ringing
Response. The sipfrag body will contain
the information requested in the Content Suggestion REFER request, per
this invention. 5.) The PoC User A wants to cancel the call and hits the disconnect button.
The PoC Client A generates a REFER
with a method=CANCEL and a Target-Dialog header with the information
received in the SIP NOTIFY. 6.) The PF sends a CANCEL request out to CANCEL the ongoing Session
setup, finding the INVITE Client transaction
using the values received in the Target-Dialog header. A 200 OK SIP
response for CANCEL is received. 7.) The Ongoing session setup is Cancelled and a 487 Request Terminated
SIP Response is returned, and an ACK
Is sent to acknowledge the final response by the PF. 8.) The PF generates a NOTIFY for the received final response.

D-3) Call Control Network Entity.
A Third Party Call Controller (3PCC) sets up sessions between two entities. It could act as a B2BUA, if it wants to be in the session/media path, or it can also be an entity which is not in the Session path but a mere observer of the Sessions initiated by it.
Let us take an example of a 3PCC initiating a call setup between 2 users A and B. The 3PCC being a Network entity wants to monitor the call for a particular duration and tear it down if the Call exceeds that time duration. The 3PCC is also an application server that initiates a call depending on the schedules submitted to it. So the 3PCC AS is continuously monitoring it's Schedule Calls request and triggering it with a REFER request to the user who requested the Call setup. The 3PCC AS, starts by sending a REFER request to the Requestor of the Schedule Calls Request, Inserting the URI of the person to be called in the Refer-To URI. The 3PCC AS also uses the method proposed in this invention, to request for a specific set of headers in the REFER event notifications, such that'it can keep track of the status of the call and do further call control activities, in this case the 3PCC AS, has requested the From, To, CSeq and Call-Id headers.
The 3PCC AS also starts a Call duration timer as soon as it receives a REFER event Notification with a status line of 200 OK and a CSeq method of INVITE. The 3PCC AS could get the updates of whether the Call ended

between the two users from other means, which are out of scope of this invention. When such an event occurs (Call Ended), the 3PCC AS stops the timer already started during the receipt of the 200 OK in the REFER event notification. When the timer fires with no updates received about the termination of the call, the 3PCC AS, issues a REFER request with a Refer-To Header parameter method="BYE", and sends it to the REFER-Recipient The 3PCC AS also includes a Target-Dialog Header whose values are ascertained from the information received in the refer Event Notifications. The REFER-Recipient then terminates the Call by sending a BYE request on the dialog previously established with an INVITE. Such scenarios can happen in a typical call center, where the REFER-Recipient can be a call center employee or simply an automaton, which just plays some preloaded media.
Referring to Figure 8 :
1.) The 3PCC AS receives an Event from a Call scheduler to setup a call between an Automata and a User of the network.
2.) The 3PCC AS sends out a REFER to the Automata with the SIP User Uri in the Refer-To set to the user's address. The body of the REFER includes a request for the content that the 3PCC AS would require to be sent in the 'refer' Event Notifications per this invention.
3.) The Automata returns a 202 Accepted SIP Response for the REFER request.

4.) The Session is setup between the automata and the User.
5.) On receipt of the 200 OK for the INVITE the Automata sends a NOTIFY with the requested SIP Response Headers in the message/sipfrag response for the suggested content in step 2 per this invention, which include the From header, To Header and the Call-Id and other headers like Cseq, Allow etc.
6.) The 3PCC AS starts an application timer, for a particular time period to keep track of the call.
7.) After sometime the Time expires and a Terminate Call Event is received by the 3PCC AS indicating it to terminate the Call. The 3PCC AS builds a Target-Dialog SIP header (from the From, To and Call-Id headers), from the SIP Response headers received earlier in the 'refer' Event Notification, and sends a REFER with method=BYE, to terminate the Call.
8.) The Automata accepts the REFER request' and sends a 202 Accepted.
9.) The Automata sends out a BYE over the dialog identified by the Target Dialog header. A 200 OK for the BYE is received by the Automata.
10.) The Automata sends a NOTIFY for the BYE response.
E) Security Considerations
Using "message/sipfrag" bodies to return the progress and results of a
27

REFER request is extremely powerful. Careless use of that capability can
compromise confidentiality and privacy. RFC 3515 Section 5, gives an
account of the ways security can be compromised if proper care is not
taken. It also suggests ways to avoid such security risks. This invention should more likely be used in a trusted environment where there is some kind of trust between the entities involved.
It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device.
Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart there from.

We Claim:
1. A method for requesting required SIP headers in a notification message created by SIP REFER method wherein the SIP REFER method indicates that a REFER-Recipient identified by a request URI contacting a third party using the contact information provided in a request.
2.. A method as claimed in claim 1 wherein, the REFER-lssuer see different SIP response headers in the body of the NOTIFY message to track the progress of the REFER request, in addition to the SIP response status line.
3. A method as claimed in claim 1 wherein the said method uses an
Xtensible Markup Language (XML) description of the required SIP response
headers in the body of the REFER request
4. A method as claimed in claim 1 wherein the REFER-lssuer indicates the
headers that it expects from the REFER-Recipient and the REFER-Recipient
decide which headers from among the headers indicated by the REFER-
lssuer wants to return to the REFER-lssuer.

5. A method for requesting required SIP headers in a notification message created by SIP REFER method substantially described particularly with reference to the accompanying drawings.