(I2) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(l 9) World Intellectual Property Organization
`International Bureau
`
`(43) International Publication Date
`24 January 2002 (24.01.2002)
`
`
`
`PCT
`
`IlI||||I|II||||||||||||||||||||||||||||||||||||||||||||I|l|||||||||||l|||HI||
`
`{I0} International Publication Number
`WO 02/07396 A1
`
`(51) International Patent Classification’:
`2‘).-‘lifi
`
`HI]-ILL I258,
`
`('34) Agents: LESON,Thomas..Iohannes,AIt:-is etaI.; Bavari-
`aring 4. D-80336 Miinchen (DIE).
`
`(21) International Application Nuln her:
`
`l’(_"l'!l?.l’ti[lit)ti't'(lt-i
`
`[22] International Filing Date:
`
`I3 July 2000 (13.07.2000)
`
`(31) Designateg states rm,-;o,m[); A11 AG’ AL AM_ A1‘: A1]_
`AZ. BA, BB, BG. BR, BY, B7,, CA, CH, (TN, CR, CU. CE,
`DIE, DK, DM, DZ, Iiii, IES, Iii, GB, GD, GIL GI-I, GM. I-IR,
`IIU, ID, IL, IN. IS, JP, KE, KG, Kl’, KR. KZ, LC. LK, LR.
`
`(25) Filing Language:
`
`Iingiish
`
`LS. LT. LU. LV. MA. MD. MG. MK. MN. MW, NIX. M2.
`NO. NZ, PL. PT. RO, RU, SD, SE. SG. SI, SK. SL. TJ, TM.
`
`(26) Pubmamn Language:
`
`English
`
`1 R. '11‘. '17., UA. no, us, uz. VN, YU, ZA. new.
`
`(71) Applicant 02);’ all desigtteted States except US): NOKIA I34) D95IB“‘“°d 59395 C"!-’5,’I0WU= _ ARIP0 P3I‘_5“i IG_H- GM-
`CORPORATION [I"IJ'I"II; Kciltiltlhdcnlic -‘I. FIN-02150
`KI"-it
`I-2S- Mw- M31 SI): SIM 535- T’/u 136- Zw)« I":|-lid-*'IaI1
`12:3]-,9“ (|=[}_
`patent (AM. AZ, BY. KG. {(2. M1), RU. ‘Ill. TM). liuropean
`patent (AT, BE, CII. CY, DIE, DK, ES, Iii, I"'R, GB, GR. IE,
`
`rm ,memm; and
`(75) lnventorshtpplieants (,r2u- US om'yt: STAACK. Jens
`[F'It'FI]; Klanecttitie 13 D 54, FIN-00420 Helsinki (Fl).
`KOSKELAINEN, Petri [FIJ’I’lI'. do Nultia Networks 03'.
`Kcilalahdentie 4, MN-t)2I5U lispoo (Ft).
`
`rt‘. Lt], MC, Ni, PT, SE). OAPI patent (or, BJ: ‘CF. CG,
`“- ‘-M- GA» "N GW- ML» MR» “in W» "1 ‘ "*-
`
`Published:
`-
`- with :'ttterrtat.=‘onm’ seat-eh report
`
`[('.‘om'imted on next page]
`
`(5-1) Title: Mi:"['I-[OD AND SYSTEM l‘R()\t'IDlNG A MHSSAGING S}‘IRVI(Iii
`
`E
`
`;
`i
`
`USER 3
`our ()1:
`REACH
`
`USER
`
`B
`
`/
`3
`
`USER
`USER B:
`A < Out-of-Reach ’
`
`Store&Fw: Notify
`Aoceptmjpeg. gif
`
`- _
`
`-
`
`I
`
`2
`
`4
`
`
`
`USERC:
`SIP: 17212.2
`/ Store&Fw: to e-mail
`.... ..
`
`Save
`
`Message
`
`SIP Store &
`Forward
`
`DATABASE
`
`SERVER
`
`||||||||||I|||||||||l||||||l|||||||||I|||l||||||||||||||l|||l||||||l||l|||||||||
`
`/07396A1
`
`(q
`=
`
`(57) Abstract: The invention is directed to a instant messaging method and communication system comprising one or more network
`elements, wherein a connection from one to another network element can he established usi I1 I a
`rotoeoi which allows the sentiin
`3
`I‘
`5
`0|‘ one or more rnessaees from the one to the another network element as art of’ one or more
`}l0t.‘.0I words. The
`rotocol includes
`P
`P“
`-
`P
`irlion allowin a network element to s ' ‘if whether or not the mcssa e is to be stored in case it cannot be mm 11
`H
`rotoeol
`P‘
`S
`P‘-'1
`3
`P
`delivered to the another network element. The Jt't)[t)t20I
`)ort:ion ireferahl
`rotoeol header. The ‘Jt‘0l0E‘.'0I ma he a
`is :-art of the
`I
`I
`I
`Y
`I
`P
`I
`3'
`Session Initiation Protocol (SIP). and the message can be contained in an Invite request sent from the sending equipment to the
`receiving equipment.
`
`
`
`I
`1
`
`Apple 1020
`Apple 1020
`U.S. Pat. 8,243,723
`U.S. Pat. 8,243,723
`
`

`
`W0 02/07396 A1
`
`||||||||||||||||||||||||||||||Ill||||||l||||||||||||l|||||||||||||HI|||l||||||
`
`Fbr rwo-{enter codes and orltcr abbrm-iatiom.-, ra,{,ré‘r to the "Guid-
`ance News on Codes :?!I'd/I bbn=:w'aIf0.I:3 " appem-mg at the begin-
`ning Qfeach regular Issue ofrhe PCT Gazette.
`
`II
`II
`
`

`
`W0 02.307396
`
`PCTr‘EPl]0.’{)6'.-'08
`
`METHOD AND SYSTEM PROVIDING A MESSAGING SERVICE
`
`5
`
`FIELD OF THE INVENTION
`
`The invention relates to a communication method and system
`
`implementing a messaging service
`
`l0
`
`BACKGROUND OF THE INVENTION
`
`Several networks provide messaging services which allow
`messages to be sent
`from one to another network terminal
`
`15
`
`without necessity of actually initiating a call. For
`
`instance, a plurality of GSM networks support a short
`
`message service (SMS) which permits the transmission of
`
`short messages. A more recent development is the multimedia
`
`messaging service (MMS) which allows the transmission not
`
`20
`
`only of text messages but also of pictures and the like.
`
`Both these SMS and MMS are store—and—forward messaging
`
`services which necessitate additional network elements
`
`[e.g. SMSC, Short Message Service Center) and dedicated
`
`protocols such as specified in ETSI TS 23.040.
`
`25
`
`Moreover,
`
`the Internet provides a direct user-to-user
`
`messaging for chatting or instant messaging (e.g. using
`
`Instant Messaging/Presence Protocol IMPP). Further,
`
`the
`
`Internet offers a store—and~forward messaging, e.g. e—mail
`
`30
`
`service (EOP3 "Post Office Protocol, version 3" or IMAP4
`
`"Internet Message Access Protocol, Version 4"}.
`
`Presently,
`
`some instant messaging services are either based
`
`on existing standards, or are proprietary solutions such as
`
`35
`
`AOL instant messaging service. Some requirements of future
`
`instant messaging services are defined in IETF RFC 2778 and
`
`

`
`W0 lJ2.’07396
`
`PCT!'EP00f06708
`
`RFC 2779. The instant messaging service requests both_
`
`sender and receiver to be on—line and registered to the
`
`instant messaging server. When the receiver is e.g. not
`
`reachable, no instant message can be delivered.
`
`For establishing a bidirectional connection between a
`
`caller and a callee, several call control protocols such as
`
`SIP (Session Initiation Protocol, see e.g. RFC 2543 and RFC
`
`2543bis) are proposed. SIP may not only be used as a call
`
`10
`
`control protocol but also offers the possibility of being
`
`the SIP
`used as instant messaging service. For instance,
`INVITE message can be used to carry content payloads (MIME
`types such as JPEG)
`inside one protocol message without the
`
`need of actually settingvup a voice—over—IP {VoIP) call.
`
`15
`
`Other SIP message types (e.g.
`
`INFO) may also be used and
`
`new message types may be defined for this purpose. Note
`
`that the INVITE message is a signalling message. As an
`
`example, a user A may include the following MIME—payloads
`
`into one INVITE message for the user B:
`
`20
`
`- image/jpeg {e.g.
`
`to send a picture)
`
`— audio/midi (e.g. for playing a sound clip).
`
`All such information fits into one SIP message.
`
`Fig.
`
`3 shows one example of using the INVITE message as a
`
`25
`
`messaging possibility. The names and numbers of the
`
`messages shown in Fig.
`
`3 are as defined in RFC 2543. First,
`
`user A sends an INVITE message (F1)
`
`to user B which message
`
`includes the payload. User B responds by returning "I00
`
`Trying" (F2),
`
`"180 Ringing" (F3), and "200 OK"
`
`(F4), which
`
`30
`
`confirms receipt of the message. User A then sends a "BYE"
`
`message (F5),
`
`to user B which acknowledges this message by
`
`returning "200 OK"
`
`[F6].
`
`SIP-based messaging provides the advantage of being usable
`
`35
`
`without need of any new network elements and is therefore
`
`cheap, and may possibly replace other messaging services.
`
`

`
`wo 0301396
`
`PCT!EP00f06708
`
`However,
`
`for performing this SIP—based messaging, both
`
`sender and receiver must be "on—line", i.e. user B must be
`
`actually reachable.
`
`SUMMARY OF THE INVENTION
`
`The present invention aims at providing a messaging service
`
`which can easily be implemented without need of new network
`
`10
`
`elements, and which offers enhanced messaging
`
`possibilities.
`
`The present invention provides a method andfbr System as
`
`defined in any one of the claims. Further,
`
`the invention
`
`15
`
`provides network element adapted to perform the necessary
`
`functions.
`
`In accordance with one aspect of the invention,
`
`the instant
`
`messaging service is enhanced by providing a storing
`
`20
`
`capability for messages. When the intended receiver of the
`
`message is presently unable to receive the message because
`
`he is e.g. not on—line, busy and/or not reachable by the
`
`network, e.g. by the proxy server of the receiving user,
`
`because of any other reason,
`
`the message may be stored.
`
`25
`
`This saving of the message enables its later delivery to
`
`the receiving user when this user is able to receive the
`
`message, e.g. after re—attachment to the network. No
`
`connection for bi-directional communication needs to be
`
`established.
`
`30
`
`The protocol normally used for initiating a connection
`
`_ enabling e.g. a bi—directional communication between a call
`‘originating equipment and a call terminating equipment thus
`
`serves the further purpose of indicating whether or not
`
`35
`
`transmitted instant messages are to be stored in case of
`
`impossibility of direct delivery. The protocol allowing
`
`

`
`W0 ll2;"07396
`
`PC'I'!EPl|0.*'06708
`
`messages to be sent from the sending to the receiving_
`
`equipment as part of the protocol,
`
`is amended so as to be
`
`able to include an identifier which may be or include a
`
`store command. The store command can be,
`
`in a preferred
`
`5
`
`implementation a store—and—forward command. A serving
`
`network element trying to provide a connection to the
`
`receiving equipment in vain,
`
`is preferably adapted to check
`
`the protocol with respect to the inclusion of such an
`
`identifier representing a store command. When the store
`
`10
`
`command is found,
`
`the message is not simply discarded but
`
`is stored in an appropriate place, such as in an own memory
`
`of this network element, or in a storage of another network
`
`element such as a server.
`
`[
`
`l5
`
`As the identifier can be included in the protocol,
`
`the
`
`message and the identifier (e.g. store command) can be
`
`transmitted in a unidirectional manner from the sending
`
`equipment to the serving network element provided for
`
`establishing connections to the receiving equipment. This
`
`20
`
`feature significantly reduces the signalling and traffic
`
`load necessary for transmitting and handling messages.
`
`In
`
`addition, no new protocols for messaging are necessary, and
`
`the invention can be implemented in existing networks in an
`
`inexpensive manner. Furthermore, no new network elements
`
`25
`
`are necessary for implementing the invention, so that the
`
`disclosed technique is easily and inexpensively deployable
`
`by a network operator or service provider. This messaging
`
`service structure may also replace existing messaging
`
`services and hence contribute to a harmonisation of
`
`30
`
`messaging services.
`
`The protocol preferably used is the Session Initiation
`
`Protocol SIP. The protocol comprises a portion allowing a
`
`network element, preferably the sending network element,
`
`to
`
`35
`
`specify whether or not the message is to be stored, or
`
`stored—and—forwarded, by respectively setting or including
`
`

`
`WO 02107396
`
`PCTt'EPO(}f06708
`
`the identifier. This protocol portion is preferably part of
`
`the protocol header. The message receiving element which
`
`may be the serving network element serving the presently
`
`unreachable receiving network element,
`
`is able to easily
`
`5
`
`check the protocol header with regard to existence of such
`
`a store, or store-and—forward, command, and will decide on
`
`storing or discarding of the message depending on the
`
`command included in the protocol header (if any).
`
`10
`
`The message is preferable sent in an INVITE request or in
`
`other SIP request sent
`
`from the sending to the receiving
`
`equipment.
`
`lg
`
`When the command is a mere "store" command,
`
`the message
`
`15
`
`will be stored, and the sending equipment will have to
`
`search for any stored messages, e.g. when re—attaching to
`
`the network.
`
`In case of a store—and~forward command,
`
`the
`
`system is adapted to automatically forward the message to
`
`the receiving equipment. This forwarding may e.g. be tried
`
`20
`
`on a periodical basis, or may be performed when detecting
`
`that the receiving equipment can be reached again.
`
`The network element providing this storing, or storing—and—
`
`forwarding service may be a server such as a proxy server
`
`25
`
`which is already provided as part of existing networks.
`
`In the following, further aspects,
`
`features and advantages
`
`of the invention will be described with reference to some
`
`embodiments as shown in the drawings.
`
`30
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`Figs.
`
`1 and 2 illustrate a preferred embodiment of a
`
`35
`
`communication system in accordance with the invention;
`
`

`
`W0 ll2;"07396
`
`PC'I'!EPlJOJ'06708
`
`Fig.
`
`3 shows the basic signalling messages between user
`
`equipments based on SIP;
`
`Figs.
`
`4 and 5 show further examples of successful SIP to
`
`5
`
`SIP messaging using two proxy servers;
`
`Fig.
`
`6 illustrates the basic structure of a protocol word
`
`adapted in accordance with one implementation of the
`
`invention (based on SIP):
`
`10
`
`Fig.
`
`7 shows a flow diagram illustrating an embodiment of a
`
`method according to the invention; and
`
`Fig.
`
`8 shows a block diagram of an embodiment of a system
`
`15
`
`in accordance with the invention.
`
`.i
`
`DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE
`
`INVENTION
`
`20
`
`Fig.
`
`1 shows a first embodiment of the invention and
`
`illustrates a case where a message is to be sent from a
`
`first network element 1 {user A)
`
`to a second network
`
`element 3
`
`(user B). The network elements 1,
`
`3 are,
`
`in the
`
`25
`
`present embodiment, client or user equipments such as
`
`terminals.
`
`In the present example,
`
`the network element 1
`
`{user A)
`
`is an equipment trying to send a message (e.g.
`
`"MESSAGE user_b@sonera.com" addressed to user_b@sonera.com)
`
`to the receiving element 3
`
`(user B} which is presently out
`
`30
`
`of reachh e.g. switched-off, busy, or located in a non-
`
`supported area, or the like. The connection request of
`
`network element 1 is handled by a network element 2 which
`
`may be a server (such as a proxy server) which provides
`
`e.g. CSCF (Call Server Control Function], and/or is a home
`
`35
`
`location server which contains a database storing
`
`information on the present locations of network element 3
`
`

`
`W0 lJ2.’07396
`
`PCT!'EP00f06708
`
`and further network elements, reachability thereof, and the
`
`like.
`
`As shown in Fig. 1,
`
`the server 2 stores parameters for
`
`5
`
`several users (user equipments)
`
`to be served by server 2.
`
`These parameters define the users profiles, network
`
`capabilities, and status of the users and terminals. For
`
`user B,
`
`the server 2 stores the information “out-ofereach";
`
`"store—and~forward: notify"; "accepts:
`
`jpeg,gif", etc. This
`
`10
`
`information may be updated by the server 2 or equipment
`
`3
`
`e.g. when re—entering the serving area of server 2, or when
`
`equipment 3 wants to change or supplement the types of
`acceptable messages. The "accepts" field defines the types
`of acceptable messages. The field "store—and?forward" can
`
`15
`
`be set by equipment 3, or by the operator or service
`
`provider of the network to "NO",
`
`"YES",
`
`"NOTIFY"
`
`(when the
`
`sending user is to be notified after successful delivery of
`
`the message to the user B)", "Forwarding Address or Service
`for forwarding messages", and the like. The operator or
`
`20
`
`service provider may provide different storing services for
`
`different subscribers, such as no storing possibility for
`
`normal subscribers, and storing possibility for premium
`
`subscribers.
`
`25
`
`The server 2 furthermore stores e.g. for user C the present
`
`IP address "172.3.2.2" for reaching user C, e.g,_via SIP.
`For user C,
`the field "store—and—forward" is set to "to e-
`
`mail" so as to forward any incoming SIP message to the e-
`
`mail address of user C. The server 2 preferably contains
`
`30
`
`further information for users B, C and additional users
`
`served by this server.
`
`The network additionally contains a network element such as
`
`a server 4 used for storing any SIP message not promptly
`
`35
`
`deliverable to the intended recipient. This server 4 is,
`
`in
`
`the present embodiment, not only used as a storing server
`
`

`
`W0 ll2;"07396
`
`PC'I'!EPl|0.*'06708
`
`but also as a forwarding server for actively forwarding any
`
`stored message to the recipient, e.g. periodically or when
`
`receiving information that the recipient is reachable
`
`again.
`
`(_,-'‘|
`
`As mentioned above,
`
`in the example shown in Fig.
`
`l,
`
`the
`
`user A is trying to send a message "MESSAGE
`
`USER_B@sonera.com" to user B using SIP. The SIP message is
`
`handled by server 2 which checks reachability of the
`
`10
`
`recipient user B and detects that user B is presently out
`
`of reach. The server 2 then checks the contents of its
`
`database field "store—and—forward" set for user B, and
`detects the condition "notify". Server 2 additionally
`checks the type of received message which,
`in the present
`example, may be a type "jpeg". When this type of message is
`
`_
`
`15
`
`not comprised in the types mentioned in the field
`
`"accepts",
`
`the message is discarded. Otherwise, server 2
`
`addresses server 4 for saving the presently undeliverable
`
`message received from user A. Hence,
`
`the SIP message is
`
`20
`
`stored in the database of server 4 and waiting for later
`
`delivery to user B.
`
`Fig.
`
`2 shows the embodiment of Fig.
`
`1 in a condition where
`
`the user equipment 3
`
`(user B) can be reached againu When
`
`25
`
`the user equipment 3 can be reached again, it will usually
`
`send a message signalling its present state or condition,
`
`e.g. its intention to receive access to the network. Such a
`
`message is shown in Fig.
`
`2 as step 1.) and may consist in a
`
`request "register",
`
`"PDP context activation“, or the like,
`
`30
`
`depending on the type of network and the like. Such a
`
`request is addressed to server 2 which therefore recognises
`
`the reachability of equipment 3. When detecting this
`
`situation,
`
`the server 2 sends,
`
`in step 2.} of Fig. 2, a
`
`message "notify: user B is on-line" to server 4. The server
`
`35
`
`4 checks its database with regard to any waiting message or
`
`messages stored for user B. When detecting such messages,
`
`

`
`W0 l]2f0'.r'396
`
`PCT.-"EP00.’067l]8
`
`the server 4 sends this message or messages directly to
`
`user equipment 3 as shown in step 3.);
`
`"MESSAGE
`
`USER_B@sonera.com". The server 4 may also be adapted to
`send a confirmation to server 2 after successful
`
`5
`
`transmission of the stored messages to user equipment 3.
`
`The server 2
`
`then preferably sends,
`
`in step 4.), a message
`
`to user equipment
`
`1
`
`informing the latter on successful
`
`delivery of the message to user equipment 3. This message
`
`is shown in Fig.
`
`2 as "NOTIFY A: contents has been
`
`10
`
`received".
`
`Furthermore,
`the server 2 changes the conditions set for
`user B from "out of reach“ to e.g.
`the address of user B,
`
`and/or the field "store—and~forward“ to "YES".
`
`In the
`
`15
`
`latter case, any message received for user B during
`
`subsequent unreachability thereof will simply be stored and
`
`forwarded after later reachability of user B, without
`
`sending any "notify" message to user A such as shown in
`
`step 4.) of Fig. 2.
`
`20
`
`As illustrated in Fig. 2,
`
`the server 2 may meanwhile also
`
`have changed the contents of the fields for user C from "to
`
`e-mail" (Fig.
`
`l)
`
`to "NO" based on information received from
`
`the equipment of user C or the network operator or service
`
`25
`
`provider.
`
`The present invention therefore guarantees that the message
`
`contents (e.g.
`
`image or audio contents) of a SIP message is
`
`delivered to the receiver even if the receiver should be
`
`30
`
`presently.out of reach or occupied. For achieving this
`
`function,
`
`the invention defines an extension to the syntax
`
`of a connection protocol such as SIP which allows the
`
`sender to define whether or not the message should be
`
`temporarily stored when the receiver should presently be
`
`35
`
`out of reach, and should be sent to the receiver as soon as
`
`possible. This local temporary storage of the message is
`
`

`
`W0 ll2;"07396
`
`PC'I'!EPlJOJ'06708
`
`performed taking account of the present status of the
`
`receiver. The storing place may be defined by the sender by
`
`adding a storing place address to the message. The storing
`
`place may also be defined by the serving server 2.
`
`5
`
`The standardisation drafts for SIP define that there may be
`
`a "request—disposition" header to specify caller
`
`preferences for the way how a server such as server 2
`
`should process a request. The header can include the
`
`10
`
`following items:
`
`Request-disposition = "Request—disposition" ":"
`l# (proxy-feature I cancel~feature I
`fork—feature I recurse—feature |
`para1lel—feature I queue—feature I
`ring—feature)
`"proxy" I "redirect"
`"cancel" I
`"no—cancel"
`"fork" I "no-fork"
`"recurse" I "no-recurse"
`
`[I
`II
`I1
`
`[I
`
`proxy—feature
`cancel—feature
`fork—feature
`recurse—feature
`
`15
`
`20
`
`parallel—feature
`queue—feature
`ring—feature
`
`"parallel" I "sequential"
`"queue"
`[
`"no—queue"
`"ring" I
`"no—ring"
`
`The invention extends this header to specify also "do—not—
`
`25
`
`store" and "store~and—forward—if-not—reached", and the
`
`like.
`
`"Do-not—store" means that this message should not be
`
`stored (e.g. it is instant in nature).
`
`"Store—and—forward—
`
`30
`
`if—not—reached" means that this message should be stored,
`in a place defined by the sender, since it is important.
`
`E.g. if receiver was out-of—reach, this message is stored
`
`temporarily and sent
`
`to the receiver afterwards, as soon
`
`as possible. Usually local proxy (or e.g. yahoo like of
`
`35
`
`proxy} will be the storing place. That proxy will be
`
`subscribed to presence status service and waits for a
`
`receiver to become on—line. When the receiver becomes on-
`
`line,
`
`the proxy gets a notification, and sends the message
`
`to the receiver. After 200 OK message,
`
`the proxy also
`
`10
`
`

`
`W0 02.-"0'!396
`
`PCTIEPBU.-‘H6708
`
`(optionally) notifies the original sender that "Message
`
`has been delivered", using SIP NOTIFY method.
`
`The above—described implementation ensures correct delivery
`
`5
`
`to the receiver as soon as same is reachable again, e.g.
`
`after re-attaching to the network or terminating any
`
`ongoing call.
`
`Fig.
`
`4 shows a basic example of a SIP call performed when
`
`10
`
`trying to establish a bi—directional media connection "Both
`
`way RTP media". The example of Fig.
`
`4 shows a successful
`
`SIP to SIP connection between users A and B through two
`proxy servers, proxy 1 and proxy 2. The numbering F1 to F23
`attached to the steps of Fig.
`4 indicate the flow sequence
`
`15
`
`whereas the words or numbers in front of this step
`
`numbering are in line with the definition of the SIP
`
`protocol. As the message flow and sequence steps of Fig.
`
`4
`
`are self—explanatory, no more detailed description is
`
`necessary.
`
`20
`
`When,
`
`in accordance with the above-described embodiments,
`
`SIP is used for messaging, no "both way RTP media" is set-
`
`up. The flow may therefore proceed,
`
`in accordance with one
`
`embodiment of the present invention, as shown in Fig. 5.
`
`25
`
`There are several flow possibilities to achieve SIP-based
`
`messaging.
`
`The INVITE request message sent in step E4 of Fig.
`
`5
`
`contains the message payload (MIME types) Sent from user A
`
`30
`
`to user B.
`
`In the following, one example of the INVITE request from
`
`user A to proxy 1 is shown:
`
`35
`
`F4
`
`INVITE A —> Proxy 1
`
`ll
`
`

`
`W0 ll2;"07396
`
`PC'I'!EPl|0.*'06708
`
`INVITE sip:UserB@ss1.wcom.com SIP/2.0
`Via: SIP/2.0/UDP here.com:5060
`
`From: BigGuy <sip:UserA@here.com>
`To: Litt1eGuy <sip:UserB@there.com>
`Call-ID:
`l2345601@here.com
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`INVITE
`1
`CSeq:
`Contact: BigGuy <sip:UserA@here.oom>
`Authorization:Digest username="UserA",
`Worldcom SIP",
`nonce="wf84f1Cec2x41ae6cbe5aea9c8e88d359",
`
`rea1m="MCI
`
`opaque=n It !
`
`uri="sip:ssl.wcom.com",
`response="42ce3oef44b22f50c6a6071bo8"
`Content-Type: multipart/mixed;
`boundary=gc0pJq0M:08jU534c0p
`Content—Length: 147
`
`v=0
`o=UserA 2890844526 2890844526 IN IP4.here.oom
`s=Session SDP
`c=IN IP4 100.101.102.103
`t=0 0
`.
`m=audio 49170 RTP/AVE 0
`
`a=rtpmap:0 PCMU/8000
`
`———— ——_=_NextPart_gc0pJq0M:08jU534c0p
`Content~Type:
`image/jpeg; charset="iso~8859—1"
`
`R01GOD1huQEFAfAAAAAAAP///yH5BAEAAAEALAAAAAC5AQUBAAL+jI+py+0
`P4wKUyouz3rz?D4biSJZmUAEn17ZW51brTNf2jec6FrvKC+sJhz0IMcWQ7Z
`bMpvO5U01RVKnliM1qt9wuFwoOi8dkr/mMTqu35Lb7DRet5/S6nRjP6/d8w
`/0PGOjVR1hoyCSYqLgIdOj4CBnCOE1JF3mJmR1Rydn5pQkamnn1WWqqJJqq
`anjaaroKG5vnS1spe4tbVrsrmOv7+8QrXAdcbIwzNaw8eNzsvLQcjfRMXWO
`jvWytvW1C
`
`If there is more than one payload
`in SIP,
`then multiparty MIME is used, as shown in the above
`examp1e(Content—Type: multipart/mixed;
`boundary=gc0pJq0M:08jU534c0p).
`In the payload itself there
`are different MIME—types, separated by boundary.
`
`If user B is not reachable then the immediate sending
`fails.
`
`
`
`12
`
`

`
`W0 02.-"0'!396
`
`PCTIEPBU.-‘H6708
`
`In order to have a store and forward service in accordance
`
`with the invention, several possibilities are described
`below.
`
`(41
`
`I—' Using the SIP forward capabilities:
`
`User B has a "forwarding on not reachable" activated at
`
`proxy 2
`
`(which may correspond to server 2 of Figs. 1, 2)-
`
`If User B can not be reached by proxy 2 then the proxy 2
`
`forwards the message to the user's B "ghost user agent" B2,
`
`10
`
`which can be a "connected" device which is always reachable
`
`/ online, such as server 4. Then user agent B2 periodically
`
`tries to forward the message (using the same SIP based
`messaging capabilities) to the User agent Bfof the user B.
`The periodical forwarding timer can be of any kind. It may
`
`15
`
`also be provided that the user agent B2 tries to forward
`
`the message only for a certain time and then discards it.
`
`2. Forwarding the message payload to the user's B e-mail
`
`address:
`
`20
`
`If user B is not reachable by the proxy 2,
`
`then proxy 2
`
`transfers the message payload (MIME type)
`
`to the user*s B
`
`e—mail address (e.g. with SMTP) which may be specified in
`
`the INVITE message or which may be contained in a user
`
`profile option used by proxy 2.
`
`25
`
`3. Forward to MMS server:
`
`Same as in 2, but the message payload {MIME types} is
`
`forwarded to a MMS server. MMS stands for Multimedia
`
`Messaging Service as defined in 3GPP 22.l4O and 23.140. The
`
`30
`
`message is delivered when user B becomes reachable by the
`
`MMS server. This can be part of the user's B profile.
`
`4. Forward to SMSC:
`
`Same as in 2, but the text part of the message (MIME type
`
`35
`
`TXT)
`
`is forwarded to the SMSC (Short Message Service
`
`13
`
`

`
`W0 ll2;"07396
`
`PC'I'!EPl|0.*'06708
`
`Centre}. The message is delivered when user B becomes
`
`reachable by the SMSC. This may be also part of the user's
`
`B profile.
`
`5
`
`Fig.
`
`6 shows an example of a basic structure of a SIP
`
`protocol word adapted in accordance with the present
`
`invention. The protocol word contains a header 11 which,
`
`in
`
`accordance with the invention,
`
`includes a "store command"
`
`field (as part of the protocol word). The "gtore Command"
`
`10
`
`field represents or includes an identifier which may be
`
`set, by the sender of the message,
`
`to the settings "store",
`
`"store—and—forward", "notify", or "do not store". The
`protocol word furthermore contains a messagedportion 12
`containing a message e.g. of MIME type, and the usual end
`field 13.
`
`15
`
`In this example, a SIP INVITE message is used for carrying
`
`the payload, wherein the payload is inserted into the MIME
`
`field 12. When the receiving user B has activated
`
`20
`
`"forwarding on not reachable“ in his/her proxy server 2,
`
`the proxy server 2 will forward any received SIP message to
`
`a network element such as network element 4 {ghost user
`
`agent) which is a device always connected to the proxy
`
`server. The proxy server 2, or the server 4 may be adapted
`
`25
`
`to periodically try to forward any stored message (using
`
`SIP)
`
`to the user equipment 3. A maximum lifetime period can
`
`be defined for undelivered messages saved in the storing
`
`network element such as server 4. Upon expiry of the
`
`lifetime period, stored undelivered messages will be
`
`30
`
`cancelled.
`
`As discussed above,
`
`the message payload may also be re-
`
`addressed to another address when the receiving user should
`
`not be reachable or occupied or the like, and may be
`
`35
`
`addressed e.g.
`
`to the e-mail address {see the parameters
`
`14
`
`

`
`W0 02.307396
`
`PCTt'EPO{}f06708
`
`stored for user C in Fig. 1), a MMS server,
`
`a SMSC, or the
`
`like.
`
`Fig.
`
`7 shows a flow chart illustrating method steps
`
`5
`
`executed in an embodiment of the invention. Steps 701 to
`
`703 may be executed in a sender which may be the user
`
`equipment 1 of user A.
`
`In step 701, a messaging (i.e. no
`
`signalling) message to be sent is received which message
`
`may be input by a user via a terminal such as keyboard,
`
`10
`
`digital camera and the like. On some embodiments message is
`
`received from another network element such as a messaging
`
`gateway acting as a gateway between the messaging system of
`
`the SIP based network and the WAP service centers connected
`
`to the GSM network. An identifier is included into, or
`
`15
`
`added to,
`
`the message in step 702. The message and the
`
`identifier may be included into a protocol word such as
`
`SIP. Thereafter the message is sent in step ?03. The sent
`
`message will be received,
`
`in step 704, by the addressed
`
`network element such as server 2 of Figs. 1, 2.
`
`20
`
`The reachability of the recipient indicated in the message
`
`or transmitting protocol is Checked in steps 705 and 706.
`
`When the recipient is reachable,
`
`the message is sent to the
`
`recipient in step 707. When,
`
`to the contrary,
`
`the recipient
`
`25
`
`is presently not reachable, e.g. busy or de-attached from
`
`the network,
`
`the process proceeds to step ?O8 where the
`
`identifier of the received message is checked in order to
`
`decide on the temporary storing (step 709) of the message
`
`in an internal or external memory, e.g.
`
`in server 4, or
`
`30
`
`immediate_discarding of the message {step 710), depending
`on the status of the identifier. The status of the
`
`identifier may e.g. have the value "00" for storing, "ll"
`
`for discarding,
`
`"01" for "Notify sender after delivery to
`
`the Recipient", and the like.
`
`35
`
`15
`
`

`
`W0 lJ2.’07396
`
`PCT!'EP00f06708
`
`when a message is stored,
`
`the step 705 may be repeatedly
`
`executed until reachability of the sender is detected. The
`
`step 705 may additionally or alternatively be triggered
`
`e.g. when the recipient attaches again to the network. When
`
`5
`
`reachability is found,
`
`the stored message is read out of
`
`the memory, and is sent to the recipient, e.g.
`4 or 2.
`
`from server
`
`Fig.
`
`8 shows a block diagram of network elements of an
`
`10
`
`embodiment of a system according to the invention. A sender
`
`80 includes a receiving means 801 for receiving a messaging
`(i.e. no signalling) message (user traffic) to be sent, and
`is adapted to execute step 701 of Fig. 7. Theimessage may
`be input via a terminal such as keyboard, digital camera
`
`15
`
`and the like, or from another network element. The sender
`
`80 further comprises an including means 802 for adding, or
`
`including, an identifier into the message, and eventually
`
`including the message into one or more protocol words of a
`
`messaging enabling protocol such as SIP, so as to carry out
`
`20
`
`step 702. A sending means 803 is adapted to execute step
`
`703,
`
`i.e.
`
`to send the protocol word(s)
`
`including the
`
`message and the identifier to a serving network element 81
`
`such as server 2.
`
`25
`
`The serving network element 81 is adapted to carry out the
`
`steps 704 to 710 shown in Fig. 7. The serving network
`
`element comprises a receiving means 811 for receiving
`
`messages, e.g.
`
`the protocol word(s) sent from sender 80,
`
`and a reachability checking means 812 which checks whether
`
`30
`
`the intended recipient 82 can be accessed so that the
`message can be promptly delivered to the intended recipient
`
`82. If yes,
`
`the message is sent to a sending means 813 of
`
`the serving network element 81. The sending means 813 sends
`
`the message to the indicated receiving address, i.e.
`
`to the
`
`35
`
`recipient 82.
`
`l6
`
`

`
`W0 ll2;"07396
`
`PC'I'!EPlJOJ'06708
`
`When the checking means 812 detects that the recipient 81
`can presently not be reached, it transfers the message to a
`
`checking means 814 which is adapted to check whether the
`
`message is to be stored or discarded. The checking means
`
`5
`
`814 performs this check by examining the identifier
`
`included in the message or protocol word. When the
`
`identifier does not command a storing of the message,
`
`the
`
`message is discarded by a discarding means 816 which e.g.
`
`actively deletes the message or simply inhibits a storing
`
`10
`
`thereof. Otherwise, when the identifier commands the
`
`storing of the message if not promptly deliverable,
`
`the
`
`checking means 814 sends the message to a storing means 815
`which may be an internal memory or an external storage such
`as in server 4.
`:
`
`15
`
`When the checking means 812 subsequently detects that the
`
`recipient 81 may be reached again, it either retrieves the
`
`stored message from the storing means 815 and transfers the
`
`message to the sending means 813, or instructs the storing
`
`20
`
`means 815 to transmit the message to the recipient Bl via
`
`other means, e.g. server 4.
`
`According to one embodiment of the invention,
`
`the header
`
`11,
`
`in particular,
`
`the Request-Disposition part, of the SIP
`
`25
`
`protocol word is newly defined so as to include an
`
`identifier, preferably the protocol portion "store command
`
`field" which may contain the Commands "do—not-store" or
`
`"store—and—forward-if—not—reached" according to the setting
`
`of