Internet protocol telephony voice video message deposit and retrieval.

(54) Title: DEPOSIT AND RECOVERY OF INTERNET PROTOCOL VOICE / VIDEO TELEPHONY MESSAGES.

(54) Title: INTERNET PROTOCOL TELEPHONY VOICE VIDEO MESSAGE DEPOSIT AND RETRIEVAL.

(57) Summary

A method of signaling an Integrated Messaging System (IMS) on a network based on Internet Protocol (IP) to deposit a message, including the steps of sending a request to INVITE SIP (Session Initiation Protocol (SIP)) to the IMS, indicating a message deposit action; receive a corresponding SIP message from the IMS agreeing to participate in the message deposit action; and sending a SIP acknowledgment message to the IMS confirming receipt of the corresponding SIP message; and deposit the message in a destination mailbox. A method of signaling an IMS in an IP-based network to retrieve a deposited message, the method including the steps of sending an INVITE SIP request to the IMS, indicating a message retrieval action; receive a corresponding SIP message from the IMS agreeing to participate in the message retrieval action; send a SIP acknowledgment message to the IMS confirming receipt of the corresponding SIP message; and retrieve the deposited message from a mailbox corresponding to the known account information.

(57) Abstract

This invention relates to the field of IP telephony. More particularly, this invention is a method for handling the signaling related to the storing and forwarding of voice and video messages in an IP based network. With reference to Fig. 1, this invention is a method for signaling an IMS (25) on an IP based network (17) to perform an action on a message, where the action is either a deposit of the message or the retrieval of a previously deposited message, including the steps of sending an SIP INVITE request from a network server (23) to the IMS (25) indicating the desired action; receiving a corresponding SIP message from the IMS (25) agreeing to participate in the desired action; and sending an SIP acknowledge message from the network server (23) to the IMS (25) confirming receipt of the corresponding SIP message; and performing the desired action.

Cj <yrvkc o ·) r ·.

<img file="MXPA02004605A_D0001.tif" />

(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)

<td>(19) World Intellectual Property Organization International Bureau</td><td> ||||</td><td></td>

<td>(43) International Publication Date May 31, 2001 (May 31, 2001)</td><td>PCT</td><td>(10) International Publication Number WO 01/39441 Al</td>

(SI) International Patent Classification^{S * 7}: 1I04L 12/58,

12/66 (21) International Application Number: PCT / USOO / 41985 (22) International Filing Date:

November 2000 (08.11.2000) (25) Filing Language: English (26) Publication Language:. English (30) Priority Data:

09 / 436,795 8 November 1999 (08.11.1999) US (71) Applicant: MCI WORLDCOM, INC. [US / US]: 515 East Amite Street, Jacksoó, MS 3920.1 (US).

___ (72) Inventor: DONOVAN, Steven, R .; 704 Forest Bend == Drive, Plano, TX 75025 (US).

(74) Agent: GRÓLZ, Edward, W .; Scully, Scott, Muipby &amp; ± 5g Presser, 400 Garden City Plaza, Garden City, NY 11530 (81) Designated States (national): AE, AG, AL, AM, AT, AU,

AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CR, CU, CZ, DE, DK, DM, DZ, EE, ES, FI, GB. GD , GE, GH. GM. HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW.

(84) Designated States (regional): APIPO patent (GH, GM, KE, LS, 'MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian patent (AM, AZ, BY, KG, KZ , MD, RU, TJ, TM), European patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE, TR ), OAPI patent (BF, BJ, CF,

CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG).

Published:

- With intemational search report.

- Befare the expiration of the time limit for amending the claims and lo be republished in the event of receipl of amendments, h '

For two-letter codes and other abbreviations, refer to the Guidance Notes orí Codes and Abbreviations appearing at the beginning of each regular issue of the PCTGazetle.

S (54) Title: INTE RNE T PROTOCOL TELEPHONY VOICE / V1DEO MESSAGE DEPOSIT ADD RETRIEVAL

<img file="MXPA02004605A_D0002.tif" />

vnwu rnon

WO 01/39441 Al (57) Abstract: A method for signaling an Integrated Messaging System (IMS) on an Internet. Protocol (EP) based network to deposit a message, including tbe steps of sending a Session Initiation Protocol (SIP) SIP INVllE request to the IMS indicating a message deposit action; receiving a corresponding SIP message from tbe IMS agreeing to participate in tbe message deposit action; and sending an SIP acknowledged message to tbe IMS confirming receipt of tbe corresponding SIP message; and depositing tbe message in a destination mailbox. A metbod of signaling an IMS on an IP based network to retrieve a deposited message, the method including the steps of sending a SIP INVITE request to tbe IMS indicating a message retrieval action; receiving a corresponding SEP message from tbe IMS agreeing to participate in tbe message retrieval action; sending an SIP acknowledged message to the IMS confirming receipt of the corresponding SIP message; and retrieving the deposited message from a mailbox corresponding to known account Information.

DEPOSIT AND RECOVERY OF VOICE / VIDEO MESSAGES

INTERNET PROTOCOL TELEPHONY

BACKGROUND OF THE INVENTION

one. Field of the Invention

The present invention relates to Internet Protocol telephony, and more particularly, to a method of managing signaling related to the storage and delivery of voice and video messages in a Protocol based network.

Internet.

two. Description of Related Technique

Internet Protocol (IP) telephony is the real-time delivery of voice data and other multimedia data between two or more parties over a network using Internet Protocols. Internet telephony began in the mid-1990s with PC-to-PC Internet telephony, which required both parties to have a personal computer with specialized hardware and software, allowing voice signals to be transmitted over the Internet. More recently, IP telephony systems have been suggested that use existing public switched telephone network (PSTN) infrastructure integrated with IP networks, such as the Internet.

Internet technology is session-based, rather than connection-based. An Internet Protocol, like Session Initiation Protocols (SIP), is typically used to establish the session and negotiate the capabilities for the session. Once the session is established, the current medium is transported over the IP network using a different protocol, such as a Real Time Transport Protocol (RTP). The use of IP telephony has advanced rapidly since its Introduction.

IP telephony has advantages over PSTN, providing cost savings for both users and carriers by allowing the transport of a variety of media types, such as voice and video, compared to voice only as in the case of PSTN. While IP telephony may one day replace PSTN, it suffers from some disadvantages, such as it currently lacks many of the features already developed for PSTN. One of these features is the recovery and deposit of call messages.

The SIP Protocol is currently a leading protocol for establishing IP telephony sessions. However, currently no definitions have been established in the SIP Protocol to manage the signaling and call forwarding logic requirements necessary for a proper interface with messaging systems for message retrieval and repository. Conditional forwarding of calls for deposit in a messaging system is generally made when the called party is either busy or does not answer the call. The called party would also like to have the caller unconditionally drop the message into a messaging system. In either case, the messaging system interface can provide signaling capabilities to store the message, either conditionally or unconditionally, and also for the later called party to retrieve the deposited message. The signaling capabilities should also include information about the calling party that is depositing the message. The Identity of the called party must also be verified when you retrieve the deposited message.

Therefore, there is a need for a method to manage the signaling required for the retrieval and repository of voice and video messages from IP telephony in an IP-based network that uses the SIP Protocol, thereby allowing IP network integration. with an Integrated Messaging System (IMS).

SUMMARY OF THE INVENTION

Therefore, it is an object of the present invention to provide a method for handling the SIP signaling requirements associated with routing calls to an IMS to allow a calling party to place a message in the message box of the called party, in a network based on Internet Protocol.

It is another object of the present invention to provide a method for managing the SIP signaling requirements associated with routing calls to an IMS to allow a calling party to unconditionally deposit a message in the message box of the called party on a network. based on Internet Protocol.

It is yet another object of the present invention to provide a method of managing the SIP signaling requirements associated with routing calls to the IMS to allow the calling party to retrieve the message deposited in the called party's mailbox in a network based on Internet Protocol.

It is yet another object of the present invention to provide a method of managing the SIP signaling requirements associated with notifying the called party that a new message has been deposited in the called party's message box, in a network based in Internet Protocol.

To achieve the aforementioned objects, a method according to the present invention is provided for signaling an IMS in an IP-based network to deposit a message, the method includes the steps of sending an INVITE SIP request to the IMS indicating a deposit action message receive a corresponding SIP message from the IMS agreeing to participate in the message repository action; and sending a SIP acknowledgment message to the IMS confirming receipt of the corresponding SIP message; and deposit the message in a destination mailbox.

Also provided is a method of signaling an IMS on an IP-based network to retrieve a deposited message; the method includes the steps of sending an INVITE SIP request to the IMS indicating a message retrieval action; receiving a corresponding SIP message from the IMS agreeing to participate in the message retrieval action; send a SIP acknowledgment message to the IMS confirming receipt of the corresponding SIP message; and retrieve the deposited message from a mailbox corresponding to the known account information.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing objects and other objects, features and advantages of the present invention will become more apparent in light of the following detailed description of an exemplary embodiment thereof taken in conjunction with the accompanying drawings in which:

Figure 1 is a block diagram illustrating a system supporting the method of the present invention; and

Figure 2 is a flowchart illustrating a method of depositing a message in accordance with an embodiment of the present invention.

Figure 3 is a flowchart illustrating a method of retrieving a message in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED MODALITY

Referring now to the drawings, where similar reference numbers identify similar or identical elements in all views, Figure 1 is a block diagram illustrating a system that provides telephony services among subscribers using traditional telephones 13 and Internet telephones 15. Signaling and means for calls are transported over the

Internet 17.

Traditional telephones 13 connect to Internet 17 through traditional telephone switching equipment, such as IP telephony ports and PBX 21. IP telephony ports 21 each include a signaling port (not shown) and a media port (not shown) The signaling port provides bi-directional transport between PSTN telephony signaling and IP telephony signaling messages, such as SIP. IP phones 15 can be connected directly to the Internet through a local area network or through a MODEM connection through an Internet service provider.

Generally, the media and call signaling are transported over the Internet 17 between a source IP telephony port 21a and a destination IP telephony port 21b. Typically, Information routing is supported by a proxy server, such as a network server (NS) 23. NS 23 also provides call control and call forwarding control. That is, NS 23 includes an intermediate application program that acts as both a server and a client for the purposes of making requests by other clients or, generally referred to hereafter as calling parties. In the SIP protocol, an INVITE request is sent from the source IP telephony port 21a to the address of the called party at NS 23. IP call set-up signaling messages are carried back and forth between IP telephony ports 21 and NS 23 until the call is established using the SIP Protocol, as is commonly known in the art.

The system also includes a location manager 31, which provides port selection and mobility management services to MS 23. Location manager 31 functions as a SIP redirect server. A redirect server is a server that accepts a SIP request, maps the address to zero or newer addresses, and returns these addresses to the sender, for example NS 23. Unlike a SIP proxy server like MS 23, a redirect server does not initiate its own SIP requests or accept calls. Thus, if NS 23 cannot send a session initiation request to IP telephony port 21, NS 23 sends a session initiation request to the called party in location manager 31. The location manager 31 either consults his own database or accesses the legacy service control entity 29 to obtain a new address for the called party. Location manager 31 then returns the new address to NS 23.

In cases where the party that was called cannot be reached, that is, the phone is busy or is not answered, the call is sent to an Integrated Messaging System (IMS) 25. In order to send, deposit and retrieve appropriately to messages in IMS 25, NS 23 must communicate with IMS 25 using the SIP Protocol. Currently, there are no established definitions for using the SIP Protocol to manage the conditional call forwarding logic and signaling requirements necessary for a proper interface with messaging systems. The present invention establishes the SIP signaling requirements for the interface with an IMS 25.

NS 23 sends one or more SIP requests to IMS 25 and receives one or more responses from IMS 25. One. request (and its retransmissions) together with the responses triggered by that request make a SIP transaction. All responses to a request contain the same values ​​in the Caller ID, CSeq, to ​​and from, as shown in the examples below. This allows responses to match requests. The functions provided by these parameters are commonly known in the art.

A successful SIP invitation consists of two requests, INVITE followed by an ACK request. The ACK request that follows INVITE is not part of the transaction as it can traverse a different set of hosts. The INVITE request asks the called party to join a particular conference to establish a two-party conversation. After the called party accepts or participates in the call by answering, for example, a 200 OK message, the caller confirms that they have received that answer by sending an ACK request. If the caller no longer wants to join the call, they send an ADIOS request instead of an ACK request. The invite request typically contains a session description that provides the called party with enough information to join the session. The session description lists the media types and formats that the caller is willing to use and where you want the media data to be sent. IF the called party wishes to accept the call, it responds to the Invitation by returning a similar description listing the means it wishes to use.

The INVITE SIP request of the present invention includes a header added by NS 23. The added header will use the SIP Require Header Protocol Extension Mechanism. The Require heading is used to tell IMS 25 about the options that should be supported. The proposed format for this heading includes an appropriate label, such as:

Required: org.ielf.messaging And the following parameters:

Messaging.param = ”action =” (“depos¡t '' |” retrieval ”) Depos¡t-type = '' dtype =” (“cfu” | ”cfb '' |” cfna ”) where the parameter of action Identifies if a deposit or recovery operation is being performed and the dtype parameter determines the call forwarding condition. The dtype parameter, which is required only for deposit actions, includes the values: cfu, for unconditional call forwarding; cfb, for busy call forwarding; and cfna, for sending unanswered calls.

NS 23 adds the Require header and the parameters associated with the INVITE SIP request sent by IMS 25 by NS 23. NS 23 must first establish whether a called party, being an IMS account user, has selected that all of its Calls are sent inconclonally to your mailbox on IMS 25. This information is obtained from the party that was called by MS 23 by means of a call made by the party that was called to NS 23 when the party that was called activates the unconditional call sending feature to the phone of the called party. , or other communication device. NS 23 determines if a called party is busy as a result of receiving a busy response, such as "486 Busy Here", in response to NS 23's request to invite the called party. during Initial call setup. NS 23 determines if a called party is not answering as a result of receiving an out-of-time request in response to NS 23's INVITE request to the called party during initial call set-up.

The call flow for general IP call set-up between a calling party and a party that was called using the SIP Protocol is well known in the art and will not be shown in detail here to avoid unnecessary obscuring of the invention. The present invention, therefore, focuses on the method of required communications between NS 23 and IMS 25, and more particularly with the addition of the Require header and its associated parameters.

Referring to Figure 2, a method of depositing a message within IMS 25 begins with a call setup and routing to the called party as described above and as represented in step 200. In step 205, the MS 23 determines if the called party has previously activated the unconditional call forwarding feature. If the Unconditional Call Forwarding feature has been activated by the called party, NS 23 sends a SIP invite request to IMS 25 which includes the Additional Require header with the action = deposlt and dtype = cfu parameters in step 206 to indicate an unconditional call send message deposit. However, if the unconditional call forwarding feature has not been activated by the called party, NS 23 determines whether a busy response, such as 486 Busy Here, is received in response to the request to invite NS 23 to the party that was called during the initial call setup in step 210. If a busy response is received, NS 23 sends an INVITE SIP request to IMS 25 that includes the additional Require header with the parameters actlon = deposlt and dtype = cfb in step 211 to indicate a conditional busy call forwarding deposit. . However, if the busy response is not received by NS 23, NS 23 determines if the called party is not responding in step 215, or more particularly, if a time-out request has been received by NS 23 in response to NS 23's INVITE request to the party that was called during the Initial call setup. IF a timeout request is received, NS 23 sends an INVITE SIP request to IMS 25 which includes the additional required header with the parameters actlon = deposlt and dtype = cfna in step 216 to indicate a call forwarding message deposit no conditional response. However, if a timeout request is not received by NS 23, NS 23 determines whether NS 23 receives a connect signal in step 245 and completes call establishment to the called party in step 250. .

In steps 206, 21 1 or 216, a typical SIP Invite request call flow sent from NS 23 to IMS 25 including the Require Additional SIP header is shown below:

INVITE: slp: IMS-ma¡lbox-¡d@¡ms.wcom.com SIP / 2.0

VIA: SIP / 2.0 / UDP calllng-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Registration-Route; <slp: ns.wcom.com>

From: Calllng User <sIp: ca111ng-user @ ca111ng-host com>

To: Called User <slp: called-user@slp.wcom.com>

Caller ID: 123456@calling-host.com Cseq: 1 INVITE

Contact: <s¡p: call¡ng-user@calling-host.com> Required: org.letf.messaging Acc¡ón = depos¡tar

Dtype = cfb

Content-type: application / sdp

Content-length: ...

v = 0 or = User A 2890844526 2890844526 IN IP4 cllent.here.com t = 0 0 t = 0 0 c = IN IP4 100.101.102.103 m = audio 491 70 RTP / AVP 0 a = rtpmap: 0 PCMU / 8000

In the example above, the selected dtype parameter contains the cfb value, indicating a conditional busy call forwarding repository operation, as in step 210. This parameter would be different for the INVITE SIP request from steps 205 and 245 and in its place would be cfu and cfna, respectively.

In either case, IMS 25 responds to the INVITE SIP request by sending a 200 OK message to NS 25 at step 225, indicating that the request was successful and that IMS 25 has agreed to participate in the call with NS 23. A typical answer is shown below:

SIP / 2.0 200 OK

VIA: SIP / 2.0 / UDP calling-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Register-Path: <sip: ns.wcom.com>

From: Calllng User <s¡p: ca11¡ng-user @ ca11¡ng-host com>

To: Called User <sip: called-user@s¡p.wcom.com>

Caller ID: 123456@calling-host.com

Cseq: 1 INVITE

Contact: <sip: call¡ng-user@call¡ng-host.com>

Content-type: application / sdp

Content-length: ...

v = 0 or = User B 2890844526 2890844527 IN IP4 client.here.com t = 0 0 t- 0 0 c = IN IP4 100.11 1,112,113 m = audlo 3456 RTP / AVP 0 a = rtpmap: 0 PCMU / 8000

NS 23 then confirms that it has received a final response to the INVITE SIP request in step 230 by sending an ACK message to IMS 25, typically as follows:

ACK s¡p: IMS-ma¡lbox-¡d@ims.wcom.com SIP / 2.0

VIA: SIP / 2.0 / UDP calling-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Path: <sIp: calllng-user@calllng.host.com>

From: Calling User <s¡p: ca11ing-user @ ca11¡ng-host com>

To: Called User <sip: called-user@sip.wcom.com>

Caller ID: 123456@calling-host.com

Cseq: 1 ACK

Content-length: O

The message, being of video or voice content, is then deposited into the mailbox address of the called party, the called party being an IMS account user, by IMS 25 in step 235. The Communication is then terminated by means of normal ADIOS SIP processing in step 240.

A method of retrieving a deposited message in accordance with the present invention is illustrated in Figure 3. Referring to Figure 3, an IMS account user is notified of the message deposited in the user's mailbox by means of a call made by IMS 25 activating a message alert feature on the user's phone, or other communication device, in step 300. The subsequent user call to retrieve the deposited message is established and routed to the IMS via MS 23 in step 300. The content of the INVITE SIP request will vary according to three possible scenarios, as determined in steps 305 and 340. However, in either case the INVITE SIP request will include the Additional Require header with only the action parameter = retrieve.

In step 305, if the IMS account user account information has been authenticated by MS 23, the call flow between MS 23 and IMS 25, for example, will be as follows, starting with step 310 where MS 23 sends the request

INVITE SIP.

INVITE sip: IMS-account-id@ims.wcom.com SIP / 2.0 VIA: SIP / 2.0 / UDP calling-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Register-Path: <s¡p: ns.wcom.com>

From: Calling User <s ¡p: ca 11 ¡ng - use r @ ca 11 i ng - h os t com>

To: voicemail <sip: voicemail@sip.wcom.com>

Caller ID: 123456@calling-host.com

Cseq: 1 INVITE

Contact: <sip: call¡ng-user@calling-host.com>

Required: org.ietf.messaging Action = retrieve Content-type: application / sdp Content-length: ...

ν = 0 ο = User A 2890844526 2890844526 IN IP4 client.here.com t = 0 0 t = 0 0 c = IN IP4 100.101.102.103 m = audio 49170 RTP / AVP 0 a = rtpmap: 0 PCMU / 8000

IMS 25 responds to the INVITE SIP request by sending a 200 OK message to MS 23 in step 315, indicating that the request was successful and that IMS 25 has agreed to participate in the call with MS 23. A typical response is shown. then:

SIP / 2.0 200 OK

VIA: SIP / 2.0 / UDP calling-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Register-Path: <sip: ns.wcom.com>

From: Calling User <s I p: ca 11 i ng-u se r @ ca 11 ing - h ost com> To: volcemail <slp: voicemail@sip.wcom.com>

Caller ID: 123456@calling-host.com Cseq: 1 INVITE

Contact: <sip: caIling-user@calling-host.com> Content-type: application / sdp Content-length: ...

ν = Ο ο = User Β 2890844526 2890844526 IN ΙΡ4 client.here.com t = 0 0 t = 0 0 c = IN ΙΡ4 110,111,112,113 m = 3456 RTP / AVP audio 0 a = rtpmap: 0 PCMU / 8000

NS 23 then confirms that it has received a final response to the INVITE SIP request in step 320 by sending an ACK message to IMS 25, typically as follows:

ACK: sip: IMS-mailbox-id@ims.wcom.com SIP / 2.0

VIA: SIP / 2.0 / UDP calling-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Path: <sip: ca lling-user@calling-host.com>

From: Calling User <sip: ca 11 i ng - u se r @ ca 11 ¡ng - h os t com>

To: voicemail <sip: voicemail@s¡p.wcom.com>

Caller ID: 123456@calling-host.com

Cseq: 1 ACK

Contents-Length: 0

In the above case, no prompting is required since the IMS account user information is authenticated and, in step 325, the IMS 25 uses the Account Information indicated in the

Uniform Resource Locator (URL) of INVITE request. After this, the calling user is granted access to the mailbox in step 410 and the message is retrieved in step 415, which is followed by normal ADIOS SIP processing in step

420 to end the call.

On the other hand, if the IMS account user cannot be authenticated in step 305, and the user is accessing IMS 25 from a device that has an implicit IMS account associated with it in step 340, the procedure in place continues to step 345, providing an INVITE SIP request from NS 23 to IMS 25 as follows, for example:

INVITE sip: IMS-accound-id ???? @ ms.wcom.com SIP / 2.0 VIA: SIP / 2.0 / UDP calllng-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Register-Path: <s¡p: ns.wcom.com>

From: Calling User <sip: ca11¡ng-user @ ca11¡ng-host com>

To: volcemall <sip: voicemail@s¡p.wcom.com>

Caller ID: 123456@calling-host.com

Cseq: 1 INVITE

Contact: <sip: call¡ng-user@calling-host.com>

Required: org.letf.messaging Action = retrieve Content-type: app11cation / sdp

Content-length: ...

ν = 0 ο = User A 2890844526 2890844526 IN IP4 client.here.com t = 0 0 t = 0 Ó

C = IN IP4 100,101,102,103 m = audio 49170 RTP / AVP 0 a = rtpmap: 0 PCMU / 8000

IMS 25 responds to the INVITE SIP request by sending a 200 OK message to NS 23 at step 350, indicating that the request was successful and that IMS 25 has agreed to participate in the call with NS 23. A typical response is shown then:

SIP / 2.0 200 OK

VIA: SIP / 2.0 / UDP calling-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Register-Path: <sip: ns.wcom.com>

From: Calling User <sIp: ca111ng-user @ ca11¡ng-host com> To: voicemail <s¡p: vo¡cemall@sip.wcom.com>

Caller ID: 123456@calling-host.com Cseq: 1 INVITE

Contact: <sip: IMS-ma¡lbox-id@lms.wcom.host.com> Content-type: application / sdp Content-length: ...

ν = 0 ο = User Β 2890844526 2890844526 IN ΙΡ4 client.here.com t = 0 0 t = 0 0 c = IN IP4 110,111,112,113 m = audio 3456 RTP / AVP 0 a = rtpmap: 0 PCMU / 8000

The NS then confirms that it has received a final response to the INVITE SIP request in step 355 by sending an ACK message to IMS 25, typically as follows:

ACK s¡p: IMS-mallbox-¡d@¡ms.wcom.com SIP / 2.0

VIA: SIP / 2.0 / UDP calling-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Path: <slp: calling-user@calling-host.com>

From: Calllng User <sip: ca11ίng-user @ ca111ng-host com>

To: volcemall <s¡p: vo¡cema¡l@slp.wcom.com>

Caller ID: 123456@calling-host.com

Cseq: 1 ACK

Content-length: O

The INVITE SIP request above contains the account information, without password authentication. At this point, IMS 25 prompts the IMS account user calling by the password to verify the account contained in the INVITE request URL in step 360. IF the account is verified, the procedure continues to steps 410-420 as previously described. IF, however, the password entered is Incorrect, or the user indicates that he is calling from a device with an Implicit account assigned to it corresponding to another user account, then the IMS 25 visits the user for a username and password at step 395 and continue to step 400 as will be described later.

However, if in step 340, the IMS account user is accessing IMS 25 from a port or other device that does not have an Implicit IMS account assigned to it, MS 23 sends an INVITE unknown SIP account request to IMS 25 in step 380 as shown below:

INVITE sip: UNKNOW@ims.wcom.com SIP / 2.0

VIA: SIP / 2.0 / UDP calllng-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Registration-Route; <s¡p: ns.wcom.com>

From: Calllng User <sip: ca111ng-user @ ca11ing-host com>

To: volcemall <s¡p: volcemall@s¡p.wcom.com>

Caller ID: 123456@calllng-host.com

Cseq: 1 INVITE

Contact: <slp: cal llng-user@calling-host.com>

Required: org.letf.messaging

Action = retrieve

Content-type: application / sdp Content-length: ...

v = 0 or = User A 2890844526 2890844526 IN IP4 client.here.com t = 0 0 t = 0 0

C = IN IP4 100,101,102,103 m = audio 49170 RTP / AVP 0 a = rtpmap: 0 PCMU / 8000

IMS 25 responds to the INVITE SIP request by sending a 200 OK message to NS 23 at step 385, indicating that the request was successful and that IMS 25 has agreed to participate in the call with MS 23. A typical response is shown to continuation:

SIP / 2.0 200 OK

VIA: SIP / 2.0 / UDP calling-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Register-Path: <s¡p: ns.wcom.com>

From: Calling User &lt;sip: ca 11 ing - use r @ ca 11 ¡ng - host run To: voicemail &lt;sip: voicema¡l@s¡p.wcom.corro Call ID: 123456@calling-host.com Cseq : 1 INVITE

Contact: <sip: IMS-mailbox-id@ims.wcom.host.com>

Content-type: application / sdp Content-length: ...

v = 0 or = User B 2890844526 2890844527 IN IP4 client.there.com t = 0 0 t = 0 0 c = IN IP4 100,111,112,113 m = audio 3456 RTP / AVP 0 a = rtpmap: 0 PCMU / 8000

NS 23 then confirms that it has decided on a final response to the INVITE SIP request in step 390 by sending the ACK message to IMS 25, typically shown below:

ACK sip: IMS-mailbox-¡d@¡ms.wcom.com SIP / 2.0

VIA: SIP / 2.0 / UDP calling-bost.com

VIA: SIP / 2.0 / UDP ns.wcom.com

Path: <s¡p: call¡ng-user@call¡ng.host.com>

From: Calling User <sip: ca11¡ng-user @ ca11¡ng-host com>

To: volcemail <s¡p: volcema¡l@s¡p.wcom.com>

Caller ID: 123456@calling-host.com

Cseq: 1 ACK

Content-length: 0

In this case, the INVITE SIP request does not contain Authentication or Account Information, but only the UNKNOWN identifier in the INVITE request URL. Accordingly, in step 395, a calling party is prompted by their username and password. IF the account is verified in step 400, the procedure continues to steps 410-420 as described above. However, if the username and password are entered incorrectly, the user has the opportunity for a predetermined number of attempts to re-enter them in step 405 before the operation is aborted, ending the call in step 406.

While the present invention has been described in detail with reference to preferred embodiments, they represent merely exemplary applications. Thus, it should be understood that variations or any with ordinary experience in the art may be made while remaining within the scope and spirit of the present invention as defined by the appended claims.