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@mailbag.intel.com

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@mailbag.intel.com

Hi Christian,

Looks good to me. Thanks.

Paul

Christian Groves wrote:

G'Day Paul,

The text I currently have in the implementors' guide is: 2) Forced - indicates that the specified Terminations were taken abruptly out of service and any established connections associated with them may be lost. For non-Root terminations 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". For the root termination the MGC can assume that all connections are lost on the MG and thus can consider that all the terminations have been subtracted.

Is this OK? I believe the text "may be lost" is a fact because you are ensure of the state of the connection. I also believe the distinction between the root and other terminations is important.

Cheers, 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@mailbag.intel.com

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