3GPP TSG-SA4 Meeting #47Tdoc S4-080083
Monte Carlo, Monaco, 21st to 25th Jan 2008
Title:LS regarding indicating image size in conversational multimedia sessions established using SIP/SDP
Source:3GPP TSG SA WG4
To:IETF MMUSIC WG
Cc:-
Contact Person:
Name:Magnus WesterlundTel. Number:+46 8404 82 87E-mail Address:
Name:Kyunghun JungTel. Number:+82 31267 4640E-mail Address:
Attachments:–
1. Overall Description
The 3GPP TSG SA WG4 (SA4) is planning to do work in the context of Multimedia Telephony Service over IMS (MTSI) for signalling of video image size. MTSI uses SIP/SDP for session establishment. The current definition of MTSI related to SA4’s work scope is specified in 3GPP TS 26.114 [1].
The signalling of video image size considers resolving two issues that are of interest to SA4.
a)Have the peers indicate the sizes in pixels (x by y) that would be most desirable to receive from other session participants. Such signalling could avoid having video senders from sending a smaller image than the available display area resulting in reduced media quality for the user from upscaling or unnecessary small image size. It also can prevent the media sender from providing a too large image requiring downscaling and reduced bit-rate efficiency, as the same number of bits would be required to cover more pixels than optimal. The considered solution to this issue is to define a new SDP attribute with the necessary SDP offer/answer rules. To SA4’s understanding this is a media level attribute but not specific to any particular RTP payload type.
b)Explicitly signalling the largest used image size for video codecs lacking explicit indication. Such a codec is H.263 using the RTP payload format identified with video/H263-2000 media type. SA4 has already defined such an SDP attribute for usage in Packet-based Streaming Service (PSS) in section 5.3.3.2 in TS 26.234 [2]. SA4 is considering extending this attribute to be applicable also in SDP offer/answer to enable usage in MTSI.
SA4’s work on these items are under a work plan that is planned to conclude by September 2008, however this may not be the final deadline.
MMUSIC WG is the creator and maintainer of SDP. SA4 is interested in feedback about these proposed extensions. Therefore SA4 is interested in determining if these issues are of general interest, and if so, whether they would be pursued in MMUSIC WG or at least be reviewedthere
2. Actions
SA4 kindly requests MMUSIC WG respond to the following questions no later than one week prior to SA4’s next meeting starting on the 7th of April.
a)Does MMUSIC WG consider either issue a) or b) and the proposed solutions to be of general interest to the users of SDP?
b)Based on the response to question a) and considering the above described timeline does MMUSIC recommend the work for either of the two parts to be carried out in the MMUSIC WG?
c)If MMUSIC WG recommends either or both of theseissues to be carried outin MMUSIC WG, in what timeframe does MMUSIC WG consider this work to be possible to reach technical stability and final publication as RFC? This assuming that key SA4 contributors will participate in the work in MMUSIC WG.
d)If MMUSIC WG instead considers it being acceptable for SA4 to develop these extensions, at what stages (if any) would it be desired by MMUSIC WG to review the work?
3. Date of Next TSG-SA4 Meetings:
TSG-SA WG4 Meeting #487th – 11th April 2008Jeju Island, South Korea
TSG-SA WG4 Meeting #4930th June — 3rd July 2008TBD, US
4. References
[1] 3GPP TS 26.114, “IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction”,
[2] 3GPP TS 26.234, “Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs “