- sg16-avd - lists.packetizer.com

Outcome of the Paris meeting
by OKUBO Sakae 03 Oct '03

03 Oct '03

Dear SG16 experts, The following documents have been placed at the 0309_Par/ directory: http://avguest@ftp3.itu.int/av-arch/avc-site/0309_Par/AVD-2410.zip http://avguest@ftp3.itu.int/av-arch/avc-site/0309_Par/WP2_Question_formulat… http://avguest@ftp3.itu.int/av-arch/avc-site/0309_Par/WP2_comments_on_NGN20… http://avguest@ftp3.itu.int/av-arch/avc-site/0309_Par/SG16_comments_to_JRG-… The first document AVD-2410 is the integrated report of the Paris meeting of Questions D,F,G,2-5 including 3 dispatched liaison statements. The second document is a compilation of revised and new draft Questions for reporting to Chairman of SG16. The third document is also a compilation of comments on SG13's NGN2004 project description for reporting to Chairman of SG16 The fourth document is an input document from SG16 management to the JRG-NGN meeting held this week in Munich. This is reflecting the action from the Paris meeting as recorded in the third document. -- 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: [Megaco] Re: Event descriptor handling for static logic inter faces like CAS
by Kevin Boyle 02 Oct '03

02 Oct '03

Apparently, I misunderstood what you were looking for. Unless I hear any objections, I will add that function to ICAS for the next meeting. Of course, this does nothing for the BCAS spec -- I assume we will need the same change there? This will require an amendment to H.248.25... I don't think this kind of change will be acceptable as an IG change. Comments? Kevin -----Original Message----- From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] Sent: Thursday, October 02, 2003 10:09 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: Christian Groves; megaco(a)ietf.org; ITU-SG16(a)external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS Hello Kevin What you mean is a general behavior, but MGC can not control it. This does not solve the problem which I ment. To make it easy I take the example for 'al/on al/of': The MGC want to be notified for 'al/on' and 'al/of'. MGC assumes that the line is in state 'al/on'. With Events{al/on{strict='exact'},al/of{strict='state'},....} the MGC do not get a Notify for al/on, because it is not necessary. When MGC then knows with the next notify, that the line is off-hook, it send perhaps a new EventsDescriptor containing the DigitMap, but now with Events{al/on{strict='state'},al/of{strict='exact'},....} This avoids again not needed Notify's. Same applies for CAS, where you have more states. With this mechanism you can update the EventsDescriptor for other things bind to this termination like R2 register signalling without again a not needed Notify AND in addition all static events are detected, not only the good case next step. Regards Thomas > Kevin Boyle wrote: > > Thomas, > > The function you want already exists in the package. Each one of the > line signalling events in both ICAS and BCAS have descriptions that > contain the following: > > The event is reported by the MG if either the timed transition to this > line signal is detected or the line signal already exists. > > This means that the strict=state behavior is already inherent in these > events. I see no problem with this, and no need for a change to these > packages. > > Kevin > > -----Original Message----- > From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] > Sent: Thursday, October 02, 2003 4:00 AM > To: Christian Groves > Cc: megaco(a)ietf.org; ITU-SG16(a)external.cisco.com > Subject: Re: [Megaco] Re: Event descriptor handling for static logic > interfaces like CAS > > Hello Christian > > I want both, > - strict parameter for CAS Line signals and in future for all > 'static'signalling interfaces. > - optionally a default strict="state" to shorten the Events Descriptor > > In my opinion, this should be used for all 'static' signalling > interfaces. With 'static' I mean that this interface has always a > state, when MG receives an EventsDescriptor from MGC. For > synchronizing the states from MGC with MG the strict mechanism is very > useful. Doing the same with EventBuffer, Embedded Descriptor > > is much more complex and increases extreme with the number of possible > states on the interface. > > Note: This 'strict' parameter is just used by MG to determine, whether a Notify > for the existing state on the interface has to be sent or not. > Further on normal event handling applies. > This approach has the advantage, that EventBuffer and Embedded can still be used > in addition. > > For all 'dynamic' events like pulses, DTMF, SPCM, normal event > handling applies. > > Best regards > > Thomas > > Christian Groves wrote: > > > > Hello Thomas, > > > > Are you wanting a general purpose mechanism such as the off-hook one > > or do you just want the default stated for H.248.26 and H.246.ICASC? > > > > Kevin Boyle is the editor of these he may have some opinion on this. > > > > Its always possible to make amendments to existing recommendations. > > Bring in a contribution for consideration to SG16 or propose a > > detailed solution on the Megaco list for experts to review. If they > > are agreeable then the change will be added. > > > > Regards, Christian > > > > Thomas Voith wrote: > > > > > Dear list-members, > > > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > > > All interfaces, which have static states, should implement such a > > > mechanism. > > > > > > The problem is that the EventsDescriptor EventBufferDescriptor or > > > an embedded EventsDescriptor may discard events, if the newly > > > received or replacing Event Descriptor does not match the event. > > > > > > In the Megaco Secnarios, always just the good case is shown. > > > > > > e.g. a static interface with 4 logical incoming events ( > > > S1,S2,S3,S4) would then set the EventsDescripror like: > > > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, > > > when state of interface is still i1. > > > > > > Events { > > > S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict > > > =" > > > state"} } > > > > > > ( Note: in case "state" is the default, then EventsDescriptor > > > could be shorter) > > > > > > The events descriptor remains active, after Notification is sent. > > > The strict parameter avoids unnecessary Notifications for the > > > already by MGC known state. > > > > > > This mechanism would be very simple and avoids lost of any events, > > > which is strong required for signalling interfaces on MG > > > transferred via H.248 to an MGC. > > > > > > > > > For a better illustration I have attached a Excel-File containing > > > a simple scenario. > > > > > > So my question/proposal is: > > > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > > strict feature? > > > - If not, can I get this functionality otherwise ? > > > > > > Kind regards > > > > > > Thomas Voith > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco(a)ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > -- _______________________________________________________________ > _ > V | Thomas Voith > +---------------+ | Dept. VS/EAC2 [Systems] > | A L C A T E L | | FL/2/50 > +---------------+ | > | Tel: +49 711 821-40293 > | Alcanet: 259-40293 > Alcatel SEL AG | Fax: +49 711 821-40211 > Fixed Networks Division | > Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de > D-70435 Stuttgart, Germany | > _______________________________________________________________ > > _______________________________________________ > Megaco mailing list > Megaco(a)ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco(a)ietf.org https://www1.ietf.org/mailman/listinfo/megaco

1 0

Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS
by Thomas Voith 02 Oct '03

02 Oct '03

Hello Kevin What you mean is a general behavior, but MGC can not control it. This does not solve the problem which I ment. To make it easy I take the example for 'al/on al/of': The MGC want to be notified for 'al/on' and 'al/of'. MGC assumes that the line is in state 'al/on'. With Events{al/on{strict='exact'},al/of{strict='state'},....} the MGC do not get a Notify for al/on, because it is not necessary. When MGC then knows with the next notify, that the line is off-hook, it send perhaps a new EventsDescriptor containing the DigitMap, but now with Events{al/on{strict='state'},al/of{strict='exact'},....} This avoids again not needed Notify's. Same applies for CAS, where you have more states. With this mechanism you can update the EventsDescriptor for other things bind to this termination like R2 register signalling without again a not needed Notify AND in addition all static events are detected, not only the good case next step. Regards Thomas > Kevin Boyle wrote: > > Thomas, > > The function you want already exists in the package. Each one of the line signalling events in both ICAS and BCAS have descriptions that contain the following: > > The event is reported by the MG if either the timed transition to this line signal is detected or the line signal already exists. > > This means that the strict=state behavior is already inherent in these events. I see no problem with this, and no need for a change to these packages. > > Kevin > > -----Original Message----- > From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] > Sent: Thursday, October 02, 2003 4:00 AM > To: Christian Groves > Cc: megaco(a)ietf.org; ITU-SG16(a)external.cisco.com > Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS > > Hello Christian > > I want both, > - strict parameter for CAS Line signals and in future for all 'static'signalling interfaces. > - optionally a default strict="state" to shorten the Events Descriptor > > In my opinion, this should be used for all 'static' signalling interfaces. With 'static' I mean that this interface has always a state, when MG receives an EventsDescriptor from MGC. For > synchronizing the states from MGC with MG the strict mechanism is very useful. Doing the same with EventBuffer, Embedded Descriptor > > is much more complex and increases extreme with the number of possible states on the interface. > > Note: This 'strict' parameter is just used by MG to determine, whether a Notify > for the existing state on the interface has to be sent or not. > Further on normal event handling applies. > This approach has the advantage, that EventBuffer and Embedded can still be used > in addition. > > For all 'dynamic' events like pulses, DTMF, SPCM, normal event handling applies. > > Best regards > > Thomas > > Christian Groves wrote: > > > > Hello Thomas, > > > > Are you wanting a general purpose mechanism such as the off-hook one > > or do you just want the default stated for H.248.26 and H.246.ICASC? > > > > Kevin Boyle is the editor of these he may have some opinion on this. > > > > Its always possible to make amendments to existing recommendations. > > Bring in a contribution for consideration to SG16 or propose a > > detailed solution on the Megaco list for experts to review. If they > > are agreeable then the change will be added. > > > > Regards, Christian > > > > Thomas Voith wrote: > > > > > Dear list-members, > > > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > > > All interfaces, which have static states, should implement such a > > > mechanism. > > > > > > The problem is that the EventsDescriptor EventBufferDescriptor or an > > > embedded EventsDescriptor may discard events, if the newly received > > > or replacing Event Descriptor does not match the event. > > > > > > In the Megaco Secnarios, always just the good case is shown. > > > > > > e.g. a static interface with 4 logical incoming events ( > > > S1,S2,S3,S4) would then set the EventsDescripror like: > > > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > > > state of interface is still i1. > > > > > > Events { > > > S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict=" > > > state"} } > > > > > > ( Note: in case "state" is the default, then EventsDescriptor could > > > be shorter) > > > > > > The events descriptor remains active, after Notification is sent. > > > The strict parameter avoids unnecessary Notifications for the > > > already by MGC known state. > > > > > > This mechanism would be very simple and avoids lost of any events, > > > which is strong required for signalling interfaces on MG transferred > > > via H.248 to an MGC. > > > > > > > > > For a better illustration I have attached a Excel-File containing a > > > simple scenario. > > > > > > So my question/proposal is: > > > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > > strict feature? > > > - If not, can I get this functionality otherwise ? > > > > > > Kind regards > > > > > > Thomas Voith > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco(a)ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > -- > _______________________________________________________________ > _ > V | Thomas Voith > +---------------+ | Dept. VS/EAC2 [Systems] > | A L C A T E L | | FL/2/50 > +---------------+ | > | Tel: +49 711 821-40293 > | Alcanet: 259-40293 > Alcatel SEL AG | Fax: +49 711 821-40211 > Fixed Networks Division | > Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de > D-70435 Stuttgart, Germany | > _______________________________________________________________ > > _______________________________________________ > Megaco mailing list > Megaco(a)ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco(a)ietf.org https://www1.ietf.org/mailman/listinfo/megaco

1 0

RE: [Megaco] Re: Event descriptor handling for static logic inter
by Kevin Boyle 02 Oct '03

02 Oct '03

Thomas, The function you want already exists in the package. Each one of the line signalling events in both ICAS and BCAS have descriptions that contain the following: The event is reported by the MG if either the timed transition to this line signal is detected or the line signal already exists. This means that the strict=state behavior is already inherent in these events. I see no problem with this, and no need for a change to these packages. Kevin -----Original Message----- From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] Sent: Thursday, October 02, 2003 4:00 AM To: Christian Groves Cc: megaco(a)ietf.org; ITU-SG16(a)external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS Hello Christian I want both, - strict parameter for CAS Line signals and in future for all 'static'signalling interfaces. - optionally a default strict="state" to shorten the Events Descriptor In my opinion, this should be used for all 'static' signalling interfaces. With 'static' I mean that this interface has always a state, when MG receives an EventsDescriptor from MGC. For synchronizing the states from MGC with MG the strict mechanism is very useful. Doing the same with EventBuffer, Embedded Descriptor is much more complex and increases extreme with the number of possible states on the interface. Note: This 'strict' parameter is just used by MG to determine, whether a Notify for the existing state on the interface has to be sent or not. Further on normal event handling applies. This approach has the advantage, that EventBuffer and Embedded can still be used in addition. For all 'dynamic' events like pulses, DTMF, SPCM, normal event handling applies. Best regards Thomas Christian Groves wrote: > > Hello Thomas, > > Are you wanting a general purpose mechanism such as the off-hook one > or do you just want the default stated for H.248.26 and H.246.ICASC? > > Kevin Boyle is the editor of these he may have some opinion on this. > > Its always possible to make amendments to existing recommendations. > Bring in a contribution for consideration to SG16 or propose a > detailed solution on the Megaco list for experts to review. If they > are agreeable then the change will be added. > > Regards, Christian > > Thomas Voith wrote: > > > Dear list-members, > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > All interfaces, which have static states, should implement such a > > mechanism. > > > > The problem is that the EventsDescriptor EventBufferDescriptor or an > > embedded EventsDescriptor may discard events, if the newly received > > or replacing Event Descriptor does not match the event. > > > > In the Megaco Secnarios, always just the good case is shown. > > > > e.g. a static interface with 4 logical incoming events ( > > S1,S2,S3,S4) would then set the EventsDescripror like: > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > > state of interface is still i1. > > > > Events { > > S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict=" > > state"} } > > > > ( Note: in case "state" is the default, then EventsDescriptor could > > be shorter) > > > > The events descriptor remains active, after Notification is sent. > > The strict parameter avoids unnecessary Notifications for the > > already by MGC known state. > > > > This mechanism would be very simple and avoids lost of any events, > > which is strong required for signalling interfaces on MG transferred > > via H.248 to an MGC. > > > > > > For a better illustration I have attached a Excel-File containing a > > simple scenario. > > > > So my question/proposal is: > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > strict feature? > > - If not, can I get this functionality otherwise ? > > > > Kind regards > > > > Thomas Voith > > > > _______________________________________________ > Megaco mailing list > Megaco(a)ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco(a)ietf.org https://www1.ietf.org/mailman/listinfo/megaco

1 0

Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS
by Thomas Voith 02 Oct '03

02 Oct '03

Hello Christian I want both, - strict parameter for CAS Line signals and in future for all 'static'signalling interfaces. - optionally a default strict="state" to shorten the Events Descriptor In my opinion, this should be used for all 'static' signalling interfaces. With 'static' I mean that this interface has always a state, when MG receives an EventsDescriptor from MGC. For synchronizing the states from MGC with MG the strict mechanism is very useful. Doing the same with EventBuffer, Embedded Descriptor is much more complex and increases extreme with the number of possible states on the interface. Note: This 'strict' parameter is just used by MG to determine, whether a Notify for the existing state on the interface has to be sent or not. Further on normal event handling applies. This approach has the advantage, that EventBuffer and Embedded can still be used in addition. For all 'dynamic' events like pulses, DTMF, SPCM, normal event handling applies. Best regards Thomas Christian Groves wrote: > > Hello Thomas, > > Are you wanting a general purpose mechanism such as the off-hook one or do you > just want the default stated for H.248.26 and H.246.ICASC? > > Kevin Boyle is the editor of these he may have some opinion on this. > > Its always possible to make amendments to existing recommendations. Bring in a > contribution for consideration to SG16 or propose a detailed solution on the > Megaco list for experts to review. If they are agreeable then the change will be > added. > > Regards, Christian > > Thomas Voith wrote: > > > Dear list-members, > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > All interfaces, which have static states, should implement such > > a mechanism. > > > > The problem is that the EventsDescriptor EventBufferDescriptor or an > > embedded EventsDescriptor may discard events, if the newly received or > > replacing Event Descriptor does not match the event. > > > > In the Megaco Secnarios, always just the good case is shown. > > > > e.g. a static interface with 4 logical incoming events ( S1,S2,S3,S4) > > would then set the EventsDescripror like: > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > > state of interface is still i1. > > > > Events { S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict="state"} } > > > > ( Note: in case "state" is the default, then EventsDescriptor could be shorter) > > > > The events descriptor remains active, after Notification is sent. > > The strict parameter avoids unnecessary Notifications for the already by MGC known state. > > > > This mechanism would be very simple and avoids lost of any events, which is strong > > required for signalling interfaces on MG transferred via H.248 to an MGC. > > > > > > For a better illustration I have attached a Excel-File containing a simple scenario. > > > > So my question/proposal is: > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > strict feature? > > - If not, can I get this functionality otherwise ? > > > > Kind regards > > > > Thomas Voith > > > > _______________________________________________ > Megaco mailing list > Megaco(a)ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco(a)ietf.org https://www1.ietf.org/mailman/listinfo/megaco

1 0

Re: H.323 Fast Connect and Versioning
by Hiroshi Tamura 02 Oct '03

02 Oct '03

Paul, Thanks for your comment. One confirmation. > > Why are there issues in Fast Connect only? > > With regular H.245 capability exchange and the use of OLCs, both sides will > know the actual capabilities. Version 2 devices should then only send an > OLC with a version that it knows the remote side can accept. > The problem has to do with sending a Fast Connect proposal (channel > proposal) for T.38v2 (2002 syntax) to a version 0 device (1998) syntax and > that device accepting the proposal and, subsequently, sending 2002-encoded > IFP packets. The version 0 device cannot decode the IFP packets. I understand it. My question is, In Figure D.8 - D.11 in H.323 Annex D, does the same issue happen? I think so. > In short, there is a potential for sending the wrong ASN.1 PER encoded > messages. Yes. Regards, -- Hiroshi Tamura

1 0

FW: Event descriptor handling for static logic interfaces like CA
by simao.campos＠ITU.INT 01 Oct '03

01 Oct '03

On behalf of Mr Voith -----Original Message----- From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] Sent: 01 October 2003 13:52 To: megaco(a)ietf.org; tsg16q3(a)itu.int Subject: Event descriptor handling for static logic interfaces like CAS Dear list-members, H.248.26 and in H.248.ICAS I miss a feature, which has been used already for On-Hook, Off-Hook the 'strict' parameter. All interfaces, which have static states, should implement such a mechanism. The problem is that the EventsDescriptor EventBufferDescriptor or an embedded EventsDescriptor may discard events, if the newly received or replacing Event Descriptor does not match the event. In the Megaco Secnarios, always just the good case is shown. e.g. a static interface with 4 logical incoming events ( S1,S2,S3,S4) would then set the EventsDescripror like: MGC guess the MG is in state i1, no Notify will be sent by MG, when state of interface is still i1. Events { S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict="state"} } ( Note: in case "state" is the default, then EventsDescriptor could be shorter) The events descriptor remains active, after Notification is sent. The strict parameter avoids unnecessary Notifications for the already by MGC known state. This mechanism would be very simple and avoids lost of any events, which is strong required for signalling interfaces on MG transferred via H.248 to an MGC. For a better illustration I have attached a Excel-File containing a simple scenario. So my question/proposal is: - Is it possible to extend the existing static state interfacepackages like H.248.26 with this strict feature? - If not, can I get this functionality otherwise ? Kind regards Thomas Voith -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________

1 0

Test message
by Paul E. Jones 29 Sep '03

29 Sep '03

This is a test... please ignore.

1 0

Re: H.323 Fast Connect and Versioning
by Paul E. Jones 26 Sep '03

26 Sep '03

Tamura-san, > I thought it would happen from the conversion among us. > I do not understand well. One of my understanding is that the version 1 machine > is not aware of our syntax issue and it could accept any Setup and return > Connect irrespective of the version. Am I right? That is correct. That's the problem we are looking at. > Why are there issues in Fast Connect only? With regular H.245 capability exchange and the use of OLCs, both sides will know the actual capabilities. Version 2 devices should then only send an OLC with a version that it knows the remote side can accept. We potentially have this same problem with SIP and other SDP-based systems. They must change the version number in the "answer" to an "offer". > The 2002 ASN.1 syntax is for t30-data. > Before V.21 signal starts, i.e. during CNG and CED exchange, > I do not believe there are issues. > If we use Fast Connect and V.21 signals are exchanged during Fast Connect, > it would be a problem. Is this one of the problems? The problem has to do with sending a Fast Connect proposal (channel proposal) for T.38v2 (2002 syntax) to a version 0 device (1998) syntax and that device accepting the proposal and, subsequently, sending 2002-encoded IFP packets. The version 0 device cannot decode the IFP packets. In short, there is a potential for sending the wrong ASN.1 PER encoded messages. Paul

1 0

Re: H.323 Fast Connect and Versioning
by Hiroshi Tamura 26 Sep '03

26 Sep '03

Paul, Thanks for your comments. (The other mails and other parts of Paul's mail are cut and snipped.) > > If we introduce the new attribute "syntax2002" in t38faxprofile, > > how does it work? > > Of course, understand that we're just "talking out loud" at the moment. We > don't have a clear proposal for this. But, the idea is that new systems > would only accept a proposal for a version that it understands and that they > would include the "syntax2002" field in any proposals and replies. The > "syntax2002" field might just be a NULL type (no real meaning). Yes, I understand. > When encoding the outgoing Fast Connect proposals, the new device would > include the "syntax2002" field. New devices would properly decode the field > and re-encode it when replying. Seeing the field in the reply, the > originating device would know without a doubt that the called device > supports the proposed version. If, on the other hand, the called device is > an older device, when the proposal is decoded, the "syntax2002" field would > not be decoded... it would simply be thrown away by the ASN.1 PER decoder. > Thus, when composing a reply, the field would not be present. This would > indicate to the calling device that, in spite of the fact that the new > device replied with, say, "version=2", the version in use is really not > version 2. In that case, the calling device would use the 1998 syntax. Are you saying it is the old verion 2? If so, right. But, according to the results of May meeting, The "new" version 2 must use 2002 ASN.1 syntax. Anyway, there may be a problem in version 2. > > But, how about one between the version 3 implmentation > > and the version 1 implmentation? From your explanation, sometimes it works > > and sometimes it doesn't. Is it unavoidable? > > I do not understand your question. Can you elaborate? I thought it would happen from the conversion among us. I do not understand well. One of my understanding is that the version 1 machine is not aware of our syntax issue and it could accept any Setup and return Connect irrespective of the version. Am I right? > > One more question. > > If we have "syntax2002", is the new T.38 version, which is 4, necessary? > > No, this would be an addition to H.245. We may need to require a new > version of H.245, though. We should make an amendment to T.38 Annex B and > H.323 Annex D, as I mentioned. We should encourage devices to advertise > multiple T.38 version proposals in fastStart in the outgoing Setup to > increase the likelihood that the called device can accept at least one of > the proposed T.38 versions. OK. That's my misunderstanding. > > Maybe, there are somthing that I do not understand. > > Don't worry.. it's confusing :-) Are you confused about the problem or the > proposed solution to the problem? Maybe, both :-< Excuse me for a basic question. Why are there issues in Fast Connect only? The 2002 ASN.1 syntax is for t30-data. Before V.21 signal starts, i.e. during CNG and CED exchange, I do not believe there are issues. If we use Fast Connect and V.21 signals are exchanged during Fast Connect, it would be a problem. Is this one of the problems? > I suppose another thing I should say is that we could potentially introduce > H.460.6 (Extendeed Fast Connect) to help resolve this issue, as well. With > that, we would not necessarily have to make several proposals. Instead, > would could make a single proposal and the called side could make a > counter-proposal to "negotiate" the version that should be used. I am not > aware of any H.460.6 implementations, yet, though there are certainly a > number of cases wherein H.460.6 would be very useful. This is just one. I do not know H.460.6, either. If it can be compatibile with the current implementation, that's ok. But, the support of new recommendation is burden to implementers. Anyway, we need to do for January meeting. Regards, -- Hiroshi Tamura

1 0