Subject: [Sip] RE: [Sip-implementors] media description in SDP is for sender or receiver?

From: "Ling, Fan" <[email-masked]>
Date: Thu, 3 Nov 2005 22:49:21 -0800

Sir,

Thanks for the reply. 

The following is an abstract from RFC3264 section 6.1 page 8:

"

The interpretation of fmtp parameters in an offer depends on the
parameters. Inmany cases, those parameters

describe specific configurations of the media format, and should
therefore be processed as the media format

value itself would be. This means that the same fmtp parameters with the
same values MUST be present

in the answer if the media format they describe is present in the
answer. Other fmtp parameters are more

like parameters, for which it is perfectly acceptable for each agent to
use different values. In that case, the

answer MAY contain fmtp parameters, and those MAY have the same values
as those in the offer, or they

MAY be different. SDP extensions that define new parameters SHOULD
specify the proper interpretation in

offer/answer.

"

Since the "config=" field in my example is specific configuration for
MPEG4 simple profile video bitstream, its interpretation should "depends
on the parameters", however, I can't find such interpretation in MPEG4
RTP RFC3016.

Any of your advice is welcome!

Thanks,

Fan  

-----Original Message-----
From: Somesh S Shanbhag [mailto:[email-masked]] 
Sent: Thursday, November 03, 2005 9:33 PM
To: Ling, Fan; [email-masked]
Subject: Re: [Sip-implementors] media description in SDP is for sender
or receiver?

Hi,

RFC 3264 specifies sendonly, recvonly, sendrecv and 

inactive attributes. UA can specify any of these 

attributes according to it's preference. When no such

attribute is present, it is assumed that the stream is

"sendrecv" stream and whatever the encodings specified

applies to both sender and receiver side.

Regards

Somesh S. Shanbhag

--- "Ling, Fan" <[email-masked]> wrote:

> Hi,

> The following SDP message describes a MPEG4 video

> bitstream:

> m=video 20000 RTP/AVP 98 34

> a=rtpmap:98 MP4V-ES/90000

> a=fmtp:98

profile-level-id=8;config=000001B008000001B5090000010000000120008440FA28

> 2C2090A21F

> Does this SDP message describes the sender encoder

> generated media

> settings or the required media settings on the

> receiver's encoder? Or

> both? Can some one point me to the proper RFCs? I

> believe this media

> settings is for the sender side, but  I can't find

> definitely

> description in any RFCs.

> Thanks a lot

> Fan

> _______________________________________________

> Sip-implementors mailing list

> [email-masked]

http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

 

-----------------------------------------

SIMPLICITY IS THE BEAUTY.

BE NATURAL LIVE NATURAL.

-----------------------------------------

Somesh S. Shanbhag

Focus Area - VoIP Team (FA-VoIP)

Mascon Global Communication Technologies

Enterprise of Mascon Global Limited

#59/2, 100Ft Ring Road

Banashankari II stage

Bangalore-560070

Karnataka

INDIA

Website: http://www.masconit.com

-----------------------------------------

            

__________________________________ 

Yahoo! Mail - PC Magazine Editors' Choice 2005 

http://mail.yahoo.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 04 Nov 2005 14:04:02 +0100

Hi,

(cc also AVT as this is an AVT WG matter)

It took AVT a long time until actually offer/answer sections started 
appearing in the RTP payload formats. It is basically only the last year 
or two that they have been included.

In general parameters applies for the stream the offerer/answer wants to 
receive. However config is a bit problematic. It provides information 
that concerns the bit-stream that the encoder will send out. Thus config 
applies from sender to receiver.

This is at least spelled out in RFC 3016:

"config: This parameter SHALL be used to indicate the configuration
       of the corresponding MPEG-4 Visual bitstream.  It SHALL NOT be
       used to indicate the codec capability in the capability exchange
       procedure."

So the interpretation I make is the following:
profile-level-id in an offer for a sendrecv stream tells the answerer 
the highest level and profile it may use to send media to the offerer.

The config string tells the answerer about the bit-stream it will 
receive from the offerer.

The issue with all parameters that relate to stream properties rather 
than capabilities or reception configurations that the receiver can 
determine for the sender is that they are based on assumptions about the 
other end-points capabilities. The offerer assumes that the answerer is 
at least as capable as the offerer and can handle the config string.

I think it is currently unspecified if the answerer may downgrade the 
received profile-level-id to a lower capability in its answer. I think 
that is reasonable, but it do generates some issues in regards to the 
config string. Because suddenly the config that the offerer provided may 
no longer be valid. The offerer would be forced to re-invite with a new 
offer that matches the answerer reception capabilities.

If one is interested in how terribly complicated this becomes should 
take a look at the H.264/MPEG AVC RTP payload format in RFC 3984.

RFC 3016 would benefit from an update to include the necessary 
offer/answer section that describe this. So volunteers are very welcome 
to start this work. Simply contact the authors and the AVT WG chairs.

As the above is my interpretation, if the interpretation made in 
implementations differ, then that fact should be commented on.

Cheers

Magnus Westerlund
AVT WG Chair

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]