[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Megaco] State of the termination after failure of a command.

Hi John,

See my comments below [FVL]

John Stock wrote:

Along this line of discussion, I was wondering about this case that provides
a twist -

- MGC receives a ring-in, and sends Add commands to MG with the al/ri signal
- The MG detects offhook before it receives the Add commands, resulting in a
Notify with al/of to the MGC.

The preferred result would probably be to connect the line with the incoming
call, as is done in traditional PSTN.  From the MGC's perspective, it just
receives the offhook after sending the Adds for the ringin, so it just
appears that the line is answering the ring.

[FVL] The preferred result depends on the operator. Sometimes the terminating
call has a higher priority, but in other cases it is originating priority.
The Notify received by the MGC tells the context to which the termination belonged,
so the MGC will know if it has been before applying ringing (termination in the NULL
context) or after it (termination in the new context created by the Add) and it will be
able to act accordingly.
 
 

However the MG now is in a quandary.  It should accept the Add commands from
the MGC, possibly along with the al/ri signal.  However you don't want to
apply ringing to a line that's offhook, especially since the MGC will not
know to give any indication to the MG to stop ringing.  The MGC thinks the
MG already stopped ringing due to the offhook event, however in the MG the
offhook event preceded the ring signal.

[FVL] If the al/ri is applied after the off hook, then I think that the MGC can indicate the MG
to stop ringing immediately.
 

So the MG cannot apply this signal, due to its knowledge of the line state,
and not due to any network or resource failures.

Thus does the MG fail the ring signal?  If so, does this mean the Add
commands (in which the signal is embedded) also fail?  What would be the
value of the error descriptor (I couldn't find one that applies)?
 

[FVL] In any case I think that the MG does not have to send an error although the
situation is not coherent. It is up to the MGC to restore a good state.
 
It seems in this case it may be appropriate for the MG to decide what is
considered a failure, and just accept the ring signal even though it doesn't
actually apply it.  There are other ways to handle it too, like sending a
Signal Completion event to the MGC, though this requires the MGC to ask for
it in the Events descriptor.

Thanks,
John


Regards
Fernando
 

 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, October 21, 2002 8:12 AM
To: Anil Jangam; Terry L Anderson; Raphael Tryster
Cc: Tom-PT Taylor; megaco@ietf.org; SHRI KUMAR
Subject: RE: [Megaco] State of the termination after failure of a
command.

More comments inline. [KJBII]

Kevin

-----Original Message-----
From: Anil Jangam [mailto:anilj@mahindrabt.com]
Sent: Monday, October 21, 2002 10:43 AM
To: Terry L Anderson; Raphael Tryster
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; megaco@ietf.org; SHRI KUMAR; Boyle,
Kevin [NCRTP:3R90:EXCH]
Subject: Re: [Megaco] State of the termination after failure of a command.

Hi Terry,

see inline... headed with [anil].

/anil.

----- Original Message -----
From: "Terry L Anderson" <tlatla@verizon.net>
To: "Raphael Tryster" <raphael@tdsoft.com>
Cc: "Tom-PT Taylor" <taylor@nortelnetworks.com>; "'Anil Jangam'"
<anilj@mahindrabt.com>; <megaco@ietf.org>; "SHRI KUMAR"
<manikaran1947@yahoo.co.in>; "Kevin Boyle" <kboyle@nortelnetworks.com>
Sent: Monday, October 21, 2002 5:59 PM
Subject: Re: [Megaco] State of the termination after failure of a command.

> I am not sure that we would want to make a narrow exception to the
> general principle just for signals.  I think if any descriptor "fails"
> then the command fails.  But that being said we DO have to be careful
> of what is considered a failure.  There are certainly things that can
> fail about a signal well after the signal has begun playing that I
> would not consider a error of the descriptor, just as failure of the
> network is not an error in the Local/Remote descriptors.
>
[anil] I disagree to your approach. I think detecting something that has
failed (say network failure) and doing nothing is of no use. What standard
says about restoring the state of the Termination is the corrective mesures
to be taken in case of the failure conditions. What is you have mentioned
about accepting the descriptor (in other words validating the descriptor) is
just a preventive measure. We have to take some actions when something goes
wrong.
[KJBII] Actually, you don't.  It is the prerogative of the MGC to clean up
after errors as it sees fit.  The MG should "as far as possible" restore the
previous state, and then wait for the MGC to act.  Autonomous cleanup by the
MG will most certainly lead to state mismatches between the MG and MGC.

> In the specific case you raise, I would expect that the MG should
> "reserve resources" for all signals when it accepts the descriptor.
> If it has no ability to play cg/bt because it is not implemented or
> some other resource limit as known at the time the descriptor is
> received, then I would expect it to return an error failing the entire
> command.  On the other hand, if (as far as it knows when the
> descriptor is
> received) it can play them, it should return success immediately and
> notify in any other appropriate way (if events are set) about any sort
> of later failure.
>
[anil] I agree that once the validation (i.e. preventive measure) is done,
you ask for the notification reporting the status of the execution. Say in
the end, the execution of the signal has failed, then we can not leave it as
it is. Take an example of call hold scenario. If you (the controlling leg)
have toggled from one party to other, you would normally remove the hold
tone on held party/termination and play hold tone on the active
party/termination. Now you move from one context to another. Mean time the
removal of the hold tone on the held party has failed, and still you try to
talk to it, then what you (MG) would do???? In this case, can't we call the
above failure condition as failure of the descriptor, and would try to
restore (i.e. corrective measure) the state to the previous state???
[KJBII] You would hook the two parties up, and continue with the service.
If the MGC asked for notification of signal completion for held tone, then
the MG will send that notification to the MGC.  Otherwise, the MG should not
take ANY action on it's own, without explicit direction from the MGC.

/anil.

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL