Subject: RE: [MMUSIC] Offer/Answer model does not work for H.264 parameter s

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 29 Mar 2004 16:49:29 +0200

Hi Magnus,

I agree with your problems related to options 1 and 3.

I need to look into option 2 more in detail later, but just a couple of issues to keep in mind.

First, when you assume that at least one PT in the answer must much the offer, please remember that you may include PTs for other, non-H264 codecs, in the same offer. You may still, of course, receive an H.264 PT, but is it possible that you receive one that doesn't "match" any in the offer?

Second, when thinking about multiple m= lines the rule that you can't use the same port comes up (even if you don't expect to receive anything on the port indicated in a sendonly stream), which may cause problems.

I don't know if these issues are valid for this problem (like I said, I will need to look into it more in detail), but just something to remember :)

Regards,

Christer Holmberg
Ericsson Finland

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Magnus Westerlund (KI/EAB)
> Sent: 26. maaliskuuta 2004 14:56
> To: mmusic (E-mail)
> Cc: Jae-Hwan Kim
> Subject: Re: [MMUSIC] Offer/Answer model does not work for H.264
> parameters
> 
> 
> Hi,
> 
> I thought about the issue and there is a reason why one could need to 
> have multiple media lines: to be able to declare asymmetric 
> sending and 
> receiving capabilities. This is best illustrated by the following 
> example. It also clarifies a bit about what restrictions will 
> need to be 
> applied to make the negotiation mechanism work.
> 
> Example:
> Below the offerer gives two sets of configurations. The 
> parameter-sets 
> are based on the offered profile and level. Notice that I am not very 
> strict with parameter names or if levels exist. it is simply 
> an example.
> 
> Offer:
> PT: parameters
> m= 97 98
> 97: profile-level:extended, level=3; interleaved-mode; 
> parameter-sets=O-1
> 98: profile-level:baseline,level=1; single-nalu-mode; 
> parameter-sets=O-2
> 
> Parameter set O-2 would be used by the offerer to send a stream in 
> accordance with the declared PT 98 from the offerer to the answerer.
> 
> If the answerer would return something like this:
> PT: parameters
> m= 100 101
> 101: profile-level:extended, level=5; interleaved-mode; 
> parameter-set=A-1
> 100: profile-level:baseline,level=1; single-nalu-mode; 
> parameter-set=A-2
> 
> Then we have a problem:
> How to know if A-1, is a sender declaration belonging to 
> payload type 97 
> or 98. This could be resolved in two ways:
> 
> 1. Restrict payload type numbers to be the same, and use 
> these to match.
> 
> 2. Restrict the payload type declaration to be exactly the 
> same, so one 
> can use the parameters string to match that it belongs to the 
> corresponding declaration.
> 
> 3. Encode the senders parameter with what payload type is belongs to.
> 
> There is a warning in RFC 3264 that due to H.323 there is 
> certain cases 
> where the PTs must change. This would make 1 in that case impossible.
> 
> 2. will probably work better, as it would allow the answerer to add 
> additional payload types for further capabilities. Please note that 
> there is a requirement in O/A that at least one PT in a 
> answer is from 
> the offer. This solution will require more difficult comparisons.
> 
> 3. This will make it impossible to have only a single round 
> of offer and 
> answer, as the initial offerer would need to update his offer 
> to match 
> the PTs that the answerer declares. Therefore I don't see 
> this a viable 
> solution.
> 
> If one applies alternative 2 above an answer would need to 
> look like this.
> 
> The answerer would return something like this:
> PT: parameters
> m= 101 102 100
> 101: profile-level:extended, level=5; interleaved-mode; 
> parameter-set=A-1
> 100: profile-level:baseline,level=1; single-nalu-mode; 
> parameter-set=A-2
> 102: profile-level:extended, level=3; interleaved-mode; 
> parameter-set=A-3
> 
> The problem with this is that the offerer would need to 
> update its offer 
> and include a configuration in accordance with the Answers PT 
> 101 in its 
> offer. Thus requiring it to do another round of O/A.
> 
> It also has the problem with that the Offer can't declare its sending 
> parameters without also accepting to receive them, unless there is a 
> send only stream. For send and receive streams it will not be 
> possible 
> to have non-symmetric receiving capabilities between the end-points.
> 
> The solution as I see to this problem would require the offerer and 
> answer to use at least two media streams. Otherwise an offerer would 
> need to declare the video stream as two separate media sessions, one 
> with sendonly, another with recvonly.
> 
> Feedback is greatly appreciated.
> 
> 
> Cheers
> 
> 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]
> 
> 
> This communication is confidential and intended solely for 
> the addressee(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you believe this message has 
> been sent to you in error, please notify the sender by 
> replying to this transmission and delete the message without 
> disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data 
> corruption, interruption, unauthorized amendment, tampering 
> and viruses, and we only send and receive e-mails on the 
> basis that we are not liable for any such corruption, 
> interception, amendment, tampering or viruses or any 
> consequences thereof.
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic