Re: [AVT] RFC 3984 offer/answer Question

[Randell Jesup <rjesup at wgate.com>]

"Yuval Nissan" <Yuval.Nissan at audiocodes.com> writes:
>Regarding the communication symmetric - if we understand it the way
>which you propose (which I think is the practical one):
>
>Offerer support up to level 3.
>Offerer -> Answerer SDP message:
>
>      m=video 49170 RTP/AVP 98
>      a=rtpmap:98 H264/90000
>      a=fmtp:98 profile-level-id=42A01E; packetization-mode=0;
>                
>Answerer support level 1 only.
>Answerer -> Offerer SDP message:
>
>     m=video 49170 RTP/AVP 98
>     a=rtpmap:98 H264/90000
>     a=fmtp:98 profile-level-id=42A00A; packetization-mode=0;
>               
>There can be 2 possibilities:
>
>1. The offerer must transmit in level 1.0. Still the answerer can
>transmit up to level 3.0 if he wants. 
>
>2. Both of them must use level 1.
>
>Which one is correct?

Correct?  Neither, I'm afraid.

Given the RFC, if someone sends a response that doesn't comply with the
RFC (i.e. a level 1.0 response to level 3.0 offer), there's no way to know
how the offerer will deal with that response.

They could:
a) go asymmetric, and send 1.0 and receive any 1.0 -> 3.0 stream
b) require symmetric, and send and receive 1.0 only
c) Not understand the response and consider it in error, and either
   reINVITE (perhaps to 1.0, or to another codec, or even 3.0 again) or
   send a BYE.
d) Not understand the response and send 3.0 anyways (since the payload
   value was accepted, and the RFC doesn't allow for changing the level of
   a payload).
e) Process the response as a new, added payload (since it doesn't match
   on the triple of level, packetization, deint-buf) even though
   numerically it's the same.  Given offer-answer semantics, this would
   mean the answer did not provide a payload that was offered, and while 
   each side should continue to accept what they sent, the offerer
   should not send.  This is probably the most canonically-correct way to
   handle the response per the RFCs (3984 and 3264).

You don't know which of these they will do, especially if the
implementation was developed in a closed system without direct
interoperation tests (against systems that may not comply with the RFC and
so force them to do something other than option e, or whatever possible
mis-reading of the RFC they had).

Now, Roni may be correct that some of the conferencing people have assumed
that you don't have to match profile-level-id (which is incorrect per the
RFC, but if they all test against each other may work in practice).  If
there is a big hole in the RFC that has caused everyone to make some
non-compliant assumption (like option 'a' above), then it should be 
made into a new RFC (3984bis).  They may find that the authors had a reason
for not allowing it, or perhaps there's a better solution to their problem.

So neither is 'correct'.  One of those (or one of a-e) may be compatible
with many or even most H.264+SIP+SDP devices -- but I doubt that either
choice will avoid compatibility problems with all such devices.
Unfortunately. 

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt