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

From: Chris Gallon <[email-masked]>
Date: Tue, 03 May 2005 14:14:45 +0100

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.

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.

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.

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.

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.

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.

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.

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.

Regards

Chris Gallon.

Kevin Boyle wrote:

> 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
>
>     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.
>
>     [Dal]  I dont 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 Im glad to see that you at least agree that this method
>     doesnt 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.
>
>     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.
>
>     [Dal]  If the MGC requests the MG to apply an FSK signal, then
>     there is no reason why the MG wouldnt 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?
>
>     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.
>
>     [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 wasnt initially envisaged to work like this
>     doesnt 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
>
>         ------------------------------------------------------------------------
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/megaco
>  
>

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 3 May 2005 09:55:08 -0400

Comments inline. [KJBII]

Jan has asked a particular question -- I suggest we see how many speak up.
I have already answered his question.

Kevin

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

  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.

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.

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.

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.

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!  

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.

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.

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?

Regards

Chris Gallon.

---

From: "Wayne Cutler" <[email-masked]>
Date: Tue, 3 May 2005 16:02:52 +0100

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

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

All the best,
Wayne

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 3 May 2005 17:26:22 -0400

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]; [email-masked]
Subject: RE: [Megaco] interpretation of H.248.23 andisp packageandthedwa /
data signals

Hi Kevin, 

  Kevin, 

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

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

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

[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"? 

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

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

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

[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

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 4 May 2005 15:56:43 -0400

Comments inline. [KJBII]
 
Kevin

  _____  

From: Chris Gallon [mailto:[email-masked]] 
Sent: Wednesday, May 04, 2005 5:31 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Wayne Cutler
Cc: Dal Chohan; [email-masked]; [email-masked]
Subject: 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. 
[KJBII] It *is* the domain of SG16 to define how the protocol works, which
is really what you are arguing.  If the network operator doesn't like the
way the protocol works, they can choose a different protocol.  I don't
believe Fujitsu is a network operator.  The only network operator we've
heard from on this issue thus far is France Telecom.
 
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).
[KJBII] Another problem with the new attempted definition: Set notify
completion for TO and IBE on the FSK signal in the SignalList as proposed.
The FSK plays, but the 200 ms timer does NOT complete before offhook occurs
in the MG and halts the signal.  The MG sends up g/sc with IBE as the
reason.  However, the FSK transmission had already COMPLETED and is being
displayed on the set.  So the indication that the FSK did not complete is
actually not true.  This is yet another inconsistency with this proposed
methodology.
 
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. 
[KJBII] Again, I have seen no technical reason for allowing the MGC to
control the TAS, other than that is what you want.  I have shown that it is
actually technically degrading to the system, since it undoes the
fundamental decomposition of the MGC-MG that under which the H.248 protocol
was defined to function. 

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.
[KJBII] I haven't seen anything, except the dependence upon failure path
resignalling, to address any of the shortcomings in your methodology.  The
resignalling adds a roundtrip delay to ringing the terminal, as well as
additional processing time on the MGC and MG.  Any existing standards the
proscribe maximum timings for alerting the set upon call presentation are in
potential jeopardy with this methodology.  The methodology set forth in
H.248.23 allows the alerting to occur without the need for two additional
messages and the associated processing time and messaging latency.

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, 

  Kevin, 

All the best, 
Wayne