IMTC Packet-Switched Streaming

Implementation Guide IMTC Packet-Switched Streaming Activity Group Implementation Guide Version 1.2 23 October 2002 IMTC-PSS-AG Page 1 Implementation Guide Table of Contents 1 2 Description ............................................................................................................. 3 Items ....................................................................................................................... 3 2.1 AMR/MP4-ff: multiple AMRSampleEntries allowed in one mp4 file track ? .... 3 2.2 MPEG4-Audio-AAC-LC/SDP: how to signal MP4-AAC-LC via SDP ? ........... 4 2.3 MPEG4-Audio-AAC-LATM/SDP: is streamMuxConfig allowed inband ? ....... 4 2.4 RFC3016/RTP/RTSP Buffering : maximum size of RTP packets? .................... 5 2.4.1 RFC3016: matching with path-MTU ............................................................ 5 2.4.2 RTP-size indication by the client to server ................................................... 5 2.5 RTSP/RTP: how to implement seek function and resynchronize AV after seek ? .................................................................................................................................... 5 2.5.1 Resynch AV after seek request: .................................................................... 5 2.5.2 mapping from Rtptime to npt: Range response header ................................. 6 2.6 MP4-ff /H263 : how to include bitrate information in a 3GPP H263 track ? ...... 6 2.7 SDP: bitrate and bandwidth indication ................................................................ 7 2.8 Limitation of multiple media sample entry .......................................................... 8 2.9 Mandate profile/level signalling for H.263 in SDP ............................................ 8 2.10 Clarification on usage of MIME parameters for AMR ...................................... 9 2.11 MPEG4-Audio-AAC-LC/RFC3016 : “last audioMuxElement containing fewer packets than signalled allowed ?” .................................................................... 9 2.12 SDP : “Usage of a=range at session and media levels in SDP”......................... 9 2.13 MP4-V/H263/SDP :Require “a=framerate” signaling for video tracks in SDP? .................................................................................................................................. 10 2.14 SDP: bitrate and bandwidth indication ............................................................ 10 2.15 RTSP: Clarifications on use of redirection in PSS .......................................... 11 2.16 RTSP: Sending PAUSE when server is in Ready state ................................... 12 2.17 Frame Size SDP Attribute ................................................................................ 12 IMTC-PSS-AG Page 2 Implementation Guide 1 Description In this guide critical and important points concerning implementation of 3GPP TS 26.233/234 are described. This is ongoing work and items mentioned here are subject to be changed. Here you find topics which revealed to be problematic and were found during the interop test phases by the group. Items a formatted the following: with: : the protocol/codec the hint/problem refers to : either · on discussion (group is still discussing about solution) · implementation hint (just a hint by the group) · external solution (if we ask 3GPP, IETF, MPEG to solve the problem change/extension of the standard · final solution (the problem was solved) the state includes a history, segmented by “->” symbols 2 Items 2.1 AMR/MP4-ff: multiple AMRSampleEntries allowed in one mp4 file track ? According to the MPEG Standard it is currently allowed to have more than one AMRSampleEntry per AMR-NB/WB track in an mp4 file. This would allow to change AMR optional parameters “mode-set” and “mode-change-period” during one stream. Since these parameters are only signalled once to the client at session description (SDP) it has to be guaranteed that the server does not change these parameters during the stream. SA4 approved the following solution due to following CRs ( Tdoc S4-020351, Tdoc S4-020350): IMTC-PSS-AG Page 3 Implementation Guide “Each AMR or AMR-WB track in a 3GPP/MP4 file shall be limited to referencing a single AMRSampleEntry. on discussion -> external solution (SA4,Rennes) -> final external solution (SA4,Rennes) 2.2 MPEG4-Audio-AAC-LC/SDP: how to signal MP4-AAC-LC via SDP ? The way to signal MP4-AAC-LC stream according to RFC3016 is by using the SDP parameters “profile-level-id” and “object”. TS 26.234 allows to use LCprofile and LTP-profile. The “object” parameter is optional. There does not exist any special profile@level defined by MPEG which only supports LC or LTP. SA4 approved the following solution due to following CRs ( Tdoc S4-020351, Tdoc S4-020350): ”When a server offers an AAC-LC or AAC-LTP stream with the specified restrictions, it shall include the “profile-level-id” and “object” MIME parameters in the SDP “a=fmtp” line. The following values shall be used:” Object Type profile-level-id object AAC-LC 15 2 AAC-LTP 15 4 on discussion -> external solution (SA4,Rennes) -> final solution (SA4,Rennes) 2.3 MPEG4-Audio-AAC-LATM/SDP: is streamMuxConfig allowed inband ? According to RFC3016 for audio streamMuxConfig can be sent inband RTP or outband in the SDP description. The advantage of outband transmission is having a secure transmission of the parameters and bit shifting of audio data can be avoided (streamMuxConfig is not byte aligned in inband mode). The advantage of inband transmission is the possibility to change parameters of streamMuxConfig during transmission. SA4 approved the following solution due to following CRs ( Tdoc S4-020349, Tdoc S4-020348): IMTC-PSS-AG Page 4 Implementation Guide ”Configuration information is mandated to be sent in the SDP (which is transported over TCP and thus safely delivered to the terminal) for MPEG4 audio and MPEG4 video.” on discussion -> external solution (SA4,Rennes) -> final solution (SA4,Rennes) 2.4 RFC3016/RTP/RTSP Buffering : maximum size of RTP packets? 2.4.1 RFC3016: matching with path-MTU Regarding RFC3016 for audio and video it is mentioned that the RTP payload should not exceed the path-MTU and that fragmentation should be avoided. The widespread fixed (1500 bytes) boundary for the MTU is as well a boundary for the SDU size in UMTS bearer service (TS 23.107-V5.3.0 : 6.5). This value will be a maximum but parameterisation is out of scope of this group. To achieve clarity on the interpretation on this recommendation in RFC3016 SA4 issued a liaison statement (S4-020345) and will wait for answer by other 3GPP goups on discussion -> external solution (SA4,Rennes) 2.4.2 RTP-size indication by the client to server If the server and the client both support the RTSP- “Block size header” the client has a chance to signal its‟ RTP buffer size to the server. Nevertheless common values for buffer implementations should be used and are implementation dependent. implementation hint 2.5 RTSP/RTP: how to implement seek function and resynchronize AV after seek ? 2.5.1 Resynch AV after seek request: The PTS in the RTP header has to be monotonically growing and doesn‟t represent the position of the stream relating to its‟ beginnig. The server does not have to return the exact position asked by the client‟s seek. So is possible that the media sent by the server after the seek don‟t match to the same absolute position and so create an offset. IMTC-PSS-AG Page 5 Implementation Guide Solutions could be: a) calculate for each media: d = PTSactual – rtptime where : PTSactual = PTS of first sent packet after seek Rtptime = PTS Info from “RTP-Info” header For one media the difference should be 0. For the others 0 is optimal, if not with the help of the relating clockrate the offset can be calculated as well in absolute time. To get absolute time information referring to the beginning of the presentation in ntp you add d to the ntp delivered back by the possibly sent range response header. implementation hint 2.5.2 mapping from Rtptime to npt: Range response header Since a server might not replay at the exact position which was requested by a range header request the client might position the time bar at a wrong position. To avoid wrong mappings of the RTP PTS the range header response will be very helpful information for the client. SA4 approved the following solution due to following CRs ( Tdoc S4-020351, Tdoc S4-020350): “PSS servers shall include the Range header field in all PLAY responses” external solution (SA4,Rennes) -> final external solution (SA4,Rennes) 2.6 MP4-ff /H263 : how to include bitrate information in a 3GPP H263 track ? Currently there is no provision for putting bitrate information inside a H263 track of a 3GPP compliant MP4 file. There can be different ways on how to include this information. SA4 approved the following solution due to following CRs (REL-5 change only,Tdoc S4-020490,Tdoc S4-020493): “The BitrateAtom field shall be as defined in table D.7.1. The BitrateAtom may be included if the MP4 file contains H.263 media. The BitrateAtom is composed of the following fields. IMTC-PSS-AG Page 6 Implementation Guide Table D.7.1: The BitrateAtom fields Field AtomHeader.Size AtomHeader.Type DecBitrateInfo Type Unsigned int(32) Unsigned int(32) DecBitrStruc Details ‘bitr’ Structure which holds the Bitrate information Value AtomHeader Size and Type: indicate the size and type of the bitrate atom. The type must be „bitr‟. DecBitrateInfo: This is the structure where the stream bitrate information resides. DecBitrStruc is defined as follows: struct DecBitrStruc { Unsigned int (32) Avg_Bitrate Unsigned int (32) Max_Bitrate } The definitions of DecBitrStruc members are as follows: Avg_Bitrate: the average bitrate in bits per second of this elementary stream. For streams with variable bitrate this value shall be set to zero. Max_Bitrate: the maximum bitrate in bits per second of this elementary stream in any time window of one second duration.” external solution (SA4,Tampere 2002) -> final external solution (SA4,Tampere 2002) 2.7 SDP: bitrate and bandwidth indication since TS 26.234 mandates the implementation of SDP “b=AS” attribute only for clients there is no guaranteed indication of the bitrates (neither net nor gross) of the session/streams/codecs . Possible solutions: Discuss with SA4 why servers are not mandated to use the “b=AS” currently. If SA4 can be convinced that these indications shall be mandatory we have the following choices: a) try to mandate the usage of payload-format/codec -specific bitrate indicating parameters such as e.g.“bitrate” described in RFC3016/5.4 for clients and servers and clients. b) mandate the “b=AS” attribute as well for servers and calculate the codec‟s maximum raw bitrate if needed . This way the network as well profits due to bandwidth indication for a session IMTC-PSS-AG Page 7 Implementation Guide SA4 approved the following solution due to following CRs (REL-5 change only, Tdoc S4-020491,Tdoc S4-020493): “The bandwidth field in SDP is needed by the client in order to properly set up QoS parameters. Therefore, a PSS server shall include the “b=AS:” field at the media level for each media stream in SDP, and a PSS client shall interpret this field. When a client receives SDP, it should ignore the session level “b=AS:” parameter (if present), and instead calculate session bandwidth from the media level bandwidth values of the relevant streams. Note that for RTP based applications , „b=AS:‟ gives the RTP "session bandwidth'' (including UDP/IP overhead) as defined in section 6.2 of [9]”…………… Complete text including all changes in text and tables has to be taken directly from the CR itself. on discussion -> external solution (SA4,Tampere 2) -> final solution (SA4,Tampere 2) 2.8 Limitation of multiple media sample entry 3GPP file format is inherited from ISO Media File format, which enables multiple media sample entry boxes per media track. Such a usage creates problems during media information signalling in SDP files. Moreover, it may bring further complexities for decoding and playback operations. Such a restriction is present for AMRSampleEntry, we propose the restriction to be enlarged to cover the other SampleEntry Boxes too, excluding the Text Sample Entry Box in Rel.5, where multiple sample entries is the key of efficiency. On discussion 2.9 Mandate profile/level signalling for H.263 in SDP For H.263 streams, the inclusion of 'profile' and 'level' on the 'a=fmtp' line is optional. If a server does not include these fields in SDP, then a client cannot tell which variant of H.263 is included in the session. Both 'Profile 0 Level 10' and 'Profile 3 level 10' are called out in the PSS specification. For this reason, we should mandate inclusion of 'profile' and 'level' fields when serving H.263 sessions in PSS. This problem was not raised to SA#4, we decided to specify the following: „profile-level-id‟ is effectively required for PSS presentations, since this point could be easily missed by developers. On discussion IMTC-PSS-AG Page 8 Implementation Guide 2.10 Clarification on usage of MIME parameters for AMR After reviewing RFC3267 and consulting with one of the authors of the RFC, we found the following: Our conclusion is that mode_set, mode-change-period, and mode-changeneighbor are not applicable to PSS, and therefore SHOULD NOT be sent in SDP by PSS servers. We request that a clarification to this effect be added to the PSS specification. SA4 approved the following solution due to following CRs (REL-5 change only, Tdoc S4-020492, Tdoc S4-020406):## “The following AMR MIME parameters are not relevant to PSS: {mode_set, mode_change_period, mode_change_neighbor}. PSS servers should not send these parameters in SDP, and PSS clients shall ignore these parameters if received.” external solution (SA4,Tampere 2) -> final solution (SA4,Tampere 2) 2.11 MPEG4-Audio-AAC-LC/RFC3016 : “last audioMuxElement containing fewer packets than signalled allowed ?” (new) when streaming AAC under the „cpresent=0‟ restriction, you cannot reconfigure the number of frames per audioMuxElement during streaming. This may present a problem at the end of the stream, since the final audioMuxElement (completed in the last RTP packet) might need to contain fewer AAC frames than originally configured at start of streaming. The issue would ask for some clarification on how to handle this. Suggestion for a solution : Send a request to IETF and/or MPEG-4 Audio for a solution. On discussion 2.12 SDP : “Usage of a=range at session and media levels in SDP” (new) The definition of “a=range” in the RTSP specification is a bit ambiguous, particularly on whether this parameter should be included at the session level, the media level, or both. Solution: Section 6 of SDP specification shows that media-level attributes “overwrite” session-level attributes. It is thus clearly legal to have “a=range” at both media and session level, and how to interpret this when parsing SDP is clear. IMTC-PSS-AG Page 9 Implementation Guide implementation hint 2.13 MP4-V/H263/SDP :Require “a=framerate” signaling for video tracks in SDP? (new) The idea is that frame rate information should always be announced for video tracks, so that the player can properly allocate resources. It would be done by requiring “a=framerate” to be included for video media, in order to signal the maximum frame rate in the presentation. This attribute is already defined in the SDP specification, but is currently not mandated. Solution: The group agreed that there was no need to mandate “a=framerate”. While the information may be useful in some cases (e.g. where the framerate is very low, e.g. a „slide show‟ presentation), it is not always needed. The default maximum framerate (15 fps for H.263 baseline and MPEG-4 Simple@L0) is often sufficient, and the server already has the option to include “a=framerate” if the max framerate is particularly low. implementation hint 2.14 SDP: bitrate and bandwidth indication (new) Please read issue 2.7 together with the info given here ! Release-5 PSS states that servers must provide bandwidth information („b=AS:‟) at the media level in SDP. However, a Release-5 client cannot rely on receiving this parameter, since a Release-4 server is not required to provide it. This point is not currently clear in the PSS specification. The lack of clarity on this point may result in Release-5 client implementations which do not handle the case where the bandwidth parameter is not provided, and such clients may not interwork with Release-4 servers. SA4 approved the following solution due to following CRs (REL-5 change only, S4-020588): Paragraph 5.3.3.1 inside TS 26.234 Rel-5 would be changed to the following: RTSP requires a presentation description. SDP shall be used as the format of the presentation description for both PSS clients and servers. PSS servers shall provide and clients interpret the SDP syntax according to the SDP specification [6] and appendix C of [5]. The SDP delivered to the PSS client shall declare the media types to be used in the session using a codec specific IMTC-PSS-AG Page 10 Implementation Guide MIME media type for each media. MIME media types to be used in the SDP file are described in clause 5.4 of the present document. The SDP [6] specification requires certain fields to always be included in an SDP file. Apart from this a PSS server shall always include the following fields in the SDP: "a=control:" according to clauses C.1.1, C.2 and C.3 in [5]; "a=range:" according to clause C.1.5 in [5]; "a=rtpmap:" according to clause 6 in [6]; "a=fmtp:" according to clause 6 in [6]. The bandwidth field in SDP is needed by the client in order to properly set up QoS parameters. Therefore, a PSS server shall include the “b=AS:” field at the media level for each media stream in SDP, and a PSS client shall interpret this field. When a PSS client receives SDP, it should ignore the session level “b=AS:” parameter (if present), and instead calculate session bandwidth from the media level bandwidth values of the relevant streams. A PSS client shall also handle the case where the bandwidth parameter is not present, since this may occur when connecting to a Release-4 server. Note that for RTP based applications , „b=AS:‟ gives the RTP "session bandwidth'' (including UDP/IP overhead) as defined in section 6.2 of [9]. ……………….. ………. … PLEASE CHECK THE MOST UP TO DATE TS 26.234 REL-5 FOR FINAL APPROVAL BY SA4 on discussion -> external solution (SA4,Montreal 2002) -> final solution (SA4,Montreal,2002) 2.15 RTSP: Clarifications on use of redirection in PSS (new) Support for redirection (both REDIRECT method and 3xx error codes) is mandatory in PSS. However, there seem to be some problems with the way redirection is defined in the RTSP specification. For example, the 3xx error codes are defined via reference to HTTP, and the definition of the codes there is quite HTTP-specific, and difficult to interpret for RTSP. Also, PSS-AG is not currently testing redirection. The proposal is that we must either (1) make clarifications and/or usage guidelines for redirection in PSS, and also test redirection in our group, or (2) remove the mandate for redirection (e.g. by restriction within PSS spec). Some clarification is warranted, but this is an issue for IETF/MMUSIC rather than SA4. MMUSIC is working to clarify this in the next generation RTSP spec, and they would appreciate any input we have on the subject. See the emails from Magnus Westerlund for some links to good information (e.g. the current draft of rtsp next-generation, and the Source-Forge bug list); these were sent to the PSS-AG technical reflector on 9/13/02. IMTC-PSS-AG Page 11 Implementation Guide Solution: Continue discussion of the issue, and provide input via SourceForge and/or the MMUSIC reflector. Possibly develop usage guidelines for the IG. Decide also whether redirection should be tested in PSS-AG, and how this would be done. (on discussion) 2.16 RTSP: Sending PAUSE when server is in Ready state (new) The issue involves proper interaction between server and player if the player should send PAUSE during the Ready state in RTSP. This happens commonly if the player tries to seek during the last few seconds of a clip. If the server has already sent the last packet and entered Ready state, then the RTSP specification does not list PAUSE as a valid method. The server would send an error message (Method not valid in this state), and the player might not react well to this error. Much of this is left to the implementation (i.e. some of our servers don‟t send the error message, some do; some of our players tolerate the error message, some don‟t). Without some clarifications or guidelines, we do not have interoperable seeking near the end of the clip. Solution: Discussion is ongoing. As we found with some of the earlier issues, this issue may be more suitable for IETF/MMUSIC than for SA4. In fact, the issue has come up in MMUSIC before, and is the topic of an outstanding bug report. See: http://sourceforge.net/tracker/index.php?func=detail&aid=556295&group_id=23194&a tid=377744 It seems they haven‟t progressed since the issue was posted there 5/15/02. We can provide some input through this SourceForge link, or via the MMUSIC reflector. (on discussion) 2.17 Frame Size SDP Attribute Syntax: a=framesize:- CRLF This 3GPP-specific attribute is used at the SDP media level to indicate the video frame size. The server SHALL include this attribute to the SDP for H.263 streams. However, the client SHOULD be ready to receive SDP descriptions without this attribute, due to backward compatibility. If this attribute is present, the frame size parameters SHALL exactly match the largest frame size defined in the video bitstream. This parameter SHALL be used for H.263. For MPEG-4 visual, the frame size information SHALL be derived from the config information. IMTC-PSS-AG Page 12 Implementation Guide SA4 approved the following solution due to following CRs (REL-5, Tdoc S4-030229) “ The following media level SDP field is defined for PSS: "a=framesize: -" This gives the largest video frame size of H.263 streams. The frame size field in SDP is needed by the client in order to properly allocate frame buffer memory. For MPEG-4 visual streams, the frame size shall be extracted from the “config” information in the SDP. For H.263 streams, a PSS server shall include the “a=framesize” field at the media level for each stream in SDP, and a PSS client should interpret this field, if present. Clients should be ready to receive SDP descriptions without this attribute. If this attribute is present, the frame size parameters shall exactly match the largest frame size defined in the video stream. The width and height values shall be expressed in pixels. “ on discussion -> external solution (SA4,Berlin 2003) -> final solution (SA4#25bis,Berlin,2003) 2.18 Clarifications on Redirect using Content-Location header The group thinks that a clarification is needed in the 3GPP specification regarding Redirect implemented by changing the Content-Location header. Since this is a compliant issue, it is suggested that it will be mentioned that clients shall support this method of redirect. After a long discussion in the group and IETF it appears that there might not be a problem here. No further actions for this topic. 2.19 RTP Timestamps handling when resuming from Pause When reading carefully RFC2326 it looks that RTP time stamps must reflect the time elapsed between the PAUSE and the RESUME (i.e. PLAY without range) command. That is to say that if the client pauses the stream for 30 seconds, there must be a gap of 30 seconds between the time stamps of the last rtp packet sent after receiving the PAUSE command and the time stamp of the first RTP packet sent after receiving the PLAY without range command. However for the server it appears that 3GPP servers are mandated to send range header in each play response even if there was no range header in the request, the client can synchronize by that header. Therefore it is suggested to add a clarification for 3GPP clients to support a gap in RTP timestamps when resuming from pause. SA4 approved the following solution due to following CRs (REL-5, Tdoc S4-030517) IMTC-PSS-AG Page 13 Implementation Guide The description below intends to clarify how RTP timestamps are specified within the 3GPP PSS when a client sends a PLAY request following a PAUSE request. The RTP timestamp space must be continuous along time during a session and then reflect the actual time elapsed since the beginning of the session. A server must reflect the actual time interval elapsed between the last RTP packets sent before the reception of the PAUSE request and the first RTP packets sent after the reception of the PLAY request in the RTP timestamp. A client will need to compute the mapping between NPT time and RTP timestamp each time it receives a PLAY response for on-demand content. This means that a client must be able to cope with any gap in RTP timestamps after a PLAY request. The PLAY request can include a Range header if the client wants to seek backward or forward in the media, or without a Range header if the client only wants to resume the paused session. Example: In this example Client C plays a media file from Server S. RTP timestamp rate in this example is 1000Hz for clarity. C -> S: PLAY rtsp://example.com/mediastream RTSP/1.0 CSeq: 2 Session: 123456 Range: npt=1.125S -> C: RTSP/1.0 200 OK CSeq: 2 Session: 123456 Range: npt=1.120RTP-Info: url=rtsp://example.com/mediastream;seq=1000;rtptime=5000 S -> C: RTP packet - seq = 1000 - rtptime = 5000 - corresponding media time (NPT time) = 1120ms S -> C: RTP packet - seq = 1001 - rtptime = 5040 - corresponding media time (NPT time) = 1160ms S -> C: RTP packet - seq = 1002 - rtptime = 5080 - corresponding media time (NPT time) = 1200ms S -> C: RTP packet - seq = 1003 - rtptime = 5120 - corresponding media time (NPT time) = 1240ms C -> S: PAUSE rtsp://example.com/mediastream RTSP/1.0 CSeq: 3 Session: 123456 S -> C: RTSP/1.0 200 OK CSeq: 3 Session: 123456 [10 seconds elapsed] C -> S: PLAY rtsp://example.com/mediastream RTSP/1.0 CSeq: 4 IMTC-PSS-AG Page 14 Implementation Guide Session: 123456 S -> C: RTSP/1.0 200 OK CSeq: 4 Session: 123456 Range: npt=1.280RTP-Info: url=rtsp://example.com/mediastream;seq=1004;rtptime=15160 S -> C: RTP packet - seq = 1004 - rtptime = 15160 - corresponding media time (NPT time) = 1280ms S -> C: RTP packet - seq = 1005 - rtptime = 15200 - corresponding media time (NPT time) = 1320ms S -> C: RTP packet - seq = 1006 - rtptime = 15240 - corresponding media time (NPT time) = 1360ms C -> S: PAUSE rtsp://example.com/mediastream RTSP/1.0 CSeq: 5 Session: 123456 S -> C: RTSP/1.0 200 OK CSeq: 5 Session: 123456 C -> S: PLAY rtsp://example.com/mediastream RTSP/1.0 CSeq: 6 Session: 123456 Range: npt=0.5[55 milliseconds elapsed during request processing] S -> C: RTSP/1.0 200 OK CSeq: 6 Session: 123456 Range: npt=0.480RTP-Info: url=rtsp://example.com/mediastream;seq=1007;rtptime=15295 S -> C: RTP packet - seq = 1007 - rtptime = 15295 - corresponding media time (NPT time) = 480ms S -> C: RTP packet - seq = 1008 - rtptime = 15335 - corresponding media time (NPT time) = 520ms S -> C: RTP packet - seq = 1009 - rtptime = 15375 - corresponding media time (NPT time) = 560ms on discussion -> external solution (SA4,Munich 2003) -> final solution (SA4#27,Munich,2003) IMTC-PSS-AG Page 15 Implementation Guide 2.20 Play response when resuming from pause at end of presentation The scenario is: The server is playing a stored media clip to the client. The client has a certain amount of buffer space. The client hits PAUSE. However when the PAUSE request reaches the server the server has played all media for the clip. The server respond to the PAUSE request with a Range header containing the pause point. The problem arise when the client likes to resume the playout of the media to the end. The client has all the rest of the media already in its buffer and this should be totally local operation. So the big question is How the server handles this PLAY request? Two options are listed below: A. The server sends a 200 OK on the request to continue. The RTP-Info is for the next packet which will not be sent as result of this PLAY request. The Range header response indicate that the server will play from the given end of the clip to the end of the clip. Then no RTP packets are sent. B. The server sends a 457 (Invalid Range) including in the response the range header for the pause point. On discussion 2.21 Indication for session aliveness It was noted that currently the spec does not mandate any specific method for the server to check the session aliveness. Since RTCP is not mandated, a server should not rely only on RTCP or only on RTSP as a session aliveness indicator. It was suggested that any signal coming from the client to the server (RTCP or RTSP) could be an indicator for session aliveness. hint 2.22 RTP-Info url Few problems regarding url‟s were identified and need to be clarified: 1. RTP-Info: RTP-Info: url=rtsp://DTSC/nex/nex_c3_1noaudio_mpeg4r32qqvga.3gp/trackID=1;seq=1; The hostname information must be FQDN or actual IP-address instead of just hostname 2. What URI to use? Magnus supplied the following interpretation: 1. What URI is used. 2. If one would like to use the relative URIs what is the base URI to use. IMTC-PSS-AG Page 16 Implementation Guide The resolution of 1 was that exactly the same as the URI used in SETUP MUST be used. The reason behind this is that this URI is the only thing that clearly identifies which stream the information relates to. So using any other URI in the response by the server will result in failure for the client to resolve which stream the information belongs to. Resolution of 2 was that the only base URI available is the PLAY request URI. Therefore any URI must be relative to that URI. If one wants to avoid this problem completely the simplest server fix is to always use absolute URIs. However the clients needs to be able to resolve the relative URIs. The Content-Base or Content-Location headers is not applicable as it only gives the base URI for a body (entity). The only available URI is the Request URI. I would recommend that you use these rules as they are the most reasonable interpretation of the ambiguities we have found. On discussion IMTC-PSS-AG Page 17