Subject: [AVT] JP2RTP & JPWL & JPSEC

From: Andrew Leung <[email-masked]>
Date: Mon, 06 Jun 2005 18:08:47 +0900

Hi All,

There is some discussion within the ISO JPEG groups to propose a new RTP
format for a new project going on there called: JPWL (JPEG 2000 for
WireLess). One idea for them was to adopt the current IETF work, JP2RTP
(our work), with an amendment to handle JPWL capabilities. Similar work
is going on in JPSEC (JPEG 2000 for Security & Authentication)

We would like to ask AVT chairs & members their opinion on extending
support in JP2RTP for these 2 related applications. As this work item,
JP2RTP, has been extended quite long, we would like to have it goto RFC
soon but if we can avoid confusion in the longer term, or avoid
amendments to it by others, we would be interested in merging this work
together and completing it here.

I have researched JPWL and found that it is probably 100% compatible
with JP2RTP. Almost all of JPWL extended functionality is through extra
markers in the codestream. These codestream extensions are designed not
to disturb a JPEG 2000 decoder from processing it properly. (i.e. a
decoder is designed to ignore unknown options and the markers are
specified in their own specification outside the normal range of JPEG
2000 and other JPEG markers.) JP2RTP is specified to send JPEG 2000
codestream in a packetized manner, regardless of markers.

Including JPWL support in JP2RTP may be as simple as adding the proper
SDP/MIME option at the start of the session to let receivers know to do
extra processing for JPWL markers. The JPWL markers and proper handling
will be described in detail in the ISO standard (it will be standardized
at the end of the year or so.)

Another highly related project following a similar pattern is JPSEC
(JPEG 2000 for Security & Authentication) which has a similar design
principle as JPWL. Changes to the codestream should not break decoder
processing, even if the image is encrypted. JPSEC codestreams encrypt
the image in a way that the decoder can properly decode the image but
fails to display properly at varying levels.

JPSEC processing is outside of the transmission but transmission level
information would be required for receiver processing. In-band signaling
(i.e. this frame/packet is encrypted) and SDP/MIME signaling (i.e.
frames in this session will be encrypted) would be all that is needed
for JP2RTP to support this application.

We are not directly involved with either of these ISO group but know
members within both from past work. We are planning to collaborate
further and there is interested from JPWL Chair, Didier Nicholson, on
this topic.

JPWL Information & Links:
http://www.jpeg.org/jpeg2000/j2kpart11.html
http://www.jpeg.org/apps/wireless.html (description @ jpeg.org)
http://lts1pc19.epfl.ch/repository/Dufaux2004_1114.pdf (paper on JPWL)

JPSEC:
http://www.jpeg.org/jpeg2000/j2kpart8.html
http://www.2kan.org/jpsec.html

Sincerely,
andrew

-- 
Andrew Leung		 	[email-masked]
BEAM Group				+81-3-5448-2125
Sony Corporation

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

---

From: Colin Perkins <[email-masked]>
Date: Sat, 11 Jun 2005 14:08:12 +0100

Andrew,

[inline]

> at the end of the year or so.)

I know very little about JPWL, but if it's possible to effectively  
use the existing RTP payload format, that would seem a more effective  
solution than defining another payload format.

That said, what is the purpose of the JPWL extensions? While the bit  
stream may be compatible with the existing RTP payload format, is  
there other functionality that might be affected by RTP  
packetisation? For example, some previous payload formats spend  
considerable effort to get tolerance to bit errors for wireless  
environments, and if that feature is needed there may be an argument  
for changing the RTP payload format to support it.

> for JP2RTP to support this application.

If it's possible to fit this into the current payload format in a  
compatible manner, that's clearly desirable. There would clearly need  
to be discussion in the payload format to describe then JPSEC is  
suitable versus SRTP, but that doesn't seem to be unreasonable. The  
more difficult issue here may be SDP signalling, especially if  
there's a need to convey keying material (i.e. do the SDP  
sdescriptions or kmgmt extensions work for this application, or is  
there a need for some new signalling).

Colin

---

From: Andrew Leung <[email-masked]>
Date: Mon, 13 Jun 2005 19:17:06 +0900

Hi Colin,

[inline & original notes deleted]

> solution than defining another payload format.

Yes, we would like to keep things as simple as possible for all parties 
involved. We have not heard much from the JPWL editors so we are 
questioning whether this issue will move forward at all. We have done 
some research on JPWL & JPSEC and this is our conclusion. Since the JPWL 
editor is based in Paris, we can definitely get some discussion on the 
issue at the next IETF meeting.

> for changing the RTP payload format to support it.

The primary goal of the JPWL extensions are to provide error correction 
within the codestream. Errors are not just masked or noticed but a 
Reed-Solomon coding is included in the codestream to recover damaged 
codestream. Markers specify how this error correction code is done and 
used within the codestream.

If we treat this as straight codestream, in the best case scenario, 
nothing is done, in the worse case scenario, the codestream would be 
processed through a JPWL decoder to perform error correction.Would there 
be a significant change to the payload format for this? From our point 
of view (as JPEG 2000 experts) how the codestream is packetized, sent, 
or flagged should not matter but it would definitely help if receivers & 
senders knew about the capability before hand (i.e. start of the 
session) and if resources were available, we could compensate using this 
information.

Should we be considering something more in such a situation? (i.e. 
sending error recovery data later, or partitioning the transfer or 
retransfering the error correction data?)

> there a need for some new signalling).

Aaaah, yes, the question of the key exchange scheme did come up after I 
wrote the email. I felt this topic could be left out of this draft (i.e. 
out of scope) but if the exchange scheme is required to be described in 
detail, we probably can't move forward. The key exchange scheme is not 
described in detail in the ISO draft either so it's out of my scope of 
knowledge and only a suggestion based on my current understanding of the 
draft.

Perhaps it is easier to keep things the way they are and when JPWL and 
JPSEC people come to IETF to do a payload format for their respective 
standard, you can point them to this work and have them extend or modify it?

regards,
andrew

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 Jun 2005 12:08:55 +0100

Hi Andrew,

On 13 Jun 2005, at 11:17, Andrew Leung wrote:
...
>> I know very little about JPWL, but if it's possible to  
>> effectively  use the existing RTP payload format, that would seem  
>> a more effective  solution than defining another payload format.
>>
>
> Yes, we would like to keep things as simple as possible for all  
> parties involved. We have not heard much from the JPWL editors so  
> we are questioning whether this issue will move forward at all. We  
> have done some research on JPWL & JPSEC and this is our conclusion.  
> Since the JPWL editor is based in Paris, we can definitely get some  
> discussion on the issue at the next IETF meeting.

Okay, good.

>> That said, what is the purpose of the JPWL extensions? While the  
>> bit  stream may be compatible with the existing RTP payload  
>> format, is  there other functionality that might be affected by  
>> RTP  packetisation? For example, some previous payload formats  
>> spend  considerable effort to get tolerance to bit errors for  
>> wireless  environments, and if that feature is needed there may be  
>> an argument  for changing the RTP payload format to support it.
>
> The primary goal of the JPWL extensions are to provide error  
> correction within the codestream. Errors are not just masked or  
> noticed but a Reed-Solomon coding is included in the codestream to  
> recover damaged codestream. Markers specify how this error  
> correction code is done and used within the codestream.
>
> nothing is done, in the worse case scenario, the codestream would  
> be processed through a JPWL decoder to perform error  
> correction.Would there be a significant change to the payload  
> format for this? From our point of view (as JPEG 2000 experts) how  
> the codestream is packetized, sent, or flagged should not matter  
> but it would definitely help if receivers & senders knew about the  
> capability before hand (i.e. start of the session) and if resources  
> were available, we could compensate using this information.
>

Yes, perhaps. The issue is that if RTP is conveyed over UDP, the UDP  
checksum will detect any bit errors and discard the packet, breaking  
any protection within the payload. If detection of corrupt packets is  
needed, then something like UDP-lite needs to be used in conjunction  
with the payload format, and the draft needs to discuss the whole  
system issues.

>> compatible manner, that's clearly desirable. There would clearly  
>> need  to be discussion in the payload format to describe then  
>> JPSEC is  suitable versus SRTP, but that doesn't seem to be  
>> unreasonable. The  more difficult issue here may be SDP  
>> signalling, especially if  there's a need to convey keying  
>> material (i.e. do the SDP  sdescriptions or kmgmt extensions work  
>> for this application, or is  there a need for some new signalling).
>
> Aaaah, yes, the question of the key exchange scheme did come up  
> after I wrote the email. I felt this topic could be left out of  
> this draft (i.e. out of scope) but if the exchange scheme is  
> required to be described in detail, we probably can't move forward.  
> The key exchange scheme is not described in detail in the ISO draft  
> either so it's out of my scope of knowledge and only a suggestion  
> based on my current understanding of the draft.

The IETF may have solutions that work off-the-shelf for JPEG,  
although some security folks would need to review both pieces of work  
to determine that. Alternatively, we might just document the issues,  
and note that the solutions are for further study.

> Perhaps it is easier to keep things the way they are and when JPWL  
> and JPSEC people come to IETF to do a payload format for their  
> respective standard, you can point them to this work and have them  
> extend or modify it?

Perhaps, although it sounds like there is more scope for discussion  
of possible solutions before we come to that conclusion.

Colin