Subject: RE: [Megaco] interpretation of H.248.23 andisp package andthedwa /datasignals

From: "Jan Lindquist \(AL/EAB\)" <[email-masked]>
Date: Mon, 2 May 2005 18:31:19 +0200

Hello megaco community,
 
It is clear that there has been different interpretations on the usage
of the andisp package by a couple of companies.  I would like to ask
again the original question since the intention of the thread was also
to gather information on how many companies have used data signal in a
signal list in order to control TAS parameters for CLIP service.  Is
there anybody else other than Fujitsu and Marconi that have used a
signal list with data signal and ringing signal in order to control TAS
parameters?
 
Best regards,
JanL
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Kevin Boyle
Sent: den 29 april 2005 21:18
To: Dal Chohan; 'Wayne Cutler'
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp package
andthedwa /datasignals

More comments inline. [KJBII]
 
Kevin

________________________________

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

	Comments in-line

	Dal.

	
________________________________

	From: Kevin Boyle [mailto:[email-masked]] 
	Sent: 29 April 2005 15:03
	To: Wayne Cutler; [email-masked]
	Cc: [email-masked]; [email-masked];
[email-masked]
	Subject: RE: [Megaco] interpretation of H.248.23 andisp package
andthedwa /datasignals

	Comments inline. [KJBII]

	Kevin

________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wayne Cutler
		Sent: Friday, April 29, 2005 4:07 AM
		To: [email-masked]
		Cc: [email-masked]; [email-masked];
[email-masked]
		Subject: RE: [Megaco] interpretation of H.248.23 andisp
package andthedwa /datasignals

		Hi Dal, 
		
		Some comments/observations in-line. 
		  
		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). 
		  
		WC - Yes, you can provision the MGC or the MG. Both cab
be made to work. It is a philosophical argument.
		[KJBII] No, it is not philosophical.  The argument is
whether you have interpreted the spec correctly.  The answer is
definitively that you have not. 

		[Dal] - The issue is not about interpretation of the
specification, but it is an architectural issue. The use of
"andisp/data" puts the emphasis on the MGC to specify the TAS signal to
apply to the physical termination. Where as the "andisp/dwa" lets the MG
determine the TAS signal.
		[KJBII] So you admit that the architecture of your
implementation is the problem?  As I pointed out before and you
conveniently ignored, it is unreasonable to require MGCs to have
knowledge of what amount to local procedures to apply signals.  MGs must
know how to apply the signals they are ordered to apply.  The use of a
particular TAS and the timing of the delivery of the data when
associated with ringing is a LOCAL requirement, and is an inherent
function of the application of FSK when associated with alerting.  If
the MGC is located in Zanzibar and is controlling MGs in Timor L'este,
Colombia and Jordan, it is completely unreasonable for the MGC to have
to have knowledge of the actual physical procedures to apply Caller ID
or any other signal.  The burden for local knowledge is on the MG, plain
and simple.  The usage of the package as it is written allows the MGC to
tell the MG to apply Caller ID.  The methodology you describe requires
the MGC to outline, in detail, the steps necessary to perform Caller ID
-- which differ not only from country to country, but even within the
same local areas based on carrier requirements.  MGs must know how to
apply their signals, plain and simple.  If not, we should scrap all the
packages and go back to having the MGC specify frequencies, cadences,
power levels, etc., for every signal that has been devised.

		This is no different to the approaches taken with the
"Xal" and the "Stimal" packages. The "Xal" lets the MG determine what
physical signal to apply upon receipt of "line side answer" signal.
Where as in the "Stimal" package the "steady signal reverse polarity" is
specified by the MGC and the MG applies the specified signal.  Both
approaches and signals are legal as they are defined in different
packages. The signal chosen to be supported in a particular territory is
dependent upon what the architectural requirements are for that
territory. Thus why should the use of "andisp/data" and "andisp/dwa" be
any different - it is analogous the "xal" and "stimal" case and a
precedence has already bee set.
		[KJBII] This is not the same.  xal and stimal are
targeted at two different cases. Stimal is the replacement for V5.  xal
is sufficient for those areas that do not have the V5 requirements to
meet.  I do not see any precedent here.

		 The use of "andisp/data" works and is a more innovative
solution than your original proposal. Therefore let's legalise it.
		[KJBII] It is not more innovative.  It has nothing to do
with innovation.  As you mentioned above, it has everything to do with
accounting for the deficiencies in your architecture.  There is a
standard package for this function that was designed to work in a
particular way.  If you don't like it, write your own proprietary
package.

		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. 
		  
		WC - Yes, andisp/data can be used for the whole lot if
desired.
		[KJBII] Again, no it cannot.  Take the following
instance: 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 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
requires that the alerting occur even if data transfer cannot. 

		[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] Modems fail.  Transmissions lose bits and fail
all the time.  There are any number of reasons why the MG would fail to
send the data.  

		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. 
		  
		WC - Yes. It is less consistent.
		[KJBII] No, it is perfectly consistent.  Display with
alerting -- ANY kind of alerting, is performed using andisp/dwa.
Display without alerting is performed using andisp/data. Instead of
trying to break this up into onhook and offhook signalling, the
breakdown is into whether alerting is occurring or not.

		[Dal] - I disagree with you here - In the "andisp/data"
case the MGC is explicitly requesting the MG to apply the specified TAS.
Where as for the "andisp/dwa" case, the TAS is determined by the MG.
This is clearly an inconsistent way of doing things and I haven't been
convinced by any of your arguments.
		[KJBII] To be blunt, you are wrong.  To quote from the
description of the TAS parameter: "The default is provisioned."  This
means that the TAS parameter is OPTIONAL. Therefore, it is REQUIRED that
the TAS be provisioned in the MG, in the instance the MGC does not
choose to send the TAS parameter.  As I have mentioned in an earlier
email, that was added to allow the MGC to suppress the TAS in the
instance of transmission features that allow multiple messages to be
sent without a TAS between them.

		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. 
		  
		 WC - There seems to be a lot oif options in this area
(and a number of implementations) and this is why the TISPAN profile
shopuld be open and allow 
		national operators (if they so wish) to decide between
options. 
		[KJBII] I disagree, and I will see that the package is
updated by SG16 to correct the misconceptions.  The TISPAN profile needs
to describe a correct usage of the package, and not be protectionist of
incorrect implementations.  Just as a MG sending an Subtract command to
a MGC is clearly not correct and needs correction in the implementation,
this case is an implementation problem and needs correction in the
implementations. 

		[Dal] Why would a MG send a Subtract to a MGC? This is
clearly invalid and violates H.248, as a Subtract command is only valid
from the MGC to the MG. This is clearly not a good example to use argue
your case.
		[KJBII] I assume you read the list.  I can therefore
assume that you have seen how many times the question of whether a MG
can autonomously Subtract a termination has come up.  I used that as a
common example to illustrate my point.  Just as that is invalid, so is
the usage of the andisp package you describe. I am telling you, as the
primary author and editor of the package, that the use of the
andisp/data signal to perform FSK delivery when associated with alerting
is just as invalid as a Subtract from a MG, and is clearly invalid given
all the supporting text I have quoted to that effect.  The
implementation you are arguing for is based upon the (admittedly
erroneous) presence of a single word in the description of the dwa
signal.  When I wrote it, the use of the phrase "during alerting" was
intended to convey "associated with alerting".  This much is clear given
all the examples I have pointed out and all the text from the other
descriptions that I have pointed out, including the bit I quoted above.
Given the overwhelming amount of additional text in the spec that backs
up my supposition, there can be no doubt as to the intent.  I have yet
to see a single quoted bit other than that one word to support your
interpretation.

		  
		Regards, 

		Wayne 

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

---

From: [email-masked]
Date: Wed, 4 May 2005 18:09:28 +0200

Jan et al.,

the interpretation & implementation by corresponding ALCATEL H.248 systems:

MGCs: use andisp/dwa signal

MGs: support both andisp/dwa (primary procedure) and andisp/data + ringing
signal, for compatibility with third party MGCs

Provisioning strategy in this context:
The physical characteristics of the TAS, timer values, etc. are provisioned
in MGs.

Best regards
Albrecht

                      "Jan Lindquist                                                                                                 
                      \(AL/EAB\)"               To:      <[email-masked]>                                                           
                      <jan.lindquist@er         cc:      [email-masked]                                                    
                      icsson.com>               Subject: RE: [Megaco] interpretation of H.248.23 andisp package      andthedwa       
                      Sent by:                  /datasignals                                                                         
                      megaco-bounces@ie                                                                                              
                      tf.org                                                                                                         

                      02.05.2005 18:31                                                                                               

Hello megaco community,

It is clear that there has been different interpretations on the usage of
the andisp package by a couple of companies.  I would like to ask again the
original question since the intention of the thread was also to gather
information on how many companies have used data signal in a signal list in
order to control TAS parameters for CLIP service.  Is there anybody else
other than Fujitsu and Marconi that have used a signal list with data
signal and ringing signal in order to control TAS parameters?

Best regards,
JanL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kevin Boyle
Sent: den 29 april 2005 21:18
To: Dal Chohan; 'Wayne Cutler'
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp package andthedwa
/datasignals

Kevin

      Comments in-line

      Dal.

      Comments inline. [KJBII]

      Kevin

            From: [email-masked] [mailto:[email-masked]]
            On Behalf Of Wayne Cutler
            Sent: Friday, April 29, 2005 4:07 AM
            To: [email-masked]
            Cc: [email-masked]; [email-masked];
            [email-masked]
            Subject: RE: [Megaco] interpretation of H.248.23 andisp package
            andthedwa /datasignals

            Hi Dal,

            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).

            WC - Yes, you can provision the MGC or the MG. Both cab be made
            to work. It is a philosophical argument.
            [KJBII] No, it is not philosophical.  The argument is whether
            you have interpreted the spec correctly.  The answer is
            definitively that you have not.
            [Dal] ? The issue is not about interpretation of the
            specification, but it is an architectural issue. The use of
            "andisp/data" puts the emphasis on the MGC to specify the TAS
            signal to apply to the physical termination. Where as the
            "andisp/dwa" lets the MG determine the TAS signal.
            [KJBII] So you admit that the architecture of your
            implementation is the problem?  As I pointed out before and you
            conveniently ignored, it is unreasonable to require MGCs to
            have knowledge of what amount to local procedures to apply
            signals.  MGs must know how to apply the signals they are
            ordered to apply.  The use of a particular TAS and the timing
            of the delivery of the data when associated with ringing is a
            LOCAL requirement, and is an inherent function of the
            application of FSK when associated with alerting.  If the MGC
            is located in Zanzibar and is controlling MGs in Timor L'este,
            Colombia and Jordan, it is completely unreasonable for the MGC
            to have to have knowledge of the actual physical procedures to
            apply Caller ID or any other signal.  The burden for local
            knowledge is on the MG, plain and simple.  The usage of the
            package as it is written allows the MGC to tell the MG to apply
            Caller ID.  The methodology you describe requires the MGC to
            outline, in detail, the steps necessary to perform Caller ID --
            which differ not only from country to country, but even within
            the same local areas based on carrier requirements.  MGs must
            know how to apply their signals, plain and simple.  If not, we
            should scrap all the packages and go back to having the MGC
            specify frequencies, cadences, power levels, etc., for every
            signal that has been devised.

            This is no different to the approaches taken with the "Xal" and
            the "Stimal" packages. The "Xal" lets the MG determine what
            physical signal to apply upon receipt of "line side answer"
            signal. Where as in the "Stimal" package the "steady signal
            reverse polarity" is specified by the MGC and the MG applies
            the specified signal.  Both approaches and signals are legal as
            they are defined in different packages. The signal chosen to be
            supported in a particular territory is dependent upon what the
            architectural requirements are for that territory. Thus why
            should the use of "andisp/data" and "andisp/dwa" be any
            different ? it is analogous the "xal" and "stimal" case and a
            precedence has already bee set.
            [KJBII] This is not the same.  xal and stimal are targeted at
            two different cases. Stimal is the replacement for V5.  xal is
            sufficient for those areas that do not have the V5 requirements
            to meet.  I do not see any precedent here.

             The use of "andisp/data" works and is a more innovative
            solution than your original proposal. Therefore let's legalise
            it.
            [KJBII] It is not more innovative.  It has nothing to do with
            innovation.  As you mentioned above, it has everything to do
            with accounting for the deficiencies in your architecture.
            There is a standard package for this function that was designed
            to work in a particular way.  If you don't like it, write your
            own proprietary package.

            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.

            WC - Yes, andisp/data can be used for the whole lot if desired.
            [KJBII] Again, no it cannot.  Take the following instance: 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 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 requires that the alerting
            occur even if data transfer cannot.

            [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] Modems fail.  Transmissions lose bits and fail all the
            time.  There are any number of reasons why the MG would fail to
            send the data.

            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.

            WC - Yes. It is less consistent.
            [KJBII] No, it is perfectly consistent.  Display with alerting
            -- ANY kind of alerting, is performed using andisp/dwa.
            Display without alerting is performed using andisp/data.
            Instead of trying to break this up into onhook and offhook
            signalling, the breakdown is into whether alerting is occurring
            or not.
            [Dal] ? I disagree with you here ? In the "andisp/data" case
            the MGC is explicitly requesting the MG to apply the specified
            TAS.  Where as for the "andisp/dwa" case, the TAS is determined
            by the MG. This is clearly an inconsistent way of doing things
            and I haven't been convinced by any of your arguments.
            [KJBII] To be blunt, you are wrong.  To quote from the
            description of the TAS parameter: "The default is provisioned."
            This means that the TAS parameter is OPTIONAL. Therefore, it is
            REQUIRED that the TAS be provisioned in the MG, in the instance
            the MGC does not choose to send the TAS parameter.  As I have
            mentioned in an earlier email, that was added to allow the MGC
            to suppress the TAS in the instance of transmission features
            that allow multiple messages to be sent without a TAS between
            them.

            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.

             WC - There seems to be a lot oif options in this area (and a
            number of implementations) and this is why the TISPAN profile
            shopuld be open and allow
            national operators (if they so wish) to decide between options.

            [KJBII] I disagree, and I will see that the package is updated
            by SG16 to correct the misconceptions.  The TISPAN profile
            needs to describe a correct usage of the package, and not be
            protectionist of incorrect implementations.  Just as a MG
            sending an Subtract command to a MGC is clearly not correct and
            needs correction in the implementation, this case is an
            implementation problem and needs correction in the
            implementations.

            [Dal] Why would a MG send a Subtract to a MGC? This is clearly
            invalid and violates H.248, as a Subtract command is only valid
            from the MGC to the MG. This is clearly not a good example to
            use argue your case.
            [KJBII] I assume you read the list.  I can therefore assume
            that you have seen how many times the question of whether a MG
            can autonomously Subtract a termination has come up.  I used
            that as a common example to illustrate my point.  Just as that
            is invalid, so is the usage of the andisp package you describe.
            I am telling you, as the primary author and editor of the
            package, that the use of the andisp/data signal to perform FSK
            delivery when associated with alerting is just as invalid as a
            Subtract from a MG, and is clearly invalid given all the
            supporting text I have quoted to that effect.  The
            implementation you are arguing for is based upon the
            (admittedly erroneous) presence of a single word in the
            description of the dwa signal.  When I wrote it, the use of the
            phrase "during alerting" was intended to convey "associated
            with alerting".  This much is clear given all the examples I
            have pointed out and all the text from the other descriptions
            that I have pointed out, including the bit I quoted above.
            Given the overwhelming amount of additional text in the spec
            that backs up my supposition, there can be no doubt as to the
            intent.  I have yet to see a single quoted bit other than that
            one word to support your interpretation.

            Regards,

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