- sg16-avd - lists.packetizer.com

(no subject)
by rkumar＠cisco.com 11 Sep '03

11 Sep '03

Dear Colleagues, For our meeting in Arlington the last week of this month, I have uploaded the following documents to the SG16/Q11 mirror site: http://ftp.tiaonline.org/TR-30/TR301/Public/TR-30.1/2003-09-Q11-mirror/ Document number Title Q1109-018.doc <http://ftp.tiaonline.org/TR-30/TR301/Public/TR-30.1/2003-09-Q11-mirror/ Q1109-018.doc> A proposed list of VBD Stimuli Q1109-019.doc <http://ftp.tiaonline.org/TR-30/TR301/Public/TR-30.1/2003-09-Q11-mirror/ Q1109-019.doc> Media Switching to Voice Band Data Q1109-020.doc <http://ftp.tiaonline.org/TR-30/TR301/Public/TR-30.1/2003-09-Q11-mirror/ Q1109-020.doc> SDP declaration and negotiation of VBD capabilities Q1109-021.doc <http://ftp.tiaonline.org/TR-30/TR301/Public/TR-30.1/2003-09-Q11-mirror/ Q1109-021.doc> New RIC codes for SSE:VBD and SSE:TR Q1109-022.doc <http://ftp.tiaonline.org/TR-30/TR301/Public/TR-30.1/2003-09-Q11-mirror/ Q1109-022.doc> New parameters for the negotiation of V.VBD operation Q1109-023.doc <http://ftp.tiaonline.org/TR-30/TR301/Public/TR-30.1/2003-09-Q11-mirror/ Q1109-023.doc> Indication of V.VBD and V.ToIP document version in channel negotiation Q1109-024.doc <http://ftp.tiaonline.org/TR-30/TR301/Public/TR-30.1/2003-09-Q11-mirror/ Q1109-024.doc> List of Discovered Errors and Inconsistencies in V.150.1 Similarly, at its companion TR.30.1 site http://ftp.tiaonline.org/TR-30/TR301/Public/TR-30.1/2003-09-Arlington/ I have uploaded the following file: Document number Title 10309059.doc <http://ftp.tiaonline.org/TR-30/TR301/Public/TR-30.1/2003-09-Arlington/1 0309059.doc> Indication of V.VBD and V.ToIP document version in channel negotiation Please review and provide me with your comments. It will save time at the meeting if we get a head start on these discussions. Thank you, Rajesh Kumar Voice Systems Architecture Cisco Systems

1 0

RE: H.323 Fast Connect and Versioning
by PeterP＠VEGASTREAM.COM 11 Sep '03

11 Sep '03

Paul, as I said before any solution is likely to be a bit dirty because of the nature of the problem. I think your "syntax2002" suggestion is perfectly valid - it is a smaller more localised change and, especially given the reluctance to add new code points, is probably a better alternative than t39faxV2. It only requires a single change to T38FaxProfile rather than changes to both DataApplicationCapability and DataApplicationMode. There is no danger that the change could affect anything other than T.38 aware endpoints. On the subject of H245 tunneling, the problem scenario we're discussing is Fast Connect and I thought that H.323 V4 says that endpoints using Fast Connect shall use H.245 tunneling! It doesn't do much for pure T.38 endpoints which don't do any H.245 though. The thread has suggested two approaches 1. resolve the issue within the Fast Connect proposal (or any subsequent requestMode/OLC etc) 2. resolve the issue by modifying some other part of the standard by introducing "special cases" As an implementor, I would prefer to see a solution within the Fast Connect proposal rather than force other changes in the standard - the danger of going that route is you don't know what the downstream consequences are going to be. Containing the solution in T38FaxProfile keeps implementation simpler - you receive a message and you know exactly what you are doing without having to go looking for other information. Logically, the tunneled H245 messages arrive after the Setup message and its easier to process the Setup completely before starting to look at the H.245. Furthermore, if H.323 endpoints are to remain interoperable with pure T.38 endpoints (are there any?) then the solution *must* be contained within the Fast Connect proposal. You suggest that "syntax002" is a bit of a kludge. It probably is but it does have the advantage of being isolated. I think that "special cases" in the standard that may have unforeseen consequences for endpoints that are not interested in T.38 are very much worse. ------------ A slight aside here (but related). Your remark about the way that all endpoints appear to decode and re-encode the Fast Connect proposals implies that the rule for not changing the proposals is effectively impossible to maintain. I only work with audio endpoints that use the basic audio codecs and T.38 so until this discussion started hadn't really thought about this issue. It's easy to say you musn't change, say, the frame count of G729 but for codecs that are defined as extensible like T.38 (and all the video codecs) there will always be a problem when new endpoints offer new features to old endpoints. Perhaps the Fast Connect rule needs some review to address the specific issue of extensible capabilities. Have video endpoints already encountered this problem? Do any video endpoint implementors have any relevent comments here? Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 23:35 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I've only seen this problem with fax. To answer your last question, I've only seen T.38 use this kind of version tag. However, V.150.1 also has versioning information as part of the object identifier that identifies the capability. This will be interesting to see if we introduce the same kind of problem there. In general, it's just not good to advertise the version through an OLC... it's better to perform a full caps exchange. The trouble is that modem and (to some extent) fax timings are such that we must open channels ASAP... before a caps exchange. (Actually, we could transmit the termcap set in the Setup message, but few devices support that.) We have had non-compatible payload specifications before and we resolved that by adding new code points. However, we've been trying to avoid that. Even so, we could do it again... it's just less desirable. I had another idea. What we could do is, within the t38faxProtocol SEQUENCE, we could indicate which syntax is to be used. Older devices would not see this field and would not decode it. So, when the reply is re-encoded, it would not be present. So, even if the version was set to "2", the "Syntax2002" field, say, would not be present. This would mean that the 1998 syntax has to be used. A newer endpoint would see the field and would properly re-encode it in the reply. This is a bit of a kludge and works only because of the way the ASN.1 encoding/decoding works with every device I've seen. Another solution to the problem might be to require that endpoint use H.245 tunneling and to advertise their capabilities in the Setup message. That could allow us to avoid this problem entirely. I'm just not sure how excited people would be to be forced to use H.245 tunneling every time they use fax, modem, or text relay. Paul ----- Original Message ----- From: Peter <mailto:PeterP@vegastream.com> Price To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> Sent: Wednesday, September 10, 2003 12:34 PM Subject: RE: H.323 Fast Connect and Versioning Paul, I wrote the first part of this email and then reread yours - I was bogged down in the fax issue but I think you are actually raising a wider issue aren't you? See part 2 below. -------------------------- Part 1 I don't believe that 5 versions of T38 would result in 5 offered channels. The need for the different capability is due to the fact that what you are offering is a payload that is encoded in a different and incompatible way. ie its a bit like offering G.729 and the sending packets encoded according to G.723.1, they both represent speech but they are not going to be played out properly. The single extra bit introduced into the T.38 payload packet by the 2002 ASN.1 is backwards incompatible. The problem only exists for endpoints that only know about the 1998 ASN.1 and are unaware of the incompatibility - it is important that they do not think they can accept the offered channel. Once an endpoint is aware of the problem (ie it knows about the 2002 ASN.1) then it can handle versions >= V2 (as well as V0 and V1). Of course, this does assume that a similar incompatibilty does not creep into the payload ASN.1 in future versions - but that's down to careful work in the standard development and editing stage. I still think adding t38faxV2 (say) to DataApplicationCapability and DataApplicationMode is the simplest solution [ t38faxV2 would use the same definitions for t38FaxProtocol and t38FaxProfile - its only the payload that has changed ]. This protects the existing T.38 implementations and avoids the need to break the rule about modifying Fast Connect proposals. The change in the T.38 payload ASN.1 breaks the fundamental backwards compatibility that ASN.1 is supposed to guarantee and thus whatever the final solution there has to be an element of a hack involved - I think that this change would isolate the change and protect the rest of the standard. -------------------------- Part 2 The versioning issue applies to any form of payload, voice/video/fax/whatever. The problem is still going to exist in early versions of endpoints that don't understand the consequence of accepting versions that they do not understand fully. If a new version of a codec's payload is not backwards compatible then I would assert that it is a new codec and must be signalled as a different capability. The issue of multiple variations already exists anyway although not (to my knowledge) with version numbers. Endpoints already offer multiple packet sizes for exactly the reason that you are not supposed to alter the Fast Connect proposal. What happens when somebody starts to offer g729Extensions and has to offer all the combinations of Annexes because they don't know what the other end can use ( I make that 64 proposals in each direction without adding further annexes! )? I don't see that relaxing the rule about modifying the version in a Fast Connect channel will help resolve the problem of having to offer multiple proposals. You either have to allow *anything* to be modified or stick to the current rule. Exceptions allowing certain fields to be modified just makes life much more difficult and confusing. T.38 is the only codec I am aware of that actually uses a version number in this manner. Are there any others? Why was it introduced in T.38? Perhaps this is a lesson for the future about the value of introducing of such a field in other codecs. Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 16:01 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I think you're on the right track. We could avoid ASN.1 changes by introducing the new capability as a generic data capability, but a new capability is required here, I think. The problem, as I see it, is that when we use Fast Connect, we can't alert the calling side as to what version the called side actually supports. This suggests that if we have 5 versions of T.38, the calling side would have to propose a channel for each version independently. That's horrible. It's only complicated further by the fact that T.38 may not be signaled by itself-- it might be part of audio proposals that also include modem, text over IP, VBD, or other media. It might even be that there are several versions of the modem (V.150.1) protocol advertised. I think the only real solution to this problem is to allow the Fast Connect proposals to be altered by the called endpoint such that they can change the version number.. and nothing else. H.323 has an explicit statement that says that the proposals can't be modified before returning them, but perhaps this simple exception might resolve these issues. I think without such, it's going to be terrible complicated. Paul ----- Original Message ----- From: Peter <mailto:PeterP@vegastream.com> Price To: 'paulej(a)PACKETIZER.COM' <mailto:'paulej(a)PACKETIZER.COM'> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> Sent: Wednesday, September 10, 2003 3:23 AM Subject: RE: H.323 Fast Connect and Versioning Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

RE: H.323 Fast Connect and Versioning
by Peter Price 11 Sep '03

11 Sep '03

Paul, as I said before any solution is likely to be a bit dirty because of the nature of the problem. I think your "syntax2002" suggestion is perfectly valid - it is a smaller more localised change and, especially given the reluctance to add new code points, is probably a better alternative than t39faxV2. It only requires a single change to T38FaxProfile rather than changes to both DataApplicationCapability and DataApplicationMode. There is no danger that the change could affect anything other than T.38 aware endpoints. On the subject of H245 tunneling, the problem scenario we're discussing is Fast Connect and I thought that H.323 V4 says that endpoints using Fast Connect shall use H.245 tunneling! It doesn't do much for pure T.38 endpoints which don't do any H.245 though. The thread has suggested two approaches 1. resolve the issue within the Fast Connect proposal (or any subsequent requestMode/OLC etc) 2. resolve the issue by modifying some other part of the standard by introducing "special cases" As an implementor, I would prefer to see a solution within the Fast Connect proposal rather than force other changes in the standard - the danger of going that route is you don't know what the downstream consequences are going to be. Containing the solution in T38FaxProfile keeps implementation simpler - you receive a message and you know exactly what you are doing without having to go looking for other information. Logically, the tunneled H245 messages arrive after the Setup message and its easier to process the Setup completely before starting to look at the H.245. Furthermore, if H.323 endpoints are to remain interoperable with pure T.38 endpoints (are there any?) then the solution *must* be contained within the Fast Connect proposal. You suggest that "syntax002" is a bit of a kludge. It probably is but it does have the advantage of being isolated. I think that "special cases" in the standard that may have unforeseen consequences for endpoints that are not interested in T.38 are very much worse. ------------ A slight aside here (but related). Your remark about the way that all endpoints appear to decode and re-encode the Fast Connect proposals implies that the rule for not changing the proposals is effectively impossible to maintain. I only work with audio endpoints that use the basic audio codecs and T.38 so until this discussion started hadn't really thought about this issue. It's easy to say you musn't change, say, the frame count of G729 but for codecs that are defined as extensible like T.38 (and all the video codecs) there will always be a problem when new endpoints offer new features to old endpoints. Perhaps the Fast Connect rule needs some review to address the specific issue of extensible capabilities. Have video endpoints already encountered this problem? Do any video endpoint implementors have any relevent comments here? Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 23:35 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I've only seen this problem with fax. To answer your last question, I've only seen T.38 use this kind of version tag. However, V.150.1 also has versioning information as part of the object identifier that identifies the capability. This will be interesting to see if we introduce the same kind of problem there. In general, it's just not good to advertise the version through an OLC... it's better to perform a full caps exchange. The trouble is that modem and (to some extent) fax timings are such that we must open channels ASAP... before a caps exchange. (Actually, we could transmit the termcap set in the Setup message, but few devices support that.) We have had non-compatible payload specifications before and we resolved that by adding new code points. However, we've been trying to avoid that. Even so, we could do it again... it's just less desirable. I had another idea. What we could do is, within the t38faxProtocol SEQUENCE, we could indicate which syntax is to be used. Older devices would not see this field and would not decode it. So, when the reply is re-encoded, it would not be present. So, even if the version was set to "2", the "Syntax2002" field, say, would not be present. This would mean that the 1998 syntax has to be used. A newer endpoint would see the field and would properly re-encode it in the reply. This is a bit of a kludge and works only because of the way the ASN.1 encoding/decoding works with every device I've seen. Another solution to the problem might be to require that endpoint use H.245 tunneling and to advertise their capabilities in the Setup message. That could allow us to avoid this problem entirely. I'm just not sure how excited people would be to be forced to use H.245 tunneling every time they use fax, modem, or text relay. Paul ----- Original Message ----- From: Peter <mailto:PeterP@vegastream.com> Price To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> Sent: Wednesday, September 10, 2003 12:34 PM Subject: RE: H.323 Fast Connect and Versioning Paul, I wrote the first part of this email and then reread yours - I was bogged down in the fax issue but I think you are actually raising a wider issue aren't you? See part 2 below. -------------------------- Part 1 I don't believe that 5 versions of T38 would result in 5 offered channels. The need for the different capability is due to the fact that what you are offering is a payload that is encoded in a different and incompatible way. ie its a bit like offering G.729 and the sending packets encoded according to G.723.1, they both represent speech but they are not going to be played out properly. The single extra bit introduced into the T.38 payload packet by the 2002 ASN.1 is backwards incompatible. The problem only exists for endpoints that only know about the 1998 ASN.1 and are unaware of the incompatibility - it is important that they do not think they can accept the offered channel. Once an endpoint is aware of the problem (ie it knows about the 2002 ASN.1) then it can handle versions >= V2 (as well as V0 and V1). Of course, this does assume that a similar incompatibilty does not creep into the payload ASN.1 in future versions - but that's down to careful work in the standard development and editing stage. I still think adding t38faxV2 (say) to DataApplicationCapability and DataApplicationMode is the simplest solution [ t38faxV2 would use the same definitions for t38FaxProtocol and t38FaxProfile - its only the payload that has changed ]. This protects the existing T.38 implementations and avoids the need to break the rule about modifying Fast Connect proposals. The change in the T.38 payload ASN.1 breaks the fundamental backwards compatibility that ASN.1 is supposed to guarantee and thus whatever the final solution there has to be an element of a hack involved - I think that this change would isolate the change and protect the rest of the standard. -------------------------- Part 2 The versioning issue applies to any form of payload, voice/video/fax/whatever. The problem is still going to exist in early versions of endpoints that don't understand the consequence of accepting versions that they do not understand fully. If a new version of a codec's payload is not backwards compatible then I would assert that it is a new codec and must be signalled as a different capability. The issue of multiple variations already exists anyway although not (to my knowledge) with version numbers. Endpoints already offer multiple packet sizes for exactly the reason that you are not supposed to alter the Fast Connect proposal. What happens when somebody starts to offer g729Extensions and has to offer all the combinations of Annexes because they don't know what the other end can use ( I make that 64 proposals in each direction without adding further annexes! )? I don't see that relaxing the rule about modifying the version in a Fast Connect channel will help resolve the problem of having to offer multiple proposals. You either have to allow *anything* to be modified or stick to the current rule. Exceptions allowing certain fields to be modified just makes life much more difficult and confusing. T.38 is the only codec I am aware of that actually uses a version number in this manner. Are there any others? Why was it introduced in T.38? Perhaps this is a lesson for the future about the value of introducing of such a field in other codecs. Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 16:01 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I think you're on the right track. We could avoid ASN.1 changes by introducing the new capability as a generic data capability, but a new capability is required here, I think. The problem, as I see it, is that when we use Fast Connect, we can't alert the calling side as to what version the called side actually supports. This suggests that if we have 5 versions of T.38, the calling side would have to propose a channel for each version independently. That's horrible. It's only complicated further by the fact that T.38 may not be signaled by itself-- it might be part of audio proposals that also include modem, text over IP, VBD, or other media. It might even be that there are several versions of the modem (V.150.1) protocol advertised. I think the only real solution to this problem is to allow the Fast Connect proposals to be altered by the called endpoint such that they can change the version number.. and nothing else. H.323 has an explicit statement that says that the proposals can't be modified before returning them, but perhaps this simple exception might resolve these issues. I think without such, it's going to be terrible complicated. Paul ----- Original Message ----- From: Peter <mailto:PeterP@vegastream.com> Price To: 'paulej(a)PACKETIZER.COM' <mailto:'paulej(a)PACKETIZER.COM'> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> Sent: Wednesday, September 10, 2003 3:23 AM Subject: RE: H.323 Fast Connect and Versioning Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

Re: H.323 Fast Connect and Versioning
by paulej＠PACKETIZER.COM 10 Sep '03

10 Sep '03

Tamura-san, > Are multiple announcements supporting a version possible? > i.e., two OLCs, one is for version 1 and the other for version 2? > Or, is it necessary? Yes, it is possible. The problem is that a version 0 device would accept either a version 0,1,2,3, or other version proposal, not knowing that the ASN.1 is not compatible. Further, it would return in the OLC in fastStart "version 2", for example, but not really be v2 compatible. Thus, even if we allow multiple proposals, it will not work properly with the currently deployed gear. I think we need something new for v2 or higher devices (different capability, for instance). > T.38 already havs 0, 1 and 2 version. According to the results of May meeting, > Does the future version have to support all versions? > Or, am I wrong? Yes, I think that future releases have to support all versions. > The syntax (1998 and 2002) is within T.38, not H.245. > If the syntax used is decided before sending T.38 packets, > I do not think there are issues. If this is the issue, > we need to clarify it. The problem is related to Fast Connect. When a new device send a fastStart element containing a T.38 with "version 2" specified, for example, the older device might accept that and return the fastStart element with "version 2" inside. The older T.38 device would not change the version number, because it was not permitted to do so. When the calling terminal receives the reply, it may immediately send 2002 syntax, which would fail to decode at the called end. That's the problem. We have to do something to alert the newer device that the older device is really not V2. Paul > Also, CNG and CED do not use Data-Field in T.38, in which 1998 syntax and > 2002 syntax are different. > > Regards, > -- > Hiroshi Tamura > > > From: "Paul E. Jones" <paulej(a)packetizer.com> > Subject: Re: H.323 Fast Connect and Versioning > Date: Wed, 10 Sep 2003 18:35:09 -0400 > > > Peter, > > > > I've only seen this problem with fax. To answer your last question, > > I've only seen T.38 use this kind of version tag. However, V.150.1 also > > has versioning information as part of the object identifier that > > identifies the capability. This will be interesting to see if we > > introduce the same kind of problem there. In general, it's just not > > good to advertise the version through an OLC... it's better to perform a > > full caps exchange. The trouble is that modem and (to some extent) fax > > timings are such that we must open channels ASAP... before a caps > > exchange. (Actually, we could transmit the termcap set in the Setup > > message, but few devices support that.) > > > > We have had non-compatible payload specifications before and we resolved > > that by adding new code points. However, we've been trying to avoid > > that. Even so, we could do it again... it's just less desirable. > > > > I had another idea. What we could do is, within the t38faxProtocol > > SEQUENCE, we could indicate which syntax is to be used. Older devices > > would not see this field and would not decode it. So, when the reply is > > re-encoded, it would not be present. So, even if the version was set to > > "2", the "Syntax2002" field, say, would not be present. This would mean > > that the 1998 syntax has to be used. A newer endpoint would see the > > field and would properly re-encode it in the reply. This is a bit of a > > kludge and works only because of the way the ASN.1 encoding/decoding > > works with every device I've seen. > > > > Another solution to the problem might be to require that endpoint use > > H.245 tunneling and to advertise their capabilities in the Setup > > message. That could allow us to avoid this problem entirely. I'm just > > not sure how excited people would be to be forced to use H.245 tunneling > > every time they use fax, modem, or text relay. > > > > Paul > > > > > > ----- Original Message ----- > > From: Peter <mailto:PeterP@vegastream.com> Price > > To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; > > itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; > > tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> > > Sent: Wednesday, September 10, 2003 12:34 PM > > Subject: RE: H.323 Fast Connect and Versioning > > > > > > Paul, > > > > I wrote the first part of this email and then reread yours - I was > > bogged down in the fax issue but I think you are actually raising a > > wider issue aren't you? See part 2 below. > > > > -------------------------- Part 1 > > I don't believe that 5 versions of T38 would result in 5 offered > > channels. > > > > > > The need for the different capability is due to the fact that what you > > are offering is a payload that is encoded in a different and > > incompatible way. ie its a bit like offering G.729 and the sending > > packets encoded according to G.723.1, they both represent speech but > > they are not going to be played out properly. The single extra bit > > introduced into the T.38 payload packet by the 2002 ASN.1 is backwards > > incompatible. > > > > The problem only exists for endpoints that only know about the 1998 > > ASN.1 and are unaware of the incompatibility - it is important that they > > do not think they can accept the offered channel. > > > > Once an endpoint is aware of the problem (ie it knows about the 2002 > > ASN.1) then it can handle versions >= V2 (as well as V0 and V1). Of > > course, this does assume that a similar incompatibilty does not creep > > into the payload ASN.1 in future versions - but that's down to careful > > work in the standard development and editing stage. > > > > I still think adding t38faxV2 (say) to DataApplicationCapability and > > DataApplicationMode is the simplest solution > > [ t38faxV2 would use the same definitions for t38FaxProtocol and > > t38FaxProfile - its only the payload that has changed ]. This protects > > the existing T.38 implementations and avoids the need to break the rule > > about modifying Fast Connect proposals. > > > > The change in the T.38 payload ASN.1 breaks the fundamental backwards > > compatibility that ASN.1 is supposed to guarantee and thus whatever the > > final solution there has to be an element of a hack involved - I think > > that this change would isolate the change and protect the rest of the > > standard. > > > > > > -------------------------- Part 2 > > > > The versioning issue applies to any form of payload, > > voice/video/fax/whatever. > > > > The problem is still going to exist in early versions of endpoints that > > don't understand the consequence of accepting versions that they do not > > understand fully. If a new version of a codec's payload is not > > backwards compatible then I would assert that it is a new codec and must > > be signalled as a different capability. > > > > The issue of multiple variations already exists anyway although not (to > > my knowledge) with version numbers. > > Endpoints already offer multiple packet sizes for exactly the reason > > that you are not supposed to alter the Fast Connect proposal. What > > happens when somebody starts to offer g729Extensions and has to offer > > all the combinations of Annexes because they don't know what the other > > end can use ( I make that 64 proposals in each direction without adding > > further annexes! )? > > > > > > I don't see that relaxing the rule about modifying the version in a Fast > > Connect channel will help resolve the problem of having to offer > > multiple proposals. You either have to allow *anything* to be modified > > or stick to the current rule. Exceptions allowing certain fields to be > > modified just makes life much more difficult and confusing. > > > > > > T.38 is the only codec I am aware of that actually uses a version number > > in this manner. Are there any others? Why was it introduced in T.38? > > Perhaps this is a lesson for the future about the value of introducing > > of such a field in other codecs. > > > > Peter > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: 10 September 2003 16:01 > > To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int > > Subject: Re: H.323 Fast Connect and Versioning > > > > > > Peter, > > > > I think you're on the right track. We could avoid ASN.1 changes by > > introducing the new capability as a generic data capability, but a new > > capability is required here, I think. > > > > The problem, as I see it, is that when we use Fast Connect, we can't > > alert the calling side as to what version the called side actually > > supports. This suggests that if we have 5 versions of T.38, the calling > > side would have to propose a channel for each version independently. > > That's horrible. It's only complicated further by the fact that T.38 > > may not be signaled by itself-- it might be part of audio proposals that > > also include modem, text over IP, VBD, or other media. It might even be > > that there are several versions of the modem (V.150.1) protocol > > advertised. > > > > I think the only real solution to this problem is to allow the Fast > > Connect proposals to be altered by the called endpoint such that they > > can change the version number.. and nothing else. H.323 has an explicit > > statement that says that the proposals can't be modified before > > returning them, but perhaps this simple exception might resolve these > > issues. I think without such, it's going to be terrible complicated. > > > > Paul > > > > > > ----- Original Message ----- > > From: Peter <mailto:PeterP@vegastream.com> Price > > To: 'paulej(a)PACKETIZER.COM' <mailto:'paulej(a)PACKETIZER.COM'> ; > > itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> > > Sent: Wednesday, September 10, 2003 3:23 AM > > Subject: RE: H.323 Fast Connect and Versioning > > > > Paul wrote > > > > "Perhaps we can require the calling device to not transmit any data > > until it receives at least one IFP packet from the called side and > > determines the ASN.1 version used to encode the message." > > > > Unfortunately this won't work - although typically the called endpoint > > will provide the first IFP (Probably a CED) this doesn't work when you > > poll for a fax - in that case the calling endpoint will probably want to > > send the first IFP. > > > > The only way I can see out of this is to add a new data application > > (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. > > t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - > > and future carefully checked modifications ;-). Now there's no problem, > > a 2002 aware endpoint can offer both versions and a 1998 aware endpoint > > can only accept the ASN.1 it understands. > > > > > > Pete Price > > Vegastream Limited > > > > > > -----Original Message----- > > From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] > > Sent: 09 September 2003 20:32 > > To: itu-sg16(a)external.cisco.com > > Subject: H.323 Fast Connect and Versioning > > > > > > Folks, > > > > Today, I was exchanging e-mail with somebody over the fax version number > > issue and the different syntax that is used (1998 vs 2002). > > > > If we open H.245 and exchange a full set of capabilities, and H.323 > > endpoint could determine the version supported by the other side and > > open a channel supporting that particular version. However, I don't > > think any text is explicitly clear on that. > > > > Another scenario-- and one I have more trouble with-- is Fast Connect. > > If a calling endpoint populates the fastStart element with "version 2" > > proposals, for example, the called side (say, a version 0 device) might > > accept the proposal and return the response. However, it is not allowed > > to modify the version field. The reason is that Fast Connect proposals > > are not ordered in a way such that replies must be ordered the same way. > > Rather, the calling device determines which proposals are accepted based > > on characteristics of the proposals returned (e.g., codec type, samples > > per packet, or other information). In some cases, a calling endpoint > > will actually not try to "match" the proposal returned, but just accept > > it as a proposal and run with it. > > > > The problem is that if a calling device proposes version 2 and the > > called device returns version 2 (but is actually a v0 device), then the > > wrong syntax will be transmitted on the wire. Thus, the text needs to > > state somewhere one of these options (or something similar): > > > > 1. The calling device must offer a proposal for each version it > > wants to potentially use and the called device must accept the first > > proposal it can accept (in order of the proposals) and the called device > > must not accept any proposal for a version it does not support > > > > 2. The calling device must wait for capability exchange to complete > > to determine the actual supported version of the other device > > > > Alternatively, we could make an allowance for the endpoint to change the > > version number in the Fast Connect proposal, but I don't think that's a > > good idea, as it would quite possibly break interoperability with some > > devices. > > > > What would a version 0 device do today if it received a Fast Connect > > proposal advertising version 2? Would it accept it? I suspect so and > > I'm afraid that we might have some interop problems regardless of the > > direction we go. > > > > Perhaps we can require the calling device to not transmit any data until > > it receives at least one IFP packet from the called side and determines > > the ASN.1 version used to encode the message. As much as we can push > > onto the shoulders of a v2 device, the better, as I don't think we have > > any real deployments in the field (yet)... might be wrong, but I think > > it would be a far less significant impact on that side. > > > > I'm open to suggestions. Perhaps this issue is even addressed and I've > > simply overlooked it. > > > > Thanks, > > Paul > > > > > > >

1 0

Re: H.323 Fast Connect and Versioning
by paulej＠PACKETIZER.COM 10 Sep '03

10 Sep '03

Peter, I've only seen this problem with fax. To answer your last question, I've only seen T.38 use this kind of version tag. However, V.150.1 also has versioning information as part of the object identifier that identifies the capability. This will be interesting to see if we introduce the same kind of problem there. In general, it's just not good to advertise the version through an OLC... it's better to perform a full caps exchange. The trouble is that modem and (to some extent) fax timings are such that we must open channels ASAP... before a caps exchange. (Actually, we could transmit the termcap set in the Setup message, but few devices support that.) We have had non-compatible payload specifications before and we resolved that by adding new code points. However, we've been trying to avoid that. Even so, we could do it again... it's just less desirable. I had another idea. What we could do is, within the t38faxProtocol SEQUENCE, we could indicate which syntax is to be used. Older devices would not see this field and would not decode it. So, when the reply is re-encoded, it would not be present. So, even if the version was set to "2", the "Syntax2002" field, say, would not be present. This would mean that the 1998 syntax has to be used. A newer endpoint would see the field and would properly re-encode it in the reply. This is a bit of a kludge and works only because of the way the ASN.1 encoding/decoding works with every device I've seen. Another solution to the problem might be to require that endpoint use H.245 tunneling and to advertise their capabilities in the Setup message. That could allow us to avoid this problem entirely. I'm just not sure how excited people would be to be forced to use H.245 tunneling every time they use fax, modem, or text relay. Paul ----- Original Message ----- From: Peter Price To: 'Paul E. Jones' ; itu-sg16(a)external.cisco.com ; tsg16q14(a)itu.int Sent: Wednesday, September 10, 2003 12:34 PM Subject: RE: H.323 Fast Connect and Versioning Paul, I wrote the first part of this email and then reread yours - I was bogged down in the fax issue but I think you are actually raising a wider issue aren't you? See part 2 below. -------------------------- Part 1 I don't believe that 5 versions of T38 would result in 5 offered channels. The need for the different capability is due to the fact that what you are offering is a payload that is encoded in a different and incompatible way. ie its a bit like offering G.729 and the sending packets encoded according to G.723.1, they both represent speech but they are not going to be played out properly. The single extra bit introduced into the T.38 payload packet by the 2002 ASN.1 is backwards incompatible. The problem only exists for endpoints that only know about the 1998 ASN.1 and are unaware of the incompatibility - it is important that they do not think they can accept the offered channel. Once an endpoint is aware of the problem (ie it knows about the 2002 ASN.1) then it can handle versions >= V2 (as well as V0 and V1). Of course, this does assume that a similar incompatibilty does not creep into the payload ASN.1 in future versions - but that's down to careful work in the standard development and editing stage. I still think adding t38faxV2 (say) to DataApplicationCapability and DataApplicationMode is the simplest solution [ t38faxV2 would use the same definitions for t38FaxProtocol and t38FaxProfile - its only the payload that has changed ]. This protects the existing T.38 implementations and avoids the need to break the rule about modifying Fast Connect proposals. The change in the T.38 payload ASN.1 breaks the fundamental backwards compatibility that ASN.1 is supposed to guarantee and thus whatever the final solution there has to be an element of a hack involved - I think that this change would isolate the change and protect the rest of the standard. -------------------------- Part 2 The versioning issue applies to any form of payload, voice/video/fax/whatever. The problem is still going to exist in early versions of endpoints that don't understand the consequence of accepting versions that they do not understand fully. If a new version of a codec's payload is not backwards compatible then I would assert that it is a new codec and must be signalled as a different capability. The issue of multiple variations already exists anyway although not (to my knowledge) with version numbers. Endpoints already offer multiple packet sizes for exactly the reason that you are not supposed to alter the Fast Connect proposal. What happens when somebody starts to offer g729Extensions and has to offer all the combinations of Annexes because they don't know what the other end can use ( I make that 64 proposals in each direction without adding further annexes! )? I don't see that relaxing the rule about modifying the version in a Fast Connect channel will help resolve the problem of having to offer multiple proposals. You either have to allow *anything* to be modified or stick to the current rule. Exceptions allowing certain fields to be modified just makes life much more difficult and confusing. T.38 is the only codec I am aware of that actually uses a version number in this manner. Are there any others? Why was it introduced in T.38? Perhaps this is a lesson for the future about the value of introducing of such a field in other codecs. Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 16:01 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I think you're on the right track. We could avoid ASN.1 changes by introducing the new capability as a generic data capability, but a new capability is required here, I think. The problem, as I see it, is that when we use Fast Connect, we can't alert the calling side as to what version the called side actually supports. This suggests that if we have 5 versions of T.38, the calling side would have to propose a channel for each version independently. That's horrible. It's only complicated further by the fact that T.38 may not be signaled by itself-- it might be part of audio proposals that also include modem, text over IP, VBD, or other media. It might even be that there are several versions of the modem (V.150.1) protocol advertised. I think the only real solution to this problem is to allow the Fast Connect proposals to be altered by the called endpoint such that they can change the version number.. and nothing else. H.323 has an explicit statement that says that the proposals can't be modified before returning them, but perhaps this simple exception might resolve these issues. I think without such, it's going to be terrible complicated. Paul ----- Original Message ----- From: Peter Price To: 'paulej(a)PACKETIZER.COM' ; itu-sg16(a)external.cisco.com Sent: Wednesday, September 10, 2003 3:23 AM Subject: RE: H.323 Fast Connect and Versioning Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1.. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2.. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

RE: H.323 Fast Connect and Versioning
by PeterP＠VEGASTREAM.COM 10 Sep '03

10 Sep '03

Paul, I wrote the first part of this email and then reread yours - I was bogged down in the fax issue but I think you are actually raising a wider issue aren't you? See part 2 below. -------------------------- Part 1 I don't believe that 5 versions of T38 would result in 5 offered channels. The need for the different capability is due to the fact that what you are offering is a payload that is encoded in a different and incompatible way. ie its a bit like offering G.729 and the sending packets encoded according to G.723.1, they both represent speech but they are not going to be played out properly. The single extra bit introduced into the T.38 payload packet by the 2002 ASN.1 is backwards incompatible. The problem only exists for endpoints that only know about the 1998 ASN.1 and are unaware of the incompatibility - it is important that they do not think they can accept the offered channel. Once an endpoint is aware of the problem (ie it knows about the 2002 ASN.1) then it can handle versions >= V2 (as well as V0 and V1). Of course, this does assume that a similar incompatibilty does not creep into the payload ASN.1 in future versions - but that's down to careful work in the standard development and editing stage. I still think adding t38faxV2 (say) to DataApplicationCapability and DataApplicationMode is the simplest solution [ t38faxV2 would use the same definitions for t38FaxProtocol and t38FaxProfile - its only the payload that has changed ]. This protects the existing T.38 implementations and avoids the need to break the rule about modifying Fast Connect proposals. The change in the T.38 payload ASN.1 breaks the fundamental backwards compatibility that ASN.1 is supposed to guarantee and thus whatever the final solution there has to be an element of a hack involved - I think that this change would isolate the change and protect the rest of the standard. -------------------------- Part 2 The versioning issue applies to any form of payload, voice/video/fax/whatever. The problem is still going to exist in early versions of endpoints that don't understand the consequence of accepting versions that they do not understand fully. If a new version of a codec's payload is not backwards compatible then I would assert that it is a new codec and must be signalled as a different capability. The issue of multiple variations already exists anyway although not (to my knowledge) with version numbers. Endpoints already offer multiple packet sizes for exactly the reason that you are not supposed to alter the Fast Connect proposal. What happens when somebody starts to offer g729Extensions and has to offer all the combinations of Annexes because they don't know what the other end can use ( I make that 64 proposals in each direction without adding further annexes! )? I don't see that relaxing the rule about modifying the version in a Fast Connect channel will help resolve the problem of having to offer multiple proposals. You either have to allow *anything* to be modified or stick to the current rule. Exceptions allowing certain fields to be modified just makes life much more difficult and confusing. T.38 is the only codec I am aware of that actually uses a version number in this manner. Are there any others? Why was it introduced in T.38? Perhaps this is a lesson for the future about the value of introducing of such a field in other codecs. Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 16:01 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I think you're on the right track. We could avoid ASN.1 changes by introducing the new capability as a generic data capability, but a new capability is required here, I think. The problem, as I see it, is that when we use Fast Connect, we can't alert the calling side as to what version the called side actually supports. This suggests that if we have 5 versions of T.38, the calling side would have to propose a channel for each version independently. That's horrible. It's only complicated further by the fact that T.38 may not be signaled by itself-- it might be part of audio proposals that also include modem, text over IP, VBD, or other media. It might even be that there are several versions of the modem (V.150.1) protocol advertised. I think the only real solution to this problem is to allow the Fast Connect proposals to be altered by the called endpoint such that they can change the version number.. and nothing else. H.323 has an explicit statement that says that the proposals can't be modified before returning them, but perhaps this simple exception might resolve these issues. I think without such, it's going to be terrible complicated. Paul ----- Original Message ----- From: Peter <mailto:PeterP@vegastream.com> Price To: 'paulej(a)PACKETIZER.COM' <mailto:'paulej(a)PACKETIZER.COM'> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> Sent: Wednesday, September 10, 2003 3:23 AM Subject: RE: H.323 Fast Connect and Versioning Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

Re: H.323 Fast Connect and Versioning
by paulej＠PACKETIZER.COM 10 Sep '03

10 Sep '03

Peter, I think you're on the right track. We could avoid ASN.1 changes by introducing the new capability as a generic data capability, but a new capability is required here, I think. The problem, as I see it, is that when we use Fast Connect, we can't alert the calling side as to what version the called side actually supports. This suggests that if we have 5 versions of T.38, the calling side would have to propose a channel for each version independently. That's horrible. It's only complicated further by the fact that T.38 may not be signaled by itself-- it might be part of audio proposals that also include modem, text over IP, VBD, or other media. It might even be that there are several versions of the modem (V.150.1) protocol advertised. I think the only real solution to this problem is to allow the Fast Connect proposals to be altered by the called endpoint such that they can change the version number.. and nothing else. H.323 has an explicit statement that says that the proposals can't be modified before returning them, but perhaps this simple exception might resolve these issues. I think without such, it's going to be terrible complicated. Paul ----- Original Message ----- From: Peter Price To: 'paulej(a)PACKETIZER.COM' ; itu-sg16(a)external.cisco.com Sent: Wednesday, September 10, 2003 3:23 AM Subject: RE: H.323 Fast Connect and Versioning Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1.. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2.. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

RE: H.323 Fast Connect and Versioning
by PeterP＠VEGASTREAM.COM 10 Sep '03

10 Sep '03

Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

RE: H.323 Fast Connect and Versioning
by Peter Price 10 Sep '03

10 Sep '03

Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

H.323 Fast Connect and Versioning
by paulej＠PACKETIZER.COM 09 Sep '03

09 Sep '03

Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1.. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2.. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

Outcome of the Paris meeting
by okubo＠MXZ.MESH.NE.JP 08 Sep '03

08 Sep '03

Dear WP2/16 experts, The outcome of the Paris meeting last week is available at the following places: *** Q.D,F,G,2-5/16 *** http://avguest@ftp3.itu.int/av-arch/avc-site/0309_Par/ TD-10a.zip Q.D report TD-11.zip Q.F report TD-12a.zip Q.G report TD-13a.zip Q.2 report TD-14b.zip Q.3 report TD-15b.zip Q.4 report TD-38b.zip Question formation and SG13 liaisons These will be integrated into AVD-2410 later. This time Q.5 report is not issued. Please note that the document list is also there as: http://avguest@ftp3.itu.int/av-arch/avc-site/0309_Par/0309_Par.html *** Q.1/16 *** http://avguest@ftp3.itu.int/av-arch/lbc-site/0309_Paris/q1b16.doc Please note that the document list is also there as: http://avguest@ftp3.itu.int/av-arch/lbc-site/0309_Paris/q1b00r2.doc -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************** <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ********************************************************************

1 0

Liaison statements from SG13
by okubo＠MXZ.MESH.NE.JP 30 Aug '03

30 Aug '03

Dear WP2/16 experts, I have uploaded the following liaison statements with their attachments to avc-site/0309_Par. AVD-2402 All NGN 2004 ITU-T Project SG13 AVD-2403 All ITU-T IP Project SG13 AVD-2404 All ITU-T NGN 2004 Project SG13 AVD-2405 D, F, G, 1, 2, 3, 4, 5 Videoconferencing services networks SG13 AVD-2406 F Clarification of Y.qosar with H.qosarch SG13 AVD-2407 F,2,3 Communication of Y.MPLSperf SG13 AVD-2408 3, F Reference models and architectures on draft Y.1530 SG13 AVD-2409 All ICG-SAT activities SG13 -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************** <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ********************************************************************

1 0

RE: Documents for the Paris meeting
by kboyle＠NORTELNETWORKS.COM 28 Aug '03

28 Aug '03

I have re-uploaded AVD-2353 to the Incoming folder. Kevin -----Original Message----- From: okubo(a)MXZ.MESH.NE.JP [mailto:okubo@MXZ.MESH.NE.JP] Sent: Wednesday, August 27, 2003 10:01 PM To: itu-sg16(a)external.cisco.com Subject: Documents for the Paris meeting Dear Q.D,F,G,2-5/16 experts, I believe I have moved all the uploaded contributions to http://ftp3.itu.int/av-arch/avc-site/0309_Par/ but AVD-2347, 2348, 2353, 2393, 2398, 2400 are missing. Please (re-)upload your contribution to http://ftp3.itu.int/av-arch/avc-site/Incoming/ or send it to me. Apologies if I have mishandled your contribution. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan *******************************************************************

1 0

Documents for the Paris meeting
by okubo＠MXZ.MESH.NE.JP 27 Aug '03

27 Aug '03

Dear Q.D,F,G,2-5/16 experts, I believe I have moved all the uploaded contributions to http://ftp3.itu.int/av-arch/avc-site/0309_Par/ but AVD-2347, 2348, 2353, 2393, 2398, 2400 are missing. Please (re-)upload your contribution to http://ftp3.itu.int/av-arch/avc-site/Incoming/ or send it to me. Apologies if I have mishandled your contribution. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan *******************************************************************

1 0

Question revision
by okubo＠MXZ.MESH.NE.JP 27 Aug '03

27 Aug '03

Dear WP2/16 Rapporteurs and experts, We will address the subject topic at the next week Rapporteur meeting in Paris. Please be prepared for this discussion. Relevant documents have been uploaded to <http://ftp3.itu.int/av-arch/avc-site/0309_Par/>: Annex to AVD-2041 All Current text of Questions: Rapporteurs TD-17 All Request for consideration of NGN toward revising Questions SG16 Chairman TD-18 All Next Generation Network studies SG13 Chairman TD-19 All NGN 2004 Project description SG13 Chairman TD-20 All Question revision - excerpt from report of the SG16 meeting in May 2003 WP2/16 Chairman -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************** <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ********************************************************************

1 0

Test
by paulej＠PACKETIZER.COM 26 Aug '03

26 Aug '03

My apologies for the test message... but no other way to check on something. Paul

1 0

Re: Uploaded contributions to Incoming directory
by okubo＠MXZ.MESH.NE.JP 24 Aug '03

24 Aug '03

Dear Christian, At 11:56 +1000 03/08/25, Christian Groves wrote: >I have uploaded the following documents to the incoming directory of >the AVC site on the ITU server: >AVD-2386, 2387, 2388, 2389 and 2390 > >Could you please place them in the Paris directory? Done as requested. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************** <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ********************************************************************

1 0

List of contributions for the Paris meeting
by okubo＠MXZ.MESH.NE.JP 23 Aug '03

23 Aug '03

Dear Q.D,F,G,2-5/16 experts, This is the current list of registered contributions for the Paris meeting (2-5 September 2003). An Excel file is available at http://avguest@ftp3.itu.int/av-arch/avc-site/0309_Par/TD-02_030823.xls Please advise me if you intend to submit your contribution but it is not listed here. AVD- Question(s) Title Source AVD-2035a All Information and request for inputs Rapporteurs of Q.D,F,G,1-5/16 AVD-2346 2 H.460.mlpp Artel AVD-2347 2 Revised H.235 Annex H Avaya AVD-2348 2 A proposal for H.245 to provide SIP-compatible encryption key distribution Avaya AVD-2349 G H.235 Annex G - "Usage of the Secure Real Time Transport Protocol (SRTP) in conjunction with the MIKEY Key Management Protocol within H.235" Editor (M Euchner) AVD-2350 3 Updated Draft H.248 Implementors' Guide Editor (Kevin Boyle II) AVD-2351 3 Updated Draft H.248.1 Annex F Editor (Kevin Boyle II) AVD-2352 3 Considerations for discussion of update of ServiceChange procedures for H.248 Editor (Kevin Boyle II) AVD-2353 3 Updated Draft H.248.icas Editor (Kevin Boyle II) AVD-2354 3 Updated Draft H.248.icasc Editor (Kevin Boyle II) AVD-2355 2, F Updated Draft H.460.9 Annex B Editor (Kevin Boyle II) AVD-2356 3, F Proposed H.248 RTCPXR Package Nortel Networks USA AVD-2357 3 Proposed H.248.1 Version 1 Amendment Nortel Networks USA AVD-2358 3 Proposed H.248.1 Version 2 Amendment Nortel Networks USA AVD-2359 3 Proposed H.248.2 Amendment Nortel Networks USA AVD-2360 3 Proposed H.248.3 Amendment Nortel Networks USA AVD-2361 3 Proposed H.248.4 Amendment Nortel Networks USA AVD-2362 3 Proposed H.248.7 Amendment Nortel Networks USA AVD-2363 3 Proposed H.248.8 Amendment Nortel Networks USA AVD-2364 2 Call Party Category Cisco Systems AVD-2365 2 Proposed Corrections to Annex P/H.323 Cisco Systems AVD-2366 2, 3 Support for RFC 3389 - RTP Payload for Comfort Noise Cisco Systems AVD-2367 3 Proposed Enhance to the Flow Control and Logical Channel Rate Cisco Systems AVD-2368 2, 3 Consideration of the Maximum Bit Rate Signaled in H.323 Systems as it Relates to V.ToIP Work in Question 11 Cisco Systems AVD-2369 2 Draft New Recommendation H.460.Delayed Editor (P Jones) AVD-2370 All Process for development and approval of Amendments and Edition 2 of the Handbook on deployment of IMT-2000 SSG AVD-2371 3 Information regarding draft G.799.1 SG15 AVD-2372 3 A question regarding possibilities to transport call quality parameters via H.248 SG15 AVD-2373 2 Comments/proposal on release/reject reasons for draft H.460.mlpp Artel AVD-2374 4 H.350 Implementor’s Guide Editor (T Johnson) AVD-2375 4 H.350 Address Book Editor (T Johnson) AVD-2376 4 H.350 Call Preferences Editor (T Johnson) AVD-2377 4 Presence for H.350 Editor (T Johnson) AVD-2378 2 Comment/corrections to H.460-series Artel AVD-2379 2 Mapping of AccessRejection, LocationReject reason codes to AdmissionReject reason codes Cisco Systems AVD-2380 2 Draft H.460.suspend Editor (V Bhargava) AVD-2381 G, 2, 3 Draft H.323 Series IG Editor (V Bhargava) AVD-2382 3 H.248 - Issues related to ServiceChange Cisco Systems AVD-2383 3 Updated Draft H.248 AJB Editor (C Teising) AVD-2384 3 Proposed H.248 DCC Package Lucent Technologies AVD-2385 Glare Control Indicator Cisco Systems AVD-2386 3 Draft H.248.19 "Gateway Control Protocol: Decomposed Multipoint Control Unit, Audio, Video and Data Conferencing Packages" Editor (C Groves) AVD-2387 3 Proposed additions to the H.248.19 for Text Conferencing LM Ericsson AVD-2388 3 Proposed Ammendment to H.248.2 "Facsimile, Text Conversation and Call Discrimination packages" LM Ericsson AVD-2389 3 Proposed additions to the H.248 Series Implementors' Guide LM Ericsson AVD-2390 3 Draft H.248.spch Semi-Permanent Connection Handling Package Editor (C Groves) AVD-2391 2, 4 Motion picture presentation in H.323 videoconferencing Waseda University AVD-2392 2 Repository of Generic Parameters update Editor (E Horvath) AVD-2393 2 Updated draft H.460.tppr Editor (E Horvath) AVD-2394 2, 3 Contribution on payload packet rate Siemens AG AVD-2395 3 Further Aspects of H.248 ICAS Package Alcatel AVD-2396 2, 3 Two calling party numbers for H.323 France Telecom AVD-2397 2 Call-diversion override within H.323 systems TE-SYSTEMS GmbH AVD-2398 2 Continuing work on Telecommunications for Disaster Recovery (TDR) Delta Information Systems AVD-2399 2 Connection Hold Cisco Systems AVD-2400 2 Draft H.323 Annex I Editor (A Li) -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* <Yokosuka Research Park> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan *******************************************************************

1 0

Re: Document number request
by okubo＠MXZ.MESH.NE.JP 23 Aug '03

23 Aug '03

Dear Mr. Li, At 11:44 -0700 03/08/21, Adam Li wrote: >I am planning to submit a draft for the H.323 Annex I for the next >meeting. Could you please assigne a document number for it? I will not >be able to attend the meeting. But hopefully the document can be >reviewed there. AVD-2400 has been allocated to your draft. Thank you. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* <Yokosuka Research Park> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan *******************************************************************

1 0

Re: AVD number request for SG16 Paris meeting
by okubo＠MXZ.MESH.NE.JP 22 Aug '03

22 Aug '03

Dear Mr. Fourie, At 15:04 -0700 03/08/22, Louis Fourie wrote: > Please assign an AVD number for the contribution: > >Connection Hold Your contribution has been numbered AVD-2399. Thank you. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan *******************************************************************

1 0

RE: AVD No. Request for SG16 Paris
by okubo＠MXZ.MESH.NE.JP 22 Aug '03

22 Aug '03

Dear Gary, At 08:35 -0400 03/08/22, Gary Thom wrote: >Please assign a document number for: > >"Continuing work on Telecommunications for Disaster Recovery (TDR)" AVD-2398 has been allocated to your contribution. Thank you. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan *******************************************************************

1 0

Re: AVD No. Request for SG16 Paris
by okubo＠MXZ.MESH.NE.JP 22 Aug '03

22 Aug '03

Dear Mr. Pose and Mr. Erichsen, In response to your requests, the following document numbers have been allocated to your contributions. Thank you. At 08:34 +0200 03/08/22, POSE Laurent FTRD/DAC/ISS wrote: >France Telecom plans a contribution on "Two calling party numbers for H.323". ==> AVD-2396 At 09:05 +0200 03/08/22, Tobias Erichsen wrote: >after some discussion concerning a missing supplementary service >for the H.323 environment, we have decided to deliver a working- >document that could be released in the H.460.x group of recommen- >dations. Therefore I would like to request a document-number that >we can name this document... ==> AVD-2397 Please advise me of its title and source. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************** <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ********************************************************************

1 0

Re: AVD No. Request for SG16 Paris
by okubo＠MXZ.MESH.NE.JP 21 Aug '03

21 Aug '03

Dear Mr. Schwarz, At 15:56 +0200 03/08/21, Albrecht.Schwarz(a)alcatel.de wrote: >ALCATEL plans a contribution on "Further Aspects of H.248 ICAS Package". >Please issue a number. Thank you for your contribution. AVD-2395 has been allocated to it. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan *******************************************************************

1 0

Re: AVD numbers
by okubo＠mxz.mesh.ne.jp 21 Aug '03

21 Aug '03

Dear Mr. Horvath, At 12:32 +0200 03/08/21, Horvath Ernst wrote: >I would need 3 AVD numbers for the following documents: Thank you for your contributions. The following numbers have been allocated to them: AVD-2392 Repository of Generic Parameters update (for Q.2/16, source: editor) AVD-2393 Updated draft H.460.tppr (for Q.2/16, source: editor) AVD-2394 Contribution on payload packet rate (for Q.2/16 and 3/16; source: Siemens AG) -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************** <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ********************************************************************

1 0

Re: Uploaded documents
by okubo＠MXZ.MESH.NE.JP 19 Aug '03

19 Aug '03

Dear Paul, At 22:10 -0400 03/08/19, Paul E. Jones wrote: >I have uploaded (what I believe to be) a complete set of documents. Your contributions AVD-2365 to 2369 have been moved to the following place: http://avguest@ftp3.itu.int/av-arch/avc-site/0309_Par/ or ftp://avguest:Avguest@ftp3.itu.int/avc-site/0309_Par/ Please also note TD-02_030820.xls there is a current list of documents for the Paris meeting. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************** <YRP> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ********************************************************************

1 0