Subject: [AVT] Doubts in draft-ietf-avt-rfc2429-bis-09.txt

From: "Huve, Frederic" <[email-masked]>
Date: Tue, 28 Nov 2006 17:00:35 +0100

Roni,

We're investigating to move from RFC 2429 support to rfc2419-bis-09
support and it remains one question around Offer/Answer. (I've browsed
the mail archive and partially found part of the response
http://www1.ietf.org/mail-archive/web/avt/current/msg06890.html :)

In the following use case, what is the valid SDP Offer/Answer scenario ?

If an offerer sends a SDP offer (meaning he wants to receive QCIF with
MPI = 2):
 
m=video 8000 RTP/AVP 96
a=rtpmap:96 H263-1998/90000
a=fmtp:96 QCIF=2
a=sendrecv
 
The answerer sends the following SDP answer (means that he can receive
up to CIF with MPI = 1):

m=video 8002 RTP/AVP 96
a=rtpmap:96 H263-1998/90000
a=fmtp:96 CIF=1
a=sendrecv

IMHO this scenario is not valid because of the RFC-2429bis statement: "
A system that declares support of a specific MPI for one of the
resolutions SHALL also implicitly support a lower resolution with the
same MPI."

In order to be compliant the answerer should instead responds with the
following SDP answer: 

m=video 8002 RTP/AVP 96
a=rtpmap:96 H263-1998/90000
a=fmtp:96 CIF=2
a=sendrecv

Warm thanks for your time !
Regards,
Frederic

[email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 29 Nov 2006 09:14:23 +0200

Frederick,
The picture size and MPI parameter specify receiver capability (see in
the text from 2429bis bellow), it does not imply what will be sent since
asymmetry is allowed. So if the answerer specified CIF=1 it means that
it can receive CIF at upto 30 frames per second, it must only send QCIF
at 15 frames per second on lower.
So both answers are correct.

The sentence from RFC2429 means that if the offer specified QCIF=2 it
means that it can receive SQCIF=2 or lower but not SQCIF=1. It does not
say what resolution and at which frame rate it will send.

>From 2429bis

Picture sizes and MPI:

   Supported picture sizes and their corresponding minimum picture
interval (MPI) information for H.263 can be combined.  All picture sizes
can be advertised to the other party, or only a subset of it. Terminal
announces only those picture sizes (with their MPIs) which it is willing
to receive.  For example, MPI=2 means that maximum(decodable) picture
rate per second is about 15.

Roni

> -----Original Message-----
> From: Huve, Frederic [mailto:[email-masked]]
> Sent: Tuesday, November 28, 2006 6:01 PM
> To: Even, Roni
> Cc: AVT WG
> Subject: Doubts in draft-ietf-avt-rfc2429-bis-09.txt
> 
> Roni,
> 
************************************************************************
**
> **********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
computer
> viruses.
************************************************************************
**
> **********

---

From: "Huve, Frederic" <[email-masked]>
Date: Wed, 29 Nov 2006 16:57:58 +0100

Roni,

Thanks for your fast and clear answer !

To complete the picture, in the depicted scenario, the answerer MAY send
a re-INVITE with a SDP Offer set to QCIF in order to insure that the
initial offerer will not send CIF, is that right ?

As suggested by Desineni some times ago on the list
(http://www1.ietf.org/mail-archive/web/avt/current/msg07267.html), it
would be good to provide some Offer/Answer examples with Profile &
Level, and also with Picture size and MPI.

Again thanks for you support.
Regards,
Frederic

[email-masked]

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Wednesday, November 29, 2006 8:14 AM
To: Huve, Frederic
Cc: AVT WG
Subject: RE: Doubts in draft-ietf-avt-rfc2429-bis-09.txt

Frederick,

Picture sizes and MPI:

Roni

computer

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 30 Nov 2006 09:32:11 +0200

Frederick,
Yes, The answerer May send a re-INVITE with QCIF to ensure that it will
receive QCIF and not CIF.

As for the suggestion to add offer answer, I think it may be a bit late
since it is in author48 but we intend to have a new and what we hope
last revision that will be the candidate for a proposed standard that
will clear all issues after deployment.

I suggest starting implementing based on this draft mostly since RFC2429
did not have the mechanism to specify resolution and frame rates.

Roni  

> Sent: Wednesday, November 29, 2006 5:58 PM
> To: Even, Roni
> Cc: AVT WG
> > In the following use case, what is the valid SDP Offer/Answer
scenario
> ?
> > IMHO this scenario is not valid because of the RFC-2429bis
statement:
> "
computer