H.248 Implementors' Guide Additions V5 Update

Willy Reheul Willy.Reheul at ALCATEL.BE
Thu Apr 5 13:07:51 EDT 2001


Assume an analogue line Termination and the ring current circuitry -due
to some MG internal power branch going down- abruptly falls out.
There are two case now :

/1/. MG sends serviceChange to MGC. Method is 'forced'. Is the
connection associated with this Termination lost ? NO.
In this case -and I think many other examples can be given- I agree with
Paul that the standard is confusing and that it is better to delete the
phrase : "and any established connections associated with them were
lost".
Moreover -in my opinion- also the following sentences  <<At a minimum
the termination shall be subtracted from the context / The termination
serviceState should be "out of service">> should be removed from the
standard. After all it is up to the MGC to decide whether or not the
call must be released and whether or not the Termination is kept in or
out of service. In this particular example of 'ring current circuitry
failure' my MGC will for sure keep the call (ie will not subtract the
termination from the context) and will keep the termination in service
(because it is better to offer the subscriber only originating services
than to offer no services at all).
The standard should only say that MGC is responsible for cleaning up and
for service status change.

/2/. MG does not send serviceChange to MGC. Why not : because analogue
line terminations offer not just one -, but a variety of services
(originating services, terminating services, maybe different line
current feeds, pad switching, echo suppressing,.....), and since only
one of these failed, MG decided that this was not sufficient reason to
conclude that 'Service' has changed.
Where I want to come is that serviceChange 'forced' is -most probably-
only sent when the termination is completely dead (due to failure) or
will be killed (because maintenance, board replacement, repair,
upgrade,.... must be done on it). Then also the established connections
are lost. In all other cases MG does not send serviceChange to MGC but
reports errors/failures to some OAM System in the network. If all this
is true there is no need to change the text of the standard.

I hope case /2/ is the right interpretation of the standard.

When it concerns ephemeral terminations, I think the text in the
standard can also be confusing.

Regards,
Willy

Paul Rheaume wrote:
>
> Christian,
>
> I agree that the servicechange forced indicates that something is wrong
> it's just that the actual connections are not necessarily lost. This
> would occur when the problem is caused by a local equipment failure as
> opposed to a network failure.
>
> Instead of deleting the text may I suggest changing the text to read:
> "and any established connections associated with them may be lost".
>
> Regards,
> Paul
>
> Christian Groves wrote:
> >
> > G'Day Paul,
> >
> > I think that the servicechange forced really does indicate that
> > something is wrong so the connections may well be lost. So I'm a little
> > hesitant removing this text. It is correct that out-of-service indicates
> > the termination cannot be used for traffic and they may well be because
> > the termination has failed and lost any connection.
> >
> > I've forwarded this to the Megaco list for comment also.
> >
> > Regards, Christian
> >
> > Paul Rheaume wrote:
> > >
> > > Christian,
> > >
> > > Proposed change to section 7.2.8 ServiceChange, 2) Forced: delete the
> > > text "and any established connections associated with them were lost" so
> > > that the paragraph now reads:
> > >
> > > 2) Forced - indicates that the specified Terminations were taken out of
> > > service. The MGC is responsible for cleaning up the context (if any)
> > > with which the failed termination is associated. At a minimum the
> > > termination shall be subtracted from the context. The termination
> > > serviceState should be "out of service".
> > >
> > > Explanation: it is possible for the connection to still exist even if a
> > > termination is out of service. It does not matter if the connection
> > > associated with the termination is lost or not it only matters whether
> > > the termination is in service or out of service. From section 7.1.5
> > > Termination State Descriptor: "The state "out of service" indiates that
> > > the termination cannot be used for traffic."
> > >
> > > Regards,
> > > Paul
> > >
> > > Christian Groves wrote:
> > > >
> > > > G'Day all,
> > > >
> > > > I have come up with an interim version of the H.248 Implementors' Guide
> > > > Additions v5. It contains additional correction to ones reviewed at the
> > > > SG16 Launceston meeting.
> > > >
> > > > It can be found at:
> > > > ftp://standard.pictel.com/avc-site/Incoming/
> > > > filenames:
> > > > TD-xxx_H248_Implementors_Additions_v5.doc
> > > > TD-xxx_H248_Implementors_Additions_v5.pdf
> > > >
> > > > Please check it for correctness and that it contains the points
> > > > discussed on the list. There were also some corrections added that were
> > > > not discussed on the list. If you have an issue please propose a
> > > > solution giving the wording that you would like to see. As mentioned in
> > > > the introduction this document is liable to change until final approval.
> > > >
> > > > v4 was my own edition and was not published to any external network/list
> > > > so please don't look for it.
> > > >
> > > > Let the editor bashing begin.
> > > >
> > > > Cheers, Christian
> > > >
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list