WO2007114616A1

WO2007114616A1 - A system and method for poc box management

Info

Publication number: WO2007114616A1
Application number: PCT/KR2007/001589
Authority: WO
Inventors: Thirumalai Echampadi Seshadri; Sung Jin Park; Mayuresh Madhukar Patil
Original assignee: Samsung Electronics Co., Ltd.
Priority date: 2006-03-31
Filing date: 2007-03-31
Publication date: 2007-10-11

Abstract

The invention relates to Voice over Internet Protocol (VOIP) technology and more particularly, to Push to Talk over Cellular (PoC) technology. According to the invention, a PoC client perform PoC box management (or media archiving) without introducing any new interface at the service provider end. The PoC client makes use of Real Time Control Protocol (RTCP) signaling for accessing and archiving media contents during live PoC communication.

Description

A SYSTEM AND METHOD FOR POC BOX MANAGEMENT

Technical Field

[1] The present invention, in general relates to the field of communication. More specifically the invention relates to the Voice over IP technology, where the user communicates using different real-time media like audio, video, and discrete message like Image, Text. The invention relates to the Push to Talk over Cellular technology, where the user takes part in a half-duplex mode of communication, and message is archived at a storage managed by the PoC(Push to Talk over Cellular) Service Providers, and the messages may be some of the contents like audios, videos, images, texts something like that. More particularly this invention relates to a system and method for PoC box management. Background Art

[2] Message archival is common mechanism available across different communication systems. However the management of message archival is a challenging aspect considering the deployment scenario of message archival. These challenging aspects could be related to the complexity involved, optimization of resources and deployment synergies. Currently 0MA(0pen Mobile Alliance) defines an application infrastructure for Push to Talk over Cellular service where the message archival mechanism is known as PoC Box. Disclosure of Invention Technical Problem

[3] 1. Introduces a new interface to PoC Architecture.

[4] 2. Increases the complexity to the PoC Architecture.

[5] 3. Increases the cost.

Technical Solution

[6] The objective of this invention is to propose some of the application extensions that enable the PoC system to perform the PoC Box management without introducing any more new interfaces. The application extensions is built over the existing interfaces, which is very well utilized by the PoC architecture, and tailor made for PoC Box management requirements. The invention is a system and method for PoC Box Access, where the PoC client gets the access to the PoC Box media in PoC architecture. Advantageous Effects

[7] 1.No need to introduce any new interface to PoC Architecture.

[8] 2.No complexity to the PoC Architecture.

[9] 3. Easy deployment. [10] 4.Saves the development efforts and easy to adapt in PoC architecture.

Brief Description of the Drawings

[11] Figure 1 depicts a logical PoC architecture.

[12] Figure 2 depicts the overall flow User plane level procedure for PLAY option.

[13] Figure 3 depicts the overall flow User plane level procedure for PAUSE option.

[14] Figure 4 depicts the overall flow User plane level procedure for PLAY option.

[15] Figure 5 depicts the overall flow User plane level procedure for PAUSE option.

[16] Figure 6 depicts the overall flow User plane level procedure for MESSAGE removal option.

[17] Figure 7 depicts the overall flow User plane level procedure for retrieveing meta information from PoC Box. Best Mode for Carrying Out the Invention

[18] System architecture for PoC Box management, to which an embodiment of the present invention is applicable, will now be described with reference to FIG. 1. XCAP is used as a protocol of an interface between a Device 160 with a PoC Client 100 and an aggregation Proxy 140, and between the aggregation Proxy 140 and a PoC XDM 130; SIP is used as a protocol of an interface between the Device 160 and an SIP/IP Core 110, between the SIP/IP Core 110 and the PoC XDM 130, between the SIP/IP Core 110 and a PoC Server 120, and between the SIP/IP Core 110 and a PoC Box 150; and RTP is used as a protocol of an interface between the Device 160 and the PoC Server 120. In addition, XCAP is used as a protocol an interface between the aggregation Proxy 140 and the PoC Box 150.

[19] Push to Talk over Cellular is a half-duplex communication mode, which allows only one user to burst media at a time and remaining users to receive the media. PoC technology may allow a PoC conversation to be archived as decided by the user. Archival of PoC conversation may be performed at the service provider end considering an advantage of huge storage space. The media information is generally archived in a media server, called PoC Box(150). The management of PoC Box(150) at the network side can equally impose a challenge considering the following user cases:

[20] i. A user may opt to perform a playing/retrieving activity over full or part of message information exchanged in a conversation

[21] ii. A user may opt to pause an ongoing Playing activity.

[22] iii. A user may opt to perform a playing activity from where it has been paused previously.

[23] iv. A user may want to retrieve the Meta information.

[24] v. A user may want to search for message information available information in a PoC Box.

[25] vi. A user may want to delete the message information archived at the PoC Box.

[26] vii. A user may want to perform Meta information related management.

[27] These are the assumptions pertaining to the present invention

[28] 1. Message related information are classified into two categories:

[29] a) Meta Information: It contains the media property information

[30] b) Media Content: Actual media information maintained in the PoC Box.

[31] 2. Meta Information is expected to be maintained in a XML document fashion in the

PoC XDM Server(130). This will allow the PoC System to reuse the XCAP functionalities and XML advantageous.

[32] 3. Media information is expected to be maintained in the media server i.e PoC Box.

[33] 4. PoC Box(150) is a media server cum PoC entity, which can take part in a PoC session, as that of normal of PoC Client(lOO). PoC Box(150) is also expected to be aware of Media Burst Control procedures.

[34] For PoC Box(150) related communication and management, the PoC system can make use the same RTCP/RTP interface within a SIP dialogue. This invention proposes some the application extensions that can be built with RTCP APP message.

[35] The following describes the playing of message from a PoC Box(150):

[36] Playing a message from a PoC Box(150) is a sequence of activities that allow the

PoC user to retrieve a selected message stored in the PoC Box(150), as a result of recording. To retrieve the PoC Box message, the user makes use of the Meta information stored in the PoC XDM. PoC User establishes a PoC session Session with PoC Box(150), and sends a MBCP message to PoC Server, to start playing the message from a PoC Box(150). Upon receiving the MBCP message for playing the message, the PoC Server sends a MBCP Granted message to the PoC Box(150), with the identity token of the PoC message. The PoC Box(150) sends the appropriate message information identified by the token. PoC User starts receiving the message.

[37] Indication of PLAYING using a MBCP message can be achieved using RTCP APP extension. A playing control applied using a RTCP channel, controls only the associated RTP session, thereby the playing control needs to applied for each RTCP channel associated with RTP message in case a PoC session contains multiple message like Voice, Video, etc.,

[38] Additionally the MBCP message for play control may convey the specific location from where the play needs to be resumed within the streaming content. Absence of this specific location indicates that the Streamed content needs to be played from the beginning.

[39] The following MBCP message defines the RTCP: APP structure for the PLAYING message without implicit PAUSE option.(Table 1) [40] Table 1 [Table 1]

[41] The following bit pattern in the subtype field SHALL be used for the PoC Box PLAY message: 11101 [42] Herein, 11101 is given as an example, and is replaceable with a predetermined appropriate value according to system or operator.

[43] The length value varies based on the application data field. [44] The SSRC value SHALL carry the SSRC value of the PoC Client(lOO). [45] For PoC the ASCII name string SHALL be the string equivalent to PoC Version. [46] For additional data field, there are entries. [47] 1. Media Identity Token [48] Field => 101 (Decimal) for Media Identity Token [49] Length => Bytes Length of the Media identity token [50] Media Identity Token => Unique identifier for identify the location of message in a PoC Box(l 50).

[51] 2. Media Location Token => OPTIONAL [52] Field => 102 (Decimal) for Media Identity Token [53] Length => Bytes Length of the Media Location token [54] Media Location Token => Unique identifier for specify the location within the messages from where media needs to be played.

[55] Note: This value is calculated by PoC Box(150) based on the media type. How this value is determined is implementation depedant. Some of the examples for the value of this field are given below,

[56] In case of the video based media the location token would be time value. So PoC Box(150) will include the time attribute in this token [57] In case of the Image based media, the location token would be indicator of the images from the lists of images. [58] In case of Audio based media, the location token would be time value. [59] 3. Media Length Timer [60] Field => 103 (Decimal) for Media Length Timer [61] Length => Bytes Length of the Media Length Timer Value [62] Media Length Timer => Timer value in sees to define the length of the play time. [63] 4. Padding Bits => OPTIONAL [64] This is used to pack the RTCP packet in 32 Bits frames. All bits are set to O's. [65] It is assumed each conference session can have multiple recording sessions within itself.

[66] The following MBCP message defines the RTCP: APP structure for the PLAYing media with PAUSE option. [67] Table 2 [Table 2]

[68] The following bit pattern in the subtype field SHALL be used for the PoC Box PLAY message: 11101 [69] Herein, 11101 is given as an example, and is replaceable with a predetermined appropriate value according to system or operator.

[70] The length value varies based on the application data field. [71] The SSRC value SHALL carry the SSRC value of the PoC Client(lOO). [72] For PoC the ASCII name string SHALL be the string equivalent to PoC Version. [73] For additional data field, there are entries for [74] 1. Media Identity Token [75] Field => 101 (Decimal) for Media Identity Token [76] Length => Bytes Length of the Media identity token [77] Media Identity Token => Unique identifier for identify the location of message in a PoC Box(l 50).

[78] 2. Media Location Token => OPTIONAL [79] Field => 102 (Decimal) for Media Identity Token [80] Length => Bytes Length of the Media Location token [81] Media Location Token => Unique identifier for specify the location within the messages from where media needs to be played.

[82] 3. Media Length Timer [83] Field => 103 (Decimal) for Media Length Timer [84] Length => Bytes Length of the Media Length Timer Value [85] Media Length Timer => Timer value in sees to define the length of the play time. [86] 4. Play Enable / Disable Bit - E [87] This bit instructs whether the media needs to be played from PoC Box(150) or not. [88] The value 1 means PLAY media. [89] The value 0 means PAUSE media. [90] 5. Padding Bits => OPTIONAL [91] This is used to pack the RTCP packet in 32 Bits frames. All bits are set to O's. [92] It is assumed each conference session can have multiple recording sessions within itself.

[93] The following RTCP: APP structure defines the impact on the MBCP Grant messages due to MBCP PLAY procedure.

[94] Following Table 3 shows the example RTCP: APP GRANT message format. [95] Table 3 [Table 3]

[96] The above MBCP GRANT message contains two more OPTIONAL fields to indicate the Media Identity Token and Media Location Token parameters, as received from RTCP: APP PLAY message. Upon receiving the message, the PoC Box(150) shall attempt to play the media identified by the token. The PoC Box(150) should also play the media from the location point mentioned by the Media Location Token.

[97] The overall flow User plane level procedure is depicted in the Figure 2 or Figure 4 for PLAY option. [98] With reference to FIG. 2, a description will now be made of a signal flow in which the PoC Client A(IOO) sends a media request to the PoC BoX(150) using the foregoing

MBCP message according to an embodiment of the present invention. [99] Assume that a PoC session is established between the PoC client A(IOO) and the PoC

Box(150). [100] 1. A PoC user pushes a PoC button to send a request for delivery of a specific message to the PoC BoX(150). [101] 2. The PoC Client A(IOO) sends an MBCP message with FLAG=I and Message

Identity Token to the PoC server(120). [102] 3. The PoC server (120) recognizes a command for PoC Box message play with

Subtype and FLAG, and sends a Talk Burst Grant to the PoC BoX(150). Talk Burst

Grant command also includes Message Identity Token.

[103] 4. The PoC server (120) sends a Talk Burst Taken to the PoC Client A( 100). [104] 5. The PoC BoX(150) sends a message corresponding to Message Identity Token to the PoC server (120). [105] 6. The PoC server (120) forwards the message provided from the PoC BoX(150), to the PoC Client A(IOO). [106] With reference to FIG. 4, a description will now be made of a signal flow in which the PoC Client A(IOO) sends a request for a message stored in the PoC Box(150) to the

PoC BoX(150) using the foregoing MBCP message according to another embodiment of the present invention. [107] Assume that a PoC session is established between the PoC client A(IOO) and the PoC

Box(150). [108] 1. If a PoC user pushes a PoC button to issue a request for delivery of a message stored in the PoC BoX(150), the PoC Client A(IOO) sends MBCP PLAY with Message

Identity Token to the PoC server (120). [109] 2. The PoC server(120) recognizes a command for PoC Box message play with

Subtype, and sends a Talk Burst Grant to the PoC BoX(150). Talk Burst Grant command also includes Message Identity Token.

[110] 3. The PoC server (120) sends a Talk Burst Taken to the PoC Client A( 100). [I l l] 4. The PoC BoX(150) sends a message corresponding to Message Identity Token to the PoC server (120). [112] 5. The PoC server(120) forwards the message provided from the PoC BoX(150), to the PoC Client A(IOO). [113] According to the flow, the user establishes a PoC Session with a PoC Box(150).

Once the PoC session is established, the user request the PoC Box(150) to play the message using the MBCP PLAY message or MBCP PLAY with Enabler Bit set to 1 message. Upon receiving this MBCP request, the controlling PoC Server sends TB

Grant Message to the PoC Box(150) giving the necessary information like Media Identity Token message, Media Location Token.

[114] The following describes how a media from a PoC Box(150) is paused:

[115] Pausing a media from a PoC Box(150) is a sequence of activities that allow the PoC user to stop retrieving a selected media retrieval from the PoC Box(150). To pause the retrieval of the PoC Box media, the user sends a MBCP PAUSE or MBCP PLAY (with Enabler bit set to O) message to PoC Server, to stop playing the media from a PoC Box(150). Upon receiving the MBCP message for pausing the media, the PoC Server sends a MBCP Revoke message to the PoC Box(150). MBCP Revoke message may indicate PoC Box(150) that the sending RTP media has been paused in the reason code. Upon receiving the MBCP revoke message, the PoC Box(150) should release the floor immediately. Since the user controls the PoC Box(150) in this PoC Session, the user has a better priority than the PoC Box(150).

[116] The following MBCP message defines the RTCP: APP structure for the PAUSING the media. This should be used in conjunction with RTCP: PLAY message that excludes the play enabler bit.( Tale 4 : RTCP:APP PAUSE message format.)

[117] Table 4 [Table 4]

V=2 P 1 1 1 0 0 PT=APP=204 Length

SSRC of PoC Client name PoC Version

[118] The following bit pattern in the subtype field SHALL be used for the PoC Box( 150) PAUSE message: 11100

[119] Herein, 11100 is given as an example, and is replaceable with a predetermined appropriate value according to system or operator.

[120] The length value varies based on the application data field.

[121] The SSRC value SHALL carry the SSRC value of the PoC Client(lOO).

[122] For PoC the ASCII name string SHALL be the string equivalent to PoC Version.

[123] The overall flow User plane level procedure is depicted in the Figure 3 or Figure 5 for PAUSE option.

[124] With reference to FIG. 3, a description will now be made of a signal flow in which the PoC Client A(IOO) issues a medial release request if there is a release request by a user in the course of receiving media from the PoC BoX(150) as described in FIG. 2.

[125] Assume that a PoC session is established between the PoC client A(IOO) and the PoC Box(150).

[126] 1. The PoC BoX(150) sends a corresponding message to the PoC server (120).

[127] 2. The PoC server (120) forwards the message provided from the PoC BoX(150), to the PoC Client A(IOO).

[128] 3. Upon receipt of a PoC button input for message release request from the PoC user, the PoC Client A(IOO) sends an MBCP with FLAG=O to the PoC server (120).

[129] 4. The PoC server (120) sends a Talk Burst Revoke to the PoC BoX(150).

[130] 5. The PoC BoX(150) sends a Last RTP Packet to the PoC server (120).

[131] 6. The PoC server (120) forwards the Last RTP Packet provided from the PoC BoX(150), to the PoC Client A(IOO).

[132] 7. The PoC BoX(150) sends a Talk Burst Release to the PoC server (120).

[133] 8. The PoC server (120) sends a Talk Burst Idle to the PoC Client A(IOO).

[134] 9. The PoC server (120) sends a Talk Burst Idle to the PoC BoX(150).

[135] With reference to FIG. 5, a description will now be made of a signal flow in which the PoC Client A(IOO) issues a message release request if there is a release request by a user in the course of receiving message from the PoC BoX(150) as described in FIG. 4.

[136] Assume that a PoC session is established between the PoC client A(IOO) and the PoC Box(150).

[137] 1. The PoC BoX(150) sends corresponding message to the PoC server (120).

[138] 2. The PoC server (120) forwards the message provided from the PoC BoX(150), to the PoC Client A(IOO).

[139] 3. Upon receipt of a PoC button input for media release request from the PoC user, the PoC Client A(IOO) sends an MBCP PAUSE message to the PoC server (120).

[140] 4. The PoC server (120) sends a Talk Burst Revoke to the PoC BoX(150).

[141] 5. The PoC BoX( 150) sends a Last RTP Packet to the PoC server ( 120)

[142] 6. The PoC server (120) forwards the Last RTP Packet provided from the PoC BoX(150), to the PoC Client A(IOO).

[143] 7. The PoC BoX(150) sends a Talk Burst Release to the PoC server (120).

[144] 8. The PoC server (120) sends a Talk Burst Idle to the PoC Client A( 100).

[145] 9. The PoC server (120) sends a Talk Burst Idle to the PoC BoX(150).

[146] According to the flow, the user establishes a PoC Session with a PoC Box(150).

Once the PoC session is established, the user is retrieving the PoC Media using PLAY procedure. Then user decides to stop the retrieval of PoC Media. Hence the user requests, thereby the PoC Client(lOO) issues a MBCP PAUSE or MBCP PLAY (with Enable bit as 0) request to the PoC Server. Upon receiving this request, the PoC Server initiates a MBCP revoke request to PoC Box(150) with reason as paused. Upon receiving this MBCP Revoke request, the PoC Box(150) releases the floor immediately.

[147] ii) Deleting a message file from a PoC Box(150):

[148] Deletion of a PoC Message by a PoC server is essential when the user attempts to cleanup his PoC Box(150). [149] The following RTCP: APP structure for the DELETING the message.(Table 5:

RTCP:APP DELETE message format.) [150] Table 5

[Table 5]

[151] The following bit pattern in the subtype field SHALL be used for the PoC Box DELETE message: 11111 [152] Herein, 11111 is given as an example, and is replaceable with a predetermined appropriate value according to system or operator.

[153] The length value varies based on the application data field. [154] The SSRC value SHALL carry the SSRC value of the PoC Client(lOO). [155] For PoC the ASCII name string SHALL be the string equivalent to PoC Version [156] Media Identity Token [157] Field => 101 (Decimal) for Media Identity Token [158] Length => Bytes Length of the Media identity token [159] Media Identity Token => Unique identifier for identify the location of message in a PoC Box(l 50).

[160] This RTCP: APP extension allows the user to delete a media from a PoC Box(150). PoC Server issues the RTCP request with this APP extension. Upon receiving this request, a PoC Box(150) shall attempt to remove the message as identified by the Media Identity Token as mentioned in the flow Figure 6. A decision to remove a message from the PoC Box(150), could be made by the PoC Server, by subscribing to the changes in Meta information changes, i.e, when the meta information itself is removed from the XDM server.

[161] Note if User has deleted the whole meta information from the XDMS then, PoC Server will send the MBCP delete message with token id as "O" so that PoC Box(150) can delete all the messages from the PoC Box(150).

[162] With reference to FIG. 6, a description will now be made of a signal flow in which the PoC Client A(IOO) issues a media delete request if the user desires to delete the media stored in the PoC BoX(150).

[163] Assume that a PoC session is established between the PoC client A(IOO) and the PoC Box(150). [164] 1. Upon receiving from the PoC user a PoC button input for requesting deletion of the media stored in the PoC BoX(150), the PoC Client A(IOO) sends an RTCP message (RTCP: APP DELETE) for requesting media deletion to the PoC server (120).

[165] 2. The PoC server (120) forwards the RTCP message (RTCP: APP DELETE) for requesting media deletion to the PoC BoX(150).

[166] In FIG. 6, the RTCP command can include an identifier for requesting deletion of a specific message, or an identifier for requesting deletion of all messages.

[167] In FIGs. 2 through 6, in order to send a request for a specific message to the PoC BoX(150), pause message delivery, or delete a specific message, the PoC client 100 should previously request and acquire meta information indicating information on the media stored in the PoC BoX(150).

[168] With reference to FIG. 7, a description will now be made of a signal flow in which the PoC client 100 requests and acquires meta information indicating information on the message stored in the PoC BoX(150).

[169] Assume that a PoC session is established between the PoC client A(IOO) and the PoC Box(150).

[170] 1. The PoC Client A(IOO) sends to the PoC server (120) an MBCP message (MBCP Meta- Info-Request) for requesting meta information indicating information on the media stored in the PoC Box(150).

[171] 2. The PoC server (120) forwards the MBCP message (MBCP Meta-Info-Request) provided from the PoC Client A(IOO), to the PoC Box(150).

[172] 3. The PoC Box (150) sends the requested meta information to the PoC server (120).

[173] 4. The PoC server (120) forwards the provided meta information to the PoC Client A(IOO).

[174] Meta Information Scheme is described as below:

[175] Meta information is normally giving the characteristic information about the message information. They are expected to be maintained in a XML document fashion. The characteristic information could be Conference Title, Keywords, Media Identity Token, Priority, Media Information (Ex: Audio, Video), Date and Time of recording, Length of Recorded media, Expiry Time, Priority, Participant's list, etc.,

[176] Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be affected therein by one skilled in the art without departing from the scope or spirit of the invention.

[177] Meta Information stored in the PoC Box(150):

[178] This section covers methods for the case where meta information is stored into PoC Box(150). Meta information is stored in XML document fashion. This section extends MBCP for meta information exchange. This section gives the examples format for meta information and then gives the methods for requesting the meta information and meta information exchange.

[179] i. Example Meta information document format: (Table 6 : Example Meta information document format) [180] Table 6 [Table 6]

<^?xml version^ 1 0 encoding^s' UTF-8"^?> <PB_Meta_lnfo xmlns=="urn oma params xml ns Metalnfo"> <Medιa MIT= 1234 Tιtle="lndιaπ Gambling Pπoπty="Normal Length- '12">

<Date>takeπ< 'Date> <tιme>taken</tιme> participants NOP= 4 >

<User>sa@re.com<<User> <User>ga@ma com</User> <User>pa@dha com</User> <User>nι@sa com< User> </partιcιpants> <MedιaType>Vιdeρ</Medιa> <Expιry>1233</Expιry>

</Medιa> </PB_Meta_lnfo>

[181] As shown in table 6, basic structure for meta information, Meta information has one root element called PB_Media_Info. This root element will have "Media" child element for each stored message. Media element will give meta information about stored Message in PoC Box(150). Media element has two attributes, MIT (media Identity token), and Title.MIT attribute gives actual reference to media in PoC Box(150). Title will give information about conference. Meta information can have additional information like Date, Time, participant list, Media types and expiry of media. For such kind of information corresponding information element is added in Media element like "Date", "Time", "participants", "MediaType", "Expiry", and "Priority". This is a example format for the Meta information. We can have many more information in the meta information based on requirement. This section just give basic example information structure.

[182] ii) Requesting Meta information using MBCP message: [183] This section inventions proposes new MBCP Message for requesting the Meta information from the PoC Box(150). This request is called as Meta-Info-request. PoC Server retrieves meta information from the PoC Box(150) and then send the Meta information to PoC Client(lOO) in response Meta- Info.

[184] Below show the structure for meta information request message. (Table 7) [185] Table 7 [Table 7]

V=2 P 1 0 0 1 PT=APP=204 Length

SSRC name (ASCII)

R C Length

Type Length

[186] Subtype field : 10101 (to indicate the meta information related MBCP message)

[187] R: To indicate it as request. R=OOl (Decimal). Same Message can be used for sending the response with R=000(Decimal)

[188] C: OOl(Decimal) to indicate the more information remaining and will be sent in a next response (This field will be used in a response). OOO(Decimal) means last packet.

[189] Field: This is used to indicate the parameter to be included in the meta information e.g. title, media type etc . Some of the example type as given below,

[190] 110(Decimal) - Title

[191] 111 (Decimal) - Date and time

[ 192] 112(Decimal) - Participation List

[193] 113(Decimal) - Media characteristics

[194] 114(Decimal) - Session Priority

[195] 115(Decimal) - Expiry Time

[196] 116(Decimal)) - Media total duration

[197] 117(Decimal) - Media Identity token (MIT)

[198] Length: This field will be useful in the response of meta info request. This value will be useful in parsing the packet quickly as value of mentioned field parameter will very every time. So this length field will be helpful in knowing the location of next parameter.

[199] This is the structure used for requesting the meta information from PoC Box(150). Note if Client doesn't included the optional field then default fields will be sent to Client like title, MIT, and media duration.

[200] For response also same MBCP message is used, with R field will be OOl(Decimal). Note there can be more information which may not fit into the RTCP APP body limit imposed by underlying layer (UDP/TCP). For this PoC Server will send the in^¬ formation in multiple messages, PoC Server will use the C bit field for indicating the more packets are expected with value 001 (Decimal). In case of last packet C field will have value OOO(Decimal). [201] Figure 7 shows, basic flow diagram for requesting the Meta information from the PoC Box(l 50). [202] According to the flow, the user establishes a PoC Session with a PoC Box(150). Once the PoC session is established, the user sends Meta info request. PoC Server also forward the request to PoC Box(150). PoC Box(150) send the meta information using meta-info MBCP message.

[203] iii) Alternate method for requesting meta information [204] This section present the alternate method for requesting the meta information from PoC Box(150). This gives simple solution which uses XML body structure to send in the MBCP meta information request. Note this will increase the payload size as unnecessary header fields are included in XML document. The Meta information request is as shown below. (Table 8)

[205] Table 8 [Table 8]

V=2 P 1 0 0 1 PT=APP=204 Length

SSRC name (ASCII)

Meta information request Body (XML firmat)

[206] Subtype: 10101 to indicate the Meta information request [207] Meta information request body: This is the body strutcture which gives the meta information request.

[208] In response to this request PoC Box(150) will send the meta information using the following MBCP message. This is called a Meta-info message, which will have the requested meta information. Below shows the structure of a MBCP message.

[209] Table 9 [Table 9]

V=2 P 1 0 1 1 1 PT=APP=204 Length

SSRC name (ASCII)

C Meta information

Meta information Body (XML format)

[210] Subtype: 10111 to indicate the Meta information request

[211] C: continue bit. 001 (Decimal) : another message including sequencial meta info is expected. For last packet it will have OOO(Decimal). [212] Meta information body: This is the body structure which gives the meta information.

[213] Meta information body structure will be same as given in the table 1. Note C bit will be used to maintain the continutity for messages. As Meta information may exceed the size limit of RTCP APP message imposed by underlying layers.

Claims

[1] A method for POC box management wherein a PoC client perform PoC box management without introducing any new interface at the service provider end where the PoC client uses the Real Time Control Protocol (RTCP) signaling for accessing and archiving media contents during live PoC communication.

[2] A method as claimed in claim 1 wherein PoC box management involves playing a media from a PoC Box allowing a PoC user to retrieve a selected media stored in the PoC Box, as a result of recording and to retrieve the PoC Box media, the user making use of the Meta information stored in the PoC XDM.

[3] A method as claimed in claim 2 wherein a PoC User establishes a PoC session with PoC Box, and sends a MBCP message to PoC Server, to start playing the media from a PoC Box.

[4] A method as claimed in claim 3 wherein upon receiving the MBCP message for playing the media, the PoC Server sends a MBCP Granted message to the PoC Box, with the identity token of the PoC media where the PoC Box sends the appropriate media information identified by the token and the PoC User starts receiving the media.

[5] A method as claimed in claim 4 wherein PLAYING using a MBCP message is achieved using RTCP APP extension where a playing control is applied using a RTCP channel.

[6] A method as claimed in claim 5 wherein the playing control gets applied for each

RTCP channel associated with RTP media if a PoC session contains multiple media.

[7] A method as claimed in claim 6 wherein the MBCP message for play control optionally convey the specific location from where the play needs to be resumed within the streaming content and absence of this specific location indicates that the Streamed content needs to be played from the beginning.

[8] A method as claimed in claim 7 wherein the overall flow user plane level procedure for PLAY option involves the user establishing a PoC Session with a PoC Box and once the PoC session is established, the user requesting the PoC Box to play the message using the MBCP PLAY message or MBCP PLAY with Enabler Bit set to 1 message.

[9] A method as claimed in claim 8 wherein, upon receiving this MBCP request, the controlling PoC Server sends TB Grant Message to the PoC Box giving the necessary information of Media Identity Token message and Media Location Token , where in a Talk Burst Grant message, Stop Talking Time corresponds to the Media Length Time specified in the MBCP Play Message. [10] A method as claimed in claim 1 wherein Pausing a media from a PoC Box involves allowing the PoC user to stop retrieving a selected media retrieval from the PoC Box. [11] A method as claimed in claim 10 wherein to pause the retrieval of the PoC Box media, the user sends a MBCP PAUSE or MBCP PLAY (with Enabler bit set to

0) message to PoC Server, to stop playing the media from a PoC Box. [12] A method as claimed in claim 11 wherein upon receiving the MBCP message for pausing the media, the PoC Server sends a MBCP Revoke message to the PoC

Box where the MBCP Revoke message indicate PoC Box that the sending RTP media has been paused in the reason code. [13] A method as claimed in claim 12 wherein upon receiving the MBCP revoke message, the PoC Box release the floor. [14] A method as claimed in claim 1 wherein the RTCP: APP extension allows the user to delete a media from a PoC Box where the PoC Server issues the RTCP request with this APP extension. [15] A method as claimed in claim 14 wherein upon receiving this request, a PoC Box attempts to remove the media as identified by the Media Identity Token. [16] A method as claimed in claim 15 wherein the decision to remove a media from the PoC Box, is made by the PoC Server, by subscribing to the changes in Meta information changes. [17] A system for POC box management comprising a PoC client performing PoC box management without introducing any new interface at the service provider end where the PoC client uses the Real Time Control Protocol(RTCP) signaling for accessing and archiving media contents during live PoC communication. [18] A system for managing a Push to Talk over Cellular (PoC) box in a PoC system including a PoC Client, a PoC Server and a PoC box, wherein a PoC Session of the PoC Client is established, the system comprising: the PoC box for storing meta information including at least one media and its media information, and performing control on corresponding media upon receipt of an MBCP message for controlling the media; the PoC Client for sending an MBCP message for controlling corresponding media to the PoC box via the PoC Server, upon receiving from a PoC user a request for controlling media stored in the PoC box; and the PoC Server for forwarding a received MBCP message to the PoC box upon receipt of the MBCP message from the PoC Client. [19] The system of claim 18, wherein the MBCP message includes a Media Identity and a Media Location. [20] The system of claim 18, wherein the PoC Client sends a message for sending a request for meta information to the PoC box, to the PoC box via the PoC Server, and the PoC box sends meta information to the PoC Client via the PoC Server upon receipt of the meta information request message from the PoC Client. [21] The system of claim 18, wherein the meta information is defined in an Extensible

Document Markup Language (XDML). [22] A Push to Talk over Cellular (PoC) box management method for controlling media stored in a PoC box by a PoC Client in a PoC system including the PoC

Client, a PoC Server and the PoC box, wherein a PoC Session of the PoC Client is established, the method comprising: sending, by the PoC Client, an MBCP message for controlling corresponding media to the PoC box via the PoC Server, upon receiving from a PoC user a request for controlling media stored in the PoC box; forwarding, by the PoC Server, a received MBCP message to the PoC box upon receipt of the MBCP message from the PoC Client; and performing, by the PoC box, control on corresponding media upon receipt of an

MBCP message for controlling the media. [23] The PoC box management method of claim 22, wherein the MBCP message includes a Media Identity and a Media Location. [24] The PoC box management method of claim 22, further comprising: sending, by the PoC Client, a message for sending a request for meta information to the PoC box, to the PoC box via the PoC Server; and sending, by the PoC box, meta information to the PoC Client via the PoC Server upon receipt of the meta information request message from the PoC Client. [25] The PoC box management method of claim 22, wherein the meta information is defined in an Extensible Document Markup Language (XDML).