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

From: "Paul W. Roder" <[email-masked]>
Date: Tue, 1 May 2001 13:51:57 -0400

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: Al Varney <[email-masked]>
Date: Wed, 02 May 2001 14:23:36 -0500

At 13:51 05/01/2001 -0400, Paul W. Roder wrote:

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

I believe the official name in ITU-T is "Ringing
Tone", with a footnote that the term "ringback" is a
common synonym in the USA.  Ringback was a term used in access
technologies (PABXs, modems) and it became more official when ISDN (also
an access technology) adopted the term.  Telcordia uses
"audible ring tone" in their early Bell-System-sourced
documentation when describing the tone (see SR-2275).  In the Bell
System, "ringbank" was a means of alerting the originating
switchboard operator from a terminating switchboard, and later for E911
operators attempts to re-ring a dropped caller.  The common terms in
ESS/Cross-bar were "ringing" (for the called-party signal) and
"audible ringing" (for the calling-party tone). -- End of
history.

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.

I've noted these reasons in a largely-ignored ITU-T
contribution last year, where a key sentence read:

The PSTN does not, in general, provide a reliable out-of-band indication
of

when Alerting of the called party is occurring.

Absent such an indicator, calls TO the PSTN
have to support your "terminating ring" model, or they are just
guessing the called party is being alerted.  The contribution also
indicated that voice-over-packet networks are responsible for GENERATING
Ring Tone and cutting through an audio path to an incoming PSTN network
when they are the terminating network (that is, the calling PSTN will NOT
be generating that tone itself).  In many cases, call failure
announcements must also come from the terminating network (without Answer
being signaled).

The SIP folks seem to have finally realized this -- see
Section 4 (about page 96) of:

<draft-ietf-sip-call-flows-04.txt>

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

Rest assured that this the case in every country's
PSTN.  Even in the case of bandwidth-starved cellular networks, an
originating mobile caller always gets a reverse audio path over which
he/she can hear the Ringing Tone (or whatever) supplied by a PSTN
terminating network.  If supplying Ring Tone at the calling terminal
were possible, you'd think it would be done in cellular networks.
Why those bandwidth-rich packet networks want to make things so
complicated has always puzzled me....

[N.B.:  I realize some vendors of mobile equipment are
working on standards for doing calling-terminal Ring Tone (even
country-specific tones).  It can work for called-parties that are
KNOWN to correctly indicate when the called party is being alerted, such
as another 'modern' mobile network not interconnected by the PSTN.
But it will be a long time before it will work for every called
party.]

Al Varney - Lucent Technologies, but just my opinion

---

From: "Vance Shipley" <[email-masked]>
Date: Wed, 2 May 2001 17:00:36 -0400

Al Varney writes:
}
}   [N.B.:  I realize some vendors of mobile equipment are working on 
} standards for doing calling-terminal Ring Tone (even country-specific
} tones).  It can work for called-parties that are KNOWN to correctly 
} indicate when the called party is being alerted, such as another 
} 'modern' mobile network not interconnected by the PSTN.  But it will 
} be a long time before it will work for every called party.]

Isn't this written into both ISUP and Q.931?  

In ISUP the Backward Call Indicators tell whether the call is end-to-end
ISUP and whether the terminating access is ISDN.  They also tell when 
interworking has been encountered (i.e. inband signaling).

Is it reasonable to assume that calling-terminal Ring Tone is possible 
when an end-to-end ISUP connection exists?

	-Vance

---

From: Al Varney <[email-masked]>
Date: Thu, 03 May 2001 23:10:05 -0500

>Isn't this written into both ISUP and Q.931?

    Yes, but the indication is there as friendly advice for display 
purposes (in my opinion).
ISUP has several sections called "Completion of Transmission Path" -- are 
you going to ignore that part of ISUP and rely only on the ACM/CallProgress 
message content? :)  Look at Q.764, section 2.1.2.1 d), for example.

    Even with both ISUP and Q.931 together, the terminating switch is 
REQUIRED to transmit back Ring Tone (Q.699/T1.609) even to an originating 
Q.931 caller.  Switches are allowed to bridge in announcements/tones at any 
time prior to sending back Answer (look at some of the INAP 
interactions).  They are allowed to change their minds even after properly 
indicating an alerting situation via ACM (for example, a problem with the 
access interface or POTS line can be detected AFTER ringing begins -- power 
cross tests can fail, ring pre-trip can occur, etc.).  These rare 
situations aren't easy to cover in standards.

    Even if all the terminating-access stuff worked in a way that permitted 
a well-educated guess at status, there are cases where maintenance/overload 
controls can force the injection of an internal announcement without Answer 
-- and it's ISUP-all-the-way, right?  (These should not have "subscriber 
free", I admit.)

>when an end-to-end ISUP connection exists?

    It may be reasonable -- but my field experience says switches RELY on 
the knowledge that, no matter what, there is a reverse audio path over 
which they can inform the caller of call progress (or lack thereof).  I 
know of no testing anywhere that assures every switch implementation of SS7 
will NEVER send non-Ring-tone audio after returning an ACM indicating 
ISUP-all-the-way and "subscriber free".  In fact, Q.764 section 2.1.4.1 
makes it pretty plain that those indications are sent after all called 
party digits have been received and the subscriber is determined to be 
free.  The exchange is not required to assure that the access network (such 
as GR-303/V5.2) is actually alerting the subscriber before returning ACM.

---
    I'll reverse the argument -- show me a circuit-switching standard that 
indicates the circumstances where a calling terminal must provide Ring 
Tone, because the audio path is delayed until answer.  Or even one that 
doesn't provide a reverse audio path for voice calls.

    As I've also mentioned, if this were easily done, why in the world 
don't mobile networks do so today?  Wouldn't it allow them to increase 
number of call attempts per cell site?  And why this concept so desirable 
in a packet network??