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

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

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. 

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. 

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.

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. 
  
Regards, 

Wayne 

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

---

From: "Dal Chohan" <[email-masked]>
Date: Fri, 29 Apr 2005 18:11:05 +0100

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

  _____  

Hi Dal, 

  

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

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.

 The use of "andisp/data" works and is a more innovative solution than your
original proposal. Therefore let's legalise it.

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

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

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

Regards, 

Wayne