- sg16-avd - lists.packetizer.com

Here goes another test from the listserv admin
by Sessions, Barbara 16 Aug '02

16 Aug '02

Still making changes please stand by Thanks Barbara.Sessions(a)intel.com CTG-IT Liaison 503-264-3030 pager 1-888-950-0710

1 0

testing to see if I get this back
by Sessions, Barbara 16 Aug '02

16 Aug '02

This is another test after a couple changes to the server. Thanks Barbara.Sessions(a)intel.com Corporate Technology Group/ITLiaison 503-264-3030

1 0

Testing to see if confirm will work for the ITU-SG16 list
by Sessions, Barbara 16 Aug '02

16 Aug '02

Hi All, I've been working with Greg to try and resolve an issue with your list. This is a test message and thanks for your patients. Thanks Barbara.Sessions(a)intel.com

1 0

Test2 without confirm from web interface
by Sessions, Barbara 15 Aug '02

15 Aug '02

Sorry all but this is another test from the postmaster.

1 0

postmaster testing your list
by Sessions, Barbara 15 Aug '02

15 Aug '02

All Thanks for allowing me to test today on your listThanks Barbara.Sessions(a)intel.com Corporate Technology Group/ITLiaison

1 0

Test #2
by Branch, Brett 14 Aug '02

14 Aug '02

OK, so the first test mail I sent didn't seem to be delivered, even though log files show that it was posted via SMTP. I am adding an ack on my options to see if I get that... -Brett

1 0

Test
by Branch, Brett 14 Aug '02

14 Aug '02

Hi all, I run the listserver that this list is hosted on. I have heard reports of mail delays and missing deliveries, so I am going to do some tests. When I look at the server log files, it says it is distributing email, so at this point I think the problem is not with the listserver itself, but that mail is being held on some other mail relay host. So, please excuse the intrusion while I send some test emails... -Brett Branch Intel Reasearch and Development Operations Support

1 0

Problems with ITU-SG16 Mail Reflector
by Meyer, Greg W 13 Aug '02

13 Aug '02

All: Part of this message is to test whether the ITU-SG16 Mail Reflector is working and the other is to announce that we are experiencing difficulties. The symptoms are that you will get a message from LISTSERV to confirm delivery by the server will never send the message. We are looking into the problems and will notify when we (think we) have it fixed. Sorry for the inconvenience. Greg Meyer Intel Labs

1 0

Re: AVD-2257
by OKUBO Sakae 12 Aug '02

12 Aug '02

Dear Mr. Anderson, At 15:53 -0400 02/08/12, Terry L Anderson wrote: >I have been unable to upload AVD-2257 to the avc-site incoming directory. >The machine will not allow anonymous connections. Can you arrange to get >the document into the Raleigh directory? Done as requested. PS I am copying this to the reflector, which was not working some days ago. I hope it would work this time. Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan *******************************************************************

1 0

Flaws in H.235 media encryption
by Paul Long 12 Aug '02

12 Aug '02

I believe there are fundamental flaws in H.235 media encryption, i.e., how long the master waits before transmitting a new payload-type after distributing the corresponding key, the directional ambiguity of encryptionUpdate and encryptionUpdateRequest, and conflicts arising from both the slave and master assigning new dynamic payload types for slave-to-master streams. These are discussed in detail, below... 1. After distributing a new key via an encryptionUpdate command for a master-to-slave RTP stream, how long should the master wait before transmitting packets with the new payload type? The problem is that packets with the new payload type (and therefore using the new key) may arrive before the encryptionUpdate command that tells the slave what payload-type/key pair to expect! There are three solutions as I see it: A. The slave discards new packets until the encryptionUpdate command arrives. B. The master uses prior network behavior to predict when the slave will receive the command and then waits so that packets using the new payload type will (hopefully) arrive sometime after that. The slave should still implement A because this prediction is imprecise. C. We require a three-way handshake by adding an encryptionUpdateAck command for master-to-slave streams (would be redundant for slave-to-master streams). This would be backwards compatible because existing implementations would simply ignore this new command which is sent from slave to master. A and B are local workarounds; C is the ultimate solution. Discarding packets is especially problematic for video because video compression schemes rely on inter-packet dependencies. I believe H.233 anticipated this problem by providing a codepoint in H.245 to define how long the transmitter must wait before using the new key. H.235 also needs something to address this problem, preferably C. 2. H.235 says that "[the slave, acting as] a receiver (or transmitter) may request a new key [from the master]" and "The master may also decide asynchronously to distribute new key(s)." However, there is no codepoint in either the encryptionUpdate or encryptionUpdateRequest command to indicate whether it refers to a slave-to-master or master-to- slave RTP stream. The MiscellaneousCommand.logicalChannelNumber field is no help either because its values are assigned independently by each transmitter--both EPs may be using the same LCN. For example, assume that both EPs are transmitting audio on their respective LCN 5. The master intends to asynchronously update the key for its outgoing audio by sending this command to the slave: MiscCmd(lCN=5,encrUpdate=(synFlag=200,h235Key=X)) How should the slave interpret this command? Does this refer to the slave's own, outgoing audio channel or the master's audio channel? Likewise, if the slave sends MiscCmd(lCN=5,encrUpdateReq=sharedSecret), how should the master interpret this? Does the slave want the master to update the key for the slave's audio channel or the master's audio channel? As it is, IMO, key resynchs should not be attempted for channels that have the same LCN; however, that would be difficult for equipment from the same vendor because, depending on the LCN-assignment scheme, the same values may always be used. 3. When the master sends an encryptionUpdate command, it specifies the new dynamic payload type, or DPT, in the synchFlag field; however, this presents problems for a slave-to-master stream because the transmitter otherwise manages its own DPTs. For example, what if the master sends an encryptionUpdate command for the slave-to-master audio stream, specifying new DPT, 102, but before the slave receives it, the slave sends a video OLC with the same DPT--102? How do we resolve this conflict? Maybe the master should reject the OLC because it knows that it just assigned that DPT to the audio channel, but what cause should the master return? cause=masterSlaveConflict? Is this enough for the slave to figure out what's wrong and retry the OLC with another DPT? We should define how to resolve these kinds of conflicts, but it would be really great if we could revamp this whole key-resynch area due to all of the problems I have described here. Paul

1 0