Subject: Re: [Megaco] CAS suspend/resume processing

From: Tom Taylor <[email-masked]>
Date: Wed, 28 May 2003 16:07:40 -0400

OK, that's consistent with the Q.699 diagram.  What it says is that in the 
CAS-to-ISUP direction, suspend is initiated by receipt of a Clearback signal, resume 
by a new Answer signal.  I see nothing that needs to be standardized at the Megaco 
level for this one.  It's not so clear what happens in the opposite direction, and 
maybe that's the source of your difficulty.

Aleksandr Ryabin wrote:
> ITU-T Q.764 par 2.4 "Suspend, resume", page 30.
>         Aleks
> 
> At 03:04 PM 5/28/2003, Tom Taylor wrote:
> 
>> I was looking for a standard describing the interworking you are 
>> trying to gain support for.  So far I've found one relevant figure in 
>> Q.699 and the logic diagrams in e.g. Q.655.  Do you have any more 
>> precise references?
>>

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

---

From: Tom Taylor <[email-masked]>
Date: Wed, 28 May 2003 16:07:40 -0400

---

From: Tom Taylor <[email-masked]>
Date: Wed, 28 May 2003 16:18:32 -0400

Found the complete answer in Q.695.  Suspend <-> Clearback and Resume <-> 
(re)Answer.  This doesn't seem to require anything new in the package documentation 
so long as Clearback and Answer signals and events have been defined.

Aleksandr Ryabin wrote:
>>> Please see comments inline [AR].
>>>         Aleks
>>> At 12:50 PM 5/28/2003, Kevin Boyle wrote:
>>>
>>>> Comments inline. [KJBII]
>>>>
>>>> Kevin
>>>>
>>>>     -----Original Message-----
>>>>     From: Aleksandr Ryabin [mailto:[email-masked]]
>>>>     Sent: Wednesday, May 28, 2003 12:25 PM
>>>>     To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]; 
>>>> [email-masked]
>>>>     Subject: RE: [Megaco] CAS suspend/resume processing
>>>>
>>>>     At 11:28 AM 5/28/2003, Kevin Boyle wrote:
>>>>
>>>>>         A few comments:
>>>>>
>>>>>         1. H.248 is not MGCP.  We do not have any reason to make
>>>>>         H.248 behave or look like MGCP.  So, the "MGCP does X"
>>>>>         argument is irrelevant.
>>>>
>>>>
>>>>
>>>>     The intention of the quote was to describe call suspend/resume
>>>>     processing and has nothing to do with "MGCP does X"
>>>>     In my very first email in the thread I explicitly stated that, but
>>>>     apparently the need to quote was still necessary
>>>>     as after all these emails it seem that there was still confusion
>>>>     on what I'm taking about.
>>>>
>>>>>         2. The bcas packages are meant to address the functionality
>>>>>         of CAS.  Remember that a CAS trunk has two wires with which
>>>>>         to do line signaling.  This means there are four states --
>>>>>         addressed in bcas by Seize, Seize Ack, Answer and Idle.  It
>>>>>         seems to me that any line signaling can therefore be done
>>>>>         using the package.  This "resume" line signal MUST align to
>>>>>         one of the four line signals by definition.
>>>>
>>>>
>>>>
>>>>     CAS trunks *can* have upto 4 supervisory bits and in no way 4
>>>>     events can cover all 16 bit sets,
>>>>     for example, Inidia registered CAS signalling uses 3 forward bits
>>>>     and 2 backward.
>>>>     Also "events" do not strictly correspond to a specific bit set,
>>>>     something else can be a mean contribution to event,
>>>>     for example, time constraints (e.g. rbs/pson, rbs/psoff, or
>>>>     metering pulse, which by the way is not defined
>>>>     as event/signal, but should be).
>>>>     [KJBII] *Basic* CAS has only 2 bits.  R2 has 4 -- in which case
>>>>     you need the icas packages. Are we addressing a *basic* CAS
>>>>     function, or an R2 function?  If it is something needed in R2, we
>>>>     can talk about including it in icas.
>>>
>>>
>>> [AR] We are addressing *basic* CAS to ISUP suspend/resume mapping 
>>> function.
>>>
>>>>>     I would prefer we address the requirements set forth by CAS
>>>>>     signaling directly, and avoid depending upon the implementation
>>>>>     of a particular requirement under a different protocol.
>>>>
>>>>
>>>>
>>>>     That was exactly the intention for starting this email thread.
>>>>     I understand that suspend/resume is not defined in CAS protocol
>>>>     itself,
>>>>     but I'd think that pretty much any softswitch which does CAS also
>>>>     would have
>>>>     to bridge ISUP (where resume/suspend is defined) with CAS and that
>>>>     is why,
>>>>     I think, the authors of MGCP CAS package decided it is quite
>>>>     appropriate
>>>>     to define such procedures in scope of package. Yes, I know, "MGCP
>>>>     does X"
>>>>     argument is irrelevant, but they (the authors of MGCP CAS package)
>>>>     did put
>>>>     some thought in it and we should not need to reinvent a bike.
>>>>     [KJBII] Except their solution is tailored specifically to MGCP,
>>>>     and so does not apply here. I would say that an MGC that has to
>>>>     handle bridging ISUP to CAS should know how to do that function
>>>>     within the context of the defined protocol.  This may not require
>>>>     a package-based solution -- e.g., don't tear down the CAS side of
>>>>     the call in the first place, so you are reattached the instant the
>>>>     ISUP resumes.
>>>
>>>
>>> [AR] We are taking about resume from CAS side, after it suspended 
>>> (placed on-hook) call.
>>> MG still needs support of the protocol to communicate resume/seize 
>>> from CAS side to MGC,
>>> and MG must be aware such state possibility, (e.g. sending seize when 
>>> trunk is not idle both ways),
>>> otherwise MG will send bcas/casf {ec=SME }. This clearly calls at 
>>> least for "procedure" definition.
>>> This procedure can ether be addressed as a separate draft, or folded 
>>> into base draft.
>>> I see no harm in folding this procedure into base draft.
>>>
>>>>     I have a problem on hand and I brought it to the list to insure
>>>>     compatibility.
>>>>     Is it just me, or are there other folks who also think this is
>>>>     relevant?
>>>>     otherwise I'll just shut up and deal with it as a "specific
>>>>     implementation" need :)
>>>>
>>>>             Aleks
>>>>
>>>>>
>>>>>         Kevin
>>>>>
>>>>>         [KJBII] snip!
>>
>>
> 
>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 28 May 2003 16:18:32 -0400

---

From: Vance Shipley <[email-masked]>
Date: Wed, 28 May 2003 16:28:39 -0400

As there is no CAS "suspend" or "resume" the issue becomes whether
or not the MG must understand a call state of "suspended" to make
it possible to provide the intended functionality.  Since the
timing required in processing the suspend/resume is in the order 
of tens of seconds I'd say not.

	-Vance

On Wed, May 28, 2003 at 04:07:40PM -0400, Tom Taylor wrote:
}  OK, that's consistent with the Q.699 diagram.  What it says is that in the 
}  CAS-to-ISUP direction, suspend is initiated by receipt of a Clearback 
}  signal, resume by a new Answer signal.  I see nothing that needs to be 
}  standardized at the Megaco level for this one.  It's not so clear what 
}  happens in the opposite direction, and maybe that's the source of your 
}  difficulty.
}  
}  Aleksandr Ryabin wrote:
}  >ITU-T Q.764 par 2.4 "Suspend, resume", page 30.
}  >        Aleks
}  >
}  >At 03:04 PM 5/28/2003, Tom Taylor wrote:
}  >
}  >>I was looking for a standard describing the interworking you are 
}  >>trying to gain support for.  So far I've found one relevant figure in 
}  >>Q.699 and the logic diagrams in e.g. Q.655.  Do you have any more 
}  >>precise references?
}  >>
}  
}  _______________________________________________
}  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: Vance Shipley <[email-masked]>
Date: Wed, 28 May 2003 16:28:39 -0400

-Vance

---

From: Tom Taylor <[email-masked]>
Date: Wed, 28 May 2003 16:48:42 -0400

That seems right: the MGC should be responsible for managing ISUP Timer T6.  And 
BTW, the reference I found was Q.696, not Q.695.

Just to summarize in terms of Aleksandr's original point: if you're talking an 
analogue line working into ISUP, you're talking on-hook/off-hook events as in Annex 
E.  If you're talking CAS signalling, you use the CAS packages to detect or signal 
Clearback and Answer.  In either case the MGC is responsible for the interworking 
and the applicable standard is Q.696 rather than the CAS package documentation.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 28 May 2003 16:48:42 -0400

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 28 May 2003 16:56:07 -0400

Yes, now it makes sense.
Although a call flow example would be nice, that is to be added to the
package spec which show that it will be Answer event.

As a side note, all call flow examples in the draft stop after call is 
answered,
IMO it would be cleaner is they continue with termination.

Thanks.
         Aleks

At 04:48 PM 5/28/2003, Tom Taylor wrote:
>That seems right: the MGC should be responsible for managing ISUP Timer 
>T6.  And BTW, the reference I found was Q.696, not Q.695.
>
>Just to summarize in terms of Aleksandr's original point: if you're 
>talking an analogue line working into ISUP, you're talking 
>on-hook/off-hook events as in Annex E.  If you're talking CAS signalling, 
>you use the CAS packages to detect or signal Clearback and Answer.  In 
>either case the MGC is responsible for the interworking and the applicable 
>standard is Q.696 rather than the CAS package documentation.
>
>Vance Shipley wrote:
>>timing required in processing the suspend/resume is in the order of tens 
>>of seconds I'd say not.
>>         -Vance
>>}  OK, that's consistent with the Q.699 diagram.  What it says is that in 
>>the }  CAS-to-ISUP direction, suspend is initiated by receipt of a 
>>Clearback }  signal, resume by a new Answer signal.  I see nothing that 
>>needs to be }  standardized at the Megaco level for this one.  It's not 
>>so clear what }  happens in the opposite direction, and maybe that's the 
>>source of your }  difficulty.
>>}
>>}  >>trying to gain support for.  So far I've found one relevant figure 
>>in }  >>Q.699 and the logic diagrams in e.g. Q.655.  Do you have any more 
>>}  >>precise references?
>>}  >>
>>}

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 28 May 2003 16:56:07 -0400

Yes, now it makes sense.

Thanks.
         Aleks