4 May 2005 18:09
ALCATEL view; RE: interpretation of H.248.23 andisp package andthedwa /datasignals
<Albrecht.Schwarz <at> alcatel.de>
2005-05-04 16:09:28 GMT
2005-05-04 16:09:28 GMT
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: <megaco <at> ietf.org>
<jan.lindquist <at> er cc: TISPAN_WG3 <at> LIST.ETSI.ORG
icsson.com> Subject: RE: [Megaco] interpretation of H.248.23 andisp package andthedwa
Sent by: /datasignals
megaco-bounces <at> 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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of
Kevin Boyle
Sent: den 29 april 2005 21:18
To: Dal Chohan; 'Wayne Cutler'
Cc: TISPAN_WG3 <at> LIST.ETSI.ORG; megaco <at> ietf.org
Subject: RE: [Megaco] interpretation of H.248.23 andisp package andthedwa
/datasignals
More comments inline. [KJBII]
Kevin
From: Dal Chohan [mailto:D.Chohan <at> ftel.co.uk]
Sent: Friday, April 29, 2005 1:11 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Wayne Cutler'
Cc: TISPAN_WG3 <at> LIST.ETSI.ORG; megaco <at> ietf.org
Subject: RE: [Megaco] interpretation of H.248.23 andisp package
andthedwa /datasignals
Comments in-line
Dal.
From: Kevin Boyle [mailto:kboyle <at> nortel.com]
Sent: 29 April 2005 15:03
To: Wayne Cutler; D.Chohan <at> ftel.co.uk
Cc: TISPAN_WG3 <at> LIST.ETSI.ORG; megaco <at> ietf.org;
megaco-bounces <at> ietf.org
Subject: RE: [Megaco] interpretation of H.248.23 andisp package
andthedwa /datasignals
Comments inline. [KJBII]
Kevin
From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org]
On Behalf Of Wayne Cutler
Sent: Friday, April 29, 2005 4:07 AM
To: D.Chohan <at> ftel.co.uk
Cc: TISPAN_WG3 <at> LIST.ETSI.ORG; megaco <at> ietf.org;
megaco-bounces <at> ietf.org
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
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
RSS Feed