Subject: RE: Providing Ringback from the Calling MG versus the Called MG

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 1 May 2001 14:15:25 -0400

Megaco the protocol is designed so that it can support "local" ringback, 
or "remote" (in band) ringback.  A given set of implementations have 
to have consistent assumptions about that to work.  This is the stuff 
profiles are made of.

Some examples:

The MG implements the ringback signal towards the ephemeral
	the near MG hears it from the far MG inband

The MG implements the ringback signal towards the external
	(physical) interface, the local device hears it directly

Neither MG implements ringback.  There is a tones and announcements
generator that generates ringback.  When the line is answered, the
MGC instructs the "near" MG to switch it's media flow from the
tones and announcements server to the far MG

Megaco can support all of these models.

Brian

> -----Original Message-----
> From: Paul W. Roder [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2001 1:52 PM
> To: [email-masked]
> Subject: Providing Ringback from the Calling MG versus the Called MG
> 
> 
> 
> 
> On 4/24/2001 Dave Sclarsky wrote, in "RE: Mode Property for a 
> Termination",
> 
> "As to your question about mode, well, in the Megaco model, 
> it is not the
> 'terminating exchange' (remote MG?) that plays ringback.  
> Look at the Modify
> for A4444 in step 16.  Here the MGC tells the caller's MG to 
> play ringback
> locally, using the signal cg/rt.  Here both physical terminations are
> initially set to sendReceive.  The ephemeral on the calling 
> side is set to
> receive, and the ephemeral on the called side is set to 
> sendReceive.  The
> MGC doesn't set the calling side's ephemeral to sendReceive 
> until the called
> party goes off hook."
> 
> I wanted to clarify one point that Dave made about which MG 
> or 'exchange'
> provides ringback (also known as "inband audible ringing") to 
> the calling party.
> Dave said that  "in the Megaco model it is not the 
> 'terminating exchange'
> (remote MG?) that plays ringback", and that the caller's MG 
> plays ringback
> locally
> based on MGC instruction.
> 
> My understanding was that the ringback signal could be 
> provided by the calling
> party's MG (as in the Appendix A Example Call Flows), the 
> called party's MG
> (if the called party were served by an MG) or by a called 
> switch in the
> PSTN/GSTN, if the call terminated there after leaving the 
> VoIP or VoATM network
> through a
> "Trunk Gateway" MG.   In each case, the MGC would have to 
> determine where the
> ringback signal should come from and send instructions to the 
> calling and called
> party MGs accordingly.
> 
> For example, if the MGC determined that ringback should come 
> from the called
> party's PSTN switch, it could set the calling party MG's 
> ephemeral termination
> to "Receive Only" and the called party MG's ephemeral and 
> physical terminations
> to "Send/Receive" (where the physical termination is a TDM 
> PSTN trunk on the
> PSTN side of the called MG), in anticipation of an inband 
> audible ringing tone
> or called network announcement being returned by that called 
> PSTN switch.
> 
> I realize that there are advocates of having the calling 
> party's MG always
> generate ringback, and others (like me) who advocate having 
> it generated by the
> called party's MG or by the called PSTN switch.  But the key 
> point is that
> Megaco does not require that the ringback signal be provided 
> by the calling
> party's MG.  The ringback or ring tone signal (cg/rt) is 
> defined as part of the
> Call Progress Tones Generator Package in Annex E,  and Annex 
> E does not dictate
> which MG (calling, called, or neither) is responsible for 
> generating it.
> 
> There are reasons for having the called party MG/PSTN switch 
> generate the
> ringback signal on calls to PSTN, such as 1) allowing for 
> in-band tones and
> announcements to be passed back before answer from the called 
> PSTN switch to the
> calling party, without having the calling MG apply a ringback 
> signal on top of
> them, and 2) ensuring that there is a  voice path "cut 
> through" from the called
> party back to the calling party before the call is answered. 
> If this path is not
> cut-through, the called party could answer the call, say 
> "Hello?", and get no
> response, since the calling MG is still waiting for an answer 
> indication from
> the MGC (which may be lost or delayed), playing the ringback 
> tone to the calling
> party, and not passing the inband voice information on to the 
> calling party.
> (Note: In North American PSTNs today, the ringback signal is 
> typically generated
> by the called switch instead of the called switch for these reasons.)
> 
> So - isn't it more accurate to say that in the Megaco model, 
> the ringback tone
> can be generated by the calling MG, the called MG, or a 
> remote PSTN switch? I
> think that the use of the calling MG in the Example Call 
> Flows is a legitimate
> example, but it's not the only Megaco-compliant way of 
> sending ringback to the
> calling party.
> 
> Paul Roder
> Telcordia Technologies
> [email-masked]
> 
> 
> 
> 
> 
> Dave Sclarsky <[email-masked]> on 04/24/2001 10:19:10 AM
> 
> To:   "'Sarju Garg'" <[email-masked]>, [email-masked]
> cc:    (bcc: Paul W. Roder/Telcordia)
> Subject:  RE: Mode Property for a Termination
> 
> 
> 
> 
> Sarju,
> 
> Yes, the example call flow isn't perfect (e.g. in step 17, 
> the reply from
> MGC uses NULL context even though the transaction used context 5000).
> 
> As to your question about mode, well, in the Megaco model, it 
> is not the
> 'terminating exchange' (remote MG?) that plays ringback.  
> Look at the Modify
> for A4444 in step 16.  Here the MGC tells the caller's MG to 
> play ringback
> locally, using the signal cg/rt.  Here both physical terminations are
> initially set to sendReceive.  The ephemeral on the calling 
> side is set to
> receive, and the ephemeral on the called side is set to 
> sendReceive.  The
> MGC doesn't set the calling side's ephemeral to sendReceive 
> until the called
> party goes off hook.
> 
> One other important point is that signals are NOT affected by 
> Mode.  The MGC
> could have left the calling physical termination as inactive and still
> played ringback (or busy, or whatever)!
> 
> DaveS.
> RadiSys Corporation [formerly S-Link Corp.]
> 
> -----Original Message-----
> From: Sarju Garg [mailto:[email-masked]]
> Sent: Tuesday, April 24, 2001 7:38 AM
> To: [email-masked]
> Subject: Mode Property for a Termination
> 
> 
> Hi Lists,
> 
> I have a query related to the call flow (Appendix A section 
> A.1.2 step 12)
> shown in the H.248 document. Why is the mode of the 
> termination A4444 not
> set to sendonly? Since the default state is inactive, then 
> how will the
> caller hear the RBT applied by the terminating exchange (if 
> mode!=sendonly)?
> Also mode in step 3 is set to send/recv. Why is that so? We 
> do not need to
> set mode now. Let it be inactive and change mode only in step 
> 12 to sendonly
> TIA
> Sarju
> 
> 
> 
>

---

From: Dave Sclarsky <[email-masked]>
Date: Tue, 1 May 2001 15:48:48 -0400

Paul,

You are absolutely correct.  I should have said:

...it is not "necessarily" the 'terminating exchange'...

Sorry if I implied that it couldn't be!

DaveS.

-----Original Message-----
From: Paul W. Roder [mailto:[email-masked]]
Sent: Tuesday, May 01, 2001 1:52 PM
To: [email-masked]
Subject: Providing Ringback from the Calling MG versus the Called MG

On 4/24/2001 Dave Sclarsky wrote, in "RE: Mode Property for a Termination",

"As to your question about mode, well, in the Megaco model, it is not the
'terminating exchange' (remote MG?) that plays ringback.  Look at the Modify
for A4444 in step 16.  Here the MGC tells the caller's MG to play ringback
locally, using the signal cg/rt.  Here both physical terminations are
initially set to sendReceive.  The ephemeral on the calling side is set to
receive, and the ephemeral on the called side is set to sendReceive.  The
MGC doesn't set the calling side's ephemeral to sendReceive until the called
party goes off hook."

I wanted to clarify one point that Dave made about which MG or 'exchange'
provides ringback (also known as "inband audible ringing") to the calling
party.
Dave said that  "in the Megaco model it is not the 'terminating exchange'
(remote MG?) that plays ringback", and that the caller's MG plays ringback
locally
based on MGC instruction.

My understanding was that the ringback signal could be provided by the
calling
party's MG (as in the Appendix A Example Call Flows), the called party's MG
(if the called party were served by an MG) or by a called switch in the
PSTN/GSTN, if the call terminated there after leaving the VoIP or VoATM
network
through a
"Trunk Gateway" MG.   In each case, the MGC would have to determine where
the
ringback signal should come from and send instructions to the calling and
called
party MGs accordingly.

For example, if the MGC determined that ringback should come from the called
party's PSTN switch, it could set the calling party MG's ephemeral
termination
to "Receive Only" and the called party MG's ephemeral and physical
terminations
to "Send/Receive" (where the physical termination is a TDM PSTN trunk on the
PSTN side of the called MG), in anticipation of an inband audible ringing
tone
or called network announcement being returned by that called PSTN switch.

I realize that there are advocates of having the calling party's MG always
generate ringback, and others (like me) who advocate having it generated by
the
called party's MG or by the called PSTN switch.  But the key point is that
Megaco does not require that the ringback signal be provided by the calling
party's MG.  The ringback or ring tone signal (cg/rt) is defined as part of
the
Call Progress Tones Generator Package in Annex E,  and Annex E does not
dictate
which MG (calling, called, or neither) is responsible for generating it.

There are reasons for having the called party MG/PSTN switch generate the
ringback signal on calls to PSTN, such as 1) allowing for in-band tones and
announcements to be passed back before answer from the called PSTN switch to
the
calling party, without having the calling MG apply a ringback signal on top
of
them, and 2) ensuring that there is a  voice path "cut through" from the
called
party back to the calling party before the call is answered. If this path is
not
cut-through, the called party could answer the call, say "Hello?", and get
no
response, since the calling MG is still waiting for an answer indication
from
the MGC (which may be lost or delayed), playing the ringback tone to the
calling
party, and not passing the inband voice information on to the calling party.
(Note: In North American PSTNs today, the ringback signal is typically
generated
by the called switch instead of the called switch for these reasons.)

So - isn't it more accurate to say that in the Megaco model, the ringback
tone
can be generated by the calling MG, the called MG, or a remote PSTN switch?
I
think that the use of the calling MG in the Example Call Flows is a
legitimate
example, but it's not the only Megaco-compliant way of sending ringback to
the
calling party.

Paul Roder
Telcordia Technologies
[email-masked]

Sarju,

Yes, the example call flow isn't perfect (e.g. in step 17, the reply from
MGC uses NULL context even though the transaction used context 5000).

As to your question about mode, well, in the Megaco model, it is not the
'terminating exchange' (remote MG?) that plays ringback.  Look at the Modify
for A4444 in step 16.  Here the MGC tells the caller's MG to play ringback
locally, using the signal cg/rt.  Here both physical terminations are
initially set to sendReceive.  The ephemeral on the calling side is set to
receive, and the ephemeral on the called side is set to sendReceive.  The
MGC doesn't set the calling side's ephemeral to sendReceive until the called
party goes off hook.

One other important point is that signals are NOT affected by Mode.  The MGC
could have left the calling physical termination as inactive and still
played ringback (or busy, or whatever)!

DaveS.

-----Original Message-----
From: Sarju Garg [mailto:[email-masked]]
Sent: Tuesday, April 24, 2001 7:38 AM
To: [email-masked]
Subject: Mode Property for a Termination

Hi Lists,

I have a query related to the call flow (Appendix A section A.1.2 step 12)
shown in the H.248 document. Why is the mode of the termination A4444 not
set to sendonly? Since the default state is inactive, then how will the
caller hear the RBT applied by the terminating exchange (if mode!=sendonly)?
Also mode in step 3 is set to send/recv. Why is that so? We do not need to
set mode now. Let it be inactive and change mode only in step 12 to sendonly
TIA
Sarju

---

From: "Paul W. Roder" <[email-masked]>
Date: Wed, 2 May 2001 16:09:43 -0400

(Note: In North American PSTNs today, the ringback signal is typically generated
by the called switch instead of the called switch for these reasons.)
                                   ^^^^^^^^^^^^^^^^^^   calling switch, right?

Right you are.  I should have been more careful in my typing - and I should have
 proofread that earlier message before I posted it to the list!

Thanks,

Paul Roder
Telcordia Technologies