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

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 4 May 2005 12:01:14 -0400

Comments inline. [KJBII]
 
Kevin

  _____  

From: CHATRAS Bruno RD-CORE-ISS [mailto:[email-masked]] 
Sent: Wednesday, May 04, 2005 6:27 AM
To: [email-masked]; [email-masked]
Cc: Chris Gallon; Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]; Wayne
Cutler
Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa /
data signals

All,

As the Rapporteur for the ETSI Work Item that trigerred this thread, I'd
like to check my understanding of the ongoing discussion on the following
two issues, which I believe should be treated separately.

1/ The need to correct the description of the dwa signal in H.248.23 in
order to reflect the original intent (i.e. "during alerting" should be
replaced with "associated with alerting"). 

I have not seen any strong disagreement about this. Anyway, the procedure
section provides already an example of use of the dwa signal and states
explicitly that the "TAS should be provisioned for the gatway's location".
Can we assume that the required correction will first be available in the IG
and then in a revised edition of H.248.23? 
[KJBII] Actually, I am going to propose that a Corrigendum be issued
immediately to deal with this issue.  If this is agreed by SG16, then then
correction would be available as H.248.23 (01/2005) Corrigendum 1
(09-ish/2005).  If the question does not agree to issue a Corrigendum, then
it will end up in the IG. 

2/ Whether an alternative method, based on the data signal, should also be
allowed by H.248.23 for supporting data transmission prior to alerting. 

Allowing this would clearly require a change to H.248.23 since the current
description of the data signal explicitly says that the purpose of the data
signal is to send "data not associated with alerting to the CPE" and
provides a number of service examples that are indeed not associated with
ringing. From my point of view 
[KJBII] Agreed. 

Having said that, I must also say that I don't really see why a
Recommendation would have to propose two methods for doing the same thing.
Assuming that the Recommendation does propose two solutions, I believe that
the TISPAN profile should select only one and preferably the one which is
already documented in H.248.23 (i.e. use of dwa irrespective of the
transmission method). 
[KJBII] Agreed.  In fact, specification of two or more methodologies
actually harms interoperability, by segmenting the available implementations
into the different methods. This kind of thing ahs led to problems in the
past with H.248, and SG16 has spent a large amount of time cleaning up all
those issues (ServiceChange comes to mind!) 

Best Regards,

Bruno

  _____  

De : Chris Gallon [mailto:[email-masked]] 
Envoyé : mercredi 4 mai 2005 11:31
À : [email-masked]
Objet : Re: [Megaco] interpretation of H.248.23 andisp packageandthedwa /
data signals

Kevin, 
 
I believe the fundamental issue is that it is not the remit of SG16 or
yourself to determine how network operators chose to architect or manage
their networks. 
 
Your argument that information such as TAS must be distributed to the MG or
it cannot work because the MGC can't handle the volume of data is simply not
true, this is born out by the very many lines of V5 deployed in ETSI markets
which have just such a management model, or are these just a figment of my
imagination. You may not like it but H.248.34 has opened the door to this
approach and in my view is likely to extend the reach of H.248 into many
markets and deployments which otherwise would have rejected it (such as the
UK).
 
A previous poster on this thread Walter Binz posted the following: 

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

I believe that this hits the nail on the head, such a mechanism may be
required by operators using a Stimal based approach. As Wayne points out FSK
can be done using andisp/data to meet this requirement. This not only works,
is legal in H.248 and is interoperable, it also has no impact whatsoever on
implementations using dwa. 

I therefore fail to see how having two solutions to FSK (and allowing the
choice to be selected based on operator/deployment) harms interoperability.
Profiles exist to allow such things to be documented in detail and the
market will decide which approach best fits.

Regards

Chris. 

----- Original Message ----- 
From: Kevin Boyle <mailto:[email-masked]>  
To: Wayne Cutler <mailto:[email-masked]>  
Cc: Chris Gallon <mailto:[email-masked]>  ; Dal Chohan
<mailto:[email-masked]>  ; [email-masked] <mailto:[email-masked]>  ;
[email-masked] <mailto:[email-masked]>  
Sent: Tuesday, May 03, 2005 10:26 PM
Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa /
data signals

Comments inline. [KJBII]
 
Kevin

  _____  

From: Wayne Cutler [mailto:[email-masked]] 
Sent: Tuesday, May 03, 2005 11:03 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Chris Gallon; Dal Chohan; [email-masked] <mailto:[email-masked]> ;
[email-masked] <mailto:[email-masked]> 
Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa /
data signals

Hi Kevin, 

I do think that some of your responses did cross the line and could have
been worded in a more suitable manner. 

Anyway,  yet more comments in-line.... 

  Kevin, 

I feel that your comments in reply to Dal Chohan are really not acceptable
on a public email exploder because they cross the line between technical
argument and personal insult. As my colleague Dal is not on email this week
I feel compelled to defend him in his absence. 

[KJBII] I see nothing personally insulting here.  If you or Dal choose to be
insulted, then that is your choice.  I am arguing technical points -- most
of which are being ignored.  I can only assume that is because there is no
response.  However, I will not stand idly by and allow Dal or others to say
things that are technically incorrect (such as the FSK transmission failure
issue) and not call them on it.  It only serves to confuse the less
experienced out there who may be reading this list. 

[WC} The argument is about whether there should be one or more than one way
to skin the FSK cat. Due to the ambiguity of your specification, there are
implemntations that have used a different way of doing FSK delivery to that
allegedly originally intended. This other method works perfectly well and I
fail to see why this should be deemed "incorrect" or "illegal". H248 is full
of ambiguities (i.e. multiple ways of performing a given function) - why is
this one such a big deal? 
[KJBII] What ambiguity?  Again, this "ambiguity" is based upon a single word
in the spec.  All the rest of the spec, many examples of which I have
pointed out, all are consistent with the assertions I have made.  I disagree
that there is the degree of ambiguity that you and Dal have made it out to
be. The reason why this particular item is a big deal is because it is
harming the interoperability of the package in particular and the protocol
in general. 

I do not believe that you have shown the use of andisp data as proposed is
illegal, you have one view there are others. There are a number of
independently developed implementations that use it in this way and it has a
number of advantages over dwa in certain network deployments. This use of
andisp/data may not have been what you intended but the fact it works merely
shows the utility of H.248 and the advantages of signal lists. 

[KJBII] I have made and remade my points ad nauseam.  It is funny how you
choose not to address the technical points I have raised to this, such as
the inconsistency between wanting to have the MG know how to apply FSK data
by conveniently adding 200ms of idle time, but not wanting the MG to know
about the TAS.  This is a completely inconsistent application of the
specification.  Further, the application of terminating idle time is, as I
have said before, nothing better than a timing kludge to allow the
misinterpretation of the H.248.23 spec to function.  How about the specific
text that discusses how the signals are to be used, or the actual
descriptions of the other signals?  I haven't heard any counter-arguments
other than the use of the word "innovative", which certainly does not apply
here. 

[WC} - The argument cuts the other way as well. Why is it OK for the GW to
knowe about TAS but not about idle time? Like I said above, there's more
than one way to skin the FSK cat. 
[KJBII] The problem is that the TAS is inherently part of the FSK signal.
Idle time at the end of a signal is generally not considered part of a
signal, unless it is a repeating pattern, such as audible ringback.  Unless,
of course, you'd like to change all the signals to have this idle padding.
Maybe call wait tone should be 500 ms followed by 10 seconds of idle time.

On a number of occasions you have referred to people misunderstanding the
specification or having architectural limitations on their implementations.
This is not the case, the fact is that there are very significant capex
advantages in limiting the amount of knowledge that an MG has of the
services it is providing and this was one of the motivating factors behind
the stimal package. 

[KJBII] Again, statements like these show a lack of knowledge and/or
experience with analog line data transmission.  The TAS is a function of the
SIGNAL, not a function of the FEATURE.  The TAS only changes with changes in
equipment on the line, not with changes in the feature itself.  Therefore,
the MGC should not have to specify it.  In fact, as I have pointed out again
and again, this is a LOCAL-type requirement, and is the domain of the MG
anyway. 

[WC} this is the philosopjical argument about whwre the data is provisioned
to deal with TAS variations. You can do it on the MG or on the MGC. Both
work and the preference is probably operator dependent/specific. 
[KJBII] As you agreed below, the TAS is dependent upon the hardware, and
therefore cannot be a part of the feature.  If it were part of the feature,
it would not be a hardware-dependent function -- rather, it would be
independent of the hardware operation.  The data ought to be provisioned
where it will be used.  The MGC certainly cannot use the TAS for anything,
since it is a MG hardware-dependent setting.  

In your view of the world the MG is responsible for providing regional
specific functionality for a generic global call control held in the MGC.
This is a valid view and works well for cases where an operator wishes to
deploy call agents on a global basis and is prepared to take the inherent
risk that an upgrade to call control will have an impact on the intelligence
in the gateways and require them to be upgraded to work with the new call
control. 

[KJBII] This is actually one of the primary design considerations behind the
H.248 protocol.  If it is not universally accepted, then interoperability
becomes nigh upon impossible.  I will be taking a contribution to SG16 to
highlight and cement this particular bit of information. 

[WC] - I disagree with your blanket assertion. Regional (or customer)
differences can be resolved by MG, MGC or combination of the both. 
[KJBII] You disagree with my assertion that H.248 was specifically designed
to decouple the call processing knowledge from the local circuit presence?
Instead of the MGC sending "play dialtone", you'd rather have it send "play
frequency X and Y in this cadence at this power level"? 

However there are alternative models for which H.248 also works well. 
For full PSTN replacement you have a few call agents but a very large number
of gateways. In this case a good approach is to minimise the intelligence
required in the MG. It is not an implementation issue, it is an operational
requirement. This approach was taken by V5 and was a direct response to the
high upgrade costs associated with the previous generation of I-Muxes which
held too much service specific information and had inflicted significant
upgrade costs and difficulties on network operators. With the introduction
of stimal this approach can also, within the rules of the H.248 protocol, be
used for the NGN. 

[KJBII] Actually, it only works in YOUR architecture.  MGC vendors with more
than one deployed customer actually realize that the data management weight
is far too high for the MGC to manage.  Regional info should be limited to
the MGs, as they have far fewer terminations, and therefore far less data to
manage.  Your point about few call agents and many MGs actually makes my
point -- Why should the MGC manage the individual TAS setting for 400K
terminations, when each MG only has to manage 5000?  It is an 80-fold
increase in data management if that is placed on the MGC -- and that is for
an admittedly very large MG!   

[WC] This has nothing to do with "architecture". It is a philosophical
argument about where the data is managed. An operator may be happier to use
the relatively complex management i/f to a MGC to tweak variations rather
than the relatively simpler MG i/f. There is an argument to use the same MGC
i/f to tweak behaviour on the (now simpler) MGs (which could come from
multi-vendors). Any operators out there who would care to comment ? 
[KJBII] It has everything to do with architecture.  You want the MGC to
manage data that has nothing to do with call processing.  If the MGC's job
is to perform call processing, then why are you intent upon saddling it with
work that is the clear domain of the MG? 

The use of andisp/data has the advantage that the MGC specifies the TAS
signal to apply to the physical termination thus removing the need for
service specific information to be provisioned in the MG. This is consistent
with the approach of V5 and subsequently the H.248 stimal package. The dwa
approach requires this information to be provisioned in the MG and is
appropriate for the alternative operation deployment that you advocate. 

[KJBII] I will say again -- the TAS is dependent upon the HARDWARE
associated with the TERMINATION.  It has nothing to do with the FEATURE.
Hardware management is CLEARLY the domain of the MG.  This is the basis of
the H.248 architecture -- the MG is decoupled from the MGC.  If you need the
MGC to manage that, the protocol you need is H.323.  I will note that none
of you have addressed my other point: that the TAS is an OPTIONAL parameter
in the andisp/data signal whose default is PROVISIONED in the MG.  So, the
MG MUST have it provisioned anyway. 

[WC} You're statement about the TAS being related to the h/w rather than the
feature is correct - but so what ? It comes down to where the bit of data
gets tweaked that has the desired effect. Both places work. 
[KJBII] So you agree that the management of the MG hardware is the domain of
the MG.  And you also agree that the TAS is dependent upon the hardware.  It
seems to me then, that the MGC has no business messing with the TAS, since
the MGC is decoupled from the hardware.  By allowing the methodology you've
described, you are re-coupling the MG hardware to the MGC.  I note that no
one has yet commented on the point that the TAS has to be provisioned in the
MG. 

So both approaches work and have been shown to work in testing. I would
question whether SG16 should retrospectively change a package not because it
is being used illegally but because some individuals do not approve of what
some vendors and hence some operators are using it for. 

This to me seems a step too far for a standards organisation to take. 

[KJBII] This is a clarification of a single typographical error, not a
"retrospective change".  This is not a matter of my approval or disapproval,
either.  This is based on interoperability testing with MANY MGC and MG
vendors, and live deployment of this solution to well over 7 million lines
of service worldwide.  If your company would like to alter the
specification, then I suggest you start sending representatives to SG16.  I
will note that for all the emails sent about various spec issues, Fujitsu
has been notably absent from the meetings of Q3/16. 

[WC] As we've said ad nauseam, there are multiple ways of delivering FSK. It
is clear that "your way" works - but so does "our way". 
[KJBII] "Your way" is not defined in any spec in detail enough to allow it
to be interoperable.  Since it isn't interoperable, except by a few
insiders, I can only conclude that it will not work in practical
circumstances.  "My way" is clearly and thoroughly defined in the H.248.23
spec.  It has had comments incorporated from many contributors over the
years, in order to assure its interoperability.  The interoperability of the
package as I have described it to be has been well tested at many events
amongst many vendors.  This leads to the conclusion that it works very well
and is well defined. 

Finally I would like to point out that Dal Chohan has very many years in the
industry working on and implementing UK (and other) telephony solutions,
ISDN and V5 in addition to his work on H.248 stimal. I can assure you that
he does "actually know how data transmission works". It is just that the
failure mode you quoted does not apply to the case being considered. In this
case FSK is being used to support a CLIP service which is provisioned in the
MGC and the MG will always be able to play the signal because of the
capabilities of the underlying (industry wide) silicon. Thus the FSK signal
will always be applied. 

[KJBII] His statements point to the contrary.  In fact, your statement here
shows a overwhelming naïveté toward the industry at large.  Are you really
saying that there will NEVER be a failure? Ever? Are you really serious?
Just because something is unlikely does not mean it does not have to be
accounted for in the design of a system.  I assume your products are
redundant.  Would that be because you are sure there will never be a
failure? 

[WC] If I remember it correctly, your problem was the inability of the MG to
apply FSK (for whatever reason) whilst it was part of the SignalList and
metting the requirement of ringing the phone anyway. So, as I think
responded earlier, the MGC could get a rejection and could re-apply the
ringing if it so desired. 
[KJBII] Actually, this particular bit of text is discussing the further
requirement that the terminal ring even if the FSK fails.  What if the MG
successfully receives the SignalList, but the FSK transmission fails --
which, contrary to assertions to the opposite, is a very real scenario that
designs must handle.  The SignalList halts at the failure of the FSK, and
ringing will not be applied.  

All the best, 
Wayne

  _____  

Mail archive for TISPAN_WG3 can be browsed at the following url :

http://list.etsi.org/TISPAN_WG3.html <http://list.etsi.org/TISPAN_WG3.html> 

  _____  

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

---

From: Tom Taylor <[email-masked]>
Date: Thu, 05 May 2005 03:02:05 -0400

I will summarize this thread, and perhaps give a fresh start from the purely 
mechanical point of view.  The HTML in the previous series of messages has caused 
a number of them to be rejected recently because they were too large.

Issue 1: intent of the package as written.
------------------------------------------

Kevin is one of the authors of the package.  Bruno was also involved.  You have to 
believe them when they say, in Bruno's terms, that andisp/dwa was intended for use 
with incoming calls, andisp/data for other situations.  As Kevin points out, the 
examples bear out this intent.  It is reasonable that the ambiguity revealed by 
discussion on this list be corrected.

Issue 2: validity of the andisp/data method with embedded silence in the narrow sense
------------------------------------------

I believe the use of andisp/data with silence embedded in the data stream with 
subsequent separate alerting as Wayne Cutler first described it is technically 
valid in the narrow sense of conformity to the protocol syntax.  I also believe it 
is brittle, but that is a matter between the practitioners of this approach and 
their customer.

Issue 3: requirements of the package
------------------------------------------

No profile can change the following requirements on the MG that claims to support 
the andisp package:
   -- if the MG receives andisp/dwa, it will execute the data display and alerting 
in accordance with a default TAS stored on the MG;
   -- if the MG receives andisp/data without a TAS parameter, it will execute the 
data display in accordance with a default TAS stored on the MG.

The only way to evade these requirements is to define an alternative package. 
H.248 has provided an extensive private package space for this purpose, but of 
course, this is not helpful to interoperability.

Issue 4: provisioning on the MG versus the MGC
------------------------------------------

This is a major issue which threatens to be extremely costly to whichever side 
loses the argument.  Historically, there has always been tension between MG and 
MGC developers on the matter.  Historically the consensus has been to have the MG 
responsible for local characteristics, as Kevin has stated.  However, Chris Gallon 
has made three arguments for provisioning of terminal characteristics on the MGC:
   -- it provides operational flexibility for replacement of MG equipment;
   -- in situations where few MGCs control a very large number of MGs, the capital 
costs of the latter become dominant and every step must be taken to minimize that 
cost;
   -- the stimal package (and the spirit of V5 which motivated it) already imposes 
the need for the MGC to know the physical characteristics of the terminals.

The first two arguments are a question of "dollars and cents", in my Canadian 
terms.  The large-scale expansion of data on the MGC implied by the choice to 
provision terminal data there will increase the cost of the MGC while reducing its 
capacity.  (Handling more data and doing the display operation in two messages 
rather than one is bound to cost more processing time per call.)  It is a matter 
of calculation to determine the least costly configuration in a given network.

The third argument seems valid.  If you are going to do a literal 
re-implementation of V5 using H.248, you will end up with the same data 
architecture.  The initial decision to do this is a larger issue of "dollars and 
cents", of which the specific issue of TAS provisioning is only a part.

In the end, this is a commercial issue which cannot really be settled on this 
list.  I believe replicating the V5 architecture in H.248 is a mistake, because 
from the point of view of MGC vendors in particular it raises a wall between 
markets that do this and markets that adopt the alternative data architecture. 
However, the customer is always right, and we have to live with the consequences.

------------------------------------------

I have issued a private note on the final issue of permissible bounds of language 
on this list.

Tom Taylor