Subject: Re: H.248 Implementors' Guide Additions V5 Update

From: Christian Groves <[email-masked]>
Date: Mon, 02 Apr 2001 10:32:23 +1000

Hello Peter,

The change bars in v5 are relative to the decided version of H.248.

There is an Approved Implementors' Guide which you should look at see
td-plen 39 from the Geneva 12/00 SG16 meeting. It contains approved
changes up until the 12/00. The implementors' guide additions v5
contains non-approved changes from 12/00 until now.

Regards, Christian

"Blatherwick, Peter" wrote:
> 
> Hi Christian:
> 
> Quick questions (apologies if I have just been out of
> the loop for too long).
> 
> - What are the change bars in v5 relative to?
> 
> - Is there a complete Implementors Guide to look at,
>   including proposed additions.  If not, where can I
>   locate the latest version that the proposed additions
>   would apply to?
> 
> Cheers,
> Peter Blatherwick
> 
> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 23:28
> To: megaco ietf; SG16
> Subject: H.248 Implementors' Guide Additions V5 Update
> 
> 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

---

From: "Alf Heidermark (UAB)" <[email-masked]>
Date: Mon, 2 Apr 2001 08:53:32 +0200

How do I reference this implementors guide. 

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: den 2 april 2001 02:32
To: Blatherwick, Peter
Cc: megaco ietf; SG16
Subject: Re: H.248 Implementors' Guide Additions V5 Update

Hello Peter,

Regards, Christian

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 10 Apr 2001 12:59:41 -0400

On review, I agree that we should not have put in the phrase "and any
established connections associated with them were lost" -- that is putting
too explicit a physical interpretation on the condition.  On the other hand,
I believe the intended meaning would be conveyed if we replaced that phrase
with: "and the MGC cannot further rely on that termination to support media
flows, signals, or events".  Given that intention, I'd say the MGC has
little choice but to do what the spec. calls for: take the termination out
of its current context.  I suppose one could argue that this should be
"should" rather than "shall", but does it matter enough to make the change?

> From: Willy Reheul [mailto:[email-masked]]
> Sent: Thursday, April 05, 2001 1:08 PM
> To: Paul Rheaume
> Cc: Christian Groves; [email-masked]; megaco ietf
> 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,
> > > > >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > For help on this mail list, send "HELP ITU-SG16" in a 
> message to
> > > > > [email-masked]
>