Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa / data signals

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 28 Apr 2005 14:54:15 -0400

What is the timing between caller ID and the ringing signal in your
implementation?
 
Note that as currently defined, H.248 requires that the second signal in the
list start immediately upon completion of the first.  Last I checked, there
is a minimum 200 ms intersignal time between the FSK transmission and the
start of ringing.  Unless you have violated H.248, you cannot meet this
requirement using a SignalList.
 
Kevin

  _____  

From: Dal Chohan [mailto:[email-masked]] 
Sent: Thursday, April 28, 2005 12:23 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Wayne Cutler'
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa
/data signals

Comments in-line.

I don't understand why the use of a signal list containing an "andisp/data"
and a ringing signal would lead to timing issues for display associated with
ringing?

We have successfully implemented and demonstrated the "caller display"
service during and prior to "ringing" using the "andisp/data" mechanism on
our MG and MGC.

Regards,

Dal.

  _____  

From: Kevin Boyle [mailto:[email-masked]] 
Sent: 28 April 2005 15:53
To: Dal Chohan; 'Wayne Cutler'
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa
/data signals

Comments inline. [KJBII]

Kevin

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dal Chohan
Sent: Thursday, April 28, 2005 10:12 AM
To: 'Wayne Cutler'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa
/data signals

Hi Wayne,

>From reading the e-mails there appear to be two different approaches for
providing "On-Hook" display associated with ringing using the H.248 "andisp"
package. 

One approach assumes that the TAS signal is determined/provisioned within
the MGC (i.e. andisp/data) and the other approach that assumes the TAS
signal is determined/provisioned in the MG (i.e. andisp/dwa).
[KJBII] While there are two approaches to the transfer of the data using the
andisp package, they are not the approaches you describe.  One approach is
if the data transfer is associated with alerting (dwa) and the other is if
the data transfer is not associated with ringing (data).  The reason why the
TAS can be specified for andisp/data is that some features allow multiple
FSK transfers without the use of a new TAS for each FSK message.  The data
signal, therefore, allows the suppression of the TAS for those features.

[Dal] - The ability to use different TAS signals is also useful for
supporting the different range of services ranging from subscriber services
such as display services and for telemetry applications.

I can understand why a number of implementations have adopted the former
approach, because it provides a single and consistent mechanism for
delivering "On-hook" display "during ringing", "prior to ringing" and "not
associated with ringing". Moreover it means that a single signal
"andisp/data" can be used for delivering all variants of the "On-Hook" and
even the "Off-Hook" display service.
[KJBII] How many is "a number"?  The design intent of the package does not
contemplate the use of the data signal with alerting.  The timing involved
is too tight for the successful use of the data signal without the
incorporation of undocumented kludges to the protocol, such as assumption of
timing associated with SignalLists -- or worse, playtone. This is especially
true of offhook FSK delivery.

[Dal] From the e-mail exchange it looks like at least Alcatel, Marconi and
Fujitsu have implementations that use "andisp/data" for display services
associated with ringing. As stated earlier I don't understand what the
timing issues are - Which timers are you referring to?

If the latter method is used, then it means the two different signals must
be used. The signal "andisp/dwa" for "On-Hook" display associated with
ringing. The signal "andisp/data" for "On-Hook" display not associated with
ringing. Also the TAS signal for the "andisp/dwa" case is
determined/provisioned within the MG, while for the "andisp/data" case the
TAS is determined/provisioned within the MGC.  This does mean things are
modelled differently for the two cases and this does seem to be an odd
approach and incorrect from a service modeling and provisioning perspective.

[KJBII] This is, in fact, how the package was designed.  It is entirely
logical to break them up into two different signals.  You seem to be
ignoring the fact that the dwa signal carries a pattern parameter, which
allows the specification of alerting as part of the signal as well.  There
is no such parameter for andisp/data -- because there is no alerting pattern
to specify! I do not see how this is odd at all.  In fact, what I find odd
is the misinterpretation involved here.  The procedures section describes a
number of usecases in detail. 

[Dal] - The fact the "dwa" carries a pattern parameter is neither here or
there - the pattern parameter would be part of the ring signal which would
be contained in the Signal List. The fact that two different mechanisms are
used is "odd", because if for example you use a "ring pulse alert" signal
for display prior to ringing and a "ring pulse alert" signal not associated
with ringing, then why should this need to different signals. Especially
since the same set of analogue signals are generated by the MG over the
analogue interface for both these methods.

We can either try to mandate that "andisp/dwa" is used for "On-Hook" display
prior to and during ringing, but there appears to be a lot of benefits and
mileage in allowing "andisp/data" to be used for "On-Hook" display prior to
ringing, during ringing and not associated with ringing- especially since a
number of implementations have already adopted this approach. 

[KJBII] I believe the package should be used as it was designed --
andisp/dwa for data transfer associated with alerting, and andisp/data for
data transfer not associated with alerting. Use of data for alerting
scenarios will lead to timing issues and failures.

[Dal] - I don't understand what the timing issues are? With the andisp/data
the MG runs timers after the TAS and after the FSK signal - How is this
timing any different to the "display associated with ringing".

The bottom line is that you have cut your cloth using two different signals
"dwa" and "data" in the "andisp" package, but using just one signal has its
merits, does work successfully and is not illegal. 

 

Regards,

Dal.

 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wayne Cutler
Sent: 28 April 2005 10:06
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp package andthedwa
/data signals

Hi Kevin, 

ETSI FSK delivery is described in ETSI EN 300 659 which has a section (6.1)
called "Data Transmission Associated with Ringing" which is then further
split into 2 sub-sections, namely "Data Transmission during Ringing" (6.1.1)
and "Data Transmission Prior to Ringing" (6.1.2). 

Interestingly, the trasnmission that uses a TAS of RP is regarded as "prior
to ringing" since the timings are different to the splash of ringing that is
used 
for the "during ringing" scenario. 

Therefore, the andisp dwa & data signals align nicely with the ETSI split
and more than one company has interpreted the standard in this way and
progressed to implementation. I would  disagree with your assertion about
the procedures "clearly stating" this distinction. In fact, the cited UK
example is incorrect since there are two methods used in the UK, namely the
"BT method" which is prior to ringing (and uses a TAS or LR followed by
DT-AS) and the "Bellocore" method used by Cable Operators (that uses a TAS
of RP). 

I think it's a bit late to try and claim that the H248.23 words "during
alerting" means "associated with alerting" - especially given the wording of
the EN. 

Regards, 
Wayne 

"Kevin Boyle" <[email-masked]> 

27/04/2005 17:52 

        To:        Wayne Cutler <[email-masked]>,
[email-masked] 
        cc:        [email-masked], [email-masked],
[email-masked] 
        Subject:        RE: [Megaco] interpretation of H.248.23 andisp
package and thedwa        /data signals

Your interpretation is incorrect.  The dwa signal is designed to perform
data delivery associated with ANY alerting, whether prior to or during
ringing.  This is clearly stated in the procedures section of the document. 

Kevin 

-----Original Message----- 
From: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Wayne Cutler 
Sent: Tuesday, April 26, 2005 5:45 AM 
To: [email-masked] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: Re: [Megaco] interpretation of H.248.23 andisp package and
thedwa/data signals 

>Question 1: 

>The description of the display with alerting signal in H.248.23 has the 
following text: 

>"Sends the display information to the CPE. This signal indicates that 
>the 
data must be applied during alerting ? either power ringing, or call
waiting. >Therefore, this signal implies alerting, which will be
appropriately applied to the CPE by the gateway, based upon the on
hook/off-hook status of the >line." 

>The ETSI specification, EN 300 659-1, On-Hook Data Transmission, 
>defines 
the following data transmission methods: 
>1. prior to ringing (including TAS equal to Ringing Pulse-Alert 
>Singal), 2. during ringing (ie between the first and second ringing 
>pattern) 

>Which signals defined in the andisp package should be used to support 
>the 
two methods because it is not clear from the andisp package descrition for
dwa >signal can be applied for method 1? 

>Question 2: 

>Additionally it would be useful to find out what MG and MGC vendors 
>have 
implemented for methods 1 and 2. 

Hi Jan, 

For question 1, we'd read h248.23 as meaning that andisp/dwa should be used
for option 2 (during ringing) and andisp/data for option 1 (prior to
ringing). 

In terms of question 2, this is what the Marconi CA & MSAN has implemented. 

Regards, 
Wayne 

_______________________________________________ 
Megaco mailing list 
[email-masked] 
 <https://www1.ietf.org/mailman/listinfo/megaco>
https://www1.ietf.org/mailman/listinfo/megaco 

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Wayne Cutler" <[email-masked]>
Date: Fri, 29 Apr 2005 08:59:16 +0100

You can  include the 200mS of silence as part of the FSK "signal". H248 is 
not violated at all.

The Signal List works like a charm.

28/04/2005 19:54

        To:     Dal Chohan <[email-masked]>, "'Wayne Cutler'" 
<[email-masked]>
        cc:     [email-masked], [email-masked]
        Subject:        RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa / data 
signals

Note that as currently defined, H.248 requires that the second signal in 
the list start immediately upon completion of the first.  Last I checked, 
there is a minimum 200 ms intersignal time between the FSK transmission 
and the start of ringing.  Unless you have violated H.248, you cannot meet 
this requirement using a SignalList.
 
Kevin

Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa /data 
signals

Comments in-line.
 
I don't understand why the use of a signal list containing an 
"andisp/data" and a ringing signal would lead to timing issues for display 
associated with ringing?

Regards,

Dal.

Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa /data 
signals
 
Comments inline. [KJBII]
 
Kevin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dal Chohan
Sent: Thursday, April 28, 2005 10:12 AM
To: 'Wayne Cutler'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa /data 
signals
Hi Wayne,

>From reading the e-mails there appear to be two different approaches for 
providing "On-Hook" display associated with ringing using the H.248 
"andisp" package. 
 
One approach assumes that the TAS signal is determined/provisioned within 
the MGC (i.e. andisp/data) and the other approach that assumes the TAS 
signal is determined/provisioned in the MG (i.e. andisp/dwa).
[KJBII] While there are two approaches to the transfer of the data using the 
andisp package, they are not the approaches you describe.  One approach is 
if the data transfer is associated with alerting (dwa) and the other is if 
the data transfer is not associated with ringing (data).  The reason why 
the TAS can be specified for andisp/data is that some features allow 
multiple FSK transfers without the use of a new TAS for each FSK message. 
The data signal, therefore, allows the suppression of the TAS for those 
features.
 
[Dal] ? The ability to use different TAS signals is also useful for 
supporting the different range of services ranging from subscriber 
services such as display services and for telemetry applications.

I can understand why a number of implementations have adopted the former 
approach, because it provides a single and consistent mechanism for 
delivering "On-hook" display "during ringing", "prior to ringing" and "not 
associated with ringing". Moreover it means that a single signal 
"andisp/data" can be used for delivering all variants of the "On-Hook" and 
even the "Off-Hook" display service.
[KJBII] How many is "a number"?  The design intent of the package does not 
contemplate the use of the data signal with alerting.  The timing involved 
is too tight for the successful use of the data signal without the 
incorporation of undocumented kludges to the protocol, such as assumption 
of timing associated with SignalLists -- or worse, playtone. This is 
especially true of offhook FSK delivery.
 
[Dal] From the e-mail exchange it looks like at least Alcatel, Marconi and 
Fujitsu have implementations that use "andisp/data" for display services 
associated with ringing. As stated earlier I don't understand what the 
timing issues are ? Which timers are you referring to?
 
If the latter method is used, then it means the two different signals must 
be used. The signal "andisp/dwa" for "On-Hook" display associated with 
ringing. The signal "andisp/data" for "On-Hook" display not associated 
with ringing. Also the TAS signal for the "andisp/dwa" case is 
determined/provisioned within the MG, while for the "andisp/data" case the 
TAS is determined/provisioned within the MGC.  This does mean things are 
modelled differently for the two cases and this does seem to be an odd 
approach and incorrect from a service modeling and provisioning 
perspective.

[KJBII] This is, in fact, how the package was designed.  It is entirely logical 
to break them up into two different signals.  You seem to be ignoring the 
fact that the dwa signal carries a pattern parameter, which allows the 
specification of alerting as part of the signal as well.  There is no such 
parameter for andisp/data -- because there is no alerting pattern to 
specify! I do not see how this is odd at all.  In fact, what I find odd is 
the misinterpretation involved here.  The procedures section describes a 
number of usecases in detail. 
 
[Dal] ? The fact the "dwa" carries a pattern parameter is neither here or 
there ? the pattern parameter would be part of the ring signal which would 
be contained in the Signal List. The fact that two different mechanisms 
are used is "odd", because if for example you use a "ring pulse alert" 
signal for display prior to ringing and a "ring pulse alert" signal not 
associated with ringing, then why should this need to different signals. 
Especially since the same set of analogue signals are generated by the MG 
over the analogue interface for both these methods.
 
We can either try to mandate that "andisp/dwa" is used for "On-Hook" 
display prior to and during ringing, but there appears to be a lot of 
benefits and mileage in allowing "andisp/data" to be used for "On-Hook" 
display prior to ringing, during ringing and not associated with ringing? 
especially since a number of implementations have already adopted this 
approach. 
[KJBII] I believe the package should be used as it was designed -- andisp/dwa for 
data transfer associated with alerting, and andisp/data for data transfer 
not associated with alerting. Use of data for alerting scenarios will lead 
to timing issues and failures.
 
[Dal] ? I don't understand what the timing issues are? With the 
andisp/data the MG runs timers after the TAS and after the FSK signal ? 
How is this timing any different to the "display associated with ringing".
 
The bottom line is that you have cut your cloth using two different 
signals "dwa" and "data" in the "andisp" package, but using just one 
signal has its merits, does work successfully and is not illegal. 

 
Regards,

Dal.

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Wayne Cutler
Sent: 28 April 2005 10:06
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp package andthedwa /data 
signals

Hi Kevin, 

ETSI FSK delivery is described in ETSI EN 300 659 which has a section 
(6.1) called "Data Transmission Associated with Ringing" which is then 
further split into 2 sub-sections, namely "Data Transmission during 
Ringing" (6.1.1) and "Data Transmission Prior to Ringing" (6.1.2). 

Interestingly, the trasnmission that uses a TAS of RP is regarded as 
"prior to ringing" since the timings are different to the splash of 
ringing that is used 
for the "during ringing" scenario. 

Therefore, the andisp dwa & data signals align nicely with the ETSI split 
and more than one company has interpreted the standard in this way and 
progressed to implementation. I would  disagree with your assertion about 
the procedures "clearly stating" this distinction. In fact, the cited UK 
example is incorrect since there are two methods used in the UK, namely 
the "BT method" which is prior to ringing (and uses a TAS or LR followed 
by DT-AS) and the "Bellocore" method used by Cable Operators (that uses a 
TAS of RP). 

I think it's a bit late to try and claim that the H248.23 words "during 
alerting" means "associated with alerting" - especially given the wording 
of the EN. 

Regards, 
Wayne 

Your interpretation is incorrect.  The dwa signal is designed to perform 
data delivery associated with ANY alerting, whether prior to or during 
ringing.  This is clearly stated in the procedures section of the 
document. 
Kevin 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wayne Cutler 
Sent: Tuesday, April 26, 2005 5:45 AM 
To: [email-masked] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: Re: [Megaco] interpretation of H.248.23 andisp package and 
thedwa/data signals 
implemented for methods 1 and 2. 
Hi Jan, 
For question 1, we'd read h248.23 as meaning that andisp/dwa should be 
used for option 2 (during ringing) and andisp/data for option 1 (prior to 
ringing). 
In terms of question 2, this is what the Marconi CA & MSAN has 
implemented. 
Regards, 
Wayne

---

From: "Wayne Cutler" <[email-masked]>
Date: Fri, 29 Apr 2005 16:50:59 +0100

Hi Kevin,

Some comments in-line.

This sounds like a kludgy stretch to me.  While it *can* be included, I 
don't recall seeing any discussion or agreement to the inclusion of 
terminating silence periods as part of a signal.  Further, I don't believe 
that you can claim to have universal agreement to that methodology, in 
this case or any other.
 
WC - since the signal is defined in the MG, whether the silence is part of 
the signal or not can be handled on the MG. This is to do with how the 
signal is 
mapped on the MG and so is (strictly speaking) outside the scope of the 
protocol - so why should there have been any discussion ?

Take the following case, which shows that this cannot work: The MGC sends 
your SignalList, sending a ringsplash, the data signal and ringing.  The 
MG is not equipped to provide FSK to that terminal.  So, it rightly 
rejects the command with the SignalList.  The specs demand that ringing 
occur even if the data transfer fails.  In this regard, the use of 
andisp/data is not an acceptable solution.  Note that the andisp/dwa 
signal supports this scenario correctly, because it demands that the 
alerting portion of the signal occur even if the MG cannot perform the 
data transfer.
 
WC - so ther MG sends a reject and the CA could re-apply ringing. Why 
wouldn't this be acceptable? 

I will reiterate what I have previously stated, just in case I wasn't 
clear enough:  The andisp package is not designed to be used in a 
SignalList in this fashion.  For display with alerting -- any king of 
alerting -- the andisp/dwa signal is the appropriate signal.  Use of the 
andisp/data signal in a SignalList is a misuse of the package.

WC - In general, H248 is flexible (possibly too flexible?) in terms of 
permitting a given action to be realised in more than one way in H248. 
This is 
true for the FSK delivery which can be realised via a mixture of data/dwa, 
data (with signal list) or even only dwa (using a pattern to mean no 
ring). The 
spec. was ambiguous and there are multiple ways to skin the FSK cat. If a 
MG gets a signal list with data & ri, the right result occurs in terms of 
the events on the line - so why should this be regarded as "incorrect"?
 
Wayne

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 29 Apr 2005 14:10:21 -0400

Comments inline. [KJBII]
 
Kevin

  _____  

From: Wayne Cutler [mailto:[email-masked]] 
Sent: Friday, April 29, 2005 11:51 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Dal Chohan; [email-masked]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa /
data signals

Hi Kevin, 

Some comments in-line. 

This sounds like a kludgy stretch to me.  While it *can* be included, I
don't recall seeing any discussion or agreement to the inclusion of
terminating silence periods as part of a signal.  Further, I don't believe
that you can claim to have universal agreement to that methodology, in this
case or any other. 
  
WC - since the signal is defined in the MG, whether the silence is part of
the signal or not can be handled on the MG. This is to do with how the
signal is 
mapped on the MG and so is (strictly speaking) outside the scope of the
protocol - so why should there have been any discussion ? 
[KJBII] Because this has an impact on when the determination of signal
complete occurs! Does it occur when the playout stops, or after some
arbitrary silent period?  When does the MGC expect to be notified?  What if
when the MG decides to tell the MGC and when the MGC expects to be notified
are two different times, due to the presence of this additional silence?
Perhaps we should add an arbitrary silence to the end of all signals!  This
is a design that is dependent upon assumptions about how the MG will behave,
rather than well-defined criteria.  I would be interested to see how many
people would actually claim that the completion of FSK transmission is after
200 ms of silence after the actual data stopped, if the signal stood on its
own.

Take the following case, which shows that this cannot work: The MGC sends
your SignalList, sending a ringsplash, the data signal and ringing.  The MG
is not equipped to provide FSK to that terminal.  So, it rightly rejects the
command with the SignalList.  The specs demand that ringing occur even if
the data transfer fails.  In this regard, the use of andisp/data is not an
acceptable solution.  Note that the andisp/dwa signal supports this scenario
correctly, because it demands that the alerting portion of the signal occur
even if the MG cannot perform the data transfer. 
  
WC - so ther MG sends a reject and the CA could re-apply ringing. Why
wouldn't this be acceptable? 
[KJBII] Which signal, in the list, was the one causing the rejection?
Because error text is optional, you cannot rely upon the MG relaying that
information to you.  So if it is the ringing portion of the signal that has
failed, then reapplication of ringing is a rather inappropriate response.
Not to mention that in the case where it IS the FSK that is the problem, you
are adding two messages and all their associated overhead and delay to the
application of ringing to the line. The dwa signal was specifically designed
to handle integration of alerting with data delivery, and also designed to
account for the instance where alerting succeeds but data transmission
fails.

I will reiterate what I have previously stated, just in case I wasn't clear
enough:  The andisp package is not designed to be used in a SignalList in
this fashion.  For display with alerting -- any king of alerting -- the
andisp/dwa signal is the appropriate signal.  Use of the andisp/data signal
in a SignalList is a misuse of the package. 

WC - In general, H248 is flexible (possibly too flexible?) in terms of
permitting a given action to be realised in more than one way in H248. This
is 
true for the FSK delivery which can be realised via a mixture of data/dwa,
data (with signal list) or even only dwa (using a pattern to mean no ring).
The 
spec. was ambiguous and there are multiple ways to skin the FSK cat. If a MG
gets a signal list with data & ri, the right result occurs in terms of the
events on the line - so why should this be regarded as "incorrect"? 
[KJBII] If the termination has a failure and the MG sends a Subtract to the
MGC, which, for some reason, accepts it, is that not incorrect?  The
clean-up of the termination took place, but that does not mean that the
function was correct within the scope of the protocol.  In this instance,
the function is not correct within the scope of the package.  Will your MG
accept the use of andisp/dwa for "prior to ringing" scenarios?  If not, then
it has usurped control from the MGC.  On the other hand, since the package
has a clear delineation between how to signal FSK associated with alerting
and how to signal FSK not associated with alerting.  To quote from the
description of the andisp/data signal: "Sends data not associated with
alerting to the CPE. Examples of this would be Analog Display Services
Interface (ADSI), Message Waiting Indicator, Short Message Service, or
Advice of Charge. ADSI is used for advanced features such as
context-specific softkeys, and in-phone visual data editing."  Note the
first sentence.  I do not know how much clearer you can get.  Use dwa to
send FSK with alerting, use data to send FSK without alerting.
  
Wayne

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 29 Apr 2005 14:20:23 -0400

More comments inline. [KJBII]
 
Kevin

  _____  

From: Dal Chohan [mailto:[email-masked]] 
Sent: Friday, April 29, 2005 1:06 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Wayne Cutler'
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa /
data signals

Comments in-line.

Dal.

  _____  

From: Kevin Boyle [mailto:[email-masked]] 
Sent: 29 April 2005 15:00
To: Wayne Cutler
Cc: Dal Chohan; [email-masked]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa /
data signals

[Dal] - I don't see this as kludge - The signal includes a silence timer
after the FSK signal - This is no big deal and totally within the spirit of
H.248. It is no different to running a timer after the TAS which is
performed for "andisp/dwa" case. There are many pulsed signals defined in
the "stimal" package which could also result in a timer being run after the
pulsed signal has been applied.
[KJBII] Actually, it is nothing like running that timer -- because applying
the alerting portion of the signal is part of dwa.  In the scenario you
describe, the alerting is a completely separate signal.  Further, your
analysis of H.248.34 does not align with the text.  The pulsed signal only
indicates the number of pulses to apply.  There is no indication that an
idle time is required after the signal completes.  In fact, there is not
mention of any extra timers that are required as part of the application of
any of the pulsed signals.

Anyway I'm glad to see that you at least agree that this method doesn't
violate H.248 as you previously suggested.
[KJBII] I agree to no such thing. The only thing I agree to is that some
kludges have been added in order to implement this functionality in a
particular way, and now the idea that those implementations will have to be
reworked to conform to the package definition is unpalatable to you.

[Dal] - If the MGC requests the MG to apply an FSK signal, then there is no
reason why the MG wouldn't apply the FSK signal as the CLIP service is
provisioned in the MGC and not the MG. 
[KJBII] Wow.  Do you actually know how data transmission works?  What if the
CLASS modem fails? 

[Dal] - I think you should not be dismissive regarding the use of
"andisp/data" for display associated with ringing as it has number of
advantages as cited by the previous e-mails. The use of "andisp/data" is
clearly an innovative way of doing things and just because it wasn't
initially envisaged  to work like this doesn't make it wrong.
[KJBII] The only advantage I see is that it protects your implementation.
There are many reasons why the FSK transmission when associated with
alerting was not designed to work this way.  I wouldn't call it innovative
either.  Don't you think I *started* with that model, then altered the
design when scenarios presented themselves that caused it to be
non-functional?  Finally, to quote the very first line of the description of
the andisp/data signal: "Sends data not associated with alerting to the
CPE."  So your use clearly does not align with the definition of the signal.

Kevin

  _____