R Ezhirpavai Internet Draft B Venkat Swamy Sunil Mahajan draft-mahajan-poc-server-package-00.txt Hughes Software Systems Expires: March 2005 September 2004 MEGACO package for Push To Talk over Cellular (PoC) Networks draft-mahajan-poc-server-package-00.txt Status of this Memo By submitting this Internet-Draft, We certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Push To Talk over cellular (PoC) networks is supported through centralised Push To Talk Servers which handles both SIP signalling and the media (RTP) relay part. This document defines a distributed architecture for PoC Server implementation with PoC signalling server handling the SIP signalling and group management, whereas Media Server handles the RTP relay part and the communication between these two servers is over MEGACO protocol using the package defined in this document. Pavai, Venkat, Sunil March 2005 -1- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 Table of Contents 1 Scope..................................................2 2 References.............................................2 3 Definitions............................................3 4 Abbreviations..........................................3 5 Introduction...........................................3 6 POC Distributed Architecture Package...................4 6.1 Properties.............................................4 6.1.1 Media Buffer Size for Early Media......................4 6.1.2 Generate Sender-Receiver Report........................5 6.1.3 PoC Server Version.....................................5 6.2 Events.................................................6 6.2.1 Floor Request..........................................6 6.2.2 Floor Release..........................................6 6.2.3 RTCP BYE...............................................7 6.2.4 Failure Cause..........................................7 6.2.5 Detect Sender Report...................................9 6.3 Signals................................................9 6.3.1 Floor Granted..........................................9 6.3.2 Floor Taken............................................9 6.3.3 Floor Deny.............................................11 6.3.4 Floor Idle.............................................11 6.3.5 Floor Revoke...........................................12 6.3.6 Send Sender Report.....................................13 6.4 Statistics.............................................14 6.5 Procedures.............................................14 6.5.1 Call Flow..............................................18 7 Authors................................................21 Intellectual Property and Copyright Statements.........22 1 Scope This document defines a MEGACO package that can be used for distributed PoC server implementation. The definition of the package is limited to functionality/features defined in PoC Release 1.0 specifications from Ericsson, Motorola, Siemens and Nokia. 2 References ITU-T Recommendation H.248.1, Gateway Control Protocol PoC Release 1.0 "PoC User Requirements" PoC Release 1.0 "PoC Architecture" PoC Release 1.0 "PoC User Plane" PoC Release 1.0 "PoC Signalling Flows" RFC 3525 "Gateway Control Protocol Version 1" Pavai, Venkat, Sunil March 2005 -2- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 3 Definitions PoC Server - PoC server is a SIP server which handles both SIP signalling to establish PoC sessions and also handles the media (RTP) relay towards all participants in the PoC call PoC Signaling Server (PSS) - PoC Signaling Server is a SIP server which handles only the SIP signalling to establish PoC sessions and instructs the Media Server over MEGACO protocol to handle the media (RTP) relay towards all participants in the PoC call PoC Media Server (PMS) - PoC Media Server is a Media server which handles media relay functions for PoC sessions based on the instructions it receives from PSS over MEGACO protocol 4 Abbreviations MEGACO Media Gateway Control Protocol PoC Push To Talk over Cellular PSS PoC Signaling Server PMS PoC Media Server RTP Real Time Transport Protocol RTCP Real Time Transport Control Protocol UE User Equipment 5 Introduction Push to talk over Cellular (PoC) introduces a new real-time direct one-to-one and one-to-many voice communication service in the cellular network. The principle of communication behind the service is simple - just push to talk. It lets mobile users send voice messages over data networks. The call connection is almost instantaneous and the receiver has the option to auto-answer the call. Like a walkie-talkie, push-to-talk is uni-directional, so callers can't talk over each other and must wait their turn to speak (Half Duplex). Push to talk defines both one-to-one and group communication for the cellular users. From the technology standpoint there are both proprietary implementations and implementation based on the standard protocols. Ericsson, Motorola, Seimens and Nokia defined a standard based PoC specification (PoC Release 1.0) that uses SIP as signalling protocol between User Terminal (UE) and PoC Server for session establishment and RTCP APP Pavai, Venkat, Sunil March 2005 -3- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 messages to handle media related signalling (Floor Control Messages). Specifications define a single PoC server entity, which handles both Media and SIP Signalling. The document defines a distributed architecture for PoC Server based on Gateway Control Protocol architecture with MEGACO protocol between two distributed components using the package defined in this document as the control mechanism to handle media component from Signalling Server. 6 PoC Distributed Architecture Package Package Name: PoC Distributed Architecture Package PackageID: pocserver, (0x00??) {Editor's note: Need to request from IANA} Description: This package defines interaction required between PoC Signalling Server and PoC Media Server through MEGACO protocol. It defines the properties, signals and events required for the control of media flow through PoC Media Server when PoC Signalling Server controls the signalling. All the events and signals for this package are detected and applied through RTCP messages. As a guideline, the PMS should always open separate RTP transport addresses for each termination created so as to detect the events based on termination rather than based on SSRC values. All the events and signals defined in this package are applied to ephemeral (RTP) terminations. Item ids 0x000B to 0x001f are reserved for future use. Version: 1 Designed to be extended only: No Extends: None 6.1 Properties 6.1.1 Media Buffer Size for Early Media Pavai, Venkat, Sunil March 2005 -4- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 Property Name: Media Buffer Size for Early Media PropertyID: mbSize, (0x0020) Description: This property indicates the maximum maximum buffer size in terms of duration in seconds for which PMS needs to buffer the talk burst in case the first peer session does not get established when media session starts from first user. If mbsize = 0, it implies that the POC Server does not intend to buffer the first talk burst. If PoC Signalling Server requests the talk burst to be sent on one or many terminations then Media Server should transmit the buffered talk burst. After transmitting that once, the talk burst should be deleted. If during transmission of the talk burst to the termination requested by PoC Signalling Server, the POC server requests for transmission to another termination as well, then PMS should transmit the remaining part of the talk burst to this termination as well. Type: Integer Possible values: 0-500 (secs) Defined in: TerminationState Characteristics: Read/Write 6.1.2 Generate Sender-Receiver Report Property Name: Generate Sender-Receiver Report PropertyID: gsr, (0x0021) Description: This instructs the PMS whether to send SR/RR on the RTCP channel or not. If the value is OFF, then the MG should not send the SR/RR value on its own, but should send when given as signal to PMS. This property is a "global" property and hence when this value is set, this value is set for all terminations that handle "pocserver" package. Type: ENUM Possible values: ON (default) or OFF Defined in: TerminationState Characteristics: Read/Write 6.1.3 PoC Server Version Property Name: PoC Server Version PropertyID: pocver, (0x0022) Description: This defines the version of the PoC Server that would be used for that session of the POC. Type: Integer Possible values: 1 or 2 (this package currently supports only version 1 of specifications) Defined in: TerminationState Characteristics: Read/Write Pavai, Venkat, Sunil March 2005 -5- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 6.2. Events 6.2.1 Floor Request Event Name: Floor Request Event ID: freq, (0x0000) Description: PSS requesting detection for floor request message for the specified termination. Events Descriptor Parameters: None Observed Events Descriptor Parameters: Parameter Name: SSRC ParameterID: ssrc, 0x0001 Type: Integer Possible values: SSRC value received in RTCP packet Description: This is the SSRC value received in RTCP packet with Floor Request message 6.2.2 Floor Release Event Name: Floor Release Event ID: frel, (0x0001) Description: PSS requests sending detection for floor release message for the specified termination. When PSS request PMS to detect with sequence no., then observed event should also specify the sequence number. If PSS requests detection of event with sequence number then PMS shall wait for RTP packet with the sequence number specified in the RTCP Floor Release message. However it shall wait for RTP (with seqeunce number) only for time "tseq" and if RTP packet not received then report floor release without observed sequence number. Value of timer "tseq" shall be configurable at PMS. Events Descriptor Parameters: Parameter Name: Sequence Number ParameterID: seqno, 0x0001 Type: ENUM Possible values: WSQ (detect with sequence no) or WOSQ (detect without sequence no). Description: This parameter suggest PMS that it should report floor release either when it has detected RTP packet with sequence number specified in Floor Release message or without waiting for sequence number (immediately report floor release) Pavai, Venkat, Sunil March 2005 -6- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 Observed Events Descriptor Parameters: Parameter Name: Observed Sequence Number ParameterID: oseqno, 0x0002 Type: Integer Possible values: sequence number received with RTCP floor release message Description: This is the sequence number received with RTCP floor release message from UE Parameter Name: SSRC ParameterID: ssrc, 0x0003 Type: Integer Possible values: SSRC value received in RTCP packet Description: This is the SSRC value received in RTCP packet with Floor Release message 6.2.3 RTCP BYE Event Name: RTCP BYE Event ID: rb, (0x0002) Description: PSS requests detection of RTCP BYE packet on the specified termination which indicates detection of end of media session without signalling session closure. This event shall also return ssrc value of RTCP session from the user terminal. Events Descriptor Parameters: None Observed Events Descriptor Parameters: Parameter Name: SSRC ParameterID: ssrc, 0x0001 Type: Integer Possible values: SSRC value received in RTCP packet Description: This is the SSRC value received in RTCP packet with RTCP BYE message 6.2.4 Failure Cause Event Name: Failure Cause Event ID: fc, (0x0003) Description: PMS needs to send these events on occurrence of a particular failure. The handling of this error at the PSS is implementation dependent. The parameter "srt" defines the duration of time in seconds for the Pavai, Venkat, Sunil March 2005 -7- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 sender-report timer. PMS needs to start this timer at end of the talk session and stop on detection of SR from the termination on which the talk burst was ongoing. If the timer elapses, it needs to send the failure cause event with SRNR cause value. The parameter "rrt" defines the duration of time in seconds for the receiver-report timer. PMS needs to start this timer on sending of SR for each termination If the timer elapses, it needs to send the failure cause event for that termination with RRNR cause value. Else timer is stopped when it receives RR from that termination. Events Descriptor Parameters: Parameter Name: Sender Report Timer (Optional) ParameterID: srt, 0x0001 Type: Integer Possible values: 1 or 2 Description: The parameter "srt" defines the duration of time in seconds for the sender-report timer. PMS needs to start this timer at end of the talk session and stop on detection of SR from the termination on which the talk burst was ongoing. If the timer elapses, it needs to send the failure cause event with SRNR cause value. Parameter Name: Receiver Report Timer (Optional) ParameterID: rrt, 0x0002 Type: Integer Possible values: 1 or 2 Description: The parameter "rrt" defines the duration of time in seconds for the receiver-report timer. PMS needs to start this timer on sending of SR for each termination. If the timer elapses, it needs to send the failure cause event for that termination with RRNR cause value. Observed Events Descriptor Parameters: Parameter Name: Cause Value ParameterID: cause, 0x0003 Type: ENUM Possible values: SRNR (Sender Report not received) RRNR (Receiver report not received) Description: Reason for generation of this event. Pavai, Venkat, Sunil March 2005 -8- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 6.2.5 Detect Sender Report Event Name: Detect Sender Report Event ID: dsr, (0x0004) Description: PSS requests PMS to detect for SR from the specified termination. On detection of the event, the PMS should also give the SSRC value received in the floor control message to the PSS Server. Events Descriptor Parameters: None Observed Events Descriptor Parameters: Parameter Name: SSRC ParameterID: ssrc, 0x0001 Type: Integer Possible values: SSRC value received in RTCP packet Description: This is the SSRC value received in RTCP packet with RTCP Sender Report message 6.3. Signals 6.3.1 Floor Granted Signal Name: Floor Granted Signal ID: fg, (0x0005) Description: PSS requests PMS to send Floor Granted Message/Command to the specified termination. Signal Type : BR Duration: Not Applicable Additional Parameters: Parameter Name: PSS SSRC Value ParameterID: pssrc, (0x0001) Type: Integer Possible values: SSRC value to be sent in RTCP packet Description: This is the SSRC value to be sent in Floor Granted message 6.3.2 Floor Taken Signal Name: Floor Taken Signal ID: ft, (0x0006) Description: PSS applies floor taken signals on the terminations specified in modify request. Here the termination ids Pavai, Venkat, Sunil March 2005 -9- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 can also be wild carded or partially wild carded in the command. The parameter "nam" gives the name and the parameter "uri" gives the SIP URI of the user who has been granted the floor. The parameter "ex_tid" specifies that the signal should not be applied on this termination if command is applied on all terminations (*) in a particular context. If the termination id specified in the command is *, then the signal needs to be applied to all terminations on the context except "ex_tid" Signal Type : BR Duration: Not Applicable Additional Parameters: Parameter Name: User Name ParameterID: nam, (0x0001) Type: String Possible values: Name of the User who is Granted Floor Description: This provide name of the user who is granted floor and should be sent in floor taken message to all specified terminations. Parameter Name: SIP URI ParameterID: uri, (0x0002) Type: String Possible values: SIP URI of the User who is Granted Floor Description: This provide SIP URI of the user who is granted floor and should be sent in floor taken message to all specified terminations. Parameter Name: PSS SSRC Value ParameterID: pssrc, (0x0003) Type: Integer Possible values: SSRC value to be sent in RTCP packet Description: This is the SSRC value to be sent in RTCP packet with RTCP Floor Taken message Parameter Name: Excluded Termination ID (Optional) ParameterID: ex_tid, (0x0004) Type: String Possible values: ID of the termination to be excluded from the list. Pavai, Venkat, Sunil March 2005 -10- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 Description: This is the ID of the termination to be excluded from signal application if this signal is applied to a wild card termination list. Typically this is the termination id of the UE, which has been granted the floor 6.3.3 Floor Deny Signal Name: Floor Deny Signal ID: fd, (0x0007) Description: PSS applies floor deny on the terminations specified in the command list. Here the termination ids can also be wild carded or partially wild carded. The cause value is mandatory and specifies the reason for the floor-deny. PSS requests PMS to send Floor Deny RTCP message to the UE(s) requesting Floor. Signal Type : BR Duration: Not Applicable Additional Parameters: Parameter Name: Cause for Denial ParameterID: cause, (0x0001) Type: Integer Possible values: 1 or 2 (Current Defined Values) Description: This is the reason code corresponding to the reason phrase parameter Parameter Name: PSS SSRC Value ParameterID: pssrc, (0x0002) Type: Integer Possible values: SSRC value to be sent in RTCP packet Description: This is the SSRC value to be sent in RTCP packet with RTCP Floor Deny message Parameter Name: Reason Phrase (Optional) ParameterID: rp, (0x0003) Type: String Possible values: This is the string specifying the reason phrase. Description: This is the reason phrase specifying the reason for floor request denial. 6.3.4 Floor Idle Signal Name: Floor Idle Signal ID: fi, (0x0008) Pavai, Venkat, Sunil March 2005 -11- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 Description: PSS applies the floor idle on the terminations specified in the command[MSOffice1]. If the termination id is * in modify command, then it is applied to all terminations in the context. The parameter "fit_start" specifies the start interval in seconds at which floor idle message is repeated. It is recommended that PMS shall ncrease this value at every repeat of floor idle till it reaches (or exceeds) "fit_max", at which floor idle is repeated at this value. Signal Type : OO Duration: Not Applicable Additional Parameters: Parameter Name: Floor Interval Start ParameterID: fit_start, (0x0001) Type: Integer Possible values: 1-100 Description: This specifies the start interval in seconds at which floor idle is repeated. Parameter Name: Floor Interval Max ParameterID: fit_max, (0x0002) Type: Integer Possible values: 1-100 Description: This specifies the max interval in seconds at which floor idle is repeated. It is expected that fit_max >= fit_start, else fit_max is assumed to be 2* fit_start Parameter Name: PSS SSRC Value ParameterID: pssrc, (0x0003) Type: Integer Possible values: SSRC value to be sent in RTCP packet Description: This is the SSRC value to be sent in RTCP packet with RTCP Floor Idle message 6.3.5 Floor Revoke Signal Name: Floor Revoke Signal ID: frev, (0x0009) Description: PSS sends floor revoke on the particular termination id. The PMS should keep re-transmitting the floor revoke signals at an interval of floor revoke timer Pavai, Venkat, Sunil March 2005 -12- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 value till the signal duration timer expires (specified by the duration of this signal). The signal duration specifies the duration till which floor revoke messages can be sent repeatedly at intervals of floor revoke timer. PSS also informs the UE about the "retry after interval" after which PSS can again grant floor to UE if requested. Signal Type : TO Duration: 100 - 2000 Additional Parameters: Parameter Name: Cause Code ParameterID: cause, (0x0001) Type: Integer Possible values: 1 or 2 (Current defined reason codes) Description: This specifies the reason why floor is being revoked from user Parameter Name: PSS SSRC Value ParameterID: pssrc, (0x0002) Type: Integer Possible values: SSRC value to be sent in RTCP packet Description: This is the SSRC value to be sent in RTCP packet with RTCP Floor Revoke message Parameter Name: Floor Revoke Timer (Optional) ParameterID: frt, (0x0003) Type: Integer Possible values: 1 or 2 Description: This specifies the repeat interval in seconds at which PMS shall repeat floor revoke. Floor Revoke message is repeated till overall signal timer expires or floor is released. Parameter Name: Retry After Interval Value (Optional) ParameterID: raftr, (0x0004) Type: Integer Possible values: 5-30 Description: This is the retry after interval value in seconds that PSS informs UE. 6.3.6 Send Sender Report Signal Name: Send Sender Report Signal ID: ssr, (0x000A) Pavai, Venkat, Sunil March 2005 -13- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 Description: PSS requests PMS to generate Sender report on a specified termination (or group of terminations). The parameter "ex_tid" specifies that if the command is applied on this termination then the signal should not be applied on the specified termination. If the termination id specified in the command is *, then the signal needs to be applied to all terminations on the context except "ex_tid". Signal Type : BR Duration: Not Applicable Additional Parameters: Parameter Name: PSS SSRC Value ParameterID: pssrc, (0x0001) Type: Integer Possible values: SSRC value to be sent in RTCP packet Description: This is the SSRC value to be sent in RTCP packet with RTCP Sender Report message Parameter Name: Excluded Termination ID (Optional) ParameterID: ex_tid, (0x0002) Type: String Possible values: ID of the termination to be excluded from the list. Description: This is the ID of the termination to be excluded from signal application if this signal is applied to a wild card termination list. Typically this is the termination id of the UE, which has generated the Sender Report 6.4. Statistics None. 6.5. Procedures This section provides details on the procedures required at both PSS and PMS to handle distributed PoC Server implementation using this package definition. Any PoC session is either a two-party communication or a multi-party communication from MEGACO perspective. PoC sessions are same as voice or any multi-media calls with added restriction on half-duplex communication (one user can speak at any time) and bearer signalling to handle floor messages. Pavai, Venkat, Sunil March 2005 -14- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 1. MEGACO protocol has already defined mechanisms to handle the establishment of two-party calls or multi-party calls, which will remain same for PoC sessions as well 2. To handle half-duplex nature of calls, PSS shall be using the mode of termination to control direction of media flow from each termination to context or from context to other terminations. Since PoC allows only one user (or termination) to be talking at a time, only one of the termination will be in receive-only mode, rest all shall be in send-only mode. This is established at start of session and changed with floor release, floor granted and floor revoke messages (modify termination command) 3. To handle bearer signalling PSS can use the signals and events defined in the specification Following are some of the implementation guidelines, which can be used by PSS and PMS implementers for each specific event and signal. 1. Property (Media buffer Size)- PSS should ask the PMS to start buffer ing by specifying a non zero value when an early session is created and should set the value to be zero after adding another termination to the session. For this the PSS would ask PMS to buffer the talk burst using valid non zero value of this property id. 2. Property (Generate Sender-Receiver Report) - If this is a general purpose MG, then PSS can send the value as off for a particular context, but if the PMS is handling only POC traffic, then the PSS can set this property as OFF for all terminations outside the context. 3. Property (PoC Server Version) - PSS can give this either on NULL context or for specific context depending on the capability of the PSS server to handle multiple versions of POC or not. 4. Event (Floor Request) - PSS could apply this event as soon as the termination is created and also when the floor is released (either by itself or is forcefully revoked) from the termination so as to detect the subsequent floor requests from the termination. On detection of the event, PMS should also give the SSRC value received in the floor control message to PSS. PSS Server could send this event in event buffer control so as to have flow control. 5. Event (Floor Release) - PSS server shall send SIP Message "NOTIFY" either on - on receipt of this and 200 OK for early session cases (both for early and late media) Pavai, Venkat, Sunil March 2005 -15- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 - OR when grace timer expires at PSS Server after initiating the forceful floor revoke and on receipt of 200 OK for early session cases (both for early and late media) PMS should deliver the floor release to the PSS server as per the follows: - On detection of the event (through any of the above methods), PMS should also check the sequence no. of the last RTP packet transferred, in this RTCP message - PMS should check whether it has received the RTP packet with that sequence no. If yes, then it can send the event to POC server immediately. - If the specified sequence no. is not received so far, PMS should wait for last RTP packet with that sequence no. Here it should also start a timer "tseq" of a configured duration awaiting the last RTP packet. - If the specified sequence no. has not been received so far, but a timeout for timer ts occurs, then it should report the floor release event to POC server On detection of the event, the MG should also give the SSRC value received in the floor control message to the POC Server. 6. Event (Failure Cause) - If PMS sends the error RRNR for a termination, which is still in setup phase, then PSS Server can ignore that error as it implies that the error occurred because the PMS would not have been successful in sending the SR value itself. 7. Event (Detect Sender Report) - PSS Server should get this event within the sender report timer value, which is started once PMS sends floor release to PSS Server. If PMS does not detect this event within this duration, then it needs to send failure cause event of this package to PSS Server with cause value as SRNR. 8. Signal (Floor Granted) - PSS server shall have all the terminations in "send-only" mode initially. When a particular termination is granted the floor, along with that it shall also change the mode to "recv-only". The POC server shall also revert the mode back to "send-only" when the floor is taken back, either due to floor revoke procedure or due to floor release by the talking user. PSS Server should send this signal with the SSRC value of the PSS Server for this context. This value is mentioned through the "pssrc" parameter along with the signal and PMS should use this to set the SSRC value in the RTCP message. Please note that the timer value for floor duration and awaiting the first talk burst is to be run at PSS server and not in PMS Pavai, Venkat, Sunil March 2005 -16- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 9. Signal (Floor Taken) - Usually the "floor taken" floor control message needs to be sent on all terminations in the context expect for the termination which has been granted the floor. Thus in those cases PSS server could issue the command with termination id as * in the command for a well-known context and specify the termination id of the termination which has been granted the floor in the parameter 'ex_tid" of this signal. This would make the signal to be sent to all terminations in the context other than the termination, which has been granted the floor. The POC Server should send this signal with the SSRC value of the POC Server for this context. This value is mentioned through the "pssrc" parameter along with the signal and PMS should use this to set the SSRC value in the RTCP message. 10. Signal (Floor Deny) - If PSS server wishes to send this signal on multiple terminations, it could send the list of command in one action of the Megaco transaction. The PSS Server should send this signal with the SSRC value of the POC Server for this context. This value is mentioned through the "pssrc" parameter along with the signal and PMS should use this to set the SSRC value in the RTCP message. 11. Signal (Floor Idle) - PMS shall apply the floor idle on all these terminations at regular intervals (floor idle timer) unless the PSS server instructs PMS to remove the signal - either by applying an empty signal descriptor or by applying another signal descriptor. Here the termination ids can also be partially wild carded. Usually the PSS server would apply the floor idle message on all terminations in that context. In that case the PSS server would send this command with a * as the termination id. When a termination is newly added to the context and the floor is idle, then the PSS server needs to send this signal explicitly for that termination. If the floor is released during a session then the PSS server can apply this signal for all terminations (using termination wild carding) for the context. When floor is granted to a termination, the PSS server would apply floor taken to the other list of terminations, which would mean that the previous signal of floor idle is stopped. The duration (inactivity timer) for which the floor can remain idle beyond which the session should be stopped is to be started at the PSS server. Hence if this timer expires then the PSS server can terminate the session and end sending of floor idle signals on the terminations. PSS Server should send this signal with the SSRC value of the PSS Server for this context . This value is mentioned through the "pssrc" parameter along with the signal and PMS should use this to set the SSRC value in the RTCP message Pavai, Venkat, Sunil March 2005 -17- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 12. Signal (Floor Revoke) - If the signal duration expires, then PMS should notify through the Signal Completion event, which is part of the generic package. On getting the Signal completion event, PSS Server should not allow the floor to be taken by this termination for a grace-period duration. The grace period duration is started at the PSS Server. PSS Server should send this signal with the SSRC value of the PSS Server for this context. This value is mentioned through the "pssrc" parameter along with the signal and MG should use this to set the SSRC value in the RTCP message 13. Signal (Send Sender Report) - Usually the SR needs to be sent on all terminations in the context at the end of the talk burst expect for the termination which has been granted the floor (which would have to sent the SR value). Thus in those cases the PSS server could issue the command with termination id as * in the command for a well-known context and specify the termination id of the termination on which the SR had been detected in the parameter 'ex_tid" of this signal. This would make the signal to be sent to all terminations in the context other than the termination, which had detected the SR value 6.5.1 Call Flow This section provides a call flow based on the package definition. It assumes 3 users in a PoC call with a group defined (sample-group) at PoC Server with these 3 users in the group. User-1 initiates the session and then User-2 and User-3 answers the call. User-1 releases floor and then floor is taken by User-2. Call flows shows SIP and MEGACO messages with important parameters and messages only. This is just a representative call flow and not an exhaustive one and variation could exist from a real call scenario or a specific implementation.In the following scenario, it is assumed that properties are already set. User-1 User-2 User-3 PSS PMS | | | | | | | | | | | INVITE(sample-group@pss.com) | | -------------------------------------->| | | | | | | | | | | | | | | ADD $ (mode=recv-only, | | | | event =pocserver/frel) | | | |---------------> Pavai, Venkat, Sunil March 2005 -18- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 | | | | ADD RESP (Context=1, | | | | Term =eph1) | | | |<---------------- | | INVITE | | | | <---------------------------- | | | | | | | | | |ADD 1 (mode=send-only) | | | --------------->| | | | | | | | | |ADD RESP (Term =eph2) | | | <---------------| | | | | | | | | |ADD 1 (mode=send-only) | | | |-------------->| | | | | | | | | INVITE | | | | |<--------------| | | | | |ADD RESP (Term =eph3) | | | <---------------- | | | | | | | | | | | | 200 OK | | | |------------------------->| | | | | | | | | | | | | | | |MODIFY 1 (eph2, remote desc | | | | signal= | | | | pocserver/floor taken) | | | |-------------->| | | | | | | | | Floor Taken | | | |<------------------------------------------ | | | |MODIFY 1 (eph1, | | | | signal=pocserver/ | | | | floorgranted) | | | |-------------> Pavai, Venkat, Sunil March 2005 -19- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 Floor Granted |<---------------------------------------------------- | | | | | | | | | | | | | 200 OK | | | | |--------------> | | | | | | | | | | MODIFY 1 (eph3, remote desc | | | | signal=pocserver/ | | | | floor taken) | | | |-----------------> | | | | | | | | Floor Taken | | | |<---------------------------------| | | | | | | | | | | UE-1 Releases | | | | Floor Control | Floor Release | | |-----------------------------------------------------> | | | | | | | | | NOTIFY(term = eph1, | | | | Observed Event = pocserver/ | | | | Floor Release ) | | | |------------------>| | | | | | | | | | MoDIFY 1 (term = *, | | | | Signal = pocserver/ | | | | floor idle) | | | |------------------>| | | | | | | | Floor Idle | | |<-----------------------------------------------------| | |<--------------------------------------------| | | |<---------------------------------| | | | | Pavai, Venkat, Sunil March 2005 -20- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 UE-2 requests Floor Floor Request | |------------------------------------------->| | | | | | | | | | | | | | | NOTIFY(term= eph2, | | | | Observed Event = pocserver/ | | | | Floor Request ) | | | |----------------->| | | | | | | | | | | | | | | MODIFY 1 (term = eph2, | | | | signal=pocserver/ | | | | floor granted) | | | |----------------->| | | | | | | | Floor Granted | | | |<-------------------------------------------| | | | | | | | | | | | | Floor Taken | | |<----------------------------------------------------| | | | | | | | | Floor Taken | | | |<---------------------------------| | | | | | | | | | | | | | | | | | | | | 7 Security Considerations This is a package definition for MEGACO protocol and as such doesn't have direct security implications in addition to what is specified in the MEGACO protocol RFC. 8 Authors R Ezhirpavai Hughes Software Systems, India rezhirpavai@hssworld.com B Venkat Swamy Hughes Software Systems bvswamy@hssworld.com Sunil Mahajan Hughes Software Systems, India smahajan@hssworld.com Pavai, Venkat, Sunil March 2005 -21- INTERNET DRAFT draft-mahajan-poc-server-package-00.txt Sep 2004 Intellectual Property and Copyright Statements Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Pavai, Venkat, Sunil March 2005 -22-