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

From: John Stock <[email-masked]>
Date: Tue, 28 Jan 2003 17:20:47 -0800

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.

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.

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)?

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

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Monday, October 21, 2002 8:12 AM
To: Anil Jangam; Terry L Anderson; Raphael Tryster
Cc: Tom-PT Taylor; [email-masked]; 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:[email-masked]] 
Sent: Monday, October 21, 2002 10:43 AM
To: Terry L Anderson; Raphael Tryster
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; 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" <[email-masked]>
To: "Raphael Tryster" <[email-masked]>
Cc: "Tom-PT Taylor" <[email-masked]>; "'Anil Jangam'"
<[email-masked]>; <[email-masked]>; "SHRI KUMAR"
<[email-masked]>; "Kevin Boyle" <[email-masked]>
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: John Stock <[email-masked]>
Date: Wed, 29 Jan 2003 08:56:09 -0800

Thanks for your description and correction - I forgot the context ID would
be different for the two offhook cases.
 
W/regards to the incoming vs. outgoing priority, I had heard this was an
operator-provisionable option in the V5.N protocol (non-North America).  In
the North American GR303 protocol it is not provisionable, at least as it
affects the Q.931 (resource management) part of the protocol; internally in
the Class 5 switch I'm not sure about.  Like you say this is the MGC's
concern though.
 
Thanks,
John

-----Original Message-----
From: Fernando Vallejo Lazaro [mailto:[email-masked]]
Sent: Wednesday, January 29, 2003 2:15 AM
To: John Stock
Cc: 'Kevin Boyle'; Anil Jangam; Terry L Anderson; Raphael Tryster; Tom-PT
Taylor; [email-masked]; SHRI KUMAR
Subject: Re: [Megaco] State of the termination after failure of a command.

Hi John, 

See my comments below [FVL] 

John Stock wrote: 

a twist - 

[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. 

[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. 

[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. 

Thanks, 
John

Regards 
Fernando 

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

Kevin 

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

Hi Terry, 

/anil. 

----- Original Message ----- 
From: "Terry L Anderson" <[email-masked]> 
To: "Raphael Tryster" <[email-masked]> 
Cc: "Tom-PT Taylor" <[email-masked]>; "'Anil Jangam'" 

/anil. 

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

_______________________________________________ 
Megaco mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
_______________________________________________ 
Megaco mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> 

-- 

Fernando Vallejo Lazaro

Phone:  +34 91 330 8279

SW  Wireline ASD-Madrid

       ALCATEL

---

From: John Stock <[email-masked]>
Date: Wed, 29 Jan 2003 08:56:09 -0800

Thanks,
John

-----Original Message-----
From: Fernando Vallejo Lazaro [mailto:[email-masked]]
Sent: Wednesday, January 29, 2003 2:15 AM
To: John Stock
Cc: 'Kevin Boyle'; Anil Jangam; Terry L Anderson; Raphael Tryster; Tom-PT

Hi John, 

John Stock wrote: 

a twist - 

  

Thanks, 
John

Regards 
Fernando 

-----Original Message----- 

Kevin 

-----Original Message----- 

Hi Terry, 

/anil. 

----- Original Message ----- 
From: "Terry L Anderson" <[email-masked]> 
To: "Raphael Tryster" <[email-masked]> 
Cc: "Tom-PT Taylor" <[email-masked]>; "'Anil Jangam'" 

/anil. 

-- 

Fernando Vallejo Lazaro

Phone:  +34 91 330 8279

SW  Wireline ASD-Madrid

       ALCATEL