Frank, To answer your questions specifically:

Pete,

I am having difficulty with what it is that you are trying to convey. Let me try to summarise:

- An empty CS is transmitted "as a TCS message" containing only a sequence number and a protocol identifier.

- The effect of receiving such a message does not effect the stored caps of

This is what an "empty TCS" is now defined as... at least for today! the sending EP at the receiving EP Yes it does: The receiving EP now believes that the sending has no receive capabilities.

- You (and the team you're working with) would have liked the effect to have been that all caps are removed.

The result of the two methods is the same, but we would have preferred an "empty TCS" to mean one that indicated that all remaining caps were removed. E.g., if you had: Current capability set: 0: {{H.261qcif&cif},{G.723.1,G.711)} 2: {{H.263sqcif&qcif&cif},{G.723,G.711}} Then empty TCS would be: 0: {} 2: {} plus removing the individual caps such as H.261qcif etc.

I do not think that I understand your statement on "Re-cap" providing 90% of the functionality in the case that you do not understand empty CSs, could you elaborate on that?

By re-capping I mean the ability to receive a new capability set and act on it accordingly. For example, if you had: Current capability set: 0: {{H.261qcif},{G.711}} 1: {{H.261cif},{G.711}} and were transmitting H.261cif and you received Incoming termCapSet 2 as: 1: {} resulting in: Current capability set: 0: {{H.261qcif},{G.711}} You would have to close your H.261cif channel (and hopefully open a H.261qcif channel). By 90% I mean, if you act as above, you get most of the behaviour required for third party pause. What you don't get is the MSD happening again when you receive a non-empty cap set. ============================================= Pete Cordell pete@tech-know-ware.com =============================================