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

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 29 Apr 2005 15:18:09 -0400

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: "Kevin Boyle" <[email-masked]>
Date: Fri, 29 Apr 2005 18:51:17 -0400

I'm sorry, but I still have not seen the need for the MGC to have any
knowledge of the TAS in the alerting scenario.  This is a function of the
FSK delivery, and should not have to be specified.  The TAS is dependent
upon the equipment at the customer premise -- something that will not change
frequently over time, and certainly not per-call.  Therefore, the solution
presented by the package -- provisioning the TAS on the MG per termination
-- is a better solution that saddling the MGC with the per-termination
knowledge over all its MGs.  As I have said before, the reason why TAS can
be overridden for the non-alerting signal (data) is due to a FEATURE
requirement to be able to suppress the TAS between subsequent messages in
some instances.  This case does not apply to the alerting scenario, and so
there is no need for the MGC to ever specify the TAS to the MG for the
alerting case.
 
I will note that this is H.248, and not V5.  The package in H.248.34
contemplates the the use of the packages in H.248.23 for alerting and, by
extension, the display features.  Even so, the philosophy in H.248 has
always been that regional requirements are the responsibility of the MG and
NOT the MGC.  This means that an MG, which by definition is a regional
entity, manages a reasonable amount of data associated with its operation,
rather than forcing the MGC to have the unreasonable and untenable burden of
universal knowledge of all requirements in all locations over the entire
earth in order to provide service.
 
I will propose to the upcoming SG16 meeting that the erroneous word already
pointed out be corrected, and that more explanatory text be added to make
the function of the package crystal clear.  I will not support making
technical changes to a package that is not broken.
 
Kevin

  _____  

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

Dal, Kevin, Wayne 
 
Let me try to summarize the situation:
 
1) The intention of the andisp package was to have 2 signals to handle 2
call situations: 
- dwa for data transmission with new incoming call (CLIP)
- data for data transmission not associated with incoming call.
 
2) The reason why certain implementations use andisp/data instead of /dwa is
because they want to control the type of TAS from the MGC.
 
The key question here is where in the network the PSTN signal mapping
provisioning is done (MG or MGC). I assume that many operators in ETSI
markets will migrate their PSTN networks with V5 class 5 switches to H.248.
Note that V5 is strict in the way that the National PSTN mapping resides in
the Local Exchange, the PSTN protocol conveys exclusively physical signals.
I can imagine that there are some advantages for operators and MGC vendors
to stay with this principle when migrating from V5 to H.248.
 
If we assume that H.248 should not prohibit this (the stimal package was
defined exactly for the reason to have the PSTN mapping in the MGC), we need
to allow the TAS signal to be controlled by the MGC (as an alternative to
provisioning it in the MG). 
 
Proposed solution: Add a TAS parameter to andisp/dwa; this solution would be
backwards compatible to the actual andisp package. Andisp/dwa could then be
used without TAS parameter (behaviour same as today - TAS default
provisioned in MG) or with TAS parameter (TAS overwritten by MGC). 
 
This would result in the following advantages (compared to using andisp/data
for CLIP):
- andisp signals are used the way the autors of the package intended
- 2 different call situations are handled with 2 signals
- implementations would only differ in whether they overwrite the default
TAS of /dwa or not
- cadence ring pattern is part of the /dwa signal, no need for signal list
 
Best regards
Walter
 
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Kevin Boyle
Gesendet: Freitag, 29. April 2005 21:18
An: Dal Chohan; 'Wayne Cutler'
Cc: [email-masked]; [email-masked]
Betreff: RE: [Megaco] interpretation of H.248.23 andisp package andthedwa
/datasignals

Kevin

  _____  

Dal.

  _____  

Comments inline. [KJBII]
 
Kevin

  _____  

Hi Dal, 

  

 

 

  

  
Regards, 

Wayne